The following requirements apply to a SQL Database mirroring environment.
Examining Supported SQL Server Editions
SharePoint 2010 supports SQL
Server 2005, SQL Server 2008, and SQL Server 2008 R2. However, if
planning for database mirroring, it is strongly recommended to deploy a
version of SQL Server 2008 or SQL Server 2008 R2 to take advantage of
the core performance enhancements for database mirroring. One of these
major enhancements includes the ability to compress the stream of log
records from the principal server to the mirror server, resulting in a
sizable performance increase.
Table 1 lists the available database mirroring features within the supported versions of SQL Server 2005 and SQL Server 2008.
Table 1. Available Database Mirroring Features in SQL Server 2005 and SQL Server 2008
| Database Mirroring Feature | Enterprise Edition | Standard Edition | Workgroup Edition | Express Edition |
|---|
| Partner | Yes | Yes | No | No |
| Mirror | Yes | Yes | No | No |
| Witness | Yes | Yes | Yes | Yes |
| Synchronous mode | Yes | Yes | No | No |
| Asynchronous mode | Yes | No | No | No |
Caution
Although the witness server can
run Workgroup or Express edition of SQL Server, both the principal and
mirror servers must be running the same version of SQL Server. To ensure
proper business continuity, it is also recommended to have both the
principal and mirror servers running on similar hardware, if not
identical.
Considering Security Requirements
There
are two types of authentication for a database mirroring session:
Windows Authentication (NTLM or Kerberos) or certificates. After a
database mirroring session is initialized, the principal server sends a
load of transaction logs to the mirror server using TCP. In addition to
transporting log files between the two partners in a database mirroring
session, TCP is used by the witness server to monitor the state of the
two partners and determine when an automatic failover is necessary. In
fact, all communication between the principal server, the mirror server,
and the witness server (if available) is done through TCP over a
specified port on each server.
Examining Supported Databases
Listed here are the services
that do not support database mirroring, simply because the data
associated with these services do not reside in a database. In other
words, they are not needed for a restore: No information is stored or
needed for these services because they are stateless and can simply
start up and restart anytime without the need to store any data.
Visio Graphics Service
Access Services
Excel Services
Word Viewing Service
PowerPoint Service
State Service
Considering Performance and Scalability
With the increased number of
configuration and service databases in SharePoint 2010, it is
recommended that administrators thoroughly test the hardware
capabilities of their SQL servers for performance and scalability issues
when creating database mirroring sessions. Although Microsoft has
stated that the practical maximum number of mirrored databases should
not exceed 50, this number will vary depending on the following factors:
Network latency—
It is recommended that network latency between the principal server and
mirror server not exceed 1ms. This applies to synchronous mirroring
only.
Network bandwidth—
It is recommended that the network bandwidth between the principal
server and mirror server be at 1Gb per second and less than 1ms of
latency for synchronous mirroring. Asynchronous mirroring does not have
these same requirements, but does require sufficient bandwidth to handle
the flow of data from principal to mirror.
Memory—
The amount of memory on both the principal server and mirror server
should follow the hardware recommendations for deploying a SharePoint
2010 farm.
Processing power—
Two threads are created for each database mirroring session; therefore,
sufficient processing power is necessary on both the principal and
mirror server to handle each database mirroring session without severely
effecting performance.
Disk I/O—
Because database mirroring involves writing potentially large amounts
of logs to disk, it is recommended that disk I/O is optimized for faster
disk access.
