Maintenance du journal des transactions sur la base de données miroir

Version de SQL Server: 2008 R2 Enterprise SP2

J'essaie d'obtenir une poignée sur notre maintenance SQL Server et je suis tombé sur quelque chose que je pense est incorrect. Nous avons une seule instance de production avec 3 bases de données, chacune étant mise en miroir hors site vers une instance DR.

En regardant l'instance DR, j'ai remarqué que les fichiers LDF étaient énormes, plus de 35 Go pour les bases de données très utilisées.

Je comprends que cela est probablement dû au fait que les bases de données miroir sont en mode de récupération complète et que les journaux n'ont jamais été sauvegardés, ils continueront de croître jusqu'à épuisement de l'espace disque.

Nous effectuons des sauvegardes de journaux sur la base de données principale, et ma question est quels sont les pièges avec faire une sauvegarde de journaux sur un miroir?

Au moins une sauvegarde complète de la base de données à partir du miroir doit être effectuée avant d'effectuer une sauvegarde du journal, dans ce cas, existe-t-il des options spéciales qui doivent être utilisées car il s'agit d'un miroir?

Encore une fois, ce sont des recommandations de maintenance du journal des transactions sur la base de données MIRROR .

Merci pour toute contribution

Nous effectuons des sauvegardes de journaux sur la base de données principale, et ma question est quels sont les pièges avec faire une sauvegarde de journaux sur un miroir?

Vous ne pouvez pas faire de sauvegarde de journal sur la base de données miroir.

Au moins une sauvegarde complète de la base de données à partir du miroir doit être effectuée avant d'effectuer une sauvegarde du journal, dans ce cas, existe-t-il des options spéciales qui doivent être utilisées car il s'agit d'un miroir?

Vous ne pouvez pas non plus effectuer une sauvegarde complète de la base de données sur la base de données miroir.

Prenons ceci par exemple: j'ai celui Server1qui abrite la base de données principale AdventureWorks2012, et j'ai celui Server2qui contient le miroir. Voici ce qui se passe lorsque j'essaie d'exécuter des sauvegardes sur la base de données miroir (activée Server2):

use master;
go

backup database AdventureWorks2012
to disk = 'c:\sqlserver\AW_mirror.bak';
go

Msg 954, niveau 14, état 1, ligne 2
La base de données "AdventureWorks2012" ne peut pas être ouverte. Il agit comme une base de données miroir .
Msg 3013, niveau 16, état 1, ligne 2
BASE DE DONNÉES DE SAUVEGARDE se termine anormalement.

backup log AdventureWorks2012
to disk = 'c:\sqlserver\AW_mirror.trn';
go

Msg 954, niveau 14, état 1, ligne 1
La base de données "AdventureWorks2012" ne peut pas être ouverte. Il agit comme une base de données miroir .
Msg 3013, niveau 16, état 1, ligne 1 Le
journal de sauvegarde se termine anormalement.

Jetez un œil à cette FAQ sur la mise en miroir de bases de données par Robert Davis . Je vais le citer concernant cette opération et la maintenance du journal des transactions de la base de données miroir:

Lorsque vous sauvegardez le journal sur le principal, les fichiers journaux virtuels (unités individuelles dans le fichier journal) sont marqués comme réinscriptibles. Les mêmes VLF sont également marqués comme réinscriptibles dans le fichier journal miroir. L'état VLF est reflété dans la base de données .

Alors voilà. Si vous avez des sauvegardes de journaux de transactions sur le principal, un comportement de réutilisation des journaux similaire sera reflété dans sa base de données partenaire.

@JeremieGrund - Si l'architecture du fichier physique de la base de données est la même (noms et emplacements des lecteurs de fichiers journaux et données), alors si vous réduisez le fichier journal sur le principal, la commande de réduction sera envoyée à Mirror et fera de même sur Mirror. Ainsi, de cette façon, votre fichier journal miroir peut être maintenu .. Si l'architecture des fichiers n'est pas identique, vous devez suivre la suggestion de Thomas Stringer ..