Introduccin a Database Mirroring en

SQL Server
Volver a: [Database Mirroring en SQL Server 2005 y
SQL Server 2008]
Database Mirroring es una solucin alternativa de Alta Diponibilidad, nueva en SQL
Server 2005, que puede verse como la evolucin natural de Log Shipping (tecnologa
disponible en ediciones anteriores de SQL Server, basada en la entrega de Logs de
Transacciones sobre una copia de la base de datos en un servidor secundario en espera, es
decir, hacer RESTORE LOG WITH NORECOVERY a "tutti" ;-). As, existen varias
diferencias entre Database Mirroring y Log Shipping, por ejemplo, Log Shipping permite
funcionar en Modo de Recuperacin de Registro Masivo (Bulk-Logged) y en el Modo de
Recuperacin Completo, mientras que Database Mirroring slo puede funcionar en Modo
de Recuperacin Completo.
A diferencia de Log Shipping, Database Mirroring ofrece recuperacin automtica ante
fallos (automatic failover) sin necesidad de disponer de ninguna solucin hardware
especial ni propietaria, con lo cual, se muestra como una alternativa de bajo coste a las
soluciones basadas en Microsoft Cluster (o Server Clustering). Adems, para casos de
balanceo (failover), es posible desarrollar las aplicaciones cliente para que se reconecten automticamente a la base de datos activa (es decir, a la que acte como base
de datos principal), como se indica ms adelante en el captulo de Administracin y
Mantenimiento de Database Mirroring (ver la seccin Redireccin de Cliente:
ADO.NET / SQL Native Client automatic redirection).
Es importante tener en cuenta, que a da de hoy, en cualquier mediana o gran empresa
abundan las soluciones SAN (ej: almacenamiento HP EVA, redes y switches de fibra, etc.)
y los servidores Wintel con interfaces HBA (ej: servidores HP Blade, HP SuperDome, etc),
infraestructuras sobre las cuales es posible construir soluciones Microsoft Cluster de forma
sencilla y econmica (es decir, tomando como premisa la existencia de dicha
infraestructura, no es necesario ningn elemento adicional para montar un Microsoft
Cluster, por lo tanto, nos da igual montar SQL Server sobre Microsoft Cluster o un
Database Mirroring, desde el punto de vista de costes adicionales, al menos en principio).
Una ventaja de montar Database Mirroring en vez de Microsoft Cluster (o Server
Clustering), la podramos encontrar si tuviramos que ofrecer Alta Disponibilidad de base
de datos para un producto que no est soportado su funcionamiento con bases de datos en
Cluster. Por poner un ejemplo real, en una instalacin MOSS 2007 (Microsoft Office
SharePoint Server 2007) o Microsoft Office Sharepoint Portal Server 2003 no estn
soportados para ejecutarse sobre bases de datos SQL Server 2005 en Cluster Geogrficos,
conforme muestra el artculo de soporte KB946791, aunque s se tratan de aplicaciones

Cluster-Aware (es decir, s pueden montarse sobre Microsoft Cluster, siempre y cuando, no
exista replicacin del almacenamiento entre ubicaciones fsicamente separadas). En este
caso, la forma de ofrecer un entorno de Alta Disponibilidad de base de datos
geogrficamente disperso, pasa por utilizar Database Mirroring (pudiendo ubicar los
servidores miembros de la correspondiente sesin de Mirroring, en ubicaciones fsicamente
distantes).
La comunicacin entre los diferentes servidores SQL Server de una topologa Database
Mirroring, se realiza a travs de Extremos o Endpoints de SQL Server especficos para
Database Mirroring, un tipo de objeto de servidor nuevo en SQL Server 2005, que
permiten la creacin de caminos de comunicacin con Instancias de SQL Server. La ventaja
de la utilizacin de Extremos o Endpoints, es que permiten configurar sus requisitos de
Autenticacin y Cifrado, ofreciendo as un camino de comunicacin ms o menos seguro
(en funcin de las necesidades de cada caso). Por defecto, la creacin de Extremos o
Endpoints (CREATE ENDPOINT) para Database Mirroring a travs del Asistente incluido
en SQL Server 2005, implicar la creacin de Extremos o Endpoints con Autenticacin y
Cifrado.
Database Mirroring, al igual que Log Shipping, slo protege a nivel de base de datos (es
decir, slo las bases de datos de usuario) y no a nivel de Instancia, para lo cual sera
necesario implementar Server Clustering (y as proteger tambin las bases de datos del
sistema y dems elementos que forman una instancia de SQL Server).
Database Mirroring es una tecnologa de Alta Disponibilidad basada en un modo de
funcionamiento Activo / Pasivo. Es decir, mientras una Instancia realiza un papel de
Servidor Principal (Activo) para una base de datos en particular, la otra instancia realiza el
papel de Servidor Espejo o Secundario (Pasivo) para dicha base de datos. En consecuencia,
no ser posible el acceso a la copia de la base de datos del Servidor Espejo, pues en dicho
caso, se producir un error como el siguiente:
Msg 954, Level 14, State 1, Line 1
The database "GuilleSQL" cannot be opened. It is acting as a mirror database.
Sin embargo, aunque el funcionamiento de Database Mirroring es Activo/Pasivo, tanto el
servidor Principal como el servidor Espejo hospedan ambos una copia de la base de datos,
con la peculiaridad de que la base de datos del servidor que acta como Espejo no
podr ser accedida (slo estar accesible la base de datos Principal), pues estar en modo
Mirror / Restoring. Claro est que podemos encontrar un pequeo truco si deseamos
acceder a la base de datos Espejo (Mirror), pues es posible crear un Database Snapshot
sobre la base de datos en Mirror, y seguidamente consultar dicho Database Snapshot
(evidentemente, slo podremos consultar los datos conforme estaban en un punto en el
tiempo, no siendo posible modificar datos). Algo sorprendente (al menos, a mi me lo
pareci cuando lo descubr), pues de hecho, sobre una base de datos en modo Restoring no
es posible crear un Database Snapshot, pero sin embargo, sobre una base de datos en Mirror
s es posible (que al fin y al cabo, se est comportando de un modo muy parecido al de

Restoring, aplicando las transacciones del principal continuamente). Ms adelante en este

