Passer à la récupération simple - réduction des journaux de transactions
Avertissement standard: je suis un "DBA involontaire" (une belle expression que j'ai vue dans cet article ) et que j'ai fait lots et lots et - lots et lots et lots de lecture sur ce sujet, mais je suis toujours confus/inquiet ...
J'ai besoin de changer le modèle de récupération de plusieurs bases de données de production SQL Server 2014 de Full à Simple.
Les bases de données sont actuellement définies sur Récupération complète et étaient sauvegardées à l'aide de SqlBackupAndFTP , qui effectuerait une sauvegarde complète quotidienne, avec 3 sauvegardes différentielles et 20 sauvegardes de transactions chaque jour. Cela fonctionnait bien jusqu'à ce que nous ayons d'énormes problèmes avec la société fournissant un stockage FTP.
Il y a environ 3 mois, je suis passé à l'utilisation de Attix5 qui fonctionne bien - cependant, j'ai maintenant découvert qu'en raison du fonctionnement du logiciel, les journaux de transactions sont aussi gros que les fichiers de données (dans un cas supérieur à 14 Go contre un fichier de données de 13 Go).
Il m'a été recommandé de basculer le modèle de récupération sur Simple, afin que le journal des transactions ne se développe pas.
Je sais qu'avoir Simple Recovery ne fournira pas de restauration ponctuelle - c'est tout à fait correct, car les sauvegardes complètes ont lieu toutes les heures et nous sommes " heureux de perdre "tout ce qui aurait pu arriver au cours des 1 à 59 minutes précédentes.
Ma compréhension est que je devrais définir le modèle de récupération sur Simple et laisser la sauvegarde avoir lieu, ce qui définira un point de contrôle dans le journal des transactions permettant la réutilisation de l'espace.
Cependant, j'ai vraiment besoin de réduire le journal des transactions à une taille raisonnable (afin qu'il n'occupe pas autant d'espace de sauvegarde), mais je continue à lire que la réduction est une mauvaise idée. Ou est-ce que je reçois la mauvaise extrémité du bâton?
Si je réduis le journal des transactions à environ 25 Mo (ce qui devrait facilement être assez grand pour un ensemble de transactions toutes les heures) à l'aide de la commande suivante, est-ce suffisant?
DBCC SHRINKFILE('log file name',25)
(Je suis vraiment désolé de demander quelque chose qui semble avoir été demandé un million de fois auparavant, mais ce n'est pas quelque chose que je peux me tromper.)
Tout d'abord, je voudrais souligner à nouveau que, dans la plupart des cas, la récupération SIMPLE n'est pas recommandée pour une base de données de production. Cependant, si c'est quelque chose que vous souhaitez modifier de la meilleure façon que j'ai trouvée pour réduire le fichier LOG, après avoir mis la base de données dans le modèle de récupération SIMPLE, procédez comme suit. Cela permettra non seulement de libérer de l'espace libre du journal, mais également de réduire le fichier à sa taille la plus petite possible.
Comme vous l'avez dit, la réduction n'est pas non plus normalement une bonne pratique, mais il y a des moments où cela est justifié. Il existe de nombreux articles pour/contre à ce sujet, et je suis d'accord avec ceux qui vous diront de ne jamais utiliser DBCC SHRINKDATABASE; utilisez toujours DBCC SHRINKFILE si vous devez absolument faire un rétrécissement.
Cependant, le fichier journal doit en effet avoir une taille raisonnable, même dans le modèle de récupération SIMPLE, car c'est là que les informations sont conservées pendant les transactions et les SPID de longue durée ont besoin de plus d'un fichier journal. Parmi de nombreuses raisons, l'une d'entre elles est la restauration en cas de problème. Comme je l'ai indiqué ci-dessus, ces scripts réduiront votre fichier journal à sa taille la plus petite possible, mais comme vous avez besoin d'au moins un peu d'espace de journal, vous devez le suivre en le repoussant manuellement et assurez-vous également que votre "croissance automatique" est définie sur une valeur raisonnable. nombre; sans doute, un pourcentage doit toujours être évité. Réduire le journal à sa plus petite taille et le repousser manuellement accomplit un processus très important - celui de garder votre VLF fragmentation/décompte. C'est un autre sujet que je n'entrerai pas ici, et de nombreux sites, y compris Brent Ozar peut entrer dans les statistiques et les tests réels montrant pourquoi, mais augmentez toujours votre fichier journal de 8 Go par croissance s'il doit être aussi grand ou plus grand. Vous avez mentionné plus de 25 Mo et je ne peux pas imaginer que ce soit assez grand. Je gère personnellement plus d'une centaine de bases de données en ce moment, et moins d'une douzaine sont définies sur 64 Mo. Toutes les autres sont beaucoup plus grandes, allant jusqu'à 64 Go. Votre activité SQL réelle et vos requêtes détermineront quelle devrait être votre taille optimale. Au minimum Je passerais de 512 Mo à 2 Go et je définirais votre croissance de la même manière jusqu'à ce que vous sachiez à quoi votre fichier journal devrait s'asseoir.
Je trouve que l'exécution de chaque ligne séparément fonctionne le mieux, garantissant le succès avant de passer à l'étape suivante. La dernière ligne est bien sûr ce qui fait repousser votre journal à la taille que vous avez définie. Je l'ai à 8 Go, mais vous pouvez changer cela pour répondre à vos besoins. Si vous ne voulez pas pour l'instant réduire complètement puis repousser, supprimez la dernière ligne et changez le "1" dans la ligne ci-dessus pour votre choix de taille.
Une dernière chose avant de sortir et de réduire votre fichier journal.
IMPORTANT: Chaque fois qu'un fichier journal se développe, manuellement ou automatiquement par SQL, votre base de données entière est verrouillée jusqu'à la fin de la croissance. Choisissez un bon moment lorsque cela n'affectera pas les transactions actives - si vous avez des "heures supplémentaires" ou des fenêtres de maintenance. Une telle petite taille de 1 Go ou moins devrait être assez rapide et invisible pour l'utilisateur final, mais cela sera vraiment déterminé par votre infrastructure.
USE [DatabaseName]
DBCC SHRINKFILE (N'LogicalName', 0, TRUNCATEONLY)
DBCC SHRINKFILE (N'LogicalName', 1)
ALTER DATABASE [DatabaseName] MODIFY FILE ( NAME = N'LogicalName', SIZE = 8192 MB )
Avis de non-responsabilité standard: Je suis un "DBA involontaire" (une belle phrase que j'ai vue dans cet article) et j'ai fait beaucoup, beaucoup et beaucoup et beaucoup et beaucoup de lecture sur ce sujet, mais je suis toujours confus/préoccupé ...
Vous savez donc que vous jouez avec une épée à double tranchant et vous êtes conscient des risques - tout tranchant que vous toucherez, vous allez vous couper.
J'ai maintenant découvert qu'en raison de la façon dont le logiciel fonctionne, les journaux de transactions sont aussi gros que les fichiers de données (dans un cas, plus de 14 Go contre un fichier de données de 13 Go).
Vérifiez auprès du fournisseur, s'ils sont en annexe les fichiers de sauvegarde du journal des transactions ou non et utilisez compression de sauvegarde .
Je sais qu'avoir Simple Recovery ne fournira pas de restauration ponctuelle - c'est tout à fait correct, car des sauvegardes complètes ont lieu toutes les heures et nous sommes "heureux de perdre" tout ce qui aurait pu se produire au cours des 1 à 59 minutes précédentes.
Je vois un problème là-dedans. Si je comprends bien, vous combattez l'espace de stockage sur disque. Une sauvegarde complète occupera plus d'espace à chaque fois par rapport à une sauvegarde du journal des transactions (ou une sauvegarde différentielle du journal).
Vous devriez consulter le fournisseur de votre outil de sauvegarde et lui demander de résoudre le problème. Sinon, pourquoi ne pas utiliser un solution T-SQL - qui a plus de transparence et de contrôle sur ce que vous faites, par opposition à l'utilisation d'un outil dont vous savez qu'il vous pose des problèmes.
Vous devriez lire une autre réponse impressionnante - Pourquoi le journal des transactions continue-t-il de croître ou de manquer d'espace?
J'ai vraiment besoin de réduire le journal des transactions à une taille raisonnable
Vous devriez découvrir à quelle fréquence la croissance automatique se déclenche et commencer par une valeur moyenne, puis ajuster. Un dimensionnement correct du journal des transactions est très important et veuillez ne pas y aller avec 25 Mo. Ses sons sont trop faibles et sa valeur sera trop faible, ce qui commencera à déclencher plus fréquemment les événements de croissance automatique.
Si votre journal de transactions est gros, alors (passez votre souris ci-dessous)
Ne laissez pas l'outil de buggy de votre vendeur affecter votre décision sensée :-)