Comment puis-je rétrécir le fichier journal de transaction physique lorsqu'il est le principal dans un miroir?
Nous configurons la base de données de la base de données au cours du week-end et j'ai oublié de réactiver le travail qui sauvegarde les journaux de transaction. Quand je suis arrivé ce matin, le journal des transactions avait un ballon à 58 Go et prends la majeure partie de l'espace de conduite.
J'ai fait une sauvegarde manuelle du journal de transaction sur le disque pour que la base de données s'allume à nouveau, quelle que soit l'exécution de DBCC Shrinkfile, ne semble pas diminuer la taille physique du fichier journal de transaction.
DBCC SHRINKFILE (N'MyDatabaseName_Log', 1000)
Si je vérifie l'utilisation du journal en utilisant
DBCC SQLPERF(LOGSPACE)
Je peux voir que seulement 22% du journal actuel est utilisé
Taille du journal de la base de données (MB) Espace journal utilisé (%) Statut [.____] MyDatabasename 55440.87 22.38189 0 [.____]
Si je vérifie log_reuse_wait_desc dans sys.databses, le seul enregistrement que je vois est DATABASE_MIRRORING, je devine donc 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 miroir de base de données principale est suspendu et essayer de le reprendre échouer immédiatement avec l'erreur suivante:
Le partenaire de mise en miroir à distance de la base de données 'MyDatabasename', une erreur rencontrée 5149, Statut 1, gravité 25. La miroir de la base de données a été suspendue. Résoudre l'erreur sur le serveur distant et reprendre la mise en miroir, ou supprimez la mise en miroir et rétablissez l'instance de serveur de miroir.
Les journaux d'erreur sur le serveur de miroir contiennent également cette erreur, mais contient également des erreurs sur le lecteur de fichier journal étant pleine
Modifier l'erreur du système d'exploitation rencontré du fichier 112 (il n'ya pas assez d'espace sur le disque.) Tout en essayant d'étendre le fichier physique.
et
F:\DatabaseLogs\myDatabasename_1.ldf: Erreur du système d'exploitation 112 (il n'y a pas assez d'espace sur le disque.) Rencontrées.
Le serveur principal a 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 n'a que 45 Go.
Sauvegardez le fichier journal de la base de données utilisable à nouveau, mais je souhaite également réduire la taille du fichier journal physique sur le disque et récupérez la mise en miroir.
Comment puis-je rétrécir la taille de mon fichier journal de transaction physique sans compromettre la miroir ou la chaîne de sauvegarde?
Je cours SQL Server 2005
D'après ce que je peux dire, je ne peux pas.
Je crois que beaucoup du fichier journal attend de se refléter sur le serveur de miroir, mais le miroir est en panne et ne peut pas être repris car le journal de transaction en miroir a également augmenté pour reprendre tout l'espace sur le disque.
Cette théorie est également sauvegardée par le fait une fois que je retire la mise en miroir, le DBCC SHRINKFILE commande rétrécit correctement le fichier journal physique et le log_reuse_wait_desc est de retour à attendre LOG_BACKUP
Je ne peux pas réduire le fichier journal sur le serveur en miroir car il agit comme un miroir et qu'il ne peut pas être ouvert, je pense donc que le miroir n'est pas recouvert.
Je vais donc supprimer entièrement le miroir et tout définir (processus très lent avec une base de données de 300 Go). Et cette fois, je vais vous assurer que la taille du journal des transactions est assez petite avant de démarrer le miroir et que les sauvegardes de journal de transaction sont en cours d'exécution une fois que le miroir est sauvegardé et en cours d'exécution.
Je vais également définir une limite sur la taille de la taille du journal des transactions sur le serveur de production. Le miroir n'essaye donc jamais de développer son journal de transaction au-delà de la taille disponible sur le disque.
Ran dans le même problème aujourd'hui avec notre DBS, qui, pour une raison quelconque, avait cessé de sauvegarder les journaux de transaction pendant les 3 derniers mois et les journaux avaient été placés à 200 Go.
Exactement les mêmes codes d'erreur que dans votre situation et la mise en miroir ne refroidiraient pas. Le lecteur de journal était complètement plein sur le miroir.
Heureusement, j'ai pu libérer de l'espace en supprimant quelques vieux journaux errants sur le lecteur de journal. Après cela, était capable de reprendre la mise en miroir.
Ensuite, entrez dans les sauvegardes du plan de maintenance et a déclenché la base de sauvegarde de la base de données et de la transaction manuellement. Même après la sauvegarde, les fichiers journaux de transaction étaient encore énormes. Donc, j'ai dû dire à plusieurs reprises SQL Studio de réduire les fichiers journaux (libérer n'importe quel espace inutilisé) et après quelques tentatives de plus de deux heures, il les a coupées à une taille plus gérable.
J'espère que cela t'aides.