Le journal des transactions est plein en raison de «CHECKPOINT» pour la base de données dans un modèle de récupération simple
Pour l'une de nos bases de données sur SQL Server 2012 RTM,
Nous n'avons pas pu effectuer presque aucune étape de dépannage car l'erreur indique:
"Le journal des transactions est plein en raison de" CHECKPOINT "
Comme il s'agit d'une base de données de développement, sa sauvegarde n'a jamais eu lieu, nous sommes donc même hors option.
J'ai essayé de réduire le fichier journal mais pas de succès et j'ai obtenu une erreur ci-dessous:
le journal manque d'espace - avec une erreur en cascade que le journal des transactions est plein en raison de 'CHECKPOINT'
DBCC CHECKDB donne principalement des erreurs car le journal des transactions est plein en raison de 'CHECKPOINT'
Je ne peux pas changer le modèle de récupération en full - obtenez une erreur car le journal des transactions est plein en raison de 'CHECKPOINT'
Impossible de prendre la sauvegarde: même erreur:
Même essayé de se détacher et de se reconnecter à un autre serveur (SQL Server 2012 RTM), mais même erreur:
Essayé de faire manuellement CHECKPOINT sur la base de données, mais toujours la même erreur:
Ont déjà refred à ce poste ici Journal de transactions de base de données de modèle simple plein 'CHECKPOINT'
et
Le journal des transactions de la base de données 'nom_base_de_données' est plein en raison de 'XTP_CHECKPOINT' , mais sans succès.
Remarque: nous n'avons pas de réplication configurée sur le serveur actuel ou sur une base de données.
S'il vous plaît, aidez-moi car je ne peux pas trouver une cause racine et résoudre ce problème!
Merci!
(puisque c'est plus long qu'un commentaire ... donc mettez-le comme réponse)
Pour l'une de nos bases de données sur SQL Server 2012 RTM.
Voilà votre problème. De nombreux correctifs ont été introduits dans les CU/SP consécutifs après la RTM build .
Pouvez-vous patcher le serveur SQL avec le dernier SP2? Après avoir patché, vérifiez si le problème persiste ou non.
Votre problème peut être dû au fait que votre base de données MODEL est peut-être en récupération simple.
Si la base de données du modèle est définie sur le modèle de récupération SIMPLE et que la base de données utilisateur est créée avec le modèle de récupération simple à partir de la base de données modèle , SQL Server ne tronque pas automatiquement son journal comme il le suppose (après une sauvegarde complète). Il semble que SQL Server le traite comme s'il était dans un modèle de récupération complète.
vous pouvez exécuter la sauvegarde du journal ci-dessous (même si votre base de données est en récupération simple - comme le modèle est en récupération simple - en raison d'un bogue en RTM, serveur SQL le traite comme étant en récupération complète )
BACKUP LOG dbName
TO DISK = 'dbName_log_backup.trn'
GO
Vérifiez cette base de connaissances: la base de données ne suit pas le comportement du modèle de récupération simple dans SQL Server 2012 après avoir défini le modèle de récupération de la base de données "modèle" sur "Simple"
Je m'assure simplement - Le fichier journal a-t-il une taille fixe? Si tel est le cas, essayez d'ajouter un fichier journal secondaire à la base de données, puis effectuez un point de contrôle. Si tout le reste échoue, reconstruisez le journal.
ALTER DATABASE <database> set EMERGENCY
ALTER DATABASE <database> REBUILD LOG ON (NAME='<database>',FILENAME='<filename>')
ALTER DATABASE <database> set online
J'ai eu le même problème avec SQL 2016.
J'ai essayé ce qui suit, mais cela n'a pas non plus permis de modifier la base de données avec le même XTP_CHECKPOINT Erreur.
USE [<DBName>]
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE [<DBName>]
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
--checkpoint;
DBCC SHRINKFILE ('<LogName>', 5);
ALTER DATABASE [<DBName>]
MODIFY file (NAME = '<LogName>', MAXSIZE = UNLIMITED, FILEGROWTH = 5MB);
GO
-- Reset the database recovery model.
ALTER DATABASE [<DBName>]
SET RECOVERY FULL;
GO
La seule chose qui a fonctionné pour moi pour récupérer de cet état était d'ajouter un nouveau fichier journal des transactions.
Une fois qu'il est ajouté, nous pouvons utiliser la requête ci-dessus pour réduire le fichier journal, si nécessaire. Mais il est recommandé de vérifier la cause première de la croissance rapide du fichier journal des transactions.
Conseil: essayez d'utiliser la requête ci-dessous pour vérifier l'utilisation du journal pour toutes les bases de données.
DBCC SQLPERF(LOGSPACE);