GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Administración y Mantenimiento de Database Mirroring en SQL Server 2005 y SQL Server 2008 (introducción)

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 caídas de servicio y entradas de incidencias. Aunque Database Mirroring es una tecnología con un bajo coste de mantenimiento (más dolores de cabeza genera la Replicación de SQL Server, por ejemplo), es necesario tener en cuenta ciertas peculiaridades en la administración y mantenimiento de las bases de datos montadas en Database Mirroring. ¿Qué se debe tener en cuenta para la Administración y Mantenimiento de Database Mirroring en SQL Server?

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.

CREATE DATABASE GuilleSQL_Snap01
ON (NAME = GuilleSQL, FILENAME = 'D:\ DATA\GuilleSQL_Snap01.mdf')
AS SNAPSHOT OF GuilleSQL

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:

ALTER DATABASE GuilleSQL SET PARTNER OFF

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:

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 sesión 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). 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:

"Data Source=SrvPrincipal;Failover Partner=SrvMirror;Initial Catalog=GuilleSQL;Integrated Security=True;"

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.

Volver a: [Database Mirroring en SQL Server 2005 y SQL Server 2008]


[Fecha del Artículo (UTC): 06/05/2009]
[Autor: GuilleSQL]


Comentarios

jeancc - 12/10/2011 (UTC)
Hola,

intentando crear un snapshot sobre la base de datos mirror, ejecutamos esto:

CREATE DATABASE MyClassWeb_Snap01
ON (NAME = MyClassWeb, FILENAME = 'C:\Snapshots\MyClassWeb_Snap01.mdf')
AS SNAPSHOT OF MyClassWeb

Y nos da este error:
Mens. 1844, Nivel 16, Estado 1, Línea 1
Database Snapshot no se admite en Standard Edition.


¿Sólo se pueden crear snapshots con la Enterprise? Necesitamos ver los datos que hay en la BD mirror.

Gracias.


GuilleSQL - 12/10/2011 (UTC)
Hola Jeancc,

Si, Database Snapshot es una característica de la edición Enterprise.

La única alternativa que se me ocurre, es romper el mirror. Creo recordar, que la base de datos espejo se quedará en estado Recovering, pudiendo ponerla online con un RESTORE DATABASE mirrorDB WITH RECOVERY.

Sé que esta alternativa podría no resultarte válida, pero es lo único que se me ocurre, al menos, en este momento.

Saludos,
Guille



Escribir un Comentario

Para poder escribir un comentario, debe Iniciar Sesión con un usuario.

Si no dispone de un usuario, puede Registrarse y hacerse miembro.

Si dispone de un usuario, pero no recuerda sus credenciales de acceso, puede Restablecer su Contraseña.

Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Esta información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This information is provided "AS IS" with no warranties, and confers no rights.

Copyright © 2007 GuilleSQL, todos los derechos reservados.
GuilleSQL.com y GuilleSQL.net son también parte de Portal GuilleSQL.

Visitas recibidas (Page Loads) en GuilleSQL (fuente: StatCounter):

screen resolution stats
Visitas