Réduction du journal des transactions d'une base de données SQL Server 2005 en miroir

https://stackoverflow.com/questions/1033158

06-07-2019
|

Question

J'ai cherché partout sur Internet et je ne trouve pas de solution acceptable à mon problème. Je me demande même s'il existe même une solution sans compromis ...

Je ne suis pas un administrateur de base de données, mais je suis une équipe composée d'un seul homme et je travaille sur un site Web immense sans financement supplémentaire pour des corps supplémentaires. Je fais donc de mon mieux.

Notre plan de sauvegarde est nul, et je l’ai vraiment beaucoup de mal à l’améliorer. Actuellement, deux serveurs exécutent SQL Server 2005. J'ai une base de données en miroir (pas de témoin) qui semble bien fonctionner. Je fais une sauvegarde complète à midi et à minuit. Celles-ci sont sauvegardées sur bande par notre fournisseur de services tous les soirs et je grave les fichiers de sauvegarde sur DVD chaque semaine pour conserver les anciens enregistrements. En fin de compte, j'aimerais passer à l'envoi de journaux, car la mise en miroir semble inutile sans serveur témoin.

Le problème est que le journal des transactions ne cesse de croître. D'après les recherches que j'ai effectuées, il semble que je ne puisse pas tronquer un fichier journal d'une base de données en miroir. Alors, comment puis-je empêcher le fichier de grandir!?

D'après cette page Web , j'ai essayé ceci:

USE dbname
GO
CHECKPOINT
GO
BACKUP LOG dbname TO DISK='NULL' WITH NOFORMAT, INIT, NAME = N'dbnameLog Backup', SKIP, NOREWIND, NOUNLOAD
GO
DBCC SHRINKFILE('dbname_Log', 2048)
GO

Mais ça n'a pas marché. Tout ce que j'ai trouvé indique que je dois désactiver le miroir avant d'exécuter la commande backup log pour que cela fonctionne.

Ma question (TL; DR)

Comment puis-je réduire mon fichier de journal des transactions sans désactiver le miroir?

La solution 3

Je pensais que je devrais répondre à cette question car elle avait été oubliée.

Il s'avère que vous ne pouvez pas réduire un t-log si la base de données est mise en miroir à moins que vous ne désactiviez le miroir. Si je me trompe, corrigez-moi, mais je n'ai trouvé aucune solution qui fonctionne!

Si vous ne disposez que de deux serveurs, l'envoi de journaux est la solution. La mise en miroir est presque inutile en l'absence de serveur témoin, car le seul moyen de basculer vers le basculement consiste à utiliser le principal ... fausse un peu l'objectif d'un miroir si vous ne pouvez pas basculer lorsque le principal tombe en panne.

Si quelqu'un souhaite partager plus d'informations ou des suggestions à ce sujet, je serai le bienvenu pour les entendre.

Autres conseils

Eh bien, techniquement, il est possible de réduire un journal en miroir. Ce qui pose problème, c’est de sauvegarder le journal avec truncate_only. La mise en miroir ne l'accepte pas. Il est donc possible de créer un journal de sauvegarde sur le disque:

use [DATABASE_NAME]
checkpoint
BACKUP LOG [DATABASE_NAME] TO DISK =  'C:\LOG_BACKUPS\DATABASE_NAME'
dbcc shrinkfile(DATABASE_NAME_Log,1)

Cela fait partie de notre plan de maintenance actuel et fonctionne sans problèmes depuis environ 2 ans.

Si l'instance de serveur miroir tombe derrière l'instance de serveur principal, la quantité d'espace de journalisation actif augmentera. Dans ce cas, vous devrez peut-être arrêter la mise en miroir de la base de données, effectuer une sauvegarde du journal qui tronque le journal, appliquer cette sauvegarde du journal à la base de données miroir et redémarrer la mise en miroir, pas la réponse que vous espériez, je sais = (

Pour réduire nos fichiers, vous pouvez essayer le script suivant:

exec sp_dboption DBName, 'trunc. connectez-vous sur chkpt. ', true point de contrôle DBCC SHRINKFILE (DBNameFileName, 500); exec sp_dboption DBName, 'trunc. connectez-vous sur chkpt. ', false

J'espère que cela vous aidera.

Il est possible de réduire le fichier de transaction pour une base de données avec miroir, la sauvegarde doit être effectuée car le fichier journal virtuel est actif: http: / /www.xoowiki.com/Article/SQL-Server/tronquer-journal-de-log-sur-base-en-miroir-499.aspx

Désactivez le partenaire miroir en utilisant .. ALTER [Nom de la base de données] SET PARTNER OFF
Effectuer une sauvegarde du journal des transactions sur le principal .. JOURNAL DE SAUVEGARDE [DatabaseName] TO DISK = 'Lecteur: \ DatabaseName_log_datetime.trn'
Copiez ce DatabaseName_log_datetime.trn vers n’importe quel emplacement du serveur miroir.
Restaurez ce journal transactionnel avec l'option NoRecovery sur la base de données miroir. RESTORE LOG [DatabaseName] FROM DISK = 'Lecteur: \ DatabaseName_log_datetime.trn'
Réduisez le fichier journal sur le principal & amp; serveur miroir.
Encore une fois, effectuez une sauvegarde du journal des transactions sur le principal et restaurez ce journal transactionnel avec l'option Aucune récupération.
Configurer la sécurité de la mise en miroir.

