La réduction de la taille d'un fichier journal doit vraiment être réservée aux scénarios où il a rencontré une croissance inattendue qui ne devrait pas se reproduire. Si le fichier journal atteint à nouveau la même taille, il n'y a pas grand-chose à faire en le réduisant temporairement. Maintenant, selon les objectifs de récupération de votre base de données, ce sont les actions que vous devez entreprendre.
Tout d'abord, effectuez une sauvegarde complète
Ne modifiez jamais votre base de données sans vous assurer de pouvoir la restaurer en cas de problème.
Si vous vous souciez de la récupération ponctuelle
(Et par récupération ponctuelle, je veux dire que vous vous souciez de pouvoir restaurer sur autre chose qu'une sauvegarde complète ou différentielle.)
Vraisemblablement, votre base de données est en FULLmode de récupération. Sinon, assurez-vous que c'est:
ALTER DATABASE testdb SET RECOVERY FULL;
Même si vous effectuez des sauvegardes complètes régulières, le fichier journal augmentera et augmentera jusqu'à ce que vous effectuiez une sauvegarde de journal - c'est pour votre protection, pour ne pas ronger inutilement votre espace disque. Vous devez effectuer ces sauvegardes de journaux assez fréquemment, selon vos objectifs de récupération. Par exemple, si vous avez une règle d'entreprise qui stipule que vous pouvez vous permettre de ne pas perdre plus de 15 minutes de données en cas de sinistre, vous devez avoir un travail qui sauvegarde le journal toutes les 15 minutes. Voici un script qui générera des noms de fichiers horodatés en fonction de l'heure actuelle (mais vous pouvez également le faire avec des plans de maintenance, etc., ne choisissez pas l'une des options de réduction dans les plans de maintenance, elles sont horribles).
DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_'
+ CONVERT(CHAR(8), GETDATE(), 112) + '_'
+ REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
+ '.trn';
BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;
Notez que cela \\backup_share\devrait être sur une machine différente qui représente un périphérique de stockage sous-jacent différent. Les sauvegarder sur la même machine (ou sur une machine différente qui utilise les mêmes disques sous-jacents ou une machine virtuelle différente qui se trouve sur le même hôte physique) ne vous aide pas vraiment, car si la machine explose, vous avez perdu votre base de données et ses sauvegardes. Selon votre infrastructure réseau, il peut être plus judicieux de sauvegarder localement, puis de les transférer vers un autre emplacement en arrière-plan; dans les deux cas, vous souhaitez les retirer de la machine de base de données principale le plus rapidement possible.
Maintenant, une fois que vous avez des sauvegardes de journaux régulières en cours d'exécution, il devrait être raisonnable de réduire le fichier journal à quelque chose de plus raisonnable que ce qu'il a explosé jusqu'à présent. Cela ne signifie pas d' exécuter SHRINKFILEindéfiniment jusqu'à ce que le fichier journal soit de 1 Mo. Même si vous sauvegardez fréquemment le journal, il doit toujours prendre en compte la somme des transactions simultanées qui peuvent se produire. Les événements de croissance automatique des fichiers journaux sont coûteux, car SQL Server doit mettre à zéro les fichiers (contrairement aux fichiers de données lorsque l'initialisation instantanée des fichiers est activée), et les transactions utilisateur doivent attendre pendant que cela se produit. Vous voulez faire cette routine de croissance-rétrécissement-croissance-rétrécissement le moins possible, et vous ne voulez certainement pas faire payer vos utilisateurs.
Notez que vous devrez peut-être sauvegarder le journal deux fois avant qu'une réduction ne soit possible (merci Robert).
Donc, vous devez trouver une taille pratique pour votre fichier journal. Personne ici ne peut vous dire ce que c'est sans en savoir beaucoup plus sur votre système, mais si vous avez fréquemment réduit le fichier journal et qu'il a de nouveau augmenté, un bon filigrane est probablement 10 à 50% plus élevé que le plus gros qu'il ait été. . Supposons que cela représente 200 Mo et que vous souhaitiez que les événements de croissance automatique ultérieurs soient de 50 Mo, vous pouvez ajuster la taille du fichier journal de cette façon:
USE [master];
GO
ALTER DATABASE Test1
MODIFY FILE
(NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO
Notez que si le fichier journal est actuellement> 200 Mo, vous devrez peut-être exécuter ceci en premier:
USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO
Si vous ne vous souciez pas de la récupération ponctuelle
S'il s'agit d'une base de données de test et que vous ne vous souciez pas de la récupération ponctuelle, vous devez vous assurer que votre base de données est en SIMPLEmode de récupération.
ALTER DATABASE testdb SET RECOVERY SIMPLE;
Le fait de mettre la base de données en SIMPLEmode de récupération garantit que SQL Server réutilise des parties du fichier journal (essentiellement en supprimant progressivement les transactions inactives) au lieu de croître pour conserver un enregistrement de toutes les transactions (comme la FULLrécupération le fait jusqu'à ce que vous sauvegardiez le journal). CHECKPOINTLes événements aideront à contrôler le journal et à s'assurer qu'il n'a pas besoin de croître, sauf si vous générez beaucoup d'activité de journal entre les CHECKPOINTs.
Ensuite, vous devez vous assurer que cette croissance du journal est vraiment due à un événement anormal (par exemple, un nettoyage de printemps annuel ou la reconstruction de vos plus gros indices), et non à une utilisation quotidienne normale. Si vous réduisez le fichier journal à une taille ridiculement petite et que SQL Server n'a qu'à le développer à nouveau pour s'adapter à votre activité normale, qu'avez-vous gagné? Avez-vous pu utiliser l'espace disque que vous avez libéré temporairement? Si vous avez besoin d'un correctif immédiat, vous pouvez exécuter ce qui suit:
USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO
Sinon, définissez une taille et un taux de croissance appropriés. Comme dans l'exemple du cas de récupération ponctuelle, vous pouvez utiliser le même code et la même logique pour déterminer la taille de fichier appropriée et définir des paramètres de croissance automatique raisonnables.
Certaines choses que vous ne voulez pas faire
Sauvegardez le journal avec l' TRUNCATE_ONLYoption, puisSHRINKFILE . D'une part, cette TRUNCATE_ONLYoption est obsolète et n'est plus disponible dans les versions actuelles de SQL Server. Deuxièmement, si vous êtes dans le FULLmodèle de récupération, cela détruira votre chaîne de journaux et nécessitera une nouvelle sauvegarde complète.
Détachez la base de données, supprimez le fichier journal et rattachez-le . Je ne peux pas souligner à quel point cela peut être dangereux. Votre base de données peut ne pas remonter, elle peut apparaître comme suspecte, vous devrez peut-être revenir à une sauvegarde (si vous en avez une), etc. etc.
Utilisez l'option "réduire la base de données" . DBCC SHRINKDATABASEet l'option du plan de maintenance pour faire de même sont de mauvaises idées, surtout si vous n'avez vraiment besoin que de résoudre un problème de journal. Ciblez le fichier que vous souhaitez ajuster et ajustez-le indépendamment, en utilisant DBCC SHRINKFILEou ALTER DATABASE ... MODIFY FILE(exemples ci-dessus).
Réduction de la taille du fichier journal 1 Mo . Cela semble tentant car, hé, SQL Server me laisse le faire dans certains scénarios, et regarde tout l'espace qu'il libère! À moins que votre base de données ne soit en lecture seule (et c'est le cas, vous devez la marquer comme telle en utilisant ALTER DATABASE), cela entraînera absolument de nombreux événements de croissance inutiles, car le journal doit prendre en charge les transactions actuelles quel que soit le modèle de récupération. Quel est l'intérêt de libérer temporairement cet espace, juste pour que SQL Server puisse le récupérer lentement et douloureusement?
Créez un deuxième fichier journal . Cela soulagera temporairement le lecteur qui a rempli votre disque, mais cela revient à essayer de réparer un poumon perforé avec un pansement. Vous devez traiter le fichier journal problématique directement au lieu d'ajouter simplement un autre problème potentiel. Outre la redirection d'une activité du journal des transactions vers un autre lecteur, un deuxième fichier journal ne fait vraiment rien pour vous (contrairement à un deuxième fichier de données), car un seul des fichiers peut être utilisé à la fois. Paul Randal explique également pourquoi plusieurs fichiers journaux peuvent vous mordre plus tard .
Etre pro-actif
Au lieu de réduire votre fichier journal à une petite quantité et de le laisser constamment se développer automatiquement à un petit taux, définissez-le sur une taille raisonnablement grande (qui acceptera la somme de votre plus grand ensemble de transactions simultanées) et définissez une croissance automatique raisonnable en tant que solution de repli, de sorte qu'il ne doive pas croître plusieurs fois pour satisfaire des transactions uniques et qu'il soit relativement rare qu'il doive jamais croître pendant les opérations commerciales normales.
Les pires paramètres possibles sont une croissance de 1 Mo ou une croissance de 10%. Assez drôle, ce sont les valeurs par défaut pour SQL Server (dont je me suis plaint et que j'ai demandé des modifications en vain ) - 1 Mo pour les fichiers de données et 10% pour les fichiers journaux. Le premier est beaucoup trop petit de nos jours et le second conduit à des événements de plus en plus longs à chaque fois (par exemple, votre fichier journal est de 500 Mo, la première croissance est de 50 Mo, la prochaine croissance est de 55 Mo, la prochaine croissance est de 60,5 Mo , etc. etc. - et sur les E / S lentes, croyez-moi, vous remarquerez vraiment cette courbe).
Lectures complémentaires
S'il vous plaît ne vous arrêtez pas ici; Bien que la plupart des conseils que vous voyez sur la réduction des fichiers journaux soient intrinsèquement mauvais et même potentiellement désastreux, certaines personnes se soucient davantage de l'intégrité des données que de la libération d'espace disque.
Un article de blog que j'ai écrit en 2009, quand j'ai vu quelques articles "voici comment réduire le fichier journal" .
Un article de blog écrit par Brent Ozar il y a quatre ans, pointant vers plusieurs ressources, en réponse à un article de SQL Server Magazine qui n'aurait pas dû être publié .
Un article de blog de Paul Randal expliquant pourquoi la maintenance des journaux est importante et pourquoi vous ne devriez pas non plus réduire vos fichiers de données .
Mike Walsh a une excellente réponse couvrant également certains de ces aspects, y compris les raisons pour lesquelles vous ne pourrez peut-être pas réduire immédiatement votre fichier journal .