artculo, se incluye algn ejemplo de Database Snapshot sobre Database Mirroring.
Database Mirroring requiere que la base de datos que se desee proteger, est configurada
con el Modo de Recuperacin Completo (Full Recover Model), algo bastante evidente, al
tratarse de una tecnologa que basa su funcionamiento en el envo de transacciones de una
base de datos principal a una base de datos espejo o secundaria.
Database Mirroring slo est disponible en las ediciones SQL Server 2005 Enterprise
y Developer (actualizado 24/07/2009: en la Standard tambin), por lo tanto, no
podremos utilizar Database Mirroring en SQL Server 2005 Workgroup, ni Express. Sin
embargo, la Instancia que realice el papel de Servidor Testigo (Witness), puede ser de
cualquier edicin de SQL Server 2005, de tal modo, que sera posible ejecutar el Servidor
Testigo sobre un servidor SQL Server 2005 Express en una mquina separada de los
Servidores Principal y Espejo (ms adelante se detallan los distintos roles de una topologa
de Database Mirroring). Ms informacin:

Comparacin Caractersticas SQL Server 2005

Comparacin Caractersticas SQL Server 2008

Una instalacin basada en Database Mirroring requiere un mnimo de dos Instancias de

SQL Server 2005: una de las Instancias realizar el papel de Principal, mientras que la otra
Instancia realizar el papel de Secundaria o Espejo, mantenindose en espera (ojo, que es
concepto de Principal y Espejo es a nivel de base de datos y no de instancia, es decir, en
una instancia puede haber varias bases de datos en Principal, otras en Espejo, y otras sin
Mirroring). En consecuencia, la base de datos que se desea proteger deber ser copiada
desde el servidor Principal al servidor Espejo (con Backup y Restore, como se describe ms
adelante), teniendo en cuenta que la base de datos principal y espejo deben mantener el
mismo nombre. Como comentamos antes, es posible incorporar una tercera instancia a una
solucin de Database Mirroring, la cual realizar un papel de rbitro o testigo.
Resumiendo, los posibles papeles o roles que puede desempear una instancia de SQL
Server en una solucin de Database Mirroring son:

Servidor Principal. Mantiene la copia activa de la base de datos (base de datos

principal), a travs de la cual, se ofrece el servicio a los usuarios. Todas las
transacciones son enviadas al Servidor Espejo antes de aplicarlas en la base de datos
principal.
Servidor Espejo (Mirror). Mantiene una copia de la base de datos principal (base
de datos espejo o mirror database), y aplica todas las transacciones enviadas por el
Servidor Principal, manteniendo sincronizada la base de datos espejo.
Servidor Testigo (Witness). Se trata de un elemento opcional. No es obligatorio o
necesario implementar un Servidor Testigo (Witness) en una solucin de Database
Mirroring. Sin embargo, si deseamos que nuestra solucin de Database Mirroring
ofrezca recuperacin automtica ante fallos (automatic failover), entonces s ser
necesario implementar un Servidor Testigo (Witness Server), pues ste es quin
monitorizar los Servidores Principal y Espejo partcipes de una Sesin de Espejo

(Mirror Session) con el objetivo de asignar el papel de Principal al servidor Espejo

en caso de una cada de servicio o prdida del primero (es decir, en caso de cada
del Servidor Principal, se asignar el papel de Principal al Servidor Espejo,
mantenindose as el servicio). El trabajo realizado por el Servidor Testigo
(Witness) no es muy intenso, por lo cual, no requiere de grandes recursos, y adems,
un mismo servidor puede actuar como Servidor Testigo (Witness) para mltiples
sesiones de espejo, sin prdida de rendimiento.
Vuelvo a insistir en que dichos Roles son a nivel de Base de Datos. Es decir, un servidor
SRV_A puede actuar como principal para una base de datos BD_A, siendo un servidor
SRV_B quien acta como espejo (mirror) para dicha base de datos. Sin embargo, nada
impedira, que para una base de datos BD_B, sea SRV_B el principal y SRV_A el espejo
(mirror). Del mismo modo, para la BD_A se podra utilizar un servidor SRV_C como
Testigo (Witness), y para la BD_B se podra utilizar otro servidor SRV_D como Witness.
Claro, que todo esto tiene sentido desde un punto de vista didctico. En un entorno
empresarial, es muy probable que se disponga de un CPD principal y un CDP de reserva
(BDC), de tal modo que en el CPD principal se site un Servidor que acte como principal
para todas las bases de datos, mientras que en el CPD secundario se site un servidor que
acte como espejo (mirror) para todas las bases de datos, utilizando un nico servidor
adicional (en caso de que se desee Automatic Failover) para actuar como servidor Testigo
(Witness) para todas las bases de datos.
Database Mirroring no estaba disponible por defecto en la primera versin de SQL Server
2005, de tal modo, que slo era posible habilitar Database Mirroring activando el Trace
Flag 1400 como parmetro de inicio de la correspondiente Instancia de SQL Server 2005,
(no es suficiente con DBCC TRACEON, debe establecerse el parmetro de inicio -t1400).
De hecho, en la primera versin de SQL Server 2005, Database Mirroring no estaba
soportado para entornos de Produccin. La disponibilidad de Database Mirroring para
entornos de Produccin fue a partir de SQL Server 2005 SP1, versin a partir de la cual,
ya no era necesario activar el Trace Flag 1400.
Database Mirroring ofrece tres modos de funcionamiento, como antes adelantamos:

Modo de Alta Disponibilidad (sncrono y con testigo). Las transacciones son

aplicadas de forma sncrona a las base de datos principal y espejo. Requiere de un
Servidor Testigo (Witness) ubicado sobre una tercera mquina (que no sea ni el
Servidor Principal ni el Servidor Espejo), gracias al cual es posible la recuperacin
automtica ante fallos (automatic failover) o conmutacin automtica de roles. En
caso de fallo del Servidor Principal durante el envo de transacciones, el Servidor
Espejo tiene que terminar las transacciones encoladas antes de poder levantarse
como Servidor Principal. Por supuesto tambin es posible la recuperacin manual
ante fallos (manual failover) o conmutacin manual de roles. En caso de una cada o
prdida del Servidor Espejo, la base de datos principal se mantendr activa.
Modo de Alta Proteccin (sncrono y sin testigo). Las transacciones son aplicadas
de forma sncrona a las base de datos principal y espejo. Sin embargo, no utiliza un
Servidor Testigo (Witness). En este modo de funcionamiento, no es posible la
existencia de prdida de datos, pero la recuperacin ante fallos se realiza de forma

