Some Notes about Mirroring in SQL Server 2008

Some important items to note about database mirroring:

• The principal database must be in the FULL recovery model. Log records that result from bulk-logged operations cannot be sent to the mirror database
• The mirror database must be initialized from a restore of the principal database with NORECOVERY, followed by restores in sequence of principal transaction log backups
• The mirror database must have the same name as the principal database
• Because the mirror database is in a recovering state, it cannot be accessed directly. You can create database snapshots on the mirror to indirectly read the mirror database at a point in time. (See 'Database Mirroring and Database Snapshots' )

- It's much easier to set up a mirrored configuration than using other high-availability technologies, such as failover clustering
- The disadvantage of mirroring working at the DB level is that system DBs (master, model, tempdb, and msdb) are not mirrored and, in fact, can't be mirrored. Therefore logins, SQL Server Agent Jobs, and other security configurations aren't identical between the two servers. This means there is a bit more administrative overhead to ensure that things function on both servers the same. However, there is more flexibility in the use of both systems
- DB mirroring involves a principal server and a mirror server. An optional witness server can also be involved. The witness server helps decide when an automatic failover can occur, under very specific circumstances
- The principal and mirror roles for each DB swap when a failover occurs
- There are 2 types of mirroring: synchronous and asynchronous
- In synchronous mirroring (AKA full transactional safety), a transaction on the principal database isn't considered to be committed until a copy of the transaction log record for that transaction is physically copied over the network to the mirror server. Therefore, no data loss can be guaranteed in a synchronous configuration
- Asynchronous configuration is AKA 'having transactional safety turned off' -> the log records are sent to the mirror server but aren't guaranteed to be in sync. So, some data loss may occur if there is a failure on the principal system before the committed transaction log records are copied to the mirror server