Définir manuellement la taille du fichier journal après la réduction de SQL Server 2008 R2

Je suis en train de devenir un administrateur de base de données quelque peu involontaire au travail au moment et j'ai vraiment besoin d'aide sur quelque chose.

Nous avons une base de données de 40 Go en mode de récupération complète, aucune sauvegarde de journal configurée et un énorme fichier journal de 84 Go. Jusqu'à présent, mon plan pour sauver cette situation consiste à exécuter une sauvegarde complète des journaux sur la base de données, à réduire le fichier journal et à lancer un plan de maintenance pour exécuter une sauvegarde des journaux chaque nuit avec la sauvegarde de la base de données pour aider à la garder sous contrôle.

Mon problème est que je ne veux pas que le fichier journal se réduise à rien et passe le premier matin du lundi à grandir constamment. J'ai une estimation approximative de ce que devrait être le fichier (environ 20% de la base de données) et je voudrais le définir dès le départ pour garantir autant d'espace contigu que possible. S'agit-il simplement d'un cas de modification de "Taille initiale" sous Propriétés de la base de données -> Fichiers? Je suppose également que la base de données devrait être hors ligne pour que cela se produise?

Merci d'avance

Réduisez simplement ce que vous pensez être la taille optimale. N'utilisez pas l'interface utilisateur, faites simplement cela - disons que 200 Mo est votre taille optimale:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);

Si vous ne souhaitez effectuer une sauvegarde des journaux qu'une fois par jour et que la récupération ponctuelle ne vous intéresse pas, vous devez passer à un modèle de récupération simple. Cela signifie que les sauvegardes de journaux ne sont pas nécessaires (en fait impossibles), mais le contenu du journal sera auto-géré.

Si vous souhaitez que les sauvegardes de journaux soient significatives, ne prévoyez pas d'effectuer une sauvegarde complète la nuit, puis une sauvegarde de journal unique juste après. Cela vous maintient dans le modèle de récupération complète, rend le journal vraiment difficile et ne vous achète rien. Donc, si vous souhaitez une récupération ponctuelle, exécutez les sauvegardes de journaux plus fréquemment à un rythme qui satisfait votre tolérance à la perte de données. Si vous ne souhaitez jamais perdre plus de 15 minutes de données, exécutez une sauvegarde du journal toutes les 15 minutes.

La gestion de vos fichiers peut être une opération entièrement en ligne. Vous disposez de deux chemins, selon votre besoin de conserver vos informations de journal à des fins de récupération:

Récupération ponctuelle non nécessaire

1. Convertissez la base de données en SIMPLErécupération. Exécutez un point de contrôle pour écrire des transactions sur le disque.
2. Aplatissez la bûche.
3. Redimensionnez le journal à la taille appropriée.

Je recommande également de définir un montant de croissance fixe et une croissance illimitée (afin de mieux gérer votre journal). Remarque, le montant de la croissance fixe dépend beaucoup du montant, je recommanderais d'utiliser initialement 1 à 2 Go en fonction de la croissance que le journal pourrait s'attendre à voir. Idéalement, votre journal ne grandira pas beaucoup, donc cela ne devrait pas avoir beaucoup d'impact. Si votre journal augmente régulièrement, vous devrez peut-être revoir votre taille.

Accompli en utilisant:

ALTER DATABASE [foo] 
SET RECOVERY SIMPLE;

CHECKPOINT;

DBCC SHRINKFILE (foo_log,0);

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

--Optional if you want the database in full recovery mode 
--for point in time recovery going forward
ALTER DATABASE [foo] 
SET RECOVERY FULL;

Récupération ponctuelle nécessaire

Le plus gros blocage sera que vous ne pouvez pas réduire votre fichier journal au-delà de votre segment VLF actuellement actif. Pour voir cela, vous pouvez utiliser DBCC LOGINFOdans le contexte de la base de données. Tout segment avec un statut = 2 est actif. Pour effacer les segments actifs, vous devrez exécuter une sauvegarde du journal des transactions lorsqu'aucune transaction n'est actuellement active dans ce segment. Vos étapes sont:

1. Exécutez une sauvegarde du journal des transactions.
2. Réduisez votre fichier. (Idéalement aplatir, mais si votre base de données est active, cela sera difficile à faire).
3. Répétez les étapes 1 et 2 jusqu'à ce que votre journal soit d'une taille appropriée, idéalement aussi petite que possible.
4. Redimensionnez le journal à la taille appropriée.

Accompli en utilisant:

BACKUP LOG [foo] TO DISK='<Location of t-log backup>';

DBCC SHRINKFILE (foo_log,0);

--Repeat the above until your log file is small "enough"

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

Quelques ressources supplémentaires pour comprendre ce qui se passe ici:

• Modèles de récupération SQL Server

• Les recommandations t-log de Kimberly Tripp

• Points de contrôle de la base de données

En fait non, la base de données n'a pas besoin d'être hors ligne pour réduire le journal. Et je dirai que c'est probablement l'un des rares cas où la réduction du journal est une bonne idée. Vous pouvez définir la taille initiale, mais il serait plus facile de réduire et de lui dire de réduire à une taille spécifique.

USE [DBName]
GO
DBCC SHRINKFILE (N'LogName' , SizeInMg)
GO

Vous pouvez également le faire en utilisant l'interface graphique et en utilisant le deuxième bouton radio et la case à cocher qui indique la taille que vous souhaitez que le journal soit à la fin. Vous pouvez accéder à l'interface graphique en cliquant avec le bouton droit sur la base de données dans l'explorateur d'objets dans SSMS, en sélectionnant les tâches, la réduction, les fichiers.

En complément de la réponse d' Aaron sur le mode simple , vous pouvez planifier 2 (ou plus) sauvegardes différentielles par jour, réduisant ainsi la fenêtre de perte de données de votre opération de base de données tout en conservant le mode SIMPLE.