manual (manual failover). En caso de una cada o prdida del Servidor Espejo, la
base de datos principal dejar de estar activa, al haber perdido el Quorum.
Modo de Alto Rendimiento (asncrono y sin testigo). Las transacciones son
aplicadas de forma asncrona a la base de datos espejo, ofreciendo mejor
rendimiento que los anteriores modos de funcionamiento, pero pagando como
precio la existencia de posibles prdidas de transacciones (y en consecuencia,
potenciales prdidas de datos). Evidentemente, la recuperacin ante fallos se realiza
de forma manual (manual failover), hablando de conmutacin forzada (es decir,
cambio de roles sin comprobacin de datos escritos en el servidor espejo). En caso
de una cada o prdida del Servidor Espejo, el Servidor Principal no se ver
afectado.

Por poner un ejemplo, en el caso de MOSS 2007 (tambin con SharePoint Portal Server
2003), para ofrecer un sistema de Alta Disponibilidad basado en servidores SQL Server
geogrficamente dispersos, el modo de funcionamiento recomendado ser el Modo de Alta
Disponibilidad, debido a que MOSS 2007 (o SharePoint 2003) contiene mltiples bases de
datos, siendo necesario mantener la consistencia e integridad sobre todas las bases de datos
SQL Server utilizadas por MOSS 2007 (o SharePoint 2003). En consecuencia, tambin
sera posible utilizar el modo de funcionamiento de Alta Proteccin, en cuyo caso se
perdera la funcionalidad de recuperacin automtica ante fallos (Automatic Failover), pero
sin riesgo de prdida de datos. Un aspecto a tener en cuenta en caso de montar Database
Mirroring para MOSS 2007 o SharePoint 2003, es el tema de la configuracin de Alias
SQL, como se coment en un artculo anterior de Instalacin y Configuracin MOSS 2007.
A continuacin se incluye una tabla resumen de los modos de funcionamiento de Database
Mirroring en SQL Server 2005:

Modo

Recuperacin Posible
Servidor Testigo Transaction
Automtica Prdida
(Witness)
Safety
ante Fallos
de Datos

Alta Disponibilidad
SI
(High Availability)
Alta Proteccin
NO
(High Protection)
Alto Rendimiento
NO
(High Performance)

NO

SI

ON

NO

NO

ON

SI

NO

OFF

Volver a: [Database Mirroring en SQL Server 2005 y

SQL Server 2008]

Mejoras de Database Mirroring en SQL

Server 2008 (introduccin)

Volver a: [Database Mirroring en SQL Server 2005 y

SQL Server 2008]
SQL Server 2008 ha introducido varias mejoras de producto, algunas de las cuales
afectan y benefician al Database Mirroring. De este modo, con SQL Server 2008 es
posible mejorar el rendimiento (ej: Backup Compression y Log Compression), la
seguridad (ej: Transparent Data Encryption - TDE) y la disponibilidad (ej: Automatic
Recovery from Corrupted Pages) de nuestra infraestructura de Database Mirroring. A
continuacin, aprovecho para introducir las principales mejoras que incorpora SQL
Server 2008 al Database Mirroring y otras peculiaridades Es posible montar Database
Mirroring con SQL Server 2005 como Principal y SQL Server 2008 como Espejo?
Es posible montar Database Mirroring sobre SQL Server 2005 y SQL Server 2008 (es
decir, mixto, como el sandwich de jamn y queso, jeje ;-). El hecho de poder montar el
Servidor Principal sobre SQL Server 2005 y el Servidor Espejo sobre SQL Server 2008,
permite plantearse soluciones de Database Mirroring interesantes para Migraciones de SQL
Server 2005 a SQL Server 2008 con a penas corte de servicio (tan slo, hacer el balanceo o
failover desde SQL Server 2005 a SQL Server 2008, y luego romper el Database Mirroring,
si no lo queremos mantener).
Es importante tener en cuenta que NO es posible hacer funcionar Database Mirroring
con el Servidor Principal en SQL Server 2008 y el Servidor Espejo en SQL Server
2005 (al menos por ahora, igual dentro de un par de Service Pack, va y funciona...). Esto
era algo de esperar. Recordemos que la inicializacin del Database Mirroring se basa en la
realizacin de Backups, y como siempre, podemos recuperar un Backup de SQL Server
sobre una versin posterior, pero no ser posible recuperar un Backup de SQL Server sobre
una versin anterior. De hecho, al realizar el Restore de una Backup realizado sobre una
versin anterior, si nos fijamos, podremos ver mensajes del sistema que indican que con el
restore se sube la versin de los ficheros de base de datos (al menos, esto se ve al hacer
un RESTORE desde comandos, con Transact-SQL...). Es decir, los propios ficheros de base
de datos son diferentes, y una versin anterior de SQL Server no es capaz de gestionar esta
informacin. Creo que por aqu van los tiros.
Con esto, sabemos que es posible montar Database Mirroring de las siguientes formas:

Servidor Principal en SQL Server 2005, y Servidor Espejo en SQL Server 2005.
Servidor Principal en SQL Server 2005, y Servidor Espejo en SQL Server 2008.
Servidor Principal en SQL Server 2008, y Servidor Espejo en SQL Server 2008.

Sin embargo, no ser posible montar Database Mirroring de la siguiente forma.

Servidor Principal en SQL Server 2008, y Servidor Espejo en SQL Server 2005.

Lo cual implica, que si tenemos el Servidor Principal en SQL Server 2005 y el Servidor
Espejo en SQL Server 2008, deberemos tener especial cuidado con que se produzca un
balanceo (failover), ya que en este caso, el balanceo (failover) no ser reversible (no hay
donde rascar, se dice por aqu, en Carabanchel ;-).
En cualquier caso, resulta muy interesante el hecho de poder construir infraestructuras de
Database Mirroring con SQL Server 2005 y SQL Server 2008, por ejemplo, como mtodo
de migracin de SQL Server 2005 a SQL Server 2008 con escaso corte de servicio.
Una vez comentada esta curiosa posibilidad de Database Mirroring con SQL Server 2005
como Servidor Principal y SQL Server 2008 como Servidor Espejo (Mirror), aprovecho
para incluir las principales mejoras de SQL Server 2008 para Database Mirroring.

Backup Compression. Una caracterstica nueva y especialmente relevante en SQL

