La base de datos comienza siempre en modo de recuperación

Cada vez que reinicio mi servidor, la base de datos siempre está en modo de recuperación, y tarda unos 20 minutos en comportarse normalmente. Esto siempre y solo ocurre cuando reinicio el servidor, así que tengo algunas preguntas ...

1. ¿Me dijeron que esto podría ser causado por un archivo de registro grande? ¿Podría ser eso correcto? Si no, ¿cuáles podrían ser las otras causas?
2. Necesito reducir el espacio del archivo de registro para evitar recuperaciones. ¿Qué es mejor: reducir o truncar?
3. ¿Cómo puedo reducir o truncar un archivo de registro / base de datos para reducir el tamaño? ¿Cuál es la sintaxis?

Actualmente estoy usando Microsoft SQL Server 2008.

Tengo el mismo problema y creo que lo he resuelto, pero no he podido probarlo por completo para confirmarlo.

Creo que los problemas están relacionados con la cantidad de VLF que tiene en su archivo de registro y no con su tamaño. Si tiene un archivo de registro grande, es probable que haya crecido orgánicamente a través de eventos de crecimiento automático y que no haya sido un crecimiento planificado intencionalmente. Si ese es el caso, es posible que tenga miles de VLF dentro de los archivos de registro.

Aquí hay una consulta para ver cuántos VLF tiene que usé desde aquí :

    Create Table #stage(
    FileID      int
  , FileSize    bigint
  , StartOffset bigint
  , FSeqNo      bigint
  , [Status]    bigint
  , Parity      bigint
  , CreateLSN   numeric(38));

Create Table #results(
    Database_Name   sysname
  , VLF_count       int 
);

Exec sp_msforeachdb N'Use ?; 
            Insert Into #stage 
            Exec sp_executeSQL N''DBCC LogInfo(?)''; 

            Insert Into #results 
            Select DB_Name(), Count(*) 
            From #stage; 

            Truncate Table #stage;'

Select * 
From #results
Order By VLF_count Desc;

Drop Table #stage;
Drop Table #results;

Para obtener una explicación más detallada de lo que son los VLF, consulte este enlace .

Creo que el problema es que con tantos VLF le lleva mucho tiempo al servidor SQL evaluar su estado y luego sacar la base de datos de la recuperación. Si reduce su archivo de registro al tamaño más pequeño posible, a menudo el tamaño del primer VLF que se creó en el archivo de registro, puede volver a crecerlo intencionalmente de inmediato y, de este modo, crear el número correcto de VLF (algo menor que dieciséis).

Una vez que esto esté completo, creo que podrá ver que su base de datos se recupera mucho más rápido.

No he tenido la oportunidad de probar la conmutación por error de nuestras instancias de producción después de resolver nuestros propios problemas de VLF, por lo que sería muy curioso si puede confirmar que esta es la causa raíz del problema. Experimentalmente, he visto que el tiempo que lleva salir de la restauración en nuestro entorno de preparación se ha reducido drásticamente debido a esto, así que espero que sea así.

De este artículo de MSDN :

Las transacciones no comprometidas de larga duración aumentan el tiempo de recuperación para todos los tipos de puntos de control.

Por lo general, no se recomienda ejecutar ningún tipo de archivo retráctil DBCC en las bases de datos de producción. También el comportamiento de truncamiento de registro HA cambiado de versiones anteriores a 2008 (gracias @Edward) - según este blog :

El registro de copia de seguridad con trucate_only ya no es compatible con SQL 2008. Si su base de datos se encuentra en un modelo de recuperación completa o de registro masivo, programe la copia de seguridad de T-Log a intervalos regulares y mantendrá su t-log en forma.

De nuevo, mencionaré, ¿con qué frecuencia hace una copia de seguridad de la base de datos? Por lo general, las copias de seguridad regulares "gestionan" mejor el tamaño del registro.

Reducir el tamaño del registro de transacciones en línea puede solucionar el problema, es decir, acelerar la conexión de la base de datos, pero debe pensar en la recuperación ante desastres antes de hacerlo. Tenga en cuenta que si está en el modelo de recuperación simple, no podrá restaurar a un punto en el tiempo. Por otro lado, si está en el modelo de recuperación COMPLETA, la mejor manera de mantener el tamaño del registro de transacciones en línea es crear una copia de seguridad del registro de transacciones en bases regulares (programarlo).

Truncar el registro de transacciones no libera espacio físico en el disco duro, solo permite que SQL Server reutilice ese espacio para las transacciones que se han producido desde el último PUNTO DE CONTROL (desde la última copia de seguridad del registro de transacciones).

Si reduce la base de datos, reducirá el tamaño de los archivos. Para reducir la base de datos MyDB en un 15 por ciento:

DBCC SHRINKDATABASE (MyDB, 15); VAMOS