Réduction d'un journal de transactions SQL Server

Je dois actuellement gérer un journal de transactions SQL Server devenu incontrôlable. Avertissement: je ne suis pas un dba et ce n'est pas mon domaine d'expertise, alors soyez indulgent avec moi.

Actuellement, j'ai un fichier journal de transactions de 115 Go pour une base de données de 500 Mo qui (évidemment) a été mal géré depuis un certain temps pour qu'il puisse se retrouver dans cet état.

La priorité absolue est de récupérer l'espace sur le disque occupé par ce fichier avant de manquer! On m'a dit que l'augmentation de la taille du disque n'est pas une option, même temporaire, et en fonction de la croissance passée, nous devons agir très rapidement.

Si je comprends bien, la meilleure approche consiste à garder la base de données en mode de récupération complète, mais à effectuer des sauvegardes régulières du fichier journal, à surveiller cela sur une période de temps et à ajuster la taille initiale et l'incrémentation en fonction. Tout va bien.

Étant donné que nous effectuons régulièrement des sauvegardes complètes de la base de données à minuit, serais-je en sécurité de mettre temporairement la base de données en mode de récupération simple (après l'exécution de l'une de ces sauvegardes), de réduire le fichier journal pour récupérer (pratiquement tout) l'espace et puis le remettre dans Full Recovery avec la stratégie de sauvegarde mentionnée ci-dessus?

Je pense que si quelque chose arrivait à cette époque, nous pourrions simplement restaurer la sauvegarde complète sans utiliser les journaux.

MISE À JOUR

Quelques détails supplémentaires en réponse à certaines des réponses et commentaires:

• Nous souhaitons conserver la possibilité d'effectuer une restauration ponctuelle afin que la base de données reste en mode de récupération complète.

• La raison pour laquelle le fichier t-log est devenu si volumineux est qu'il n'a jamais été sauvegardé . Vérifié car log_reuse_wait_desc renvoie 'LOG_BACKUP'.

Le journal des transactions de cette base de données contient toutes les transactions depuis la dernière sauvegarde du journal des transactions ou la dernière fois qu'il est passé du mode de récupération simple. Exécutez ce qui suit pour obtenir la réponse définitive quant aux raisons pour lesquelles SQL Server ne peut pas tronquer le journal et, par conséquent, pourquoi le journal augmente.

SELECT  d.Name
        ,d.log_reuse_wait_desc
FROM    sys.databases d
ORDER BY
        d.name

Si vous souhaitez une récupération ponctuelle, laissez la base de données dans le modèle de récupération complète et effectuez des sauvegardes de journaux fréquentes. Chaque sauvegarde de journal contiendra toutes les transactions depuis la dernière sauvegarde de journal. Le processus de sauvegarde du journal est également responsable de l'effacement du journal et du marquage de l'espace à réutiliser, c'est-à-dire que la prochaine transaction effectuée dans la base de données sera écrite au début du journal tronqué de manière circulaire. Cette sauvegarde et cette réutilisation du journal empêchent la croissance du fichier journal.

Si vous n'êtes pas intéressé par la récupération ponctuelle et souhaitez simplifier l'administration de la base de données. Ensuite, définissez la base de données sur le modèle de récupération simple et n'effectuez pas de sauvegardes de journal. SQL Server tronquera automatiquement le journal des transactions après la validation de chaque transaction. Cela signifie qu'une fois la transaction validée dans le journal, l'enregistrement est écrasé par la transaction suivante, etc.

Quoi qu'il en soit, une fois que vous avez pris l'une de ces deux décisions, vous pouvez réduire le fichier journal à une taille plus raisonnable. Notez idéalement que vous voulez le rendre assez grand pour qu'il ne grossisse pas mais pas si grand que vous aurez besoin de le rétrécir à nouveau. Notez également que vous ne pouvez pas réduire la partie active du journal.

Téléchargez et déployez https://ola.hallengren.com/ une solution d'administration de base de données pour couvrir les sauvegardes, la fragmentation d'index, les statistiques et CHECKDB.

Vous pouvez également trouver le rapport «utilisation du disque» renvoyé en cliquant avec le bouton droit sur la base de données dans Explorateur d'objets> Rapports> Rapports standard> «utilisation du disque» utile pour renvoyer l'espace libre dans le t-log.

Je recommande également à Google pourquoi il est si important de garder la chaîne de journaux intacte d'un point de vue DR, et comment le passage de complet à simple rompt la chaîne, vous exposant à la perte de données.

Étant donné que nous effectuons régulièrement des sauvegardes complètes de la base de données à minuit, serais-je en sécurité de mettre temporairement la base de données en mode de récupération simple (après l'exécution de l'une de ces sauvegardes), de réduire le fichier journal pour récupérer (pratiquement tout) l'espace et puis le remettre dans Full Recovery avec la stratégie de sauvegarde mentionnée ci-dessus?

Oui, ce serait sûr à condition que vous n'interfériez avec aucune transaction lorsque vous faites cela, comme un chargement de fin de nuit. En général, si une base de données doit être en mode de récupération complète, vous souhaitez des sauvegardes T-Log régulières. Cela réduira le problème auquel vous êtes confronté. J'écris "en général" parce que dans certains cas, j'ai vu des gens définir une base de données complète sans savoir pourquoi ils l'ont fait. Supposons que ce n'est pas ce cas.

Cependant, vous voudrez peut-être déterminer pourquoi le journal est de cette taille par rapport à la taille de la base de données. Une base de données de 500 Mo avec un journal de 116 Go semble très disproportionnée pour un événement ponctuel. Je suggère de surveiller ce qui se passe dans la base de données pour voir comment elle est arrivée à cette taille en premier lieu.