Server 2008, es la posibilidad de hacer Backups comprimidos, directamente desde
SQL Server 2008 (es decir, sin necesidad de utilizar herramientas de terceros, como
SQL Backup de Red Gate Software o Quest Software LiteSpeed for SQL
Server), pero por desgracia slo disponible en las ediciones SQL Server 2008
Developer y SQL Server 2008 Enterprise. De este modo, es posible generar
ficheros backup de menor tamao y minimizar el tiempo empleado en los
Backups (consecuencia directa de una menor necesidad de accesos a disco). Para
poder disfrutar de Backup Compression, es suficiente con aadir la opcin
COMPRESSION en la clusula WITH de la correspondiente sentencia BACKUP.
Del mismo modo, es posible configurar la instancia de SQL Server 2008, para que
por defecto, todos los Backups se realicen comprimidos sin necesidad de especificar
WITH COMPRESSION en cada sentencia de BACKUP, configuracin que
podemos realizar a travs de sp_configure (ej: EXEC sp_configure 'backup
compression default', 1), muy til para casos particulares como hacer Backups de
MOSS 2007. En el caso particular de una implementacin de Database Mirroring,
Backup Compression agiliza la creacin del Mirror (recordemos que el punto de
partida es un Backup Completo y al menos un Backup de Log), y evidentemente, el
hecho de poder utilizar Backup Compression en los backups habituales repercutir
en una mejora directa en nuestra implementacin de Database Mirroring (siempre y
cuando no existan problemas de CPU en las ventanas de Backup).
Database Mirroring Log Compression. En una sesin de Database Mirroring, la
informacin del Registro de Transacciones de la base de datos en Espejo, es enviada
desde el Servidor Principal al Servidor Espejo (Mirror) a travs de la red, de tal
modo, que el ancho de banda disponible en la red puede llegar a ser un factor
limitante. Database Mirroring Log Compression es una caracterstica nueva en SQL
Server 2008, que permite que la informacin del Registgro de Transacciones a
enviar desde la base de datos Principal a la base de datos Espejo (Mirror), sea
enviada en formato comprimido, aumentando el rendimiento.
Transparent Data Encryption (TDE). Se trata de una mejora de SQL Server
2008, que puede aprovecharse con Database Mirroring. Transparent Data
Encryption (TDE) permite encriptar o cifrar los ficheros de una base de datos
automticamente y transparentemente, garantizando que un usuario no autorizado

no podr acceder con xito ni a la informacin de los ficheros de base de datos, ni a

la informacin de los ficheros de backup de la base de datos.
Automatic Recovery from Corrupted Pages. Si un servidor miembro de una
sesin de Database Mirroring no puede acceder con xito a una pgina de datos
desde disco, intentar solicitar dicha pgina de datos al otro servidor miembro de la
sesin de Database Mirroring, de tal modo, que si finalmente obtiene dicha pgina
de datos reemplazar la pgina inaccesible en disco, corrigiendo dicho error para
futuros intentos de acceso a la misma.

Probablemente, haciendo una investigacin ms amplia se puedan encontrar ms mejoras,

pero quizs las principales y ms relevantes sean ests que acabo de comentar, junto con la
posibilidad de poder montar Database Mirroring con SQL Server 2005 y SQL Server 2008
a la vez (eso s, SQL Server 2008 slo podra actuar como Servidor Espejo en este caso).

Volver a: [Database Mirroring en SQL Server 2005 y

SQL Server 2008]

Configuracin de Database Mirroring en

SQL Server 2005 Cmo Configurar
Database Mirroring?
Volver a: [Database Mirroring en SQL Server 2005 y
SQL Server 2008]
En este captulo se vuelven a recordar los principales requisitos para poder configurar
Database Mirroring en SQL Server 2005 y se detallan los pasos a realizar en la
configuracin de Database Mirroring, inicialmente en un modo superficial, seguido de un
mayor detalle a modo de Gua o Manual de Configuracin de Database Mirroring paso a
paso. Aunque los pasos de configuracin incluidos han sido desarrollados sobre una
instalacin de Database Mirroring sobre SQL Server 2005, no existe mayor diferencia en
la configuracin de Database Mirroring sobre SQL Server 2008.
Antes de poder empezar con la configuracin de Database Mirroring en SQL Server, es
necesario comprobar que se cumplen los principales requisitos de Database Mirroring:
la Base de Datos debe existir en la instancia SQL Server que se desee que acte como
Principal, configurada con el Modo de Recuperacin Completo, y con el Modo de
Compatibilidad en SQL Server 2005 (90).

Comprobado que se cumplen los requisitos necesarios de Database Mirroring, estamos en

condiciones de empezar la configuracin de Database Mirroring, que consistir en los
cuatro pasos que a continuacin se enumeran:

Realizar un Backup Completo y un Backup de Log de la base de datos principal.

Realizar un Restore en el servidor espejo con el mismo nombre, dejando la base de
datos en modo NORECOVERY.
Configurar Database Mirroring, con el asistente de SSMS o por medio de TransactSQL (creacin de extremos o ENDPOINT y establecimiento de la sesin de
Mirroring).
Creacin de objetos de servidor adicionales (ej: Inicios de Sesin, Jobs, Backups,
etc.).

Una vez introducidos los pasos a realizar para la configuracin de Database Mirroring, a
continuacin se detalla cada uno de estos pasos, con el fin de poder detallar e incluir
ejemplos de configuracin de Database Mirroring que facilite la compresin de dicho
proceso, a modo de Gua o Manual de Configuracin de Database Mirroring, paso a paso:

Realizar un Backup Completo y un Backup de LOG de la Base de Datos

principal, en el Servidor Principal, como se muestra en el siguiente ejemplo.

BACKUP DATABASE GuilleSQL TO DISK='D:\temp\GuilleSQL.bak'

BACKUP LOG GuilleSQL TO DISK='D:\temp\GuilleSQL.trn'

Debe tenerse en cuenta, que si disponemos de algn backup completo reciente y de

los correspondientes y sucesivos backups de Log (ej: el Backup Completo de
anoche, y todos los Backups de Log desde entonces), podemos utilizarlos y evitar
tener que realizar ningn Backup adicional. En el caso de grandes bases de datos, o
de bases de datos con gran actividad, esta sera una prctica muy recomendable,
ahorrando tiempo y liberando a SQL Server de consumir recursos innecesariamente.

Realizar el Restore en el Servidor Espejo (Mirror) de un Backup completo

reciente de la base de datos principal (con el mismo nombre, no vale restaurar con
un nombre diferente), y de todos los Backup de LOG sucesivos, siempre con la
opcin NORECOVERY. A continuacin se muestra un ejemplo, con fines
didcticos:

RESTORE DATABASE GuilleSQL FROM DISK='D:\temp\GuilleSQL.bak'

WITH NORECOVERY
, MOVE 'GuilleSQL' TO 'D:\DATA\GuilleSQL.mdb'
, MOVE 'GuilleSQL_log' TO 'D:\DATA\GuilleSQL_log.ldf'
RESTORE LOG GuilleSQL FROM DISK='D:\temp\GuilleSQL.trn'
WITH NORECOVERY

Como aclaracin, comentar que es requisito recuperar al menos un Backup

Completo y un Backup de Log para poder a funcionar Database Mirroring. Si no
realizamos al menos un Restore del LOG (es decir, si slo restauramos un Backup
Completo), al intentar activar Database Mirroring obtendremos un error como el
siguiente:
Alter failed for Database GuilleSQL.
The mirror database, GuilleSQL, has insufficient transaction log data to preserve
the log backup chain of the principal database. This may happen if a log backup
from the principal database has not been taken or has not been restored on the
mirror database (Microsoft SQL Server, Error: 1478)

Configurar Database Mirroring (emparejar), con el Asistente de SSMS o con

Transact-SQL. La ejecucin de dicho asistente, crear los objetos ENDPOINT
necesarios en cada instancia de SQL Server (en caso de ser necesario, si ya
estuviesen creados los ENDPOINT se utilizarn los existentes), tanto en el Servidor
Principal, como en el Servidor Espejo (Mirror) y en el Servidor Testigo (Witness) si
se especifica. Adems, configurar la sesin de Database Mirroring entre el
Principal y el Espejo, y configurar Database Mirroring en modo Alta
Disponibilidad (High Availability) o Alto Rendimiento (High Performance) si es
necesario (por defecto, Database Mirroring se configura en modo Alta Proteccin High Protection).
Para lanzar el asistente de configuracin de Database Mirroring (Configure
Database Mirroring Security Wizard), abrir el dilogo de Propiedades de la base de
datos principal (click con el botn derecho sobre la base de datos en SSMS, y
despus click Properties), seleccionar la pgina Mirroring, y seguidamente click
sobre el botn Configure Security.
En cualquier caso, tambin es posible configurar Database Mirroring utilizando
Transact-SQL, para lo cual ser necesario hacer por cdigo todas las tareas que
realiza el asistente, como se muestra a continuacin a modo ejemplo:

-- Crear el ENDPOINT en el Principal

-- Ejecutar desde el Principal
CREATE ENDPOINT [Mirroring]
STATE=STARTED
AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
FOR DATA_MIRRORING (ROLE = PARTNER, ENCRYPTION = REQUIRED)
-- Crear el ENDPOINT en el Espejo
-- Ejecutar desde el Espejo
CREATE ENDPOINT [Mirroring]
STATE=STARTED
AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)

