Many of the well-known HA technologies included in SQL Server, such as failover clustering and log shipping, are very valuable but somewhat cumbersome to configure and use. Also, in many cases, they solve only half of the problem for many applications—namely, failing over the database server. This leaves the application developer in a lurch, since all applications must be programmed with special code to failover the application to a new database server in the case of a failure in the original database server.
With database mirroring, SQL Server provides both database availability and application availability through the SQL Native Access Client (SNAC) stack, which understands and can work with database mirrors.
In the simplest deployment of database mirroring, there are two major server-side components: the principal server instance (principal) and the mirror server instance (mirror). The principal, as the name implies, contains the principal database. This is the database where you will perform your transactions.
The basic idea behind database mirroring is that synchronized versions of the database are maintained on the principal and mirror. If the principal database (or the principal itself!) becomes unavailable, then the client application will smoothly switch over to the mirror database, and operation (from the users’ point of view) will continue as normal.
So, a client interacts with the principal and submits a transaction. The principal writes the requested change to the principal transaction log and automatically transfers the information describing the transaction over to the mirror, where it is written to the mirror transaction log. The mirror then sends an acknowledgment to the principal. The mirror continuously uses the remote transaction log to “replicate” changes made to the principal database to the mirror database. With SQL Server 2008, a good amount of focus has been placed on the performance of handling these log records, and the following enhancements have been made:
• The data stream between the two partners is compressed. Note that SQL Server will compress the data stream between partners only when a 12.5 percent compression ratio can be achieved.
• SQL Server adds records to the mirror log asynchronously, while at the same time processing records from the log on disk.
• SQL Server has improved its efficiency around the buffers used to queue up log records when sending them to the mirror.
• When a failover occurs, SQL Server has improved the undo/redo process for transactions on the mirror (which was the principal before failure) that may not have been commited. SQL Server sends page hints to the principal early in the undo process, so that the principal can cache the pages into the send queue for the mirror.
Database mirroring runs in-process in SQL Server. Unlike replication, which is a log reader, database mirroring sends the log buffers stored in memory to the mirror before writing them to disk.
Sometimes corruption occurs in the log files because of disk errors, failures, or other issues. With database mirroring, if the mirror is keeping up with the principal, you can avoid some of these disk-based corruptions. One caveat is that if the mirror gets behind for some reason, such as being suspended, or if you have a failover and the other server comes back online after a period of time, the principal will need to go to disk to get the older log blocks, so hardening your disks and making sure they are reliable is a must with database mirroring.
Source of Information : Apress Accelerated SQL Server 2008
With database mirroring, SQL Server provides both database availability and application availability through the SQL Native Access Client (SNAC) stack, which understands and can work with database mirrors.
In the simplest deployment of database mirroring, there are two major server-side components: the principal server instance (principal) and the mirror server instance (mirror). The principal, as the name implies, contains the principal database. This is the database where you will perform your transactions.
The basic idea behind database mirroring is that synchronized versions of the database are maintained on the principal and mirror. If the principal database (or the principal itself!) becomes unavailable, then the client application will smoothly switch over to the mirror database, and operation (from the users’ point of view) will continue as normal.
So, a client interacts with the principal and submits a transaction. The principal writes the requested change to the principal transaction log and automatically transfers the information describing the transaction over to the mirror, where it is written to the mirror transaction log. The mirror then sends an acknowledgment to the principal. The mirror continuously uses the remote transaction log to “replicate” changes made to the principal database to the mirror database. With SQL Server 2008, a good amount of focus has been placed on the performance of handling these log records, and the following enhancements have been made:
• The data stream between the two partners is compressed. Note that SQL Server will compress the data stream between partners only when a 12.5 percent compression ratio can be achieved.
• SQL Server adds records to the mirror log asynchronously, while at the same time processing records from the log on disk.
• SQL Server has improved its efficiency around the buffers used to queue up log records when sending them to the mirror.
• When a failover occurs, SQL Server has improved the undo/redo process for transactions on the mirror (which was the principal before failure) that may not have been commited. SQL Server sends page hints to the principal early in the undo process, so that the principal can cache the pages into the send queue for the mirror.
Database mirroring runs in-process in SQL Server. Unlike replication, which is a log reader, database mirroring sends the log buffers stored in memory to the mirror before writing them to disk.
Sometimes corruption occurs in the log files because of disk errors, failures, or other issues. With database mirroring, if the mirror is keeping up with the principal, you can avoid some of these disk-based corruptions. One caveat is that if the mirror gets behind for some reason, such as being suspended, or if you have a failover and the other server comes back online after a period of time, the principal will need to go to disk to get the older log blocks, so hardening your disks and making sure they are reliable is a must with database mirroring.
Source of Information : Apress Accelerated SQL Server 2008
|
|
0 comments
Post a Comment