Comment puis-je réduire le fichier journal des transactions physique lorsqu'il est le principal dans un miroir?

Nous avons configuré la mise en miroir de bases de données au cours du week-end et avons oublié de réactiver le travail de sauvegarde des journaux de transactions. Lorsque je suis arrivé ce matin, le journal des transactions avait grimpé à 58 Go et occupait la majeure partie de l'espace disque.

J'ai effectué une sauvegarde manuelle du journal des transactions sur le disque pour que la base de données fonctionne à nouveau, mais l'exécution de DBCC SHRINKFILE ne semble pas diminuer la taille physique du fichier journal des transactions.

DBCC SHRINKFILE (N'MyDatabaseName_Log', 1000)

Si je vérifie l'utilisation du journal à l'aide de

DBCC SQLPERF(LOGSPACE)

Je peux voir que seulement 22% du journal actuel est utilisé

Nom de la base de données Taille du journal (Mo) Espace journal utilisé (%) État
MyDatabaseName 55440.87 22.38189 0

Si je log_reuse_wait_descrécupère dans sys.databses, le seul enregistrement que je vois est DATABASE_MIRRORING, donc je suppose que le miroir joue un rôle dans la raison pour laquelle la taille physique du fichier journal ne diminuera pas?

SELECT log_reuse_wait_desc
FROM sys.databases
WHERE name = N'MyDatabaseName';

J'ai également remarqué que mon état de mise en miroir de la base de données principale est suspendu et que la tentative de reprise échoue immédiatement avec l'erreur suivante:

Le partenaire de mise en miroir distant pour la base de données 'MyDatabaseName', a rencontré l'erreur 5149, état 1, gravité 25. La mise en miroir de la base de données a été suspendue. Résolvez l'erreur sur le serveur distant et reprenez la mise en miroir, ou supprimez la mise en miroir et rétablissez l'instance du serveur miroir.

Les journaux d'erreurs sur le serveur miroir contiennent également cette erreur, mais contiennent également des erreurs sur le lecteur de fichier journal saturé

MODIFY FILE a rencontré l'erreur 112 du système d'exploitation (il n'y a pas assez d'espace sur le disque.) Lors de la tentative de développement du fichier physique.

et

F: \ Databaselogs \ MyDatabaseName_1.ldf: erreur de système d'exploitation 112 (il n'y a pas assez d'espace sur le disque.) Rencontrée.

Le serveur principal dispose de 60 Go sur le lecteur de fichier journal (il existe d'autres bases de données hébergées ici), tandis que le serveur en miroir ne dispose que de 45 Go.

La sauvegarde du fichier journal a rendu la base de données à nouveau utilisable, mais je souhaite également réduire la taille du fichier journal physique sur le disque et reprendre la mise en miroir.

Comment réduire la taille de mon fichier journal des transactions physiques sans compromettre la mise en miroir ou la chaîne de sauvegarde?

J'exécute SQL Server 2005

D'après ce que je peux dire, je ne peux pas.

Je crois qu'une grande partie du fichier journal attend d'être mise en miroir sur le serveur miroir, mais le miroir est en panne et ne peut pas être repris car le journal des transactions en miroir a également augmenté pour occuper tout l'espace sur le disque.

Cette théorie est encore renforcée par le fait une fois que je supprime la mise en miroir, la DBCC SHRINKFILEcommande réduit correctement le fichier journal physique et log_reuse_wait_descest de nouveau en attenteLOG_BACKUP

Je ne peux pas réduire le fichier journal sur le serveur en miroir car il agit comme un miroir et ne peut pas être ouvert, donc je pense que le miroir est irrécupérable.

Je vais donc supprimer complètement le miroir et tout remettre en place (processus très lent avec une base de données de 300 Go). Et cette fois, je m'assurerai que la taille du journal des transactions est assez petite avant de démarrer le miroir, et que les sauvegardes du journal des transactions s'exécutent une fois le miroir de nouveau opérationnel.

Je vais également définir une limite sur la taille du journal des transactions sur le serveur de production, de sorte que le miroir n'essaie jamais de développer son journal des transactions au-delà de la taille disponible sur le disque.

Ran dans le même problème aujourd'hui avec nos bases de données, qui pour une raison quelconque avaient cessé de sauvegarder les journaux de transactions au cours des 3 derniers mois et les journaux avaient grimpé à 200 Go.

Exactement les mêmes codes d'erreur que dans votre situation et la mise en miroir ne reprendrait pas. Le lecteur de journal était complètement plein sur le miroir.

Heureusement, j'ai pu libérer de l'espace en supprimant quelques anciens journaux errants sur le lecteur de journal. Après cela, a pu reprendre la mise en miroir.

Entré ensuite dans les sauvegardes du plan de maintenance et déclenché manuellement les sauvegardes de la base de données et du journal des transactions. Même après la sauvegarde, les fichiers journaux des transactions étaient toujours énormes. J'ai donc dû répéter à plusieurs reprises à SQL Studio de réduire les fichiers journaux (libérer tout espace inutilisé), et après quelques tentatives sur quelques heures, il les a réduits à une taille plus gérable.

J'espère que cela t'aides.