Como en todas áreas, podríamos extendernos ampliamente para cubrir este tema. Sin embargo, y para no abrumar, vamos a intentar hacer un capítulo introductorio capaz de presentar las principales problemáticas, herramientas y comandos a tener en cuenta en la administración 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
• Cómo quitar Database Mirroring
• Orden de Parada y Arranque de Servidores SQL Server con Database Mirroring
• Cómo Pausar y Reanudar Database Mirroring
• Quitar o Reemplazar el Servidor Testigo (Witness)
• Redirección de Cliente: ADO.NET / SQL Native Client automatic redirection
• Otras consideraciones de la Administración 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), están disponibles las siguientes herramientas o utilidades:

• Página Mirroring del diálogo de Propiedades de Base de Datos. Al abrir el diálogo de Propiedades de una base de datos (click con el botón derecho sobre la base de datos deseada, y seguidamente click en Properties), podemos acceder a la página Mirroring. Aquí se muestra información general sobre el Mirroring (Extremos o EndPoints de los Servidores Principal, Espejo y Testigo, Modo de Operación del Database Mirroring, Estado, etc.), y además, se permite realizar distintas acciones, como Pausar y Reanudar el Database Mirroring, realizar un balanceo (failover), o eliminar el Database Mirroring.
• Asistente de Configuración de Database Mirroring (Configure Database Mirroring Security Wizard). Este asistente está disponible desde la página Mirroring del diálogo de Propiedades de Base de Datos. A través de este asistente es posible configurar el Database Mirroring (creación de los Extremos o EndPoints necesarios, establecimiento de la sesión 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 botón derecho sobre la base de datos deseada, después click sobre Tasks en el menú contextual, y seguidamente click sobre la opción Launch Database Mirroring Monitor. Database Mirroring Monitor, permite monitorizar en tiempo real las bases de datos configuradas en Database Mirroring, así como obtener información histórica 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 días. Este valor no se puede cambiar.

Como siempre, todo lo que se puede realizar desde un interfaz gráfico, es posible realizarlo también 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 creación de un Snapshot (o Instantánea 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 creación del Snapshot (eso sí, accederemos en modo de sólo lectura). A continuación se incluye un trozo de código Transact-SQL como ejemplo de creación de un Database Snapshot.

Cómo 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 sólo es necesario ejecutar una sentencia ALTER DATABASE SET PARTNER OFF, como se muestra en el siguiente ejemplo:

También es posible realizarlo de forma gráfica desde la pestaña Mirroring del diálogo de Propiedades de la base de datos correspondiente (botón Remove Mirroring).

Después 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 configuración 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 sesión de Database Mirroring con la sentencia ALTER DATABASE SET PARTNER OFF, y si queremos dejar la casa limpia, el siguiente paso sería 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 sesión de Database Mirroring (es decir, si no se están 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 podría producirse un failover automático, es decir, que se intercambien los roles de Principal y Mirror. En consecuencia, en el posterior inicio de servidores, los roles de mantendrán intercambiados.

Por ejemplo, si trabajando en modo Alta Disponibilidad (High Availability), primero se produce la parada del Principal (lo cual, implica un failover automático, intercambiándose los roles), y seguidamente se realiza la parada del Mirror (mentira… después del anterior failover, realmente ahora sería el Principal debido al intercambio de roles, ¿ok?) y Witness, en el siguiente inicio de servidores, se mantendrán los roles intercambiados.

En este caso, si las aplicaciones clientes de dichas bases de datos en Mirror, no disponen de ningún sistema automático de re-dirección a la nueva instancia que actúa como Principal en el Database Mirroring, podría ser necesaria alguna operación manual para conseguir restablecer el correcto funcionamiento de las aplicaciones, ya sea la realización de un balanceo manual (manual failover) a través de una sentencia ALTER DATABASE SET PARTNER FAILOVER, o bien, una redirección manual de las aplicaciones (ej: modificar el Alias SQL utilizado para conectar a las bases de datos, cambiar la cadena de conexión 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 automático - automatic failover), ni en modo Alta Disponibilidad (High Availability), ni en ningún otro modo. Este comportamiento es bastante lógico, aunque en algún caso cuesta más entenderlo. El Quiz de la cuestión es el siguiente: si están todos los servidores parados, y se inician el Testigo (Witness) y el Espejo (Mirror) ¿Qué debería ocurrir? ¿Debería el Testigo (Witness) forzar un balanceo automático (automatic failover)? Pues no, el Mirror seguirá como Mirror y los clientes no podrán 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 sólo deberíamos 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 opción 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 habría que hacer), el servidor me ha dicho que me peine.

Cómo Pausar y Reanudar Database Mirroring

Estas tareas resultan bastante fáciles de ejecutar, pues tan sólo requieren la ejecución de un único comando ALTER DATABASE SET PARTNER, y para quienes le guste, también es posible realizarlas de forma gráfica con SQL Server Management Studio (SSMS) desde la pestaña Mirroring del diálogo de Propiedades de la base de datos deseada. Sin embargo, bajo mi punto de vista, la problemática es para qué, y no el cómo. ¿Qué implica parar una sesión de Database Mirroring? ¿Para qué sirve? ¿Qué ventajas o inconvenientes tiene parar el Database Mirroring?

Parar una sesión de Database Mirroring suspende el Mirroring, lo cual implica que se detiene el envío de transacciones desde la Base de Datos Principal a la Base de Datos Espejo (Mirror). Esta situación nos va a permitir obtener una mejora de rendimiento adicional, que puede resultar de gran utilidad para realizar alguna tarea de mantenimiento o ejecutar algún proceso que genere muchas escrituras en base de datos. Sin embargo, nos va a traer un riesgo adicional, debido a que no se podrán truncar transacciones de los ficheros de Log (aún haciendo backups de Log), lo cual podría llegar incluso a llenar completamente el disco, impactando en el servicio de base de datos. Por ello, en caso de pausar una sesión de Database Mirroring, es importante reanudar dicha sesión de Database Mirroring lo antes posible, así como vigilar el crecimiento del Log en la base de datos Principal mientras la sesión de mirroring se mantenga pausada. También es importante tener en cuenta, que al reanudar la sesión de Database Mirroring, se enviarán las transacciones acumuladas en Log desde la base de datos Principal a la base de datos Espejo (Mirror).

A continuación se incluyen las sentencias Transact-SQL (ALTER DATABASE SET PARTNER) correspondientes a pausar y reaundar una sesión de Database Mirroring:

Quitar o Reemplazar el Servidor Testigo (Witness)

Para quitar el Servidor Testigo (Witness) asociado a una sesión de Database Mirroring, es suficiente con ejecutar un comando ALTER DATABASE SET WITNESS OFF, como se muestra en el siguiente ejemplo:

Este comando puede ejecutarse independientemente desde el Servidor Principal o desde el Servidor Espejo (Testigo). También es posible ejecutarlo con éxito, aún con el Servidor Testigo (Witness) caído. En cualquier caso, debe tenerse en cuenta que el hecho de quitar el Servidor Testigo (Witness), configurará implícitamente el Database Mirroring en el modo de funcionamiento de Alta Protección (High Protection). Por ello, en caso de tener que quitar el Servidor Testigo (Witness) por pérdida 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.

Redirección de Cliente: ADO.NET / SQL Native Client automatic redirection

En una conexión a una base de datos SQL Server configurada en Database Mirroring, realizada a través de ADO.Net o SQL Native Client, permite que pueda realizarse una Redirección Automática de la conexión a SQL Server. Es decir, si el cliente al conectarse a SQL Server detecta que el Servidor Principal está caído, será capaz de conectarse a través del Servidor Espejo (Mirror). Del mismo modo, si una vez el cliente ha conectado con SQL Server, se produce un failover, en la siguiente ocasión que el cliente necesite acceder a la base de datos, será capaz de reconectarse automáticamente al servidor que actúe como Servidor Principal.

La Redirección Automática del cliente en una infraestructura de Database Mirroring, es una funcionalidad muy apreciada, y en este caso, es tan fácil como utilizar una sintaxis determinada en la cadena de conexión a SQL Server, como se muestra en el siguiente:

De este modo, una aplicación que utilice esta funcionalidad (ej: una Aplícación Web de ASP.Net) será capaz de reconectarse automáticamente en caso de balanceo (failover), reduciéndose el coste de mantenimiento de la infraestructura.

Otras consideraciones de la Administración 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 realización de los backups sea condicionada, y sólo 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 Catálogo 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 Artículo de Soporte KB937531, dónde además se describe una solución 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 capítulo. Evidentemente, con este contenido no seremos los más expertos en Database Mirroring con SQL Server, pero seguro que tendremos una idea orientativa bastante acertada de las principales tareas de Mantenimiento y Administración de Database Mirroring.