FOR DATA_MIRRORING (ROLE = PARTNER, ENCRYPTION = REQUIRED)

-- Crear el ENDPOINT en el Testigo (Opcional)
-- Slo necesario si se desea el Modo de Alta Disponibilidad
-- Ejecutar desde el Testigo
CREATE ENDPOINT [Mirroring]
STATE=STARTED
AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
FOR DATA_MIRRORING (ROLE = PARTNER, ENCRYPTION = REQUIRED)
-- Especificar al servidor Espejo cul ser su Principal
-- especificando el ENDPOINT creado en el Principal
-- que actuar como extremo de comunicacin
-- Ejecutar desde el Espejo
ALTER DATABASE GuilleSQL
SET PARTNER = 'TCP://vsql01.guillesql.local:5022'
-- Establecer al servidor Principal cul ser su Espejo
-- especificando el ENDPOINT creado en el Espejo
-- que actuar como extremo de comunicacin.
-- Una vez ejecutado, se iniciar Database Mirroring
-- en modo Alta Proteccin (High Protection).
-- Ejecutar desde el Principal
ALTER DATABASE GuilleSQL
SET PARTNER = 'TCP://vsql02.guillesql.local:5022'
-- Habilitar el Modo Alta Disponibilidad (Opcional)
-- Establecer al servidor Principal cul ser el Testigo (Witness)
-- especificando unl ENDPOINT creado en el Testigo (Witness)
-- Ejecutar desde el Principal
ALTER DATABASE GuilleSQL
SET WITNESS = 'TCP://vsql03.guillesql.local:5022'
-- Habilitar el Modo Alta Proteccin (Opcional)
-- Deshabilitar Transacction Safety
-- Ejecutar desde el Principal
ALTER DATABASE AdventureWorks
SET PARTNER SAFETY OFF

Crear o configurar otros objetos de servidor (ej: Inicios de Sesin, Jobs,

Backups, etc.). Por ltimo, ser necesario crear aquellos objetos de servidor que
sean necesarios para el funcionamiento de la instalacin, como por ejemplo Inicios
de Sesin, Jobs, etc.
Por ejemplo, en una instalacin de MOSS 2007 sobre Database Mirroring, ser
necesario crear en el Servidor Espejo, todos los inicios de sesin utilizados en el

