Actualizar el envío de registros a SQL Server 2014 (Transact-SQL)

Es posible conservar las configuraciones de trasvase de registros al actualizar de SQL Server 2005, SQL Server 2008, SQL Server 2008 R2 o SQL Server 2012 a SQL Server 2014. En este tema se describen escenarios alternativos y procedimientos recomendados para actualizar una configuración de trasvase de registros.

Proteger los datos antes de la actualización

Como práctica recomendada, es aconsejable que proteja sus datos antes de realizar una actualización del trasvase de registros.

Para proteger los datos

1. Realice una copia de seguridad completa de cada base de datos principal.

   Para obtener más información, consulte Crear una copia de seguridad completa de base de datos (SQL Server).

2. Ejecute el comando DBCC CHECKDB en cada base de datos principal.

Actualización de la instancia del servidor de supervisión

La instancia del servidor de supervisión, si existe, se puede actualizar en cualquier momento.

Mientras se actualiza el servidor de supervisión, la configuración de trasvase de registros continúa funcionando, pero su estado no se registra en las tablas del monitor. Cualquier alerta que se haya configurado no se desencadenará mientras el servidor de supervisión se esté actualizando. Después de la actualización, puede actualizar la información de las tablas del monitor ejecutando el procedimiento almacenado del sistema sp_refresh_log_shipping_monitor.

Actualización de configuraciones de trasvase de registros con un único servidor secundario

El proceso de actualización descrito en esta sección supone una configuración que consta del servidor principal y solo un servidor secundario. Esta configuración se representa en la ilustración siguiente, que muestra una instancia de servidor principal, A y una única instancia de servidor secundario, B.

Para obtener información sobre cómo actualizar varios servidores secundarios, vea Actualización de varias instancias de servidor secundario, más adelante en este tema.

Actualización de la instancia del servidor secundario

El proceso de actualización implica actualizar las instancias del servidor secundario de una configuración de trasvase de registros de SQL Server 2005 o posterior a SQL Server 2014 antes de actualizar la instancia del servidor principal. Actualice siempre primero la instancia del servidor secundario. Si el servidor principal se actualizara antes de un servidor secundario, se produciría un error en el trasvase de registros porque una copia de seguridad creada en una versión más reciente de SQL Server no se puede restaurar en una versión anterior de SQL Server.

El trasvase de registros continúa durante el proceso de actualización porque los servidores secundarios actualizados continúan restaurando las copias de seguridad de registros desde el servidor principal de SQL Server 2005 o superior. El proceso para actualizar las instancias del servidor secundario depende en parte de si la configuración de trasvase de registros posee varios servidores secundarios. Para obtener más información, vea Actualización de varias instancias de servidor secundario, más adelante en este tema.

Mientras se actualiza la instancia del servidor secundario, los trabajos de copia y restauración del envío de registros no se ejecutan, por lo que las copias de seguridad del registro de transacciones pendientes de restaurar se acumularán. La cantidad de acumulación depende de la frecuencia de copia de seguridad programada en el servidor principal. Además, si se ha configurado un servidor de supervisión independiente, se podrían generar alertas que indiquen que no se han realizado restauraciones durante más tiempo que el intervalo configurado.

Una vez actualizado el servidor secundario, los trabajos de los agentes de trasvase de registros se reanudan y continúan copiando y restaurando las copias de seguridad de registros desde la instancia del servidor principal, el servidor A. La cantidad de tiempo necesaria para que el servidor secundario ponga actualizada la base de datos secundaria varía, en función del tiempo necesario para actualizar el servidor secundario y la frecuencia de las copias de seguridad en el servidor principal.

Actualizar la instancia del servidor principal

Al planear una actualización, una consideración significativa es la cantidad de tiempo que la base de datos no estará disponible. El escenario de actualización más sencillo implica que la base de datos no esté disponible mientras actualiza el servidor principal (escenario 1, a continuación).

