J'ai une base de données s'exécutant sur SQL Server 2005. La base de données fait 20 Go et le fichier LDF, 35 Go! Je manque maintenant d’espace disque et je veux réduire le fichier journal.
Comment puis-je faire cela et comment puis-je empêcher que cela ne se reproduise?
Réponses:
En gros, vos fichiers journaux SQL Server doivent être sauvegardés régulièrement, toutes les deux heures ou tous les jours. Quand vous faites cela, ils vont rétrécir.
Maintenant, dans votre cas, vous pouvez faire deux choses:
basculez le "modèle de récupération" de votre base de données sur "simple". Cela signifie que vous pourrez restaurer la base de données sur la dernière sauvegarde de données complète ou différentielle, mais rien depuis, vous aurez moins de journaux, bien que
utilisation
BACKUP LOG (yourDB) WITH TRUNCATE_ONLY
pour tronquer les journaux immédiatement (vous perdrez la possibilité de restaurer n'importe quoi dans le passé entre la dernière sauvegarde de données et maintenant)
Résumé: Si vous vous trouvez dans cette situation, vous voudrez probablement l’option 1 ci-dessous. Ignorez-le pour résoudre le problème ou lisez la suite pour plus d'explications.
Une base de données dans Microsoft SQL Server a différents "modes de récupération", elle peut être configurée pour être dans:
Facile. Vous pouvez effectuer des sauvegardes complètes et des sauvegardes différentielles d’une base de données en mode de récupération simple. Une sauvegarde complète contient la base de données entière à un moment donné, tandis qu'une sauvegarde différentielle contient tout ce qui a changé depuis la dernière sauvegarde complète.
Un plan de sauvegarde pour une telle base de données pourrait être "Une sauvegarde complète tous les dimanches, plus une sauvegarde différentielle quotidienne". Les sauvegardes différentielles sont donc relativement petites, car elles ne contiennent que des données modifiées depuis le dimanche précédent. En cas de panne, vous ne perdez pas plus d'une journée de données.
Plein. Vous pouvez toujours effectuer des sauvegardes complètes et différentielles, mais vous devez également effectuer des sauvegardes périodiques du journal des transactions. Alors que les sauvegardes différentielles contiennent des modifications de la base de données depuis la dernière sauvegarde complète, log backukps ne contient que des données depuis la dernière sauvegarde du journal . Par conséquent, les sauvegardes du journal doivent être petites et rapides.
Un plan de sauvegarde pour une base de données de récupération complète peut être "une sauvegarde complète hebdomadaire, une sauvegarde différentielle quotidienne et une sauvegarde du journal des transactions toutes les 5 minutes". Cela signifie que vous ne perdez jamais plus de 5 minutes de données. Lors de la restauration d'une telle base de données, vous devez restaurer la dernière sauvegarde différentielle, puis appliquer chaque sauvegarde de journal effectuée depuis ce point.
En vrac connecté. C'est un peu comme un "mode de récupération complet, sauf quand je dis le contraire".
La récupération complète est un avantage car vous pouvez restaurer votre base de données presque jusqu’au moment du blocage, mais vous devez également effectuer des sauvegardes du journal. Pourquoi? Parce que les journaux à l'intérieur du fichier du journal des transactions ne sont marqués comme "tronqués" qu'une fois que vous effectuez une sauvegarde du journal. Une fois qu'un journal est tronqué, les nouveaux journaux sont autorisés à l'écraser.
Si vous n'effectuez jamais de sauvegarde de journal, rien dans le journal des transactions n'est jamais marqué comme tronqué. Par conséquent, le fichier journal doit croître à chaque changement de base de données.
Pour plus d'informations sur le fonctionnement du journal des transactions, veuillez lire les excellents articles de Paul Randal:
Maintenant, dans la situation où vous vous trouvez avec un journal de transactions énorme, il existe deux options réelles:
Vous n'avez probablement pas besoin de faire des sauvegardes de journaux (puisque vous ne le faites pas maintenant), vous pouvez donc simplement passer à un modèle de récupération simple:
ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE
Ceci marquera tout le journal de transaction comme étant tronqué, ainsi le fichier journal ne deviendra pas plus gros. Une fois que vous avez fait cela, pour réduire le fichier journal physique:
DBCC SHRINKFILE N'MyDatabase.ldf'
Cela signifie que le fichier journal se tronque automatiquement après chaque transaction. Par conséquent, sa taille ne deviendra pas incontrôlable. Vous n'aurez probablement pas à gérer le journal des transactions; Cependant, vous perdez la possibilité de restaurer votre base de données au-delà de votre dernière sauvegarde complète ou différentielle.
Si vous avez vraiment besoin d'une récupération complète, vous devez commencer à effectuer des sauvegardes du journal des transactions.
Tout d'abord, pour vous sortir de la mauvaise situation, vous voulez tronquer tout le journal, puis le réduire:
BACKUP LOG [MyDatabase] WITH TRUNCATE_ONLY
GO
DBCC SHRINKFILE N'MyDatabase.ldf'
GO
Votre fichier de journal des transactions doit maintenant avoir une taille raisonnable. Il va recommencer à grandir immédiatement; bien que. Vous devez maintenant commencer à prendre des sauvegardes de journal régulièrement. Vous pouvez le faire via un plan de maintenance ou en exécutant régulièrement une commande telle que:
BACKUP LOG [MyDatabase] TO DISK = N'C:\Backups\MyDatabase_Log_Backup1.bak' WITH INIT
DBCC SHRINKFILE n'est pas destiné à être utilisé régulièrement:
Si vous réduisez régulièrement les fichiers journaux, vous devriez probablement soit passer au modèle de récupération simple, soit effectuer des sauvegardes de journal plus fréquentes.