La base de données démarre toujours en mode de récupération

Chaque fois que je redémarre mon serveur, la base de données est toujours en mode de récupération et il faut environ 20 minutes pour qu'elle se comporte normalement. Cela se produit toujours et uniquement lorsque je redémarre le serveur, j'ai donc quelques questions ...

1. On m'a dit que cela pouvait être dû à un gros fichier journal? Serait-ce correct? Sinon, quelles pourraient être les autres causes?
2. J'ai besoin de réduire l'espace du fichier journal pour éviter les récupérations. Quoi de mieux: rétrécir ou tronquer?
3. Comment réduire ou tronquer un fichier journal / une base de données pour réduire la taille? Quelle est la syntaxe?

J'utilise actuellement Microsoft SQL Server 2008.

J'ai le même problème et je crois l'avoir résolu mais je n'ai pas pu le tester complètement pour le confirmer.

Je crois que les problèmes sont liés au nombre de VLF que vous avez dans votre fichier journal et non à sa taille. Si vous disposez d'un fichier journal volumineux, il est probable qu'il se soit développé de manière organique lors d'événements de croissance automatique et qu'il ne s'agissait pas d'une croissance intentionnelle planifiée. Si tel est le cas, vous pourriez avoir des milliers de VLF dans les fichiers journaux.

Voici une requête pour voir combien de VLF vous avez que j'ai utilisés à partir d' ici :

    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;

Pour une explication supplémentaire de ce que sont les VLF, consultez ce lien .

Je crois que le problème est qu'avec tant de VLF, il faut beaucoup de temps au serveur SQL pour évaluer leur état, puis sortir la base de données de la récupération. Si vous réduisez votre fichier journal à la plus petite taille possible, souvent la taille du premier VLF qui a été créé dans le fichier journal, vous pouvez immédiatement l'agrandir intentionnellement de nouveau et ainsi le faire créer le bon nombre de VLF (quelque chose de moins que 16).

Une fois cela terminé, je pense que vous pourrez voir que votre base de données sort de la récupération beaucoup plus rapidement.

Je n'ai pas eu l'occasion de tester le basculement de nos instances de production après avoir résolu nos propres problèmes VLF, je serais donc très curieux de savoir si c'est la cause première du problème. Expérimentalement, j'ai vu le temps qu'il faut pour sortir de la restauration dans notre environnement de mise en scène considérablement réduit à cause de cela, espérons-le.

De cet article MSDN :

Les transactions non validées de longue durée augmentent le temps de récupération pour tous les types de points de contrôle.

Il n'est généralement pas recommandé d'exécuter tout type de fichier rétractable DBCC sur des bases de données de production. Le comportement de troncature des journaux a également changé par rapport aux versions antérieures à 2008 (merci @Edward) - par ce blog :

Le journal de sauvegarde avec trucate_only n'est plus pris en charge dans SQL 2008. Si votre base de données est dans un modèle de récupération en bloc ou complet, planifiez la sauvegarde T-Log à intervalle régulier et il gardera votre t-log en forme.

Encore une fois, je mentionnerai, à quelle fréquence sauvegardez-vous la base de données? En règle générale, les sauvegardes régulières «gèrent» mieux la taille des journaux.

Réduire la taille du journal des transactions en ligne peut résoudre le problème, c'est-à-dire accélérer la mise en ligne de la base de données, mais vous devez penser à la reprise après sinistre avant de le faire. Notez que si vous êtes dans le modèle de récupération simple, vous ne pourrez pas restaurer à un moment donné. D'un autre côté, si vous êtes dans le modèle de récupération COMPLET, la meilleure façon de conserver la taille du journal des transactions en ligne est de créer une sauvegarde du journal des transactions sur des bases régulières (le planifier).

La troncature du journal des transactions ne libère pas d'espace sur le disque dur physique, elle permet uniquement à SQL Server de réutiliser cet espace pour les transactions qui se sont produites depuis le dernier CHEKPOINT (depuis la dernière sauvegarde du journal des transactions).

Si vous réduisez la base de données, vous réduirez la taille des fichiers. Pour réduire la base de données MyDB de 15%:

DBCC SHRINKDATABASE (MyDB, 15); ALLER