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


10

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


2
Vous prévoyez de sauvegarder la base de données une fois par nuit et d'exécuter une sauvegarde du journal une fois par nuit? Vous devriez peut-être envisager un modèle de récupération simple pour que le journal se gère lui-même.
Aaron Bertrand

Aaron, je suis d'accord avec vous sur un point de vue de récupération DR, mais pour la récupération opérationnelle, ils peuvent toujours le vouloir aussi complet. N'oubliez pas que même s'ils ne font qu'une sauvegarde de journal une fois par jour, cela permet toujours une récupération ponctuelle.
Kenneth Fisher

1
@Kenneth donc si vous faites une sauvegarde complète à minuit, puis une sauvegarde du journal à 12h05, je trouve cela assez faux. YMMV.
Aaron Bertrand

@Aaron à nouveau, tout est opérationnel, mais à moins que je ne me trompe, vous pouvez utiliser la sauvegarde complète de la nuit précédente, et le journal pris à 12h05 et à une récupération à tout moment de la journée précédente. De plus, s'ils rencontrent un problème, ce n'est pas grave de faire un journal, de restaurer à partir de la nuit précédente et de faire un point dans le temps pour revenir à il y a quelques minutes. Je ne dis pas qu'ils devraient le garder aussi plein, je dis simplement qu'il y a plus d'implication que le point de vue DR. Cela étant dit, s'ils restent aussi complets, ils devraient effectuer des sauvegardes de journaux plus d'une fois par jour.
Kenneth Fisher

2
@Kenneth mais si vous ne sauvegardez le journal qu'une fois par jour, c'est pourquoi c'est énorme en premier lieu! Si vous devez récupérer à 12 h 07 hier, vous devez charger le journal entier pour toute la journée pour récupérer 2 minutes. Pas très utile.
Aaron Bertrand

Réponses:


6

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.


Merci pour cela. Je comprends parfaitement tous les commentaires sur le passage au modèle de récupération simple. malheureusement, c'est une décision que je ne peux pas prendre et qui doit passer par plusieurs niveaux de bureaucratie. C'est certainement quelque chose que je proposerai cependant.
Tim Alexander

12

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:


2

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 utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.