Servidor Principal (ej: el inicio de sesin del Crawler - Index Server, etc.).
Aqu tambin tenemos algunos detalles importantes. Por ejemplo, en el caso de
utilizar Inicios de Sesin (Logins) de Directorio Activo, el SID utilizado se obtendr
de Directorio Activo, por lo tanto la creacin del Inicio de Sesin en el Servidor
Espejo (Mirror) no esconde truco alguno. Sin embargo, en el caso de Inicios de
Sesin de SQL Server, el SID es generado de forma aleatoria por SQL Server, y en
consecuencia, si creamos un Inicio de Sesin de SQL Server en el Servidor
Espejo (Mirror) se generar un SID diferente, y en caso de balanceo (failover)
nos encontraremos con Usuarios Hurfanos (es decir, el Inicio de Sesin perder
el acceso a la base de datos). Cmo solucionar este problema? Pues lo suyo, es la
utilizacin del mismo SID en los dos servidores (Principal y Espejo), para lo cual
podemos crear el nuevo Inicio de Sesin con una sentencia CREATE LOGIN
WITH SID (ej: CREATE LOGIN GuilleSQL WITH PASSWORD='segura',
CHECK_POLICY=OFF, SID=0xB228CA1014A7464AC7C1E31A27B1213A).
Recordemos que es posible conocer el SID asociado a un Inicio de Sesin,
consultando las vistas del sistema en la base de datos master, como las vistas del
catlogo sys.sql_logins y sys.server_principals. Evidentemente, la utilizacin del
procedimiento almacenado sp_change_users_login es una apa en este caso, que
malfuncionar, pues en cada balanceo ser necesario ejecutar dicho procedimiento
almacenado para corregir los Usuarios Hurfanos.
Otro problema tpico es el hecho de necesitar duplicar los trabajos del Agente de
SQL Server que acten sobre las bases de datos en Mirroring, de tal modo, que
estn en ambos servidores (Principal y Espejo), pues siempre que se modifique un
Job ser necesario replicar dicho cambio en el otro servidor. Pero la historia no
acaba aqu, ya que ser necesario que los Jobs slo acten sobre una base de
datos si dicha base de datos est como Principal en la instancia. Pongamos el
tpico ejemplo de la realizacin de Backups o Mantenimientos (ej: Reindexaciones),
los cuales slo debern de ejecutarse sobre la base de datos principal
(evidentemente, pues al intentar acceder a la base de datos Espejo recibirn un
bonito error, claro). Una forma de conseguir que los Jobs funcionen correctamente
es personalizarlos (o customizarlos, como ahora est de moda decir), condicionando
las tareas a realizar en funcin de si la base de datos a la que se necesita acceder
acta como Principal o como Espejo (Mirror). Para esto, es posible consultar la
vista del catlogo sys.database_mirroring, por ejemplo, para consultar el valor del
campo mirroring_role (el valor 1 significa Principal y el valor 2 significa Espejo Mirror) para la base de datos deseada, y en funcin de este campo, hacemos algo o
no lo hacemos. De este modo, podemos lanzar el mismo trabajo (Job) en ambos
servidores (Principal y Espejo), con la garanta de que slo se ejecutar sobre la
instancia que hospede la base de datos deseada como Principal.

Volver a: [Database Mirroring en SQL Server 2005 y

SQL Server 2008]

Administracin y Mantenimiento de
Database Mirroring en SQL Server 2005 y
SQL Server 2008 (introduccin)
Volver a: [Database Mirroring en SQL Server 2005 y
SQL Server 2008]
Una vez configurado y puesto en marcha Database Mirroring en SQL Server, es
necesario estar preparados para administrar y mantener dicha infraestructura de Database
Mirroring, evitando cadas de servicio y entradas de incidencias. Aunque Database
Mirroring es una tecnologa con un bajo coste de mantenimiento (ms dolores de cabeza
genera la Replicacin de SQL Server, por ejemplo), es necesario tener en cuenta ciertas
peculiaridades en la administracin y mantenimiento de las bases de datos montadas en
Database Mirroring. Qu se debe tener en cuenta para la Administracin y
Mantenimiento de Database Mirroring en SQL Server?
Como en todas reas, podramos extendernos ampliamente para cubrir este tema. Sin
embargo, y para no abrumar, vamos a intentar hacer un captulo introductorio capaz de
presentar las principales problemticas, herramientas y comandos a tener en cuenta en la
administracin y mantenimiento de Database Mirroring. En particular, vamos a ver lo
siguente:

Herramientas de Database Mirroring

Crear un Database Snapshot sobre la base de datos Espejo
Cmo quitar Database Mirroring
Orden de Parada y Arranque de Servidores SQL Server con Database Mirroring
Cmo Pausar y Reanudar Database Mirroring
Quitar o Reemplazar el Servidor Testigo (Witness)
Redireccin de Cliente: ADO.NET / SQL Native Client automatic redirection
Otras consideraciones de la Administracin y Mantenimiento de Database
Mirroring en SQL Server

Tomada conciencia de qu es lo que vamos a ver, empezamos a meternos en harina...

Herramientas de Database Mirroring

Desde SQL Server Management Studio (SSMS), estn disponibles las siguientes
herramientas o utilidades:

Pgina Mirroring del dilogo de Propiedades de Base de Datos. Al abrir el

dilogo de Propiedades de una base de datos (click con el botn derecho sobre la

base de datos deseada, y seguidamente click en Properties), podemos acceder a la

pgina Mirroring. Aqu se muestra informacin general sobre el Mirroring
(Extremos o EndPoints de los Servidores Principal, Espejo y Testigo, Modo de
Operacin del Database Mirroring, Estado, etc.), y adems, se permite realizar
distintas acciones, como Pausar y Reanudar el Database Mirroring, realizar un
balanceo (failover), o eliminar el Database Mirroring.
Asistente de Configuracin de Database Mirroring (Configure Database
Mirroring Security Wizard). Este asistente est disponible desde la pgina
Mirroring del dilogo de Propiedades de Base de Datos. A travs de este asistente es
posible configurar el Database Mirroring (creacin de los Extremos o EndPoints
necesarios, establecimiento de la sesin de Database Mirroring entre el Principal y
Espejo, agregar el Testigo, etc.).
Database Mirroring Monitor. Podemos acceder a esta herramienta, desde SQL
Server Management Studio (SSMS), haciendo click con el botn derecho sobre la
base de datos deseada, despus click sobre Tasks en el men contextual, y
seguidamente click sobre la opcin Launch Database Mirroring Monitor.
Database Mirroring Monitor, permite monitorizar en tiempo real las bases de datos
configuradas en Database Mirroring, as como obtener informacin histrica de las
mismas (qu servidor era Principal y Secundario en un momento anterior en el
tiempo, transacciones pendientes, etc.). Nota: el historial almacenado es de los
ltimos 7 das. Este valor no se puede cambiar.

Como siempre, todo lo que se puede realizar desde un interfaz grfico, es posible realizarlo
tambin por comandos, utilizando Transact-SQL. En este caso, trataremos especialmente
con los comandos ALTER DATABASE SET PARTNER y CREATE ENDPOINT.

Crear un Database Snapshot sobre la base de datos

Espejo
Una tarea que puede resultar de gran utilidad, es la creacin de un Snapshot (o Instantnea
de Base de Datos) sobre una base de datos en Espejo. Lo gracioso de esto, es que la base de
datos en Espejo no puede ser accedida, pero sin embargo, si creamos un Snapshot sobre
dicha base de datos espejo, si podremos acceder a los datos de la base de datos en el
momento de creacin del Snapshot (eso s, accederemos en modo de slo lectura). A
continuacin se incluye un trozo de cdigo Transact-SQL como ejemplo de creacin de un
Database Snapshot.
CREATE DATABASE GuilleSQL_Snap01
ON (NAME = GuilleSQL, FILENAME = 'D:\ DATA\GuilleSQL_Snap01.mdf')
AS SNAPSHOT OF GuilleSQL

