Maximizing Availability of a Scalable Shared Database
We recommend using two, alternate sets of reporting volumes. This allows you to maximize availability of reporting data by overlapping two update cycles. While one set of reporting volumes is mounted to the reporting servers, you can build an up-to-date version of the reporting database on the alternate set of volumes. After completing the build phase or refresh phase for the fresh reporting database, you can overlap the attach and detach phases of the two sets of volumes.
To overlap the detach phase of the stale reporting database with the attach phase of the fresh reporting database, on each reporting server:
- Begin the attach phase for the fresh database, by mounting the alternative set of volumes onto the reporting server*.*
- Perform the whole detach phase for the stale database by detaching it, which makes the scalable shared database unavailable on this reporting server, and dismounting the corresponding reporting volume or volumes.
- Complete the attach phase for the fresh version by attaching the database to the server instance, which makes it available as a scalable shared database.
The overlapped attach and detach phases can be completed on one server at a time, or each step can be performed on every server before you continue to the next step. The best approach depends on your business requirements.
- If you want your reporting database to return identical results to clients, you need to synchronize the updates by detaching the old copy from all the server instances before attaching the new copy to any of them. In this case, start the attach phase for the fresh database on all the servers, then complete the detach phase on all the servers, and, finally, attach the database on each of the reporting server as quickly as possible. For more information, see Performing a Synchronized Update of a Scalable Shared Database.
- If you can tolerate clients getting different results on different server instances, you can perform a rolling update of the reporting database, by completing the overlapping attach and detach phases on one reporting server at a time. For more information, see Performing a Rolling Update of a Scalable Shared Database.
See Also
Concepts
Overview of Scalable Shared Databases
Ensuring a Correct Environment for a Scalable Shared Database
Building or Refreshing a Reporting Database
Attaching a Reporting Database as a Scalable Shared Database
Detaching a Scalable Shared Database
Help and Information
Getting SQL Server 2005 Assistance
Change History
| Release | History |
|---|---|
5 December 2005 |
|