Question

I have a web app that is used on multiple continents. The underlying transaction DB is locking up when large reports are run. I want to:

  1. make a realtime of the SQL Server 2005 database to a reports DB
  2. direct all reporting to the reports DB

In theory this will prevent transaction locking for inserts and updates. It is OK if the reports DB gets locked temporarily as long as the transactions continue. The reports DB can receive the new transactions when it is under a lighter load. What is the best way to maintain a near realtime copy of the transaction DB? Should I use replication, mirroring or a combination of the two? What general guidelines I should follow?

Thanks!

Was it helpful?

Solution

Use Sql Server replication for implementing this kind of architecture. E.g. replicate data from your main db server to the reporting server. It's not quite real time (few systems are) but can be very close.

There are several flavors with Sql Server replication and you'll probably want server-to-server. Also see this article about data warehousing and reporting. It describes the exact scenario that you're up against and your goals:

By design, transactional replication addresses the principal requirements for this scenario:

  • Transactional consistency
  • Low latency
  • High Throughput
  • Minimal overhead

OTHER TIPS

Mirroring = whole DB, replication is a subset usually based on what you "publish"

In this case, I'd use replication if you need near real-time. I'd consider mirroring if reporting could lag a few minutes or reports should be "static" for a period of time.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top