Après avoir testé quelques suggestions dans ce billet, j’ai constaté qu’après la sauvegarde complète, la commande checkpoint et la sauvegarde du journal des transactions, la taille du journal des transactions de la base de données principale pouvait être réduite. La taille du journal des transactions de la base de données miroir est ensuite synchronisée avec la taille réduite principale.

USE [DATABASE_NAME];
BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_FULL.bak' WITH FORMAT;
CHECKPOINT;
WAITFOR DELAY '00:00:02';
BACKUP LOG [DATABASE_NAME] TO DISK = 'E:\Backup\DATABASE_NAME_TL.trn';
WAITFOR DELAY '00:00:02';
DBCC SHRINKFILE('DATABASE_NAME_log', 500);

Utiliser OSQL peut exécuter les commandes SQL ci-dessus dans un lot DOS. WAITFOR DELAY est indispensable s’il est exécuté par lots, par exemple.

C:\Program Files\Microsoft SQL Server\100\Tools\Binn\osql.exe -E -S "DATABASE_SERVER" -Q "USE [DATABASE_NAME]; BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_FULL.bak' WITH FORMAT;"

Je pense que les différentes sauvegardes doivent également être travaillées, mais ne testent pas. La commande de sauvegarde ci-dessous va ajouter les données au lieu d’écraser.

BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_DIFF.bak' WITH DIFFERENTIAL;

le seul moyen: 1) Arrêtez de refléter 2) réduire les fichiers sur le principal 3) sauvegarde complète du principal, + transaction jrnl 4) arrêtez le serveur miroir, supprimez mdf et ldf de mirrorDatabase 5) démarrer mirrorser et supprimer mirrorDatabase 6) restaurer sans sauvegardes de récupération de 3) sur mirroServer 7) réinstaller la mise en miroir Ouf!

Il est vrai que vous ne pouvez pas réduire le journal de la base de données une fois que celui-ci est devenu trop volumineux. À ce stade, votre seule option est de casser le miroir, de le réduire et de le recréer. De plus, peu importe si vous devriez utiliser la mise en miroir avec seulement deux serveurs, ce que je peux dire, c'est que si vous sauvegardez régulièrement le journal des transactions. L'espace en sera libéré, permettant ainsi à MSSQL de réutiliser l'espace mort dans le fichier journal. Cela ne réduit rien, mais répond à l'exigence d'arrêter la croissance.

Ensuite, tout ce que vous avez à faire est de supprimer régulièrement les sauvegardes de fichiers. Par exemple, vous pouvez faire ceci:

USE your_database
GO
BACKUP LOG your_database TO DISK = 'x:\your_backup_filepath\your_database.tlog'
GO

Faites-le en dehors des heures si vous le pouvez.

Je ne sais pas pourquoi cela fonctionne, seulement que cela fonctionne effectivement. Je lance cela comme un bloc dans une fenêtre de requête. Utilisez à votre discrétion. Ce serait bien si un microsoftie commentait.

use my_database
dbcc shrinkfile ( my_database_log, 1000 )
use my_database
dbcc shrinkfile ( my_database_log, 1000 )
alter database my_database
  modify file ( 
    name = my_database_log, 
    size = 1000MB
  )

Vous ne pouvez vraiment rien faire avec une base de données en miroir sans la sortir du miroir, tant que ce n'est pas la base de données principale.

Ce qui devrait fonctionner, c’est que si vous sauvegardez vos bases de données sur le serveur principal et fassiez ensuite une réduction. C'est-à-dire que votre plan de maintenance devrait inclure un travail en diminution. Ces modifications doivent être automatiquement synchronisées sur le serveur secondaire (miroir).

Si vous souhaitez créer une réduction qui ne réduit que le fichier de transaction, vous pouvez utiliser le T-SQL suivant:

USE [your_db_name]
GO
DBCC SHRINKFILE (N'your_db_name_logfile' , 0, TRUNCATEONLY)
GO

Ensuite, vous utilisez simplement cet extrait pour chaque base de données et vous l'exécutez juste après l'exécution de votre sauvegarde.

Cela devrait garder le fichier journal petit sur le serveur principal et donc sur le serveur secondaire / miroir.

J'espère que cela vous aidera.

Btw. Si vous avez atteint le point où il ne reste plus de place sur le disque pour les fichiers journaux, la seule option est de le sortir du mode miroir, de définir la base de données en mode de récupération simple, de réduire le fichier journal, de le définir en mode plein. mode de récupération à nouveau et configurez à nouveau le miroir (en utilisant des sauvegardes du fichier journal de la base de données pour les restaurer sur le serveur miroir).

De plus, vous pouvez utiliser SQL Express comme serveur témoin si le problème est lié à la gestion de licences. Cela ne devrait pas nécessiter trop de ressources, vous pouvez donc utiliser un serveur Web, s'il s'agit d'une application Web. N'oubliez pas de regarder également les fichiers journaux du serveur témoin.

** la réduction peut être effectuée en miroir, nous ne pouvons pas tronquer le journal, car ce dernier est envoyé au serveur miroir et le principal attend l'accusé de réception.

Une solution au problème consiste à sauvegarder le journal sans tronquer, puis à réduire le fichier journal, ou vous pouvez même ignorer la réduction. Si cela ne fonctionne pas, essayez un point de contrôle avant de sauvegarder votre journal. Cela devrait fonctionner ...

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow