Le journal des transactions pour la base de données est plein en raison de «OLDEST_PAGE»
Nous avons une base de données hébergée sur Azure. Il fait partie d'une piscine élastique Azure. Depuis hier, toutes nos opérations de base de données échouent systématiquement avec l'erreur suivante.
Le journal des transactions pour la base de données est plein en raison de "OLDEST_PAGE"
Nous avons vérifié toutes les transactions actives dans la base de données, mais il n'y a aucune transaction active actuellement, mais le fichier journal occupe toujours 100% de l'espace.
J'ai parcouru les pages de documentation suivantes, mais je n'ai pas pu comprendre complètement le problème:
Quelqu'un peut-il m'aider à comprendre ce problème?
Mise à jour
Lorsque nous avons déplacé cette base de données vers un nouveau pool, la taille du journal a été automatiquement réduite. Nous ne rencontrons aucun problème après le déménagement.
Ce n'est pas quelque chose que vous devriez voir sur une base de données SQL Azure. Vous devriez engager un soutien à ce sujet.
Il y a quelques choses que vous pouvez faire vous-même, si vous le souhaitez. Essayez tout d'abord de CHECKPOINT la base de données. Deuxièmement, si vous êtes sûr de ne pas avoir de transactions actives, modifiez le SLO de la base de données. Le retirer de la piscine élastique, puis le remettre.
Remarque: j'ai écrit cette réponse avant de réaliser que c'était sur Azure SQL DB ( la réponse de David semble indiquer qu'il s'agit d'un comportement de buggy légitime dans Azure).
Laissant ici car l'OP cherchait également une explication sur ce que cette erreur signifiait, et peut-être que cela sera utile pour les autres dans une configuration sur site avec cette erreur.
Votre journal des transactions est plein. En regardant la capture d'écran que vous avez partagée, ce n'est que 59 Mo. Ce qui est assez petit. On pourrait penser qu'il continuerait de croître pour accueillir plus de transactions. Mais cela ne peut pas pour une raison quelconque.
SQL Server souhaite commencer à réutiliser le fichier journal. Mais vous avez cette embêtante OLDEST_PAGE chose qui se passe. Cela signifie qu'il existe des pages de date modifiées en mémoire qui n'ont pas été conservées dans le fichier de données sur le disque, et donc SQL Server ne peut pas commencer à réutiliser la partie du journal des transactions qui documente ces transactions potentiellement non persistantes.
Un correctif temporaire consisterait à exécuter manuellement la commande CHECKPOINT sur le serveur, pour essayer de forcer le vidage de ces pages en mémoire tampon sur le disque. Vous devrez peut-être exécuter la commande plusieurs fois, mais cela permettra au fichier journal des transactions de commencer à être réutilisé.
Le plus gros problème est avec votre journal des transactions. Vous devez exécuter cette requête:
select max_size, growth from sys.master_files where [name] = 'YourLogFileName';
Et alors:
Vérifiez max_size pour voir s'il existe un maximum explicite empêchant la croissance de votre fichier journal
Si tel est le cas, définissez max_size à un plus grand nombre pour tenir compte de votre charge transactionnelle réelle. Le nombre dépendra de votre nombre habituel de transactions et du modèle de récupération que vous utilisez.
Vérifiez growth pour voir si la croissance automatique a été désactivée (croissance = 0)
S'il est désactivé, vous pouvez l'activer.
Si vous ne pouvez pas le faire et que vous êtes dans le modèle de récupération COMPLET, vous pouvez planifier des sauvegardes de journaux plus fréquentes.
Si vous ne pouvez pas le faire et que vous êtes dans le modèle de récupération SIMPLE, vous devrez augmenter la taille du fichier journal manuellement jusqu'à ce qu'il soit suffisamment grand pour gérer les transactions que vous avez entre des points de contrôle automatiques ou indirects.
Il est possible, peut-être, que le disque de votre stockage Azure soit plein et c'est ce qui empêche la croissance du fichier (bien que je m'attende à des messages d'erreur différents).
Pour ma base de données, cela était dû à la fonction de points de contrôle indirects. Si votre application n'a pas beaucoup de pages sales, mais beaucoup de journaux de transactions, le journal continuera de croître. Par exemple, Citrix mettra à jour la même colonne encore et encore. Cela n'augmente pas le nombre de pages sales. Les points de contrôle indirects dépendent du nombre de pages sales pour savoir quand exécuter un point de contrôle.
Désactivez la fonction de point de contrôle indirect:
ALTER DATABASE DBName SET TARGET_RECOVERY_TIME = 0 SECONDS WITH NO_WAIT
Ce n'est peut-être pas la raison, mais c'est ce qui l'a causé à ma base de données.