Cmo quitar Database Mirroring

Aunque no se trate de una tarea de mantenimiento habitual, resulta interesante conocer
como quitar o deshacer el Database Mirroring, principalmente para pruebas que deseemos

realizar en entornos de laboratorio, etc. En cualquier caso, se trata de una tarea muy
sencilla, pues para deshacer el Database Mirroring, tan slo es necesario ejecutar una
sentencia ALTER DATABASE SET PARTNER OFF, como se muestra en el siguiente
ejemplo:
ALTER DATABASE GuilleSQL SET PARTNER OFF
Tambin es posible realizarlo de forma grfica desde la pestaa Mirroring del dilogo de
Propiedades de la base de datos correspondiente (botn Remove Mirroring).
Despus de desconfigurar Database Mirroring con la anterior sentencia ALTER
DATABASE SET PARTNER OFF o desde SSMS, es posible volver a configurarlo (si
fuese necesario, por ejemplo, por haber deshabilitado Database Mirroring por error) sin
necesidad de volver a ejecutar sentencias de BACKUP ni de RESTORE, es decir,
directamente ejecutando las correspondientes sentencias ALTER DATABASE SET
PARTNER (como se vi anteriormente, en el apartado de configuracin de Database
Mirroring). Esto es as (probado), siempre y cuando no perdamos transacciones en la base
de datos principal (ej: truncar el Log).
De hecho, al ejecutar la sentencia ALTER DATABASE SET PARTNER OFF, la base de
datos Principal se quedar activa como una base de datos normal y corriente (sin Database
Mirroring, ni n de n), mientras que la base de datos Espejo se quedar en estado
Restoring, igual que la dejamos cuando ejecutamos los RESTORE WITH NORECOVERY
utilizados inicialmente para configurar el Database Mirroring. Por este motivo, tenemos la
posibilidad de volver a configurar el Database Mirroring, o bien, si lo deseamos podemos
configurar la base de datos del Espejo como una base de datos activa ejecutando una
sentencia RESTORE WITH RECOVERY (ej: RESTORE DATABASE GuilleSQL
WITH RECOVERY).
En cualquier caso, una vez que se ha roto la sesin de Database Mirroring con la sentencia
ALTER DATABASE SET PARTNER OFF, y si queremos dejar la casa limpia, el
siguiente paso sera eliminar los ENDPOINT creados para el Database Mirroring (en el
Principal, Espejo y Testigo), mediante sentencias DROP ENDPOINT (ej: DROP
ENDPOINT Mirroring) en cada uno de los servidores. Eso s, eliminaremos los
ENDPOINT si no existe ninguna otra sesin de Database Mirroring (es decir, si no se estn
utilizando, claro).

Orden de Parada y Arranque de Servidores SQL Server

con Database Mirroring
El orden de parada de los servidores Database Mirroring en modo Alta
Disponibilidad (High Availability) es vinculante, pues podra producirse un failover
automtico, es decir, que se intercambien los roles de Principal y Mirror. En consecuencia,
en el posterior inicio de servidores, los roles de mantendrn intercambiados.

Por ejemplo, si trabajando en modo Alta Disponibilidad (High Availability), primero se

produce la parada del Principal (lo cual, implica un failover automtico, intercambindose
los roles), y seguidamente se realiza la parada del Mirror (mentira despus del anterior
failover, realmente ahora sera el Principal debido al intercambio de roles, ok?) y Witness,
en el siguiente inicio de servidores, se mantendrn los roles intercambiados.
En este caso, si las aplicaciones clientes de dichas bases de datos en Mirror, no disponen de
ningn sistema automtico de re-direccin a la nueva instancia que acta como Principal en
el Database Mirroring, podra ser necesaria alguna operacin manual para conseguir
restablecer el correcto funcionamiento de las aplicaciones, ya sea la realizacin de un
balanceo manual (manual failover) a travs de una sentencia ALTER DATABASE SET
PARTNER FAILOVER, o bien, una redireccin manual de las aplicaciones (ej: modificar
el Alias SQL utilizado para conectar a las bases de datos, cambiar la cadena de conexin a
la base de datos, etc.).
Del mismo modo, es importante aclarar, que el orden de arranque de los servidores
Database Mirroring no es vinculante (es decir, no producir balaceo automtico automatic failover), ni en modo Alta Disponibilidad (High Availability), ni en ningn otro
modo. Este comportamiento es bastante lgico, aunque en algn caso cuesta ms
entenderlo. El Quiz de la cuestin es el siguiente: si estn todos los servidores parados, y
se inician el Testigo (Witness) y el Espejo (Mirror) Qu debera ocurrir? Debera el
Testigo (Witness) forzar un balanceo automtico (automatic failover)? Pues no, el Mirror
seguir como Mirror y los clientes no podrn conectarse a la base de datos hasta que
arranque el servidor Principal, excepto que rompamos el Database Mirroring (ejecutando
la correspondiente sentencia ALTER DATABASE GuilleSQL SET PARTNER OFF) y
recuperemos dicha base de datos (RESTORE DATABASE GuilleSQL WITH
RECOVERY), algo que slo deberamos realizar en caso de emergencia (ojo, que en este
caso, cuando levante el servidor Principal, nos encontraremos con dos servidores que
contienen la misma base de datos viva, con el riesgo de que unos clientes puedan
conectarse a un servidor y otros clientes a otro, y aqu si podemos liarla parda con los
datos). He comentado la opcin de romper el Mirroring en vez de forzar el cambio de roles,
porque en las pruebas que he realizado, al intentar ejecutar la sentencia ALTER
DATABASE SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS (que es lo que
en principio yo pensaba que habra que hacer), el servidor me ha dicho que me peine.

Cmo Pausar y Reanudar Database Mirroring

Estas tareas resultan bastante fciles de ejecutar, pues tan slo requieren la ejecucin de un
nico comando ALTER DATABASE SET PARTNER, y para quienes le guste, tambin es
posible realizarlas de forma grfica con SQL Server Management Studio (SSMS) desde la
pestaa Mirroring del dilogo de Propiedades de la base de datos deseada. Sin embargo,
bajo mi punto de vista, la problemtica es para qu, y no el cmo. Qu implica parar una
sesin de Database Mirroring? Para qu sirve? Qu ventajas o inconvenientes tiene
parar el Database Mirroring?

