Database Mirroring
Lesson 1: Overview of Database Mirroring
1. Database Mirroring Roles
(1) sample
(2) sample
2. Principal Role
(1) Sample
(2) sample
3. Mirror Role
4. Witness Server
5. Database Mirroring Endpoints
6. Operating Modes
All of above please refer the Chapter 5. SQL Server Endpoint
7. Caching
(1) Database mirroring, however, does not have caching issues. In addition to sending transactions to the mirror, Database Mirroring also performs periodic metadata transfers. The purpose of these metadata transfers is to cause the mirror to read pages into data cache. This purpose maintains the cache on the mirror in a “semihot” state.
(2) The cache on the mirror does not reflect the exact contents of the cache on the principal, but it does contain most of the pages. Thus, when the database mirroring session fails over, SQL Server does not have to completely rebuild the cache and application do not experience as larger a performance impacts as they do if you use the other availability technologies.
8. Transparent Client Redirect
(1) One of the most difficult processes of failing over when using either log shipping or replication involves application connections. Application must be redirected to the secondary server to continue processing. Database mirroring can avoid this necessity under a very particular configuration.
(2) MDAC, which ships with VS2005 contains a Database Mirroring-related feature within the connection objet call Transparent Client Redirect. When a client makes a connection to a principal, the connection object caches the principal as well as the mirror. This caching is transparent to the application, and developers do not need to write any code to implement this functionality.
9. Database Snapshots (Enterprise Edition only)
(1) The mirror database within a Database Mirroring session is in a constantly revering state and is inaccessible to users. However, you can create a database snapshot against a mirror database that provides point-in-time, read-only access
(2) TSQL.
CREATE DATABASE DB_Mirror_SnapShot ON
(
NAME = DB_Mirror_SnapShot_Data,
FILENAME='C:\TEST\DB_Mirror_SnapShot_Data.ds'
)
AS SNAPSHOT OF DB_Mirror_Sample
(3) SSMS
10. Practice: Establishing Endpoint for Database Mirroring
Lesson 2: Initializing of Database Mirroring
1. Recovery Model : Full recovery model
2. Backup and Restore
3. Copy System Objects
4. Practice: Configuring Database Mirroring
See the chapter 5
Lesson 3: Designing Failover and Failback Strategies
1. Designing Mirroring Session Failover
(1) Database mirroring session occur between databases. As such, a mirroring session does not account for cross-database transactions or any server objects external to the database being mirrored.
(2) Applications submitting transactions to multiple databases in a single instance are a concern only when data in one database in dependent upon data in another database.
(3) Migrating login and linked servers is the most important step you must take to ensure that applications continue to function following a failover.
(4) If your security access is denied using Windows accounts, no additional work is required following a failover, while SQL Server logins, you might need to perform additional steps following a failover.
(5) The other objects that you need to re-create on the mirror to ensure complete and proper failover for applications are SQL Server Agent jobs, SSIS packages, and customer error messages.
2. Designing Mirroring Session Failback
(1) Failback After Graceful Failover
① When the principal fails, the mirror is promoted, either manually or automatically. After the failed principal is brought back online, it is automatically demoted to a mirror. The automatic demotion of the principal to a mirror prevents applications from being able to connect to a database in an older state.
② Because Database Mirroring maintains each database within the session in lock-step with each other, a path is present to incrementally resynchronize the failed partner. Not only does a failed principal automatically demote to a mirror but the transaction flow also automatically reverses direction to bring the failed partner back up to data with all transaction.
③ If the event that a failed partner has been offline for a period time, transaction log backup could have been taken that would remove records from the transaction log. To make incremental resynchronization as smooth as possible, refer the following steps:
Pause the transaction log backups on the principal.
Bring the failed partner back online
Restore all transaction log backups taken from the time of the failure to the present, ensuring that you always specify the NONRECOVERY option
After the principal starts sending transaction to the mirror, restart the transaction log backups on the principal.
When the principal and mirror are completely resynchronized, gracefully fail over the mirroring session and reconnect application to the principal.
(2) Failback After Forced Failover
① A forced failover occurs when the principal while the mirroring session is in an unsynchronized state, causing transactions that were committed on the principal to become lost. This situation is possible only for the high performance and high protection operating modes.
② Failover for high performance and high protection operating modes is manual.
ALTER DATABASE DB_SAMPLE_MIRROR SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
③As is readily apparent from the ALTER DATABASE option, a forcible failover can cause transactions to be lost. This situation can create a gap in the LSN sequence between the two partners in the mirroring session.
ALTER DATABASE DB_SAMPLE_MIRROR SET PARTNER OFF
3. Practice: Failover a Database Mirroring Session
