Disaster recovery for database servers
This topic describes a disaster-recovery solution for BMC Server Automation database servers. The following databases are addressed:
Oracle Database 10g and 11g
For disaster recovery for enterprise-level databases, Oracle recommends their Data Guard software. This software maintains a standby database at a secondary site. It offers a number of failover options, including fully automatic failover to the standby database after loss of the primary database.
Oracle Data Guard uses Oracle internal features to replicate the minimum data set necessary while verifying against data corruption. This is the main advantage to using Oracle Data Guard over other replication technologies. Active Data Guard, available in 11g, offers an additional advantage by making the replicated instance open for reads. Thus it provides the capability to offload major housekeeping tasks and reporting from the primary instance.
Implementing a standby database using Oracle Data Guard is beyond the scope of this documentation. However, BMC makes the following recommendations and assumptions about the secondary site in a Data Guard implementation:
- You implement an Oracle Data Guard standby database node by following the best practices recommended by Oracle.
- Regarding requirements about performance and possible data loss, implement the synchronous (0-data loss) versus asynchronous mode of replication.
- You make the standby database-specific virtual IP addresses (VIPs) and the associated TCP network port used to access the database available to all database-dependent components in the BMC architecture (that is, to the Application Servers, provisioning servers, and report servers).
Microsoft SQL Server 2005 and 2008
In SQL Server database environments, SQL Server database mirroring is the recommended technology for disaster recovery. Database mirroring is primarily a software solution that increases database availability by supporting almost instantaneous failover after a disaster event.
Database mirroring maintains a single standby database (the mirror database) for a corresponding production database (the principal database). Database mirroring runs with either synchronous operation in high-safety mode or asynchronous operation in high-performance mode.
- In high-performance mode, the transactions commit without waiting for the mirror server to write the log to disk, which maximizes performance.
- In high-safety mode, a committed transaction is committed on both partners, but at the risk of increased transaction latency.
Implementing a mirrored database is beyond the scope of this documentation. However, BMC makes the following recommendations and assumptions about the secondary site:
- You configure the mirrored instance according to Microsoft best practices. For information, see the following Microsoft web page: http://msdn.microsoft.com/en-us/library/bb934127.aspx.
- You choose the replication model (high-performance versus high-safety mode) by carefully considering implications for performance and possible data loss.
- You make the mirrored database instance and port available to all database-dependent components in the BMC architecture (that is, to the Application Servers, provisioning servers, and report servers).