Le journal des transactions de la base de données 'nom_base_de_données' est plein en raison de 'XTP_CHECKPOINT'
J'ai une question sur XTP_CHECKPOINT.
J'utilise SQL Server 2014. J'ai une base de données qui est en mode modèle de récupération SIMPLE. Il est également en cours de réplication.
Il n'y a pas de transactions ouvertes. J'ai couru DBCC OPENTRAN et il renvoie:
"Aucune transaction ouverte active."
Mais je continue à recevoir ce message chaque fois que j'essaie de créer ou de supprimer une table ou de supprimer des données:
(J'ai remplacé mon nom de base de données réel par le mot database_name)
"Le journal des transactions de la base de données 'nom_base_de_données' est plein en raison de 'XTP_CHECKPOINT'"
Est-ce que quelqu'un sait pourquoi cela pourrait se produire et, plus important encore, comment puis-je faire en sorte que cela cesse?
Et oui, la base de données est vraiment en mode modèle de récupération SIMPLE. c'est-à-dire que le journal des transactions doit être tronqué automatiquement.
Par ailleurs, une autre base de données que j'ai en mode de récupération complète a fait la même chose, a commencé à renvoyer la même erreur:
Le journal des transactions de la base de données 'nom_base_de_données' est plein en raison de 'XTP_CHECKPOINT'
J'ai essayé de changer les paramètres de croissance du journal en une croissance illimitée, mais cela ne m'a pas permis de retourner la même erreur.
Je peux reproduire le problème sans aucun élément XTP, à l'exception du groupe de fichiers. Voici comment: http://Pastebin.com/jWSiEU9
J'ai eu un problème similaire: je n'avais pas de réplication mais une fois que j'ai utilisé la table Memory Optimized comme test, la base de données en mode de récupération simple, mais mes journaux de transactions n'étaient pas tronqués. La troncature manuelle, même juste après une sauvegarde complète, a donné l'erreur:
Impossible de réduire le fichier journal X car le fichier journal logique situé à la fin du fichier est en cours d'utilisation.
Un point de contrôle manuel a échoué:
Msg 41315, niveau 16, état 4, opération de point de contrôle de ligne N a échoué dans la base de données X.
Un point de contrôle manuel n'a réussi qu'après le redémarrage du service SQL, ce qui entraînerait un état de récupération de 4 heures en raison de la taille de ma base de données Multi Tb. J'ai également essayé de définir la croissance automatique à une taille spécifique, mais tout a fini par faire de même: remplir les journaux de transactions jusqu'à ce qu'il ne reste plus d'espace.
Enfin, après des jours et des nuits à essayer et à rechercher, j'ai trouvé la solution à mon problème en installant Cumulative Update 3 pour SQL Server 2014 SP1
Assurez-vous d'abord que la réplication n'est pas à l'origine de cela, comme indiqué dans élément de connexion "log_wait_reuse_desc = XTP_CHECKPOINT ne signifie pas nécessairement que le travailleur du point de contrôle XTP retarde la troncature du journal". alors commencez par exécuter sp_repltrans et assurez-vous que toutes les données ont été distribuées.
Ensuite, il y a ce petit extrait ici:
"cela se produit sur une base de données, qui a un groupe de fichiers optimisé en mémoire, qu'il y ait ou non des tables optimisées en mémoire.
La solution de contournement actuelle est définie sur l'AutoGrown à une taille fixe. Ou, changer le mode de récupération pour être simple et réduire le journal. "
Donc, si le nettoyage de la réplication ne fonctionne pas, essayez ce qui suit:
checkpoint;
dbcc shrinkfile (Logfile, truncateonly)
alter database [database] modify file (filename = 'TRANSACTIONLOG', FILEGROWTH = 5MB)
Il n'est pas indiqué s'il s'agit du fichier journal ou des fichiers de base de données, mais commençons par essayer les fichiers journaux et sinon, essayez de définir les fichiers de base de données sur une croissance fixe:
J'ai pu contourner le problème en ajoutant un autre fichier journal, ce qui m'a ensuite permis d'exécuter une sauvegarde complète, d'ajuster la taille du fichier journal principal et la croissance plafonnée ainsi que de supprimer le fichier journal supplémentaire ajouté pour résoudre le problème XTP_CHECKPOINT.
J'ai vécu cela avec un client. Le journal et les fichiers de données FILESTREAM en mémoire se trouvaient sur le même lecteur. Ils ont créé un nouveau fichier journal (peu l'ont suggéré) mais le système ne peut pas CHECKPOINT car il ne parvient pas à créer les fichiers de point de contrôle en mémoire (* .HKCKP).
Essayez de libérer de l'espace sur le lecteur avec les données FILESTREAM en mémoire.