Monitoring a Mirrored Database Environment
After active mirroring has
started, you can monitor the complete mirrored topology in a few ways.
You can start by registering the database being mirrored to a new
facility within SSMS called Database Mirroring Monitor. Database
Mirroring Monitor allows you to monitor roles of the mirroring
partnership (that is, principal, mirror, and witness), see the history
of transactions flowing to the mirror server, see the status and speed
of this transaction flow, and set thresholds to alert you if failures or
other issues occur. In addition, you can administer the logins/service
accounts being used in the mirrored database topology.
Figure 15
shows how you launch the Database Mirroring Monitor from SSMS: you
right-click the principal database being mirrored, choose Tasks, and
then choose Launch Database Mirroring Monitor.
You must register the
database being mirrored. To do so, you select the principal or mirror
server instance and set the Register check box for the database.
Database Mirroring Monitor registers the database and both partner
server instances, as shown in Figure 16.
After the database is
registered, all partners and the witness server instances show up in the
Database Mirroring Monitor, as shown in Figure 17.
At a glance, you can see
which server is playing what role (principal or mirror) and whether each
partner has defined and is connecting to a witness server. In addition,
you can see the unsent log (in size), the un-restored log (in size),
when the oldest unsent transaction occurred, the amount of time it took
to send the transaction to the mirror server instance, the send rate
(KB/second), the current rate at which the transactions get restored
(KB/second), the mirror commit overhead (in milliseconds), the listener
port of the witness server instance, and the operating mode of the
mirroring (in this case, high safety with automatic
failover—synchronous).
Figure 18
shows the detailed transaction history for a particular part of the
mirroring flow (either the send out of the principal part or the restore
to the mirror part). You can click the appropriate partner to see all
transaction history details of the mirrored copy and restore process.
If you click the Warnings
tab of the Database Mirroring Monitor, you can set various thresholds
within the monitor to alert you when they have been reached (see Figure 19). Basically, you want to set thresholds that monitor the effectiveness of the mirroring operation.
If these key thresholds
are ever exceeded, you want to be notified that something is very wrong
and that failover may be in jeopardy. When a threshold is exceeded, an
event is logged to the Application event log. You can configure an alert
on this event by using SSMS or Microsoft Management Operations Manager
(MOM). The threshold levels depend on your own failover tolerance. Our
advice is to monitor the transaction and transfer rates for a peak
period and then set the thresholds to be 100% higher than that. For
example, if you see a peak mirror commit overhead value of 750
milliseconds, you should set the threshold to 1,500 milliseconds. This
should be within the tolerance for commit overhead in your organization.
Figure 20
shows how easy it is to administer the service accounts/login IDs being
used for database mirroring. You simply click an Edit button to change
or set the login account you want to use for database mirroring at each
instance in the mirroring topology.
From the Database
Properties Mirroring page, you can easily pause (and resume) database
mirroring if you suspect that there are issues related to the mirroring
operation. In addition, you can easily see what role each server
instance is playing.
Removing Mirroring
Very
likely, you will have to remove all traces of database mirroring from
each server instance of a database mirroring configuration at some
point. Doing so is actually pretty easy. Basically, you have to disable
mirroring of the principal, drop the mirror server’s database, and
remove all endpoints from each server instance. You can simply start
from the Database Properties page and the Mirroring option and do the
whole thing. Alternatively, you can do this through SQL scripts. Let’s
first use the Mirroring options. Looking at the options on Figure 21,
you simply choose to remove mirroring (from the principal server
instance). This is just a bit too easy to do—almost dangerous!
The mirroring process is
immediately disabled. When mirroring is disabled, you can drop the
database on the mirror server instance, remove the endpoints on each
server instance (that is, principal, mirror, and witness instances), and
be done—all through SSMS. This approach is straightforward.
If you’re removing
mirroring with SQL scripts, however, you need to break the mirroring
from the principal, remove the principal’s endpoint, drop the mirror
database and remove the mirror’s endpoint, and then drop the witness
server’s endpoint. At this point, all mirroring is removed. Follow along
as we remove the database mirroring configuration we just set up.
The ALTER DATABASE and DROP ENDPOINT SQL commands break mirroring on the principal and remove the endpoint:
ALTER DATABASE AdventureWorks set partner off
go
DROP ENDPOINT EndPoint4DBMirroring1430
go
From the mirror server instance (not the principal!), you run the DROP DATABASE and DROP ENDPOINT SQL commands, as follows:
DROP DATABASE AdventureWorks
go
DROP ENDPOINT EndPoint4DBMirroring1440
go
From the witness server instance, you remove the endpoint as follows:
DROP ENDPOINT EndPoint4DBMirroring1450
go
To verify that you have removed these endpoints from each server instance, you simply run the following SELECT statements:
select name,type_desc,port,ip_address from sys.tcp_endpoints
select name,role_desc,state_desc from sys.database_mirroring_endpoints
All references to the endpoints and roles are removed.
You can also take a peek at the SQL Server log entries being made as you remove database mirroring:
02/05/2009 13:06:42,spid55,Unknown,The Database
Mirroring protocol transport is disabled or not configured.
02/05/2009 13:06:40,spid55,Unknown,The Database Mirroring
protocol transport has stopped listening for connections.
02/05/2009 12:52:55,spid19s,Unknown,Database mirroring
connection error 4 'An error occurred while receiving
data: '64(The specified network name is no longer
available.)'.' for 'TCP:// REM1233..:1440'.
02/05/2009 12:52:55,spid19s,Unknown,Error: 1474
<c/> Severity: 16<c/> State: 1.
02/05/2009 12:52:55,spid19s,Unknown,Database mirroring
connection error 4 'An error occurred while
receiving data: '64(The specified network name is
no longer available.)'.' for 'TCP://REM1233..:1450'.
02/05/2009 12:52:55,spid19s,Unknown,Error: 1474
<c/> Severity: 16<c/> State: 1.
02/05/2009 12:51:14,spid21s,Unknown,Database mirroring
has been terminated for database 'AdventureWorks'.
These
are all informational messages only. No user action is required. As you
can see from these messages, you are now in a state of no database
mirroring. You have to completely build up database mirroring again if
you want to mirror the database again.