Parar una sesin de Database Mirroring suspende el Mirroring, lo cual implica que se
detiene el envo de transacciones desde la Base de Datos Principal a la Base de Datos
Espejo (Mirror). Esta situacin nos va a permitir obtener una mejora de rendimiento
adicional, que puede resultar de gran utilidad para realizar alguna tarea de mantenimiento o
ejecutar algn proceso que genere muchas escrituras en base de datos. Sin embargo, nos va
a traer un riesgo adicional, debido a que no se podrn truncar transacciones de los
ficheros de Log (an haciendo backups de Log), lo cual podra llegar incluso a llenar
completamente el disco, impactando en el servicio de base de datos. Por ello, en caso de
pausar una sesin de Database Mirroring, es importante reanudar dicha sesin de Database
Mirroring lo antes posible, as como vigilar el crecimiento del Log en la base de datos
Principal mientras la sesin de mirroring se mantenga pausada. Tambin es importante
tener en cuenta, que al reanudar la sesin de Database Mirroring, se enviarn las
transacciones acumuladas en Log desde la base de datos Principal a la base de datos Espejo
(Mirror).
A continuacin se incluyen las sentencias Transact-SQL (ALTER DATABASE SET
PARTNER) correspondientes a pausar y reaundar una sesin de Database Mirroring:
ALTER DATABASE GuilleSQL SET PARTNER SUSPEND
ALTER DATABASE GuilleSQL SET PARTNER RESUME

Quitar o Reemplazar el Servidor Testigo (Witness)

Para quitar el Servidor Testigo (Witness) asociado a una sesin de Database Mirroring, es
suficiente con ejecutar un comando ALTER DATABASE SET WITNESS OFF, como se
muestra en el siguiente ejemplo:
ALTER DATABASE GuilleSQL SET WITNESS OFF
Este comando puede ejecutarse independientemente desde el Servidor Principal o desde el
Servidor Espejo (Testigo). Tambin es posible ejecutarlo con xito, an con el Servidor
Testigo (Witness) cado. En cualquier caso, debe tenerse en cuenta que el hecho de quitar
el Servidor Testigo (Witness), configurar implcitamente el Database Mirroring en el
modo de funcionamiento de Alta Proteccin (High Protection). Por ello, en caso de
tener que quitar el Servidor Testigo (Witness) por prdida del mismo, es recomendable
configurar como Servidor Testigo (Witness) cualquier otra instancia de SQL Server, como
medida preventiva, y hasta que pueda recuperarse el Servidor Testigo (Witness),
recuperando as el modo de Alta Disponibilidad (High Availability) del Database
Mirroring.

Redireccin de Cliente: ADO.NET / SQL Native Client

automatic redirection

En una conexin a una base de datos SQL Server configurada en Database Mirroring,
realizada a travs de ADO.Net o SQL Native Client, permite que pueda realizarse una
Redireccin Automtica de la conexin a SQL Server. Es decir, si el cliente al conectarse a
SQL Server detecta que el Servidor Principal est cado, ser capaz de conectarse a travs
del Servidor Espejo (Mirror). Del mismo modo, si una vez el cliente ha conectado con SQL
Server, se produce un failover, en la siguiente ocasin que el cliente necesite acceder a la
base de datos, ser capaz de reconectarse automticamente al servidor que acte como
Servidor Principal.
La Redireccin Automtica del cliente en una infraestructura de Database Mirroring, es una
funcionalidad muy apreciada, y en este caso, es tan fcil como utilizar una sintaxis
determinada en la cadena de conexin a SQL Server, como se muestra en el siguiente:
"Data Source=SrvPrincipal;Failover Partner=SrvMirror;Initial
Catalog=GuilleSQL;Integrated Security=True;"
De este modo, una aplicacin que utilice esta funcionalidad (ej: una Aplcacin Web de
ASP.Net) ser capaz de reconectarse automticamente en caso de balanceo (failover),
reducindose el coste de mantenimiento de la infraestructura.

Otras consideraciones de la Administracin y

Mantenimiento de Database Mirroring en SQL Server

No es posible realizar un Backup sobre la base de datos espejo. Al intentar

realizar una copia de seguridad sobre la base de datos espejo, se obtiene el siguiente
error:
Msg 954, Level 14, State 1, Line 1
The database "GuilleSQL" cannot be opened. It is acting as a mirror database.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.
Por ello, ser necesario que la realizacin de los backups sea condicionada, y slo se
realice el backup de una base de datos configurada en Database Mirroring, cuando
est actuando como Principal. Esto puede solucionarse consultando la Vista de
Catlogo sys.database_mirroring.

Las operaciones SHRINK no son siempre correctamente duplicadas de la base

de datos principal a la base de datos espejo. Este problema est descrito en el
Artculo de Soporte KB937531, dnde adems se describe una solucin temporal
(WorkAround) para dicho problema. No nos asustemos, porque no es habitual, pero
eso no quita que lo tengamos en cuenta.

Y con esto acaba este captulo. Evidentemente, con este contenido no seremos los ms
expertos en Database Mirroring con SQL Server, pero seguro que tendremos una idea

orientativa bastante acertada de las principales tareas de Mantenimiento y Administracin

de Database Mirroring.

Volver a: [Database Mirroring en SQL Server 2005 y

SQL Server 2008]

Database Mirroring, Enlaces de Inters

Volver a: [Database Mirroring en SQL Server 2005 y
SQL Server 2008]
Por ultimo, antes de finalizar vamos a incluir unos cuantos enlaces de inters a
documentacin variada sobre Database Mirroring, de fuentes como Microsoft TechNet,
Blogs de MSDN, para aquellos que se animen y quieran poder seguir investigando y
profundizando en los secretos y maldades de Database Mirroring sobre SQL Server 2005
y 2008.
Aqu la una listita de enlaces a informacin variada sobre Database Mirroring:

Configuring Database Mirroring for SharePoint Products & Technologies

Database Mirroring en SQL Server 2005 (By Ron Talmage, Solid Quality
Learning). Muy bueno... claro est, que los de SolidQ son los mejores.
Database Mirroring FAQ
Eventos de alerta en Database Mirroring
Informacin sobre sys.database.mirroring
Usando Database Mirroring en MOSS 2007
Caso de Estudio de MOSS 2007 con Database Mirroring
Database Mirroring Monitor
Database Mirroring How-tos
Consideraciones de buenas prcticas y rendimiento
Builds, parches y descripciones de SQL 2005

Volver a: [Database Mirroring en SQL Server 2005 y

SQL Server 2008]