KB2653893 - CORRECCIÓN: Se tarda mucho tiempo en restaurar una base de datos en SQL Server 2008 R2, en SQL Server 2008 o en SQL 2012

Síntomas

Puede tardar mucho tiempo en restaurar una base de datos en Microsoft SQL Server 2008 R2 o en Microsoft SQL Server 2008 o en Microsoft SQL Server 2012.

Causa

Este problema se produce porque se tarda mucho tiempo en crear la lista del archivo de registro virtual (VLF) cuando hay muchos VLFs en la base de datos.

Solución

Estado

Microsoft ha confirmado que se trata de un problema de los productos de Microsoft enumerados en la sección "Se aplica a".

Más información

Puede comprobar el número de segmentos VLF revisando el archivo de registro de errores SQL y, a continuación, buscando el número de secuencia de registro (LSN) en cada archivo de copia de seguridad del registro de transacciones. Los primeros dígitos antes del símbolo de dos puntos en los LSN corresponden al número del LSN.

Por ejemplo, el primer número del primer mensaje informativo para el LSN es 1. Sin embargo, el primer número del segundo mensaje informativo para el LSN es 100001. En este escenario, hay 100 000 VLFs que se utilizan entre la hora del primer mensaje informativo y el segundo mensaje informativo. Por lo tanto, el registro de transacciones fragmentado registrado que tiene muchas Files de registro virtual (VLFs) se parece a la siguiente:

Se ha realizado una copia de seguridad de {Log. Base de datos: nombre_de_archivo, fecha(hora) de creación: 07/2010/08(12:36:46), primer LSN: 1:5068:70, último LSN: 1:5108:1, número de dispositivos de volcado: 1, información del dispositivo: (FILE=1, TYPE=DISK: {'C:\folder\logbackup1.trn'}). Solo se trata de un mensaje informativo. No es necesaria ninguna acción del usuario.

Se realizó una copia de seguridad del registro. Base de datos: nombre_de_archivo, fecha(hora) de creación: 07/2010/08(15:36:46), primer LSN: 100001:5108:1, último LSN: 100002:5108:1, número de dispositivos de volcado: 1, información del dispositivo: (FILE=2, TYPE=DISK: {'C:\folder\logbackup2.trn'}). Solo se trata de un mensaje informativo. No es necesaria ninguna acción del usuario.}

Referencias

Para obtener más información sobre los números de secuencia de registro (LSN), visite el siguiente sitio web de MSDN:

Información general sobre los números de secuencia de registro

Para obtener más información sobre cómo una estructura de archivos de registro puede afectar al tiempo de recuperación de la base de datos, visite el siguiente sitio web de MSDN:

Cómo puede afectar la estructura de un archivo de registro al tiempo

de recuperación de la base de datosPara obtener más información sobre las VL del registro de transacciones, visite el siguiente sitio web de MSDN:

Información general sobre el archivo de registro de transacciones

Solución alternativa 

• Espere a que finalice
  
  la operación de restauración o recuperación Si tiene una base de datos no recuperada que experimenta el bajo rendimiento al restaurar o recuperar la base de datos, es posible que tenga que esperar a que se complete la operación de restauración o recuperación. Por ejemplo, es posible que vea el estado sin conexión o el estado de recuperación en SQL Server Management Studio (SSMS) para una base de datos no recuperada. Detener SQL Server normalmente no ofrece alivio para una recuperación lenta y puede tardar más tiempo en repetir la misma fase de análisis de recuperación, en la fase de rehacer o en la de deshacer.

• Evite restaurar la secuencia del registro de transacciones que contiene miles de VLFs
  
  Si experimenta el bajo rendimiento al restaurar y recuperar una base de datos mediante un archivo de copia de seguridad, puede evitar restaurar las secuencias de registro de transacciones que contienen miles de VLFs. Para identificar el archivo de copia de seguridad que tiene la mayor parte de los archivos de registro virtuales registrados, use la siguiente instrucción para ver las columnas FirstLSN y LastLSN en los archivos de copia de seguridad de registro:
  RESTORE HEADERONLY FROM DISK='C:\folder\file.trn'You
  
  can decide evitar restaurar los archivos de copia de seguridad del registro. O bien, puede usar la instrucción STOP AT en los comandos RESTORE para evitar las partes muy fragmentadas de los registros de transacciones. Si no restaura completamente las secuencias de registro hasta el punto más reciente en el tiempo durante un escenario de recuperación de errores, la pérdida de datos se produce en la base de datos SQL Server. Esta pérdida de datos se produce porque no se mantienen todas las transacciones. Por lo tanto, existe una decisión de compensación empresarial. Puede restaurar por completo un registro de transacciones muy fragmentado. Sin embargo, esta operación puede tardar varias horas. O bien, puede usar la instrucción STOP AT en la recuperación para detener la recuperación antes de la parte altamente fragmentada del registro. Sin embargo, se perderán todas las transacciones que falten que omita.
  
  Nota Sin instalar esta revisión, normalmente no hay recurso seguro para la recuperación acelerada después de reiniciar SQL Server. SQL Server tiene que localizar la lista de VLFs para analizar los archivos de registro, rehacer transacciones completadas y luego deshacer transacciones incompletas para finalizar la recuperación y poner la base de datos en línea de forma segura. No puede omitir transacciones de forma segura durante la recuperación.