web-dev-qa-db-fra.com

Journal des transactions saturé en raison de log_backup

Je teste comment certaines opérations sont enregistrées sous différents modèles de récupération. Voici les étapes que j'ai suivies jusqu'à présent

1. créer une base de données dans un modèle de récupération complète
2.prendre une sauvegarde
3.créer un tableau et insérer 10 millions d'enregistrements
4.Prendre la sauvegarde du journal, vérifier VLF compter et voir le pourcentage d'espace libre dans le journal
5.Maintenant, effectuez une reconstruction d'index et voyez les enregistrements générés à l'aide de la fonction fn_dblog

6.Maintenant, je suis passé au modèle de récupération en masse
7.A effectué une sauvegarde
8.Une sauvegarde du journal
9. a fait une reconstruction d'index

Étrangement, la reconstruction de l'index échoue avec l'erreur ci-dessous.

La déclaration est terminée. Msg 9002, niveau 17, état 2, ligne 1 Le journal des transactions pour la base de données 'bulklogging' est plein en raison de 'LOG_BACKUP'.

ce n'est pas vrai, en fait

La croissance automatique de l'espace du journal n'est pas restreinte

Autogrwoth setting

2.Espace où le fichier journal est stocké

space on drive where log file is stored

Quelqu'un peut-il m'aider à comprendre pourquoi j'obtiens au-dessus de l'erreur, même s'il y a de l'espace et que la croissance automatique n'est pas rétablie

ajout d'une image de la taille de l'index ..

Le problème a été résolu, mais je ne sais pas comment ce changement a fait la différence.Tous les conseils seraient très appréciés.

Le commentaire dit deux longs - donc à poster ici ...

j'ai scripté à nouveau l'index, après avoir changé de modèle de récupération, puis cela a fonctionné.En outre, l'index scripté avant et après reste exactement le même, seule la session a été modifiée.Mais je ne sais pas comment cela a fonctionné.

Avant: 

USE [bulklogging]  
GO  
ALTER INDEX [PK__bcc__3213E83FAC9DB5ED] ON [dbo].[bcc] 
REBUILD PARTITION = ALL WITH (PAD_INDEX = OFF, 
STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO

Après: 

USE [bulklogging]  
GO  
ALTER INDEX [PK__bcc__3213E83FAC9DB5ED] ON [dbo].[bcc] 
REBUILD PARTITION = ALL WITH (PAD_INDEX = OFF, 
STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO

Mise à jour pour fermer cette question:
J'utilise Fn_dblog pour vérifier les enregistrements du journal, cela semble avoir un bug caché comme décrit ici , qui peut affecter la croissance de mon journal ..

Edit 15/08/13: Attention - Jonathan vient de découvrir à partir d'un système client qui l'utilise largement que chaque fois que fn_dump_dblog est appelé, il crée un nouveau planificateur SQLOS caché et jusqu'à trois threads, qui ne disparaîtront pas (et ne disparaîtront pas être réutilisé) jusqu'au redémarrage du serveur. C’est un bug que l’équipe SQL va corriger maintenant que nous l’avons alerté. Utiliser avec précaution.

Modification du 15/05/15: elle a été corrigée dans SQL Server 2012 SP2 + et SQL Server 2014. La correction ne sera plus rétroportée plus tôt.

enter image description here

sql-servertransaction-log
7
TheGameiswar

Cette erreur se produit car le journal des transactions est plein en raison de LOG_BACKUP. Par conséquent, vous ne pouvez effectuer aucune action sur cette base de données et, dans ce cas, le moteur de base de données SQL Server génère une erreur 9002.

Dans ce cas, vous devez faire

  • Faites une sauvegarde complète de la base de données.
  • Réduisez le fichier journal pour réduire la taille du fichier physique.
  • Créez un LOG_BACKUP.
  • Créez un plan de maintenance LOG_BACKUP pour prendre fréquemment les journaux de sauvegarde.

Remarque: L'opération de rétrécissement affecte les performances de SQL Server lors de l'exécution de la commande de rétrécissement. il provoque également la fragmentation de l'index et peut ralentir les performances des requêtes qui recherchent une plage de l'index.

Par conséquent, avant la mise en service, il est recommandé de préparer n plan de maintenance LOG_BACKUP pour sauvegarder fréquemment le fichier journal afin d'éviter l'opération de réduction en production.

Pour plus de détails, vérifiez Le journal des transactions de la base de données ‘SharePoint_Config’ est plein en raison de LOG_BACKUP

J'espère que cela vous aidera

6
Mohamed El-Qassas MVP

J'ai rencontré ce problème aujourd'hui avec l'une de mes bases de données de production. Je l'ai résolu en ajoutant un deuxième fichier journal à la base de données. Je n'ai pas pu effectuer une sauvegarde complète ou effectuer une réduction du fichier journal comme décrit ci-dessus, car lorsque j'essayais de générer le LOG_BACKUP Message d'erreur. J'ai également tenté d'étendre le fichier journal, mais cela a également généré la même erreur. À la fin, l'ajout d'un deuxième fichier journal plus petit a rendu la base de données réutilisable - après quoi j'ai pu sauvegarder la base de données et redimensionner le journal d'origine.

0
Mr.Brownstone