Share via

Actualizar el trasvase de registros a SQL Server 2012 (Transact-SQL)

  • Artículo

Es posible conservar las configuraciones de trasvase de registros al actualizar de SQL Server 2005, SQL Server 2008 o SQL Server 2008 R2 a SQL Server 2012. En este tema se describen escenarios alternativos y prácticas recomendadas para actualizar la configuración de trasvase de registros.

[!NOTA]

La compresión de copia de seguridad se incluyó en SQL Server 2008 Enterprise. Una configuración de trasvase de registros actualizada utiliza la opción de copia de seguridad backup compression default de nivel servidor para controlar si se emplea la compresión de copia de seguridad para los archivos de copia de seguridad de registros de transacciones. El comportamiento de la compresión de las copias de seguridad de registros se puede especificar para cada configuración de trasvase de registros. Para obtener más información, vea Configurar el trasvase de registros (SQL Server).

En este tema:

  • Proteger los datos antes de la actualización

  • Actualizar la instancia del servidor de supervisión

  • Actualizar las configuraciones de trasvase de registros con un único servidor secundario

  • Actualizar varias instancias del servidor secundario

  • Volver a implementar el 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, vea Crear una copia de seguridad completa de base de datos (SQL Server).

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

Actualizar 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 de sistema sp_refresh_log_shipping_monitor.

Actualizar las 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 de un único servidor secundario. Esta configuración se representa en la ilustración siguiente, que muestra una instancia del servidor principal, A, y una única instancia del servidor secundario, B.

Un servidor secundario y ningún servidor supervisor

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

En esta sección:

  • Actualizar la instancia del servidor secundario

  • Actualizar la instancia del servidor principal

Actualizar la instancia del servidor secundario

El proceso de actualización implica actualizar las instancias de los servidores secundarios de una configuración de trasvase de registros de SQL Server 2005, SQL Server 2008 o SQL Server 2008 R2 a SQL Server 2012 antes de actualizar la instancia del servidor principal. Actualice siempre la instancia del servidor secundario en primer lugar. Si el servidor principal se actualizara antes que 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 a lo largo del proceso de actualización porque los servidores secundarios actualizados continúan restaurando las copias de seguridad de registros a partir del servidor principal de SQL Server 2005, SQL Server 2008 o SQL Server 2008 R2. El proceso para actualizar las instancias de los servidores secundarios depende en parte de si la configuración de trasvase de registros posee varios servidores secundarios. Para obtener más información, vea Actualizar varias instancias del servidor secundario, posteriormente en este tema.

Mientras se actualiza la instancia del servidor secundario, no se ejecutan los trabajos de copia y restauración del trasvase de registros, por lo que se acumularán las copias de seguridad de registros de transacciones sin restaurar. El grado de acumulación depende de la frecuencia de la 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 que el servidor secundario se ha actualizado, los trabajos de los agentes de trasvase de registros se reanudan y siguen copiando y restaurando las copias de seguridad de registros a partir de la instancia del servidor principal, server A. La cantidad de tiempo requerido para que el servidor secundario actualice la base de datos secundaria varía en función del tiempo empleado en actualizar el servidor secundario y de la frecuencia de las copias de seguridad en el servidor principal.

[!NOTA]

Durante la actualización del servidor, la base de datos secundaria no se actualiza a una base de datos de SQL Server 2012. Solo se actualizará si se pone en conexión.

Nota importanteImportante

La opción RESTORE WITH STANDBY no se admite para una base de datos que requiere actualizarse. Si una base de datos secundaria actualizada se ha configurado utilizando RESTORE WITH STANDBY, los registros de transacciones ya no se pueden restaurar después de la actualización. Para reanudar el trasvase de registros en esa base de datos secundaria, tendrá que configurarlo de nuevo en ese servidor de reserva. Para obtener más información acerca de la opción STANDBY, vea RESTORE (argumentos, Transact-SQL).

Actualizar la instancia del servidor principal

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

A costa de un proceso de actualización más complicado, puede obtener la máxima disponibilidad de la base de datos conmutando por error el servidor principal de SQL Server 2005, SQL Server 2008 o SQL Server 2008 R2 al servidor secundario de SQL Server 2012 antes de actualizar el servidor principal original (escenario 2, a continuación). Hay dos variantes del escenario de conmutación por error. Puede volver al servidor principal original y mantener la configuración de trasvase de registros original. O bien, puede quitar la configuración de trasvase de registros original antes de actualizar el servidor principal original y después crear una configuración nueva usando el servidor principal nuevo. En esta sección se describen ambos escenarios.

Nota importanteImportante

Asegúrese de actualizar la instancia del servidor secundario antes de actualizar la instancia del servidor principal. Para obtener más información, vea Actualizar la instancia del servidor secundario, anteriormente en este tema.

En esta sección:

  • Escenario 1: actualizar la instancia del servidor principal sin conmutación por error

  • Escenario 2: actualizar la instancia del servidor principal con conmutación por error

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

Este es el escenario más sencillo, pero ocasiona más tiempo de inactividad que la conmutación por error. Simplemente se actualiza la instancia del servidor principal y la base de datos no está disponible durante la 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: actualizar la instancia del servidor principal con conmutación por error

En este escenario se obtiene la máxima disponibilidad y se reduce al mínimo el tiempo de inactividad. Utiliza una conmutación por error controlada a la instancia del servidor secundario, lo que mantiene la base de datos disponible mientras se actualiza la instancia del servidor principal original. El tiempo de inactividad se limita al tiempo relativamente corto que se requiere para la conmutación por error, en lugar del tiempo exigido para actualizar la instancia del servidor principal.

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

Nota importanteImportante

Si piensa tener la instancia del servidor secundario como instancia del nuevo servidor principal, tiene que quitar la configuración de trasvase de registros. Una vez actualizada la instancia del servidor principal original, será preciso reconfigurar el trasvase de registros desde el nuevo servidor principal hasta el nuevo servidor secundario. Para obtener más información, vea Quitar el trasvase de registros de (SQL Server).

En esta sección:

  • Procedimiento 1: realizar una conmutación por error controlada al servidor secundario

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

  • Procedimiento 3: configurar el trasvase de registros en SQL Server 2012

Procedimiento 1: realizar una conmutación por error controlada al servidor secundario

Conmutación por error controlada al servidor secundario:

  1. Realice manualmente una copia del final del registro del registro de transacciones en la base de datos principal especificando WITH NORECOVERY. Esta copia de seguridad de registros captura cualquier entrada del registro que todavía no se haya incluido en la copia de seguridad y deja la base de datos sin conexión. Tenga en cuenta que mientras la base de datos esté sin conexión, se producirá un error en el trabajo de copia de seguridad del trasvase de registros.

    En el ejemplo siguiente se crea una copia del final del registro 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 que utilice una convención de nomenclatura de archivos distinta para diferenciar el archivo de copia de seguridad creado manualmente de los que crea 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 los trabajos de copia de seguridad de trasvase 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 los servidores principal y secundario. 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 y restaurado, invoque manualmente los trabajos de restauración y copia del agente para la configuración de trasvase de registros.

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

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

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

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

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

      [!NOTA]

      En una configuración que contenga más de un servidor secundario, hay consideraciones adicionales. Para obtener más información, vea Actualizar varias instancias del servidor secundario, posteriormente en este tema.

    4. Realice la conmutación por error de la base de datos redirigiendo a los clientes del servidor principal original (servidor A) al servidor secundario (servidor B) en línea.

    5. Tenga cuidado de que el registro de transacciones de la base de datos secundaria no se llene mientras la base de datos está en línea. Para evitar que el registro de transacciones se llene, puede que sea necesario realizar una copia de seguridad del mismo. En ese caso, se recomienda que ponga la copia de seguridad en una ubicación compartida, un recurso compartido de copia de seguridad, de modo que las copias de seguridad estén disponibles para restaurarse en la otra instancia del servidor.

Procedimiento 2: actualizar la instancia del servidor principal original a SQL Server 2012

Después de actualizar la instancia del servidor principal original a SQL Server 2012, la base de datos todavía estará sin conexión y en el formato.

Procedimiento 3: configurar el trasvase de registros en SQL Server 2012

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

  • Si ha conservado la configuración de trasvase de registros de SQL Server 2005, SQL Server 2008 o SQL Server 2008 R2, vuelva a la instancia del servidor principal original. Para obtener más información, vea Para 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 instancia del nuevo servidor principal. Para obtener más información, vea Para mantener la instancia del servidor secundario anterior como instancia del nuevo servidor principal, posteriormente en esta sección.

Para volver a la instancia del servidor principal original

  1. En el servidor principal provisional (servidor B), haga una copia de seguridad del final del registro usando WITH NORECOVERY para crear una copia del final del registro y dejar la base de datos sin conexión. La copia de seguridad del final del registro 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 realizó alguna copia de seguridad de registros de transacciones en la base de datos principal provisional exceptuando la copia de seguridad del final del registro que creó en el paso 1, restaure esas copias de seguridad del registro usando WITH NORECOVERY en la base de datos sin conexión del servidor principal original (servidor A). La base de datos se actualiza al formato de SQL Server 2012 cuando se restaura la primera copia de seguridad de registros.

  3. Restaure la copia del final del registro, Switchback_AW_20080315.trn, en la base de datos principal original (en servidor A) usando WITH RECOVERY para poner en línea la base de datos.

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

Una vez que la base de datos se ponga en línea, se reanudará la configuración de trasvase de registros original.

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

Establezca una nueva configuración de trasvase de registros utilizando la instancia del servidor secundario anterior, B, como servidor principal y la instancia del servidor principal anterior, A, como nuevo servidor secundario, de la forma siguiente:

Nota importanteImportante

La configuración de trasvase de registros anterior se debería haber quitado del servidor principal original al principio del proceso, antes de realizar la copia de seguridad manual del registro de transacciones que puso sin conexión la base de datos.

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

  2. Haga una copia de seguridad de registros desde la nueva base de datos principal (en el servidor B).

  3. Restaure las copias de seguridad de registros en la instancia del nuevo servidor secundario (servidor A) usando WITH NORECOVERY. La primera operación de restauración actualiza la base de datos a SQL Server 2012.

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

    Nota importanteImportante

    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 del servidor principal original (servidor A) al servidor secundario (servidor B) en línea.

    Nota importanteImportante

    Cuando realice la conmutación por error a una nueva base de datos primaria, debe asegurarse de que sus metadatos sean coherentes con los de la base de datos principal original. Para obtener más información, vea Administrar los metadatos cuando una base de datos pasa a estar disponible en otra instancia de servidor (SQL Server).

Actualizar varias instancias del servidor secundario

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

Dos servidores secundarios y ningún servidor supervisor

En esta sección se explica cómo actualizar con una conmutación por error y después volver al servidor principal original. Al actualizar la instancia principal con conmutación por error, el proceso es más complejo si hay varias instancias de servidores secundarios. En el procedimiento siguiente, una vez actualizados todos los servidores secundarios, el servidor principal conmuta por error a una de las bases de datos secundarias actualizadas. Se actualiza el servidor principal original y el trasvase de registros conmuta por error a él.

Nota importanteImportante

Actualice siempre todas las instancias de los servidores secundarios antes de actualizar el servidor principal.

Para actualizar con una conmutación por error y volver al servidor principal original.

  1. Actualice todas las instancias de los servidores secundarios (servidor B y servidor C).

  2. Obtenga el final del registro de transacciones de la base de datos principal (en el servidor A) y ponga la base de datos sin conexión, haciendo una copia de seguridad de registros de transacciones usando WITH NORECOVERY.

  3. En el servidor secundario hacia el que planea realizar la conmutación por error (servidor B), ponga la base de datos secundaria en línea, restaurando la copia de seguridad de registros usando WITH RECOVERY.

  4. En el otro servidor secundario (servidor C), deje la base de datos secundaria sin conexión restaurando la copia de seguridad de registros usando WITH NORECOVERY.

    [!NOTA]

    Los trabajos de copia y restauración del trasvase de registros y se ejecutarán en los servidores secundarios, pero no harán nada 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 redirigiendo a los clientes del servidor principal original (servidor A) al servidor secundario (servidor B) en línea. La base de datos en línea se convierte en el servidor principal provisional y se mantiene 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ó la conmutación por error, es decir, la base de datos principal provisional (en el servidor B), realice manualmente una copia de seguridad de registros de transacciones usando WITH NORECOVERY. De esta forma se deja la base de datos sin conexión.

  8. Restaure todas las copias de seguridad de registros de transacciones que creó en la base de datos principal provisional (en el servidor B) en la otra base de datos secundaria (en el servidor C) usando WITH NORECOVERY. Esto permite al trasvase de registros continuar a partir de la base de datos principal original después de su actualización, sin requerir una restauración de la base de datos completa en cada base de datos secundaria.

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

Volver a implementar el trasvase de registros

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

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

Vea también

Conceptos

Copias de seguridad de registros de transacciones (SQL Server)

Aplicar copias de seguridad de registros de transacción (SQL Server)

Tablas y procedimientos almacenados de trasvase de registros