asked on

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?

chapmandew

You can use transactional replication to setup a near real time reporting environment....

Bruce McConnell

ASKER

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

chapmandew

Ummm...what restrictions are you talking about?

Bruce McConnell

ASKER

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

ASKER CERTIFIED SOLUTION

chapmandew

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial