Clients using a connection string identifying the primary and mirror database will automatically failover to the mirror when the primary database is confirmed to have failed. This takes a little bit of time because you don’t want to failover when a short interruption occurs. There is a lot more to configuring a database mirror outside the scope of this summary.
While database mirroring sounds very similar to database clustering it is slightly different Database clustering duplicates all of the databases on an instance of SQL Server, or it could be said that it mirrors an instance of SQL Server. Database mirroring mirrors each database separately and must be configured independently for each database. Also, with mirroring there is no shared disk requiring duplicate disk space availability. This costs twice as much for disk, but provides more redundancy at the disk level. For smaller databases mirroring may make more sense.
Just because you are using a mirror implementation does not mean you cannot use a SAN. However, if you use a SAN for your disk storage, each database must have separate disk allocations, sharing nothing. Generally a SAN will have a lot of redundancy built in, so putting everything on the SAN for a mirrored installation is still quite well protected.
Monday we’ll look at Always On failover released in SQL Server 2012. If space allows we’ll also look at some other third party failover techniques.
Cheers,
Ben