Al coste de un proceso de actualización más complicado, puede maximizar la disponibilidad de su base de datos transfiriendo el servidor principal de SQL Server 2005 o superior a un servidor secundario de SQL Server 2014 antes de actualizar el servidor principal original (escenario 2, a continuación). Hay dos variantes en el escenario de conmutación por error. Puede volver al servidor principal original y mantener la configuración de trasvase de registros original. Como alternativa, puede quitar la configuración de trasvase de registros original antes de actualizar el servidor principal original y, posteriormente, crear una nueva configuración mediante el nuevo servidor principal. En esta sección se describen ambos escenarios.

Escenario 1: Actualización de la instancia del servidor principal sin conmutación por error

Este es el escenario más sencillo, pero provoca más tiempo de inactividad que el uso de la conmutación por error. La instancia del servidor principal simplemente se actualiza y la base de datos no está disponible durante esta actualización.

Una vez actualizado el servidor, la base de datos se vuelve a poner en línea automáticamente, lo que hace que se actualice. Una vez actualizada la base de datos, los trabajos de trasvase de registros se reanudan.

Escenario 2: Actualización de la instancia del servidor principal y conmutación por error

Este escenario maximiza la disponibilidad y minimiza el tiempo de inactividad. Utiliza una conmutación por error controlada a la instancia del servidor secundario, manteniendo la base de datos disponible mientras se actualiza la instancia inicial del servidor primario. El tiempo de inactividad se limita a un periodo de tiempo relativamente corto necesario para la conmutación por error, en lugar del tiempo necesario para actualizar la instancia del servidor principal.

La actualización de la instancia de servidor principal con conmutación por error implica tres procedimientos generales: realizar una conmutación por error controlada al servidor secundario, actualizar la instancia de servidor principal original a SQL Server 2014 y configurar el trasvase de registros en una instancia de servidor principal de SQL Server 2014. Estos procedimientos se describen en esta sección.

Procedimiento 1: Realizar una conmutación por error controlada en el servidor secundario

Conmutación de emergencia controlada al servidor secundario

1. Realice manualmente una copia de seguridad del registro final del registro de transacciones en la base de datos principal que especifica WITH NORECOVERY. Esta copia de seguridad de registros captura cualquier registro de los que aún no se ha realizado una copia de seguridad y pone la base de datos sin conexión. Tenga en cuenta que, mientras la base de datos está sin conexión, el trabajo de copia de seguridad del envío de registros fallará.

   El siguiente ejemplo crea una copia de seguridad del tail log de la base de datos AdventureWorks en el servidor principal. El archivo de copia de seguridad se denomina Failover_AW_20080315.trn:

   BACKUP LOG AdventureWorks 
     TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Failover_AW_20080315.trn' 
      WITH NORECOVERY;
   GO
   

   Se recomienda usar una convención de nomenclatura de archivos distinta para diferenciar el archivo de copia de seguridad creado manualmente de los archivos de copia de seguridad creados por el trabajo de copia de seguridad de trasvase de registros.

2. En el servidor secundario:

   1. Asegúrese de que se han aplicado todas las copias de seguridad realizadas automáticamente por las tareas de copia de seguridad de envío de registros. Para comprobar qué trabajos de copia de seguridad se han aplicado, use el procedimiento almacenado del sistema sp_help_log_shipping_monitor en el servidor de supervisión o en el servidor primario y en los servidores secundarios. El mismo archivo debe aparecer en las columnas last_backup_file, last_copied_file y last_restored_file . Si alguno de los archivos de copia de seguridad no se ha copiado ni restaurado, ejecute manualmente los trabajos de copia y restauración del agente para la configuración de envío de registros.

      Para obtener información sobre cómo iniciar un trabajo, vea Iniciar un trabajo.

   2. Copie el archivo final de copia de seguridad de registros que creó en el paso 1 del recurso compartido de archivos a la ubicación local que usa el trasvase de registros en el servidor secundario.

   3. Restaure la copia de seguridad final del registro especificando WITH RECOVERY para poner la base de datos en línea. Como parte de la puesta en línea, la base de datos se actualizará a SQL Server 2014.

      En el ejemplo siguiente se restaura la copia de seguridad del registro final de la base de datos AdventureWorks en la base de datos secundaria. En el ejemplo se usa la opción WITH RECOVERY, que pone la base de datos en línea:

      RESTORE LOG AdventureWorks 
        FROM DISK = N'c:\logshipping\Failover_AW_20080315.trn' 
         WITH RECOVERY;
      GO
      

      Nota:

      Para una configuración que contiene más de un servidor secundario, hay consideraciones adicionales. Para obtener más información, vea Actualización de varias instancias de servidor secundario, más adelante en este tema.

   4. Realice la conmutación por error de la base de datos mediante la redirección de clientes desde el servidor principal original (servidor A) al servidor secundario en línea (servidor B).

   5. Tenga cuidado de que el registro de transacciones de la base de datos secundaria no se rellene mientras la base de datos está en línea. Para evitar que el registro de transacciones se llene, es posible que tenga que realizar una copia de seguridad. Si es así, se recomienda realizar una copia de seguridad en una ubicación compartida, un recurso compartido de copia de seguridad, para que las copias de seguridad estén disponibles para restaurar en la otra instancia del servidor.

