"Le journal des transactions de la base de données est plein en raison de" LOG_BACKUP "" dans un hôte partagé

J'ai un site Web Asp.Net MVC 5 avec l'approche EntityFramework codefirst dans un plan d'hébergement partagé. Il utilise le WebbsitePanel open source pour le panneau de configuration et son panneau SQL Server est quelque peu limité. Aujourd'hui, lorsque je voulais modifier la base de données, j'ai rencontré cette erreur:

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

J'ai cherché et j'ai trouvé beaucoup de réponses connexes comme ceci et ceci ou ceci, 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 puis-je résoudre mon problème? Dois-je contacter l'équipe d'assistance (ce qui est un peu médiocre pour mon hôte) ou puis-je résoudre ce problème moi-même?

Appelez votre société d'hébergement et demandez-lui de configurer des sauvegardes régulières des journaux ou de définir le modèle de récupération sur simple. Je suis sûr que vous savez ce qui informe le choix, mais je serai quand même explicite. Définissez le modèle de récupération sur complet si vous avez besoin de la possibilité de restaurer à un moment arbitraire. Dans tous les cas, la base de données est mal configurée telle quelle.

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 

Mettre à jour Credit @ cema-sp

Pour trouver les noms de fichiers de base de données, utilisez la requête ci-dessous

select * from sys.database_files;

Parfois, lorsqu'un disque manque d'espace, le message «Le journal des transactions de la base de données XXXXXXXXXX est plein en raison de« LOG_BACKUP »» sera renvoyé lorsqu'une instruction SQL de mise à jour échoue. Vérifiez votre espace disque :)

Cette erreur se produit car le journal des transactions devient 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 déclenchera une erreur 9002.

Pour résoudre ce problème, procédez comme suit

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

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 plein en raison de LOG_BACKUP

J'ai eu la même erreur mais d'un travail backend (travail SSIS). Lors de la vérification du paramètre de croissance du fichier journal de la base de données, le fichier journal a une croissance limitée de 1 Go. Ainsi, ce qui s'est passé, c'est lorsque le travail s'est exécuté et qu'il a demandé au serveur SQL d'allouer plus d'espace de journal, mais la limite de croissance du journal refusé a provoqué l'échec du travail. J'ai modifié la croissance du journal et l'ai configurée pour qu'elle augmente de 50 Mo et de croissance illimitée et l'erreur a disparu.

Cela peut également se produire lorsque la taille du fichier journal est limitée.

Cliquez avec le bouton droit sur la base de données dans l'Explorateur d'objets

Sélectionnez Propriétés

Sélectionnez les fichiers

Sur la ligne du journal, cliquez sur les points de suspension dans la colonne Autogrowth / Maxsize

Modifier / vérifier que la taille maximale du fichier est illimitée.

Après avoir changé pour illimité, la base de données est revenue à la vie.