"Le journal des transactions pour la base de données est complet en raison de 'LOG BACKUP' " dans un hôte partagé

j'ai un Asp.Net site Web MVC 5 avec L'approche "Entiteframcadre codefirst" dans un plan d'hébergement partagé. Il utilise l'open source WebbsitePanel pour le panneau de contrôle et son panneau SQL Server est quelque peu limité. Aujourd'hui quand j'ai voulu éditer la base de données, je rencontre cette erreur:

The transaction log for database 'db_name' is full due to 'LOG_BACKUP'

j'ai cherché et trouvé beaucoup de réponses comme ce et ce ou ce mais le problème est qu'ils suggèrent d'exécuter une requête sur la base de données. J'ai essayé de courir

db.Database.ExecuteSqlCommand("ALTER DATABASE db_name SET RECOVERY SIMPLE;");

avec le studio visuel (sur le HomeController ) mais j'obtiens l'erreur suivante:

System.Data.SqlClient.SqlException: ALTER DATABASE statement not allowed within multi-statement transaction.

comment résoudre mon problème? Dois-je contacter l'équipe de soutien (ce qui est un peu pauvre pour mon hôte) ou puis-je résoudre ce moi?

49
demandé sur Alireza Noori 2014-01-20 11:50:53

6 réponses

appelez votre hébergeur et demandez-lui de configurer des sauvegardes de logs régulières ou de configurer le modèle de récupération à simple. Je suis sûr que vous savez ce qui guide le choix, mais je serai explicite de toute façon. Définir le modèle de récupération complète si vous avez besoin de la capacité à restaurer à un point arbitraire dans le temps. De toute façon la base de données est mal configuré.

25
répondu Ben Thul 2014-11-30 05:37:25

en plus de la réponse de Ben, vous pouvez essayer les requêtes ci-dessous selon vos besoins""

USE {database-name};  
GO  
-- Truncate the log by changing the database recovery model to SIMPLE.  
ALTER DATABASE {database-name}
SET RECOVERY SIMPLE;  
GO  
-- Shrink the truncated log file to 1 MB.  
DBCC SHRINKFILE ({database-file-name}, 1);  
GO  
-- Reset the database recovery model.  
ALTER DATABASE {database-name}
SET RECOVERY FULL;  
GO 

mise à Jour Crédit @cema-sp

pour trouver des noms de fichiers de base de données utiliser la requête ci-dessous

select * from sys.database_files;
71
répondu Mohit Dharmadhikari 2017-08-14 21:23:45

cette erreur se produit parce que le journal des mouvements devient complet à cause de LOG_BACKUP. Par conséquent, vous ne pouvez pas effectuer d'action sur cette base de données, et dans ce cas, le moteur de base de données SQL Server affichera une erreur 9002.

pour résoudre ce problème, vous devez faire ce qui suit""

  • faites une sauvegarde complète de la base de données.
  • rétrécir le fichier journal pour réduire la taille physique du fichier.
  • créer un LOG_BACKUP.
  • créer un plan de Maintenance LOG_BACKUP pour prendre des journaux de sauvegarde fréquemment.

j'ai écrit un article avec tous les détails concernant cette erreur et comment la résoudre à le journal des transactions pour la base de données ‘SharePoint_Config’ est complet en raison de LOG_BACKUP

6
répondu Mohamed El-Qassas MVP 2017-06-11 09:43:16

à L'occasion, lorsqu'un disque manque de place, le message "le journal des transactions pour la base de données XXXXXXXXXX est plein en raison de 'LOG_BACKUP'" sera retourné lorsqu'une déclaration SQL de mise à jour échoue. Vérifiez votre espace disque:)

4
répondu Hein Gous 2017-12-28 06:19:53

j'ai eu la même erreur mais d'un backend job (SSIS job). En vérifiant le paramètre de croissance du fichier journal de la base de données, le fichier journal était une croissance limitée de 1 Go. Donc ce qui s'est passé c'est quand le travail a été exécuté et QU'il a demandé à SQL server d'allouer plus d'espace de log, mais la limite de croissance du log refusé a causé l'échec du travail. J'ai modifié la croissance logarithmique et l'ai réglée pour augmenter de 50MB et croissance illimitée et l'erreur a disparu.

1
répondu Andy 2017-02-08 17:07:50

cette erreur que j'ai rencontrée dans le système client où nous avions le manque d'espace à l'emplacement du serveur lui-même. Pour cette raison, nous n'avons pas pu rétrécir le journal de bord ou prendre la sauvegarde complète.

voici la solution de contournement utilisée: # copié de la solution de Mohit donnée ci-dessus pour ce scénario spécifique.

UTILISER DBNAME;

GO

ALTER DATABASE DBNAME SET RECOVERY SIMPLE;

ALLER

DBCC SHRINKFILE ('DBNAME', 10);

GO

ALTER DATABASE DBNAME SET RECOVERY FULL;

GO

-3
répondu Avineshkumar Tiwari 2017-06-29 12:08:13