Procedimiento 2: Actualizar la instancia original del servidor principal a SQL Server 2014

Después de actualizar la instancia de servidor principal original a SQL Server 2014, la base de datos seguirá sin conexión y con el formato .

Procedimiento 3: Configurar el trasvase de registros en SQL Server 2014

El resto del proceso de actualización depende de si el trasvase de registros sigue configurado, como se indica a continuación:

• Si ha mantenido la configuración de envío de registros de SQL Server 2005 o superior, vuelva a la instancia original del servidor principal. Para obtener más información, vea Volver a la instancia del servidor principal original, más adelante en esta sección.

• Si quitó la configuración de trasvase de registros antes de la conmutación por error, cree una nueva configuración de trasvase de registros en la que la instancia del servidor secundario original sea la nueva instancia del servidor principal. Para obtener más información, vea Para mantener la instancia del servidor secundario anterior como nueva instancia de servidor principal, más adelante en esta sección.

Para volver a la instancia del servidor principal original

1. En el servidor principal provisional (servidor B), realice una copia de seguridad del final del registro mediante WITH NORECOVERY para crear una copia de seguridad del final del registro y desconectar la base de datos. La copia de seguridad del registro de tail se denomina Switchback_AW_20080315.trn. Por ejemplo:

   BACKUP LOG AdventureWorks 
     TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Switchback_AW_20080315.trn' 
      WITH NORECOVERY;
   GO
   

2. Si se realizaron copias de seguridad de registros de transacciones en la base de datos principal provisional, aparte de la copia de seguridad final que creó en el paso 1, restaure esas copias de seguridad de registros mediante WITH NORECOVERY a la base de datos sin conexión en el servidor principal original (servidor A). La base de datos se actualiza al formato SQL Server 2014 cuando se restaura la primera copia de seguridad del registro.

3. Restaure la copia de seguridad del tail-log, Switchback_AW_20080315.trn, en la base de datos principal original (en el servidor A) utilizando WITH RECOVERY para poner la base de datos en línea.

4. Conmutar de nuevo a la base de datos principal original (en el servidor A) redirigiendo a los clientes desde el servidor principal original al servidor secundario en línea.

Una vez que la base de datos se conecte, se reanudará la configuración de trasvase de registros original.

Para mantener la instancia del servidor secundario anterior como la nueva instancia del servidor principal

Establezca una nueva configuración de trasvase de registros con la instancia del servidor secundario anterior, B, como servidor principal y la instancia de servidor principal anterior, A, como el nuevo servidor secundario, como se indica a continuación:

1. Para evitar realizar una copia de seguridad completa y restaurar la base de datos en el nuevo servidor secundario (servidor A), aplique las copias de seguridad de registros de la nueva base de datos principal a la nueva base de datos secundaria. En la configuración de ejemplo, esto implica restaurar las copias de seguridad de registros realizadas en el servidor B a la base de datos del servidor A.

2. Realice una copia de seguridad del registro desde la nueva base de datos principal (en el servidor B).

3. Restaure las copias de seguridad del registro en la nueva instancia del servidor secundario (servidor A) mediante WITH NORECOVERY. La primera operación de restauración actualiza la base de datos a SQL Server 2014.

