From the SSMS, you can easily fail over from the
principal to the mirror server instance (and back again) by using the
Failover button on the Database Properties Mirroring page, as shown in Figure 1.
You must test this
failover at some point to guarantee that it works. When you click the
Failover button for this database mirroring configuration, you are
prompted to continue with the failover by clicking Yes or No, as in the
dialog shown in Figure 2.
Remember that clicking Yes
closes all connections to the principal server instance that are
currently connected to this database. Later, we show you how to make
your clients aware of both the principal and mirror server instances so
that they can just pick up and run against either server instance, by
design.
Now, if you look at the Database Properties Mirroring page (see Figure 3),
you see that the principal and mirror listener port values have
switched: the principal instance is now port value 1440, and the mirror
instance is port value 1430. The server instances have completely
switched their roles. You must now go to the server instance playing the
principal role to fail over back to the original operating mode. If you
try to open the current mirror server instance database, you get an
error stating that you cannot access this database because it is in
restore mode.
You can also manually run an ALTER DATABASE command to force failover to the mirrored server as follows:
ALTER DATABASE AdventureWorks set partner FAILOVER;
This command has the same effect as using SSMS or even shutting down the principal SQL Server instance service.
One last note with
mirroring a database is that you cannot bring the principal offline as
you would be able to do in an unmirrored configuration.
