Pourquoi le journal des transactions continue-t-il de croître en mode de récupération simple avec des sauvegardes nocturnes
Avant de marquer immédiatement comme doublon , j'ai lu Mike Walsh Pourquoi le journal des transactions continue-t-il de croître ou de manquer d'espace? , mais je ne pense pas que cela ait donné de réponse à ma situation. J'ai regardé à travers une douzaine de questions similaires, mais les plus pertinentes venaient juste de dire "dupliquer" et pointaient la question de Mike.
Détails: J'ai un tas de bases de données de ~ 500 Mo sur SQL Server 2008 R2, toutes en mode de récupération SIMPLE (pas mon choix), des sauvegardes complètes nocturnes, avec ~ 200 Mo de fichiers de données et ~ 300 Mo de fichiers journaux. Le journal n'atteint pas immédiatement 300 Mo, mais plutôt lentement au cours de quelques mois. Il n'y a aucune transaction ouverte sur aucun d'entre eux, du moins selon sp_who2 et le moniteur d'activité. Si je clique avec le bouton droit sur la base de données et sélectionne les propriétés, cela m'indique qu'il y a ~ 50 Mo d'espace libre. Particulièrement juste après une sauvegarde, le journal entier ne devrait-il pas être gratuit? En mode SIMPLE, le journal ne devrait-il pas être gratuit tant qu'il n'y a pas de transaction ouverte?
log_reuse_wait_desc de sys.databases dit dit "RIEN", ce qui, sur la base de la question et de la réponse référencée ci-dessus, indique qu'il ne devrait rien attendre pour réutiliser l'espace.
Si je fais "DBCC SHRINKFILE", le fichier journal se réduit à 1 Mo, il est donc prêt à récupérer l'espace. Je peux configurer quelque chose qui réduit les journaux chaque semaine et empêcher les choses de devenir hors de contrôle, mais je ne comprends pas pourquoi SQL Server me ferait faire cela.
Je peux comprendre s'il y avait une transaction folle qui nécessitait 300 Mo pour la journaliser, mais nous ne faisons rien d'extrême, juste OLTP de base. D'après la question/réponse de Mike:
Modèle de récupération simple - Donc, avec l'introduction ci-dessus, il est plus facile de parler d'abord du modèle de récupération simple. Dans ce modèle, vous dites à SQL Server - je suis d'accord avec vous en utilisant votre fichier journal des transactions pour la récupération après incident et redémarrage (vous n'avez vraiment pas le choix là-bas .. Recherchez les propriétés ACID et cela devrait avoir un sens rapidement), mais une fois que vous n'avez pas vous en aurez plus besoin à des fins de récupération après un crash/redémarrage, continuez et réutilisez le fichier journal.
SQL Server écoute cette demande dans Simple Recovery et ne conserve que les informations dont il a besoin pour effectuer une récupération après panne/redémarrage. Une fois que SQL Server est sûr qu'il peut récupérer car les données sont durcies dans le fichier de données (plus ou moins), les données qui ont été durcies ne sont plus nécessaires dans le journal et sont marquées pour la troncature - ce qui signifie qu'elles sont réutilisées.
Il continue de dire que l'espace journal devrait être réutilisé, mais avec cette croissance lente au cours des mois, il ne semble pas que ce soit le cas.
Qu'est-ce que je rate? Quelque chose empêche-t-il SQL Server de reconnaître les données comme "renforcées" et de libérer le journal?
(modifier) Le rapport après action - AKA un peu de connaissance est dangereux
Après avoir découvert qu'il s'agissait d'une "question populaire", j'ai eu l'impression que je devais une explication de ce qui s'est passé il y a 7 mois et de ce que j'ai appris pour, espérons-le, sauver d'autres personnes du chagrin.
Tout d'abord, l'espace disponible que vous voyez dans SSMS lorsque vous affichez les propriétés d'une base de données est l'espace disponible dans le fichier de données. Vous pouvez le voir en exécutant ce qui suit sur une base de données, et vous constaterez que l'espace disponible signalé par SSMS est la différence entre FileSizeMB et UsedSpaceMB:
SELECT
DB.name,
MF.physical_name,
MF.type_desc AS FileType,
MF.size * 8 / 1024 AS FileSizeMB,
fileproperty(MF.name, 'SpaceUsed') * 8/ 1024 AS UsedSpaceMB,
mf.name LogicalName
FROM
sys.master_files MF
JOIN sys.databases DB ON DB.database_id = MF.database_id
WHERE DB.name = 'yourdatabasename'
Cela a confirmé que dans des circonstances normales, nous utilisions très peu d'espace de journal (20 Mo ou moins), mais cela nous amène au deuxième élément ...
Deuxièmement, ma perception de la croissance des grumes était celle de lentement au fil du temps. Cependant, en réalité, les journaux augmentaient rapidement les nuits où le gars responsable de l'application des correctifs pour cette application tierce appliquait des correctifs. Le correctif a été effectué en une seule transaction, donc selon le correctif, les données de 200 Mo nécessitaient 300 Mo de journal. La clé du suivi a été la requête d'Aaron Bertrand sur https://sqlblog.org/2007/01/11/reviewing-autogrow-events-from-the-default-trace
DECLARE @path NVARCHAR(260);
SELECT
@path = REVERSE(SUBSTRING(REVERSE([path]),
CHARINDEX('\', REVERSE([path])), 260)) + N'log.trc'
FROM sys.traces
WHERE is_default = 1;
SELECT
DatabaseName,
[FileName],
SPID,
Duration,
StartTime,
EndTime,
FileType = CASE EventClass
WHEN 92 THEN 'Data'
WHEN 93 THEN 'Log'
END
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE
EventClass IN (92,93)
ORDER BY
StartTime DESC;
Cela montrait que le journal augmentait certains soirs, lorsque le client n'utilisait pas la base de données. Cela a conduit à la conversation avec le gars appliquant les patchs et la réponse au mystère.
Merci encore pour les personnes qui m'ont aidé à obtenir la réponse.
Il nous est impossible de deviner ce qui en est la cause, mais SQL Server ne fait pas que développer un fichier journal à 300 Mo pour le diable, il atteint 300 Mo car à un moment donné depuis votre dernière opération de réduction, il en avait besoin beaucoup d'espace de journal (que ce soit en raison d'une grosse transaction unique ou de beaucoup de petites transactions simultanées). Vous devez suivre les événements de croissance des fichiers journaux (j'en ai parlé ici et ici ) pour essayer de préciser quand ou pourquoi cela se produit (également si vous enregistrez la croissance des fichiers est de 300 Mo ou quelque chose comme ça, alors il augmentera de 300 Mo dès qu'il aura besoin de plus de 1 Mo d'espace pour accueillir les transactions actives).
Quoi qu'il en soit, pourquoi pensez-vous que vous devez réduire le fichier journal une fois qu'il a atteint 300 Mo? Avez-vous réellement lu toutes les réponses, à fond, sur question de Mike ? Le fichier journal ne va PAS se réduire de lui-même, car la réduction du fichier journal à 1 Mo - juste pour qu'il puisse augmenter à nouveau lors de vos transactions les plus importantes - est une perte de temps totale. Qu'allez-vous faire de tout cet espace libre en attendant?
Tous vos tests actuels (DBCC SHRINKFILE, log_reuse_wait_desc) prouve simplement que --- maintenant vous réutilisez les fichiers journaux virtuels du journal des transactions de manière appropriée. Mais lorsque vos événements de croissance automatique se produisent sur votre fichier journal de transactions, c'est une réaction au fait que le journal ne peut pas être réutilisé.
Souvent, cela n'est pas une condition en cours (exactement ce qu'il vous semble en ce moment avec le manque de symptômes que vous voyez actuellement). Il existe une poignée de choses qui pourraient provoquer ce comportement, même dans le modèle de récupération simple.
Le mieux serait de configurer un travail de collecte de données pour tirer régulièrement le log_reuse_wait_desc pour votre base de données, et enregistrez-le régulièrement quelque part. Vous devriez ensuite être en mesure de procéder à une rétro-ingénierie de la cause du manque de réutilisation des journaux.
Il continue de dire que l'espace journal devrait être réutilisé, mais avec cette croissance lente au cours des mois, il ne semble pas que ce soit le cas.
Comme je l'ai indiqué ci-dessus, ce n'est généralement pas une condition continue qui provoque le manque de réutilisation du journal des transactions (sauf quelques cas de coin, comme des transactions mal construites), vous devez donc déterminer les moments où cela is = passe. La collecte légère des données de diagnostic devrait être un bon début.
Le rétrécissement automatique est-il activé sur les bases de données? Et/ou avez-vous des plans de maintenance planifiés effectuant des reconstructions d'index?
Un rétrécissement automatique suivi d'une maintenance d'index produira un volume de journal important.
La maintenance des index en elle-même produira également un volume important de journaux, s'il existe des problèmes de conception de base de données comme des index clusterisés sur les GUID.