4. Configure el trasvase de registros con el servidor secundario anterior (servidor B) como instancia del servidor principal.

   Importante

   Si usa SQL Server Management Studio, especifique que la base de datos secundaria ya está inicializada.

   Para obtener más información, vea Configurar el trasvase de registros (SQL Server).

5. Realice la conmutación por error de la base de datos redirigiendo a los clientes desde el servidor principal original (servidor A) al servidor secundario activo (servidor B).

   Importante

   Al conmutar a una nueva base de datos principal, se recomienda asegurarse de que sus metadatos sean consistentes con los metadatos de la base de datos principal original. Para obtener más información, consulte Administración de los metadatos cuando una base de datos pasa a estar disponible en otro servidor (SQL Server).

Actualización de varias instancias de servidor secundario

Esta configuración se representa en la ilustración siguiente, que muestra una instancia de servidor principal, A y dos instancias de servidor secundario, B y C.

En esta sección se describe cómo actualizar mediante una conmutación por error y, a continuación, volver al servidor principal original. Al actualizar la instancia principal utilizando conmutación por error, el proceso se vuelve más complejo cuando existen múltiples instancias de servidores secundarios. En el procedimiento siguiente, después de actualizar todos los servidores secundarios, el servidor principal se transfiere a una de las bases de datos secundarias actualizadas. El servidor principal original se actualiza y el trasvase de registros se conmuta por error a él.

Para actualizar mediante una conmutación por error y, a continuación, restaurar el servidor principal original

1. Actualice todas las instancias del servidor secundario (servidor B y servidor C).

2. Obtenga la última parte del registro de transacciones de la base de datos principal (en el servidor A) y desconecte la base de datos realizando una copia de seguridad del registro de transacciones mediante WITH NORECOVERY.

3. En el servidor secundario al que planea hacer un cambio por error (servidor B), ponga en línea la base de datos secundaria restaurando la copia de seguridad del registro con WITH RECOVERY.

4. En todos los demás servidores secundarios (servidor C), deje la base de datos secundaria sin conexión restaurando la copia de seguridad de registros mediante WITH NORECOVERY.

   Nota:

   Los trabajos de copia y restauración del envío de registros se ejecutarán en los servidores secundarios, pero no realizarán ninguna acción porque los nuevos archivos de copia de seguridad de registros no se colocarán en el recurso compartido de copia de seguridad.

5. Realice la conmutación por error de la base de datos mediante la redirección de clientes desde el servidor principal original (servidor A) al servidor secundario en línea (servidor B). La base de datos en línea se convierte en un servidor principal provisional, manteniendo la base de datos disponible mientras el servidor principal original está sin conexión (servidor A).

6. Actualice el servidor principal original (servidor A).

7. En la base de datos a la que realizó un failover, la base de datos primaria temporal (en el servidor B), haga manualmente una copia de seguridad del log de transacciones usando WITH NORECOVERY. Esto pone la base de datos fuera de línea.

8. Restaure todas las copias de seguridad del registro de transacciones que creó en la base de datos principal provisional (en el servidor B) en todas las demás bases de datos secundarias (en el servidor C) mediante WITH NORECOVERY. Esto permite que el trasvase de registros continúe desde la base de datos principal original después de su actualización, sin necesidad de una restauración completa de la base de datos en cada base de datos secundaria.

9. Restaure el registro de transacciones desde el servidor principal provisional (servidor B) a la base de datos principal original (en el servidor A) mediante WITH RECOVERY.

Volver a implementar el envío de registros

Si no desea migrar la configuración de trasvase de registros mediante uno de los procedimientos mostrados anteriormente, puede volver a implementar el trasvase de registros desde cero reinicializando la base de datos secundaria con una copia de seguridad completa y restauración de la base de datos principal. Puede ser una opción deseable si tiene una base de datos pequeña o si la alta disponibilidad no es fundamental durante el procedimiento de actualización.

Para obtener información sobre cómo habilitar el trasvase de registros, vea Configurar el trasvase de registros (SQL Server).

Véase también

Copias de seguridad del registro de transacciones (SQL Server)Aplicar copias de seguridad del registro de transacciones (SQL Server)Tablas de trasvase de registros y procedimientos almacenados