With SAP application the process of utilizing database mirroring entails the design to be well-planned design and few changes in some SAP profiles for making the SAP applications run smoothly along with database mirroring.
This tutorial explains:
- Basic modes of database mirroring:
- Asynchronous Mirroring
- Synchronous Mirroring
- SAP setup and configuration for database mirroring
- Monitoring database mirroring
- Considerations for deploying database mirroring
Database mirroring is a new feature which has been made available for production use along with SQL Server 2005 Service Pack 1 (SP1).
Database mirroring also makes sure that a transaction-consistent, hot standby SAP database is available at a rapid pace in case the database fails.
The principle of database mirroring is transferring the transaction log entries from the 'principal' server directly to the 'mirror' server each time those transaction log records are hardened in the principal server’s transaction log file.
During a comparison of the features of the different configurations of database mirroring with log shipping and MSCS functionality displays the following:
Similar, to log shipping, database mirroring also provides two disconnected database images. Quite unlike log shipping, the user can set up database mirroring for not losing the committed transactions.
Database mirroring delivers dependent on the setup an automatic failover for applications namely SAP ABAP application server, just like MSCS.
Database mirroring also provides a database image close to production which comes with anon-measurable performance impact.
One major restriction of database mirroring is that only one destination can be targeted at a given time. The granularity of mirroring is a generally a single database. However more than one databases of one SQL Server instance can ideally be mirrored.
System administrators can manually force a failover. suspending active mirroring for performing maintenance on one of the servers is also possible. The transaction log records are collected in the transaction log of the active database, once the database mirroring has been suspended. These transaction records are not deleted by these log backups. This means that during the time mirroring remains suspended it must be limited. After database mirroring has been resumed, it goes into synchronization.
In this phase all changes are moved over to the mirror server along with the current changes which queue up at the end of the data which has to be synchronized. This relates to the volume of data which is altered during the suspended period and the network bandwidth influence the time it takes to synchronize.