If you are using database mirroring to
improve your availability, you can also create a database snapshot
against this mirrored database and expose the snapshot to your
reporting users. Doing so further enhances the overall database
availability to all end users (transactional
and reporting users). In addition, it serves to isolate the reporting
users from the transactional users. The reporting users are connected
to the mirror server’s version of the database (via a database snapshot
of the mirrored database), and their reporting queries do not impact
the principal server in any way. Remember that the mirrored database is
not usable for any access whatsoever (it is in constant restore mode).
SQL Server allows a snapshot to be created against it .
As mentioned previously, the only real issues arise when the principal
server fails over to the mirror database. When the mirror server takes
over for the principal, the database snapshot terminates its reporting
user connections. The reporting users only need to reconnect to pick up
where they left off. However, you now have both transactional and
reporting users using the same database server instance, and
performance of all is affected.
A possible solution to this situation would be to
automatically (or manually) drop the database snapshot on the mirror
server if it becomes the principal and create a new snapshot on the old
principal server if it is available (it is now the mirror). You then
just point all your reporting users to this new database snapshot. This
process can be handled fairly easily in an application server layer.
This is basically a reciprocal principal/mirror reporting configuration
approach that always tries to get the database snapshot that is used
for reporting to be on the server that is the mirror server. You would
never really want to have active database snapshots on both the
principal server and mirror server at the same time.
Reciprocal Principal/Mirror Reporting Configuration
The following steps outline the method to create the
snapshot on the mirror, drop it when the mirror becomes the principal,
and create a new snapshot against the old principal (now the mirror):
1. | Create the database snapshot on a mirrored database server for reporting on the mirror server (REM12374333\SQL08DE02):
Use [master]
go
CREATE DATABASE SNAP_AdventureWorks_REPORTING
ON ( NAME = AdventureWorks_Data, FILENAME= 'C:\Program Files\
Microsoft SQL Server\MSSQL10.SQL08DE02\MSSQL\DATA\
SNAP_AdventureWorks_data_REPORTING.snap')
AS SNAPSHOT OF AdventureWorks
Go
As you can see in Figure 1, this would be the live configuration of the principal server (REM12374333\SQL08DE01), the mirror server (REM12374333\SQL08DE02), and the reporting database snapshot (SNAP_AdventureWorks_REPORTING), as shown from SQL Server Management Studio.
If the principal fails over to the mirror, you would drop the database
snapshot that is currently created off that database and create a new
one on the old principal (now the mirror), as shown in the following
steps.
|
2. | Drop the reporting database snapshot on the new principal server (the principal is now REM12374333\SQL08DE02):
Use [master]
go
DROP DATABASE SNAP_AdventureWorks_REPORTING
go
|
3. | Create the new reporting database snapshot on the new mirrored database server (the mirror is now REM12374333\SQL08DE01):
Use [master]
go
CREATE DATABASE SNAP_AdventureWorks_REPORTING
ON ( NAME = AdventureWorks_Data, FILENAME= 'C:\Program Files\
Microsoft SQL Server\ MSSQL10.SQL08DE01\MSSQL\DATA\
SNAP_AdventureWorks_data_REPORTING.snap')
AS SNAPSHOT OF AdventureWorks
Go
|
That’s it. You now have your reporting
users completely isolated away from your principal server (and the
transactional users) again. Life can return to normal very quickly.
