Avant de marquer immédiatement comme doublon , j'ai lu pourquoi 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 répondu à ma situation. J'ai regardé à travers une douzaine de questions similaires, mais les questions pertinentes ont simplement dit "dupliquer" et ont pointé 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_descde sys.databasesdit dit "RIEN", qui sur la base de la question et réponse référencée ci-dessus dit qu'il ne devrait pas attendre quoi que ce soit 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 avait besoin de 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.