[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 543
  • Last Modified:

Alternatives to offload Reporting Services workload from main Database

We are running our SQL2005 databases on an HP EVA SAN and are licensed for local mirroringclone, snapshotting and snapcloning. We also have DoubleTake for disaster recovery to a second SAN. We are in the process of implementing reporting services but do not want to drag down the preformance of our production databases with long running queries. We would like to use SQL reporting services for near-real-time reporting but that can include multiple batched reports, so we want to have a second server with SSRS and a near-real-time copy on which we can run the reports. In looking at the various SAN alternatives for creating copies and at double take it appears the destination cannot really be used for reporting unless it is a snapshort (point in time) followed by bringing up the destination SQL instance, as opposed to being a mirror (up to date). Same issue for DoubleTake (must snapshot and bring up instance). SQL Database mirroring does not allow access to the destination database because it is in constant recovery mode. The only thing I can see that might work is basic SQL transactional replication. Anyone else have any possible solutions?
0
dennis_boruck
Asked:
dennis_boruck
  • 3
  • 2
1 Solution
 
chapmandewCommented:
You can use transactional replication to setup a near real time reporting environment....
0
 
dennis_boruckAuthor Commented:
I proposed alternative in my question. I had hoped there was some other alternative, but if not I will have to live with it. Let me see if anyone else has any other possible ideas because transactional replication has a number of restrictions associated with it that I would prefer to avoid.

Thanks.

Dennis
0
 
chapmandewCommented:
Ummm...what restrictions are you talking about?
0
 
dennis_boruckAuthor Commented:
It requires additional fields on the tables to insure uniqueness if there is no primary key (possibly transaction sets). Secondly, when a full snapshot must be propagated tables being snapped are locked, thus preventing writes on the live database on that table. Finally, there are certain kinds of schema changes that cannot be replicated but will cause the database to be re-snapped afterward. The SAN and double-take based solutions do not have these limitations, however their destination databases are not usable while mirroring either, so if we need a near-real-time database that can be used for reporting, I suspect we are stuck with transactional replication.

Have you created separate databases for reporting services using transactional replication?

Dennis
0
 
chapmandewCommented:
Yes, I've always created the publications at night on databases that have heavy loads.  If you don't have primary keys on your tables, then you may want to start thinking about meaningful ones to put on them before you transfer them....not sure if that is a limitation though.  Some schema changes are limited, but not many.  Its been a perfect solution for me over the years....if you do it right, its a great reporting solution.

>>Have you created separate databases for reporting services using transactional replication?

Not sure what you're asking.
0

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now