Impossible de mettre en miroir une base de données SQL Server 2012

Lorsque vous essayez de mettre en miroir une base de données à l'aide de la commande suivante

ALTER AVAILABILITY GROUP SQLAlwaysonGroup ADD DATABASE test0916aj8CJ

J'obtiens l'erreur suivante

Msg 1475, niveau 16, état 105,
base de données de ligne 1 "test0916aj8CJ" peut contenir des modifications enregistrées en bloc qui n'ont pas été sauvegardées. Effectuez une sauvegarde du journal sur la base de données principale ou la base de données principale. Restaurez ensuite cette sauvegarde soit sur la base de données miroir pour activer la mise en miroir de la base de données, soit sur chaque base de données secondaire pour vous permettre de la joindre au groupe de disponibilité.

Peut-on le faire sans sauvegarder la base de données? Ou dois-je sauvegarder puis supprimer la sauvegarde. C'est pour une base de données nouvellement créée, donc je n'ai pas besoin de la sauvegarde de toute façon à ce stade.

J'ai essayé ce qui suit ...

BACKUP
DATABASE [test0916aj8CJ] TO DISK = N’NUL’
WITH COPY_ONLY, NOFORMAT, INIT,
NAME = N’test-Full Database Backup’,
SKIP, NOREWIND, NOUNLOAD
GO

mais la méthode ci-dessus n'a pas fonctionné non plus.

Merci

Il est facile de reprocher l'erreur que vous avez

• Créez une base de données en mode de récupération complète sur le serveur principal.
• Créez une base de données en mode de récupération complète dans Secondaire.
• Lancez l'interface graphique et essayez de configurer la mise en miroir entre le primaire et le secondaire.

Voici l'erreur que vous obtiendrez:

La base de données "test_mirroring_kin" peut contenir des modifications enregistrées en bloc qui n'ont pas été sauvegardées. Effectuez une sauvegarde du journal sur la base de données principale ou la base de données principale. Restaurez ensuite cette sauvegarde soit sur la base de données miroir pour activer la mise en miroir de la base de données, soit sur chaque base de données secondaire pour vous permettre de la joindre au groupe de disponibilité. (Microsoft SQL Server, erreur: 1475)

Permet de comprendre quelle est cette erreur:

Vous avez configuré votre base de données en mode de récupération complète et pensez que la base de données est en effet en mode de récupération complète.

Ce qui précède n'est pas vrai. Après avoir créé la base de données, si vous ne faites pas de sauvegarde COMPLÈTE, même si la base de données est en mode de récupération COMPLÈTE, elle est en récupération pseudo-SIMPLE

Vous pouvez facilement le vérifier en utilisant dbcc dbinfo-> dbi_dbbackupLSNayant une valeur 0:0:0(0x00000000:00000000:0000)ou en utilisant le script de Paul Randal

dbcc traceon (3604)
go
dbcc dbinfo('test_mirroring_kin') with tableresults
go
dbcc traceoff (3604)

Edit: Même la prise d'une première sauvegarde complète avec COPY_ONLYoption n'établit pas non plus de chaîne de sauvegarde

backup database test_mirroring_kin
to disk = 'D:\test_mirroring_kin_FULL.bak'
with init, stats=10, COPY_ONLY

dbcc dbinfo-> a dbi_dbbackupLSNtoujours une valeur de 0:0:0(0x00000000:00000000:0000). Cela signifie que la base de données est toujours en mode de récupération pseudo-simple.

Que devez-vous faire pour résoudre l'erreur ci-dessus?

Vous devez effectuer une sauvegarde complète + une sauvegarde du journal des transactions sur le serveur principal, puis le restaurer sur la base de données secondaire with norecovery, puis rejoindre la base de données dans le groupe AG ou la mise en miroir.

En guise de note complémentaire et pour être complet, pour votre scénario backup to NUL, lisez cet article de blog de Gail Shaw.

Pourquoi TO DISK = N’NUL’?

Je ne comprends pas pourquoi vous utilisez TO DISK = N’NUL’:

BACKUP
DATABASE [test0916aj8CJ] TO DISK = N’NUL’

Si vous faites cela, la sauvegarde est enregistrée dans NUL(c'est-à-dire. = Nulle part / rien) et ne peut pas être utilisée car son fichier n'existe pas.

Bien qu'il NULpuisse également être utilisé comme destination pour les sauvegardes de LOG, il ne doit pas être utilisé non plus, en particulier sur les serveurs Prod car les LOG seront perdus et la chaîne de sauvegarde sera rompue. (~ similaire à a SHRINKFILE)

Sauvegarde du LOG

Avant d'ajouter une base de données au groupe, vous devez la préparer. Lorsque vous souhaitez préparer une base de données secondaire, au moins 1 sauvegarde du journal des transactions doit être effectuée et restaurée. Le miroir l'utilise pour déterminer quelles transactions ont déjà été synchronisées sur la base de données secondaire et quelles transactions ne sont pas encore synchronisées avec la base de données principale.

Par conséquent, vous devez sauvegarder les journaux de transactions sur la base de données principale:

BACKUP LOG [test0916aj8CJ] TO  DISK = N'....bak' 
WITH  COPY_ONLY, FORMAT, INIT,  NAME = N'test0916aj8CJ-Transaction Log  Backup', STATS = 10

L' COPY_ONLYoption doit être utilisée. Il s'assure que les journaux ne sont pas tronqués à la fin de la sauvegarde du journal.

Chaîne de sauvegarde DB principale

Cependant, vous ne pouvez pas restaurer une sauvegarde de journal seule, c'est-à-dire sans chaîne de sauvegarde (voir également la réponse de Kin). Cela signifie que la sauvegarde du journal des transactions doit être effectuée après une sauvegarde complète de la base de données (+ un différentiel facultatif si nécessaire).

Étant donné que l' COPY_ONLYoption ne rompt pas la chaîne de sauvegarde, elle ne crée pas non plus de chaîne de sauvegarde. L' COPY_ONLYoption ne peut pas être utilisée pour la sauvegarde de la base de données.

Sauvegardes dans l'ordre:

• Sauvegarde complète de la base de données sans l' COPY_ONLYoption
• Sauvegarde différentielle en option
• 1 sauvegarde de LOG avec COPY_ONLYoption
• une autre (ou plus) sauvegarde LOG si nécessaire ...

Restaurer la base de données secondaire

Ensuite, la sauvegarde de la base de données doit être restaurée (+ différentielle) sur le secondaire.

Il doit être restauré avec l' NORECOVERYoption car vous souhaitez également restaurer la ou les sauvegardes LOG une fois la sauvegarde complète restaurée.

Enfin, vous restaurerez la sauvegarde LOG. Vous devez toujours utiliser l' NORECOVERYoption, car le miroir continuera de restaurer les transactions une fois en place.

• Restaurer la sauvegarde complète avec l' NORECOVERYoption
• Restaurer la sauvegarde DIFF avec l' NORECOVERYoption
• Restaurer toutes les sauvegardes LOG dans l'ordre avec l' NORECOVERYoption

Permet de tout assembler (l'adapter à votre env)

• Sur l'exécution du serveur principal:

  USE master
  Go
  BACKUP DATABASE [test0916aj8CJ] TO DISK = N'....bak'
  WITH FORMAT, INIT, NAME = N'test0916aj8CJ-Full Database Backup', STATS = 10
  GO
  BACKUP LOG [test0916aj8CJ] TO DISK = N'....bak' 
  WITH COPY_ONLY, FORMAT, INIT, NAME = N'test0916aj8CJ-Transaction Log Backup', STATS = 10
  GO

• Sur le serveur secondaire, exécutez:

  USE master
  Go
  RESTORE DATABASE [test0916aj8CJ] FROM DISK = N'....bak' 
  WITH FILE = 1, NORECOVERY, NOUNLOAD, REPLACE, STATS = 10
  GO
  RESTORE LOG [test0916aj8CJ] FROM DISK = N'....bak' 
  WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10

• Vous pouvez ensuite ajouter la nouvelle base de données secondaire au groupe de disponibilité ...

Actions facultatives

• Il est préférable de définir l'option DISK sur un dossier partagé disponible à partir des serveurs principal et secondaire.
• Il est également préférable de stocker les fichiers DB sur un disque et un emplacement similaires sur les serveurs principal et secondaire.