web-dev-qa-db-fra.com

Envoi de journaux «désynchronisé» mais aucun des travaux échoue

J'ai configuré l'envoi de journaux à partir d'un serveur, vers le même serveur, uniquement avec une instance différente.

Primary server est configuré de cette façon:

LSBACKUP_MyDatabase - toutes les 25 minutes

Secondary server:

LSCOPY_MyDatabase - toutes les 1 minute

LSRESTORE_MyDatabase - toutes les 10 minutes

Ce qui se passe, c'est que le travail de sauvegarde principal fonctionne bien (il y a beaucoup plus d'historique, je ne montre que les 2 derniers).

enter image description here

dans le dossier, je peux voir les fichiers TRN.

enter image description here

Dans l'instance secondaire, LSCOPY et LSRESTORE est également correct. Il s'agit de copier des fichiers, mais le problème est là. Le travail de restauration signale ce "message" (le travail s'exécute correctement, donc je ne pense pas que ce soit une erreur):

Message

2015-12-29 09: 10: 02.41 Fichier de sauvegarde du journal ignoré. Base de données secondaire: 'MyDatabase', fichier: '\ ServerIP\instancia g\BACKUP\Log_Sp_Secundario\MyDatabase_20151229104500.trn'

2015-12-29 09: 10: 02.41 Impossible de trouver un fichier de sauvegarde du journal qui pourrait être appliqué à la base de données secondaire 'MyDatabase'.

2015-12-29 09: 10: 02.42 L'opération de restauration a réussi. Base de données secondaire: 'MyDatabase', Nombre de fichiers de sauvegarde du journal restaurés: 0

2015-12-29 09: 10: 02.42 Suppression des anciens fichiers de sauvegarde du journal. Base de données primaire: 'MyDatabase'

2015-12-29 09: 10: 02.42 L'opération de restauration a réussi. Identifiant secondaire: "5a0a361c-039c-40a3-9c39-af5e338c7f72"

Et puis, quand je clique pour voir l'historique du LSALERT_ Job, ses erreurs de rapport avec ce message:

enter image description here

Message exécuté en tant qu'utilisateur: CMDO\gdladmin. La base de données secondaire d'envoi de journaux VMWGDLPRD04\GDLIC2014.GDL_IC a un seuil de restauration de 45 minutes et n'est pas synchronisée. Aucune restauration n'a été effectuée pendant 8323 minutes. La latence restaurée est de 0 minute. Vérifiez les informations du journal de l'agent et du moniteur d'envoi de journaux. [SQLSTATE 42000] (erreur 14421). L'étape a échoué.

Selon l'une des pages de support de Microsoft, cette requête indique s'il y a des écarts entre les journaux. il n'y en a pas:

SELECT 
    s.database_name,s.backup_finish_date,y.physical_device_name
FROM 
    msdb..backupset AS s INNER JOIN
    msdb..backupfile AS f ON f.backup_set_id = s.backup_set_id INNER JOIN
    msdb..backupmediaset AS m ON s.media_set_id = m.media_set_id INNER JOIN
    msdb..backupmediafamily AS y ON m.media_set_id = y.media_set_id
WHERE 
    (s.database_name = 'MyDatabase')
ORDER BY 
    s.backup_finish_date DESC;

J'ai cherché partout sur Internet, mais je n'ai pu trouver que les blogs dba manquant d'informations et certains articles disant que la base de données principale avait été supprimée (ce n'était évidemment pas le cas).

L'instance principale est 2012. La seconde est 2014. la base de données secondaire est en mode de récupération.

Pour résoudre ce problème, dois-je recréer tous les envois de journaux?

sql-serverlog-shipping
5
Racer SQL

Eh bien, cela n'a pas été corrigé. Je pense que je vais recréer l'envoi de journaux

Avant, vous essayez avec cela, pourquoi ne pas aller chercher la sauvegarde différentielle la plus récente et la restaurer sur le secondaire.

Nous avons également eu des situations comme mentionné ci-dessus et avons constaté que:

Cela s'est produit en raison d'un problème de NW à cause duquel le dossier partagé (sur le principal comme emplacement de sauvegarde commun avec le secondaire) n'était plus partagé (en raison de certains problèmes sur les ressources du cluster) et, par conséquent, quelques sauvegardes de journaux ne sont jamais allées/copiées sur le secondaire et depuis il y avait un écart, même si le travail de restauration était terminé, mais LS n'arrêtait pas de le répéter.

Eh bien, dans notre cas, nous sommes allés de l'avant et avons restauré la dernière sauvegarde complète pour synchroniser les chaînes LSN manquantes et plus tard, le travail de restauration a choisi le prochain fichier de sauvegarde du journal et LS était de nouveau synchronisé.

5
KASQLDBA

Je prends le travail LSAlert avec un grain de sel. Dépannage de ce problème m'a fait arracher mes cheveux! Au final, les travaux de sauvegarde, de copie et de restauration des journaux fonctionnaient comme prévu.

Voici quelques éléments à prendre en compte lorsque vous obtenez ces messages d'erreur LSAlert sur votre serveur de surveillance:

  • La date ou l'heure sur le serveur de surveillance peuvent être différentes de la date et de l'heure sur le serveur principal. Il est également possible que la date ou l'heure système ait été modifiée sur le moniteur ou le serveur principal.
  • Lorsque le serveur de surveillance est hors ligne et remis en ligne, les champs de la table log_shipping_primaries ne sont pas mis à jour avec les valeurs actuelles avant l'exécution du travail de message d'alerte.
  • Le travail de copie d'envoi de journaux exécuté sur le serveur principal peut ne pas se connecter à la base de données msdb du serveur de surveillance pour mettre à jour les champs de la table log_shipping_primaries. Cela peut être le résultat d'un problème d'authentification entre le serveur de surveillance et le serveur principal.
  • Le travail de restauration d'envoi de journaux en cours d'exécution sur le serveur secondaire ne peut pas se connecter à la base de données msdb du serveur de surveillance pour mettre à jour la table log_shipping_secondaries avec la valeur correcte. Cela peut être le résultat d'un problème d'authentification entre le serveur secondaire et le serveur de surveillance.
  • Vous avez peut-être défini une valeur petite ou incorrecte pour le seuil d'alerte de sauvegarde. Idéalement, vous devez définir cette valeur sur une telle valeur en fonction de vos seuils SLA et de la fréquence du travail de sauvegarde).
  • Le travail de sauvegarde sur le serveur principal peut échouer. Dans ce cas, nous devons vérifier l'historique du travail de sauvegarde et tout message d'erreur dans le journal d'erreurs SQL du serveur principal.

Il existe deux façons de vérifier que les restaurations se déroulent comme prévu. La requête suivante vous aidera à trouver des lacunes dans le processus de restauration du journal:

 SELECT 
    s.database_name,s.backup_finish_date,y.physical_device_name
FROM 
    msdb..backupset AS s INNER JOIN
    msdb..backupfile AS f ON f.backup_set_id = s.backup_set_id INNER JOIN
    msdb..backupmediaset AS m ON s.media_set_id = m.media_set_id INNER JOIN
    msdb..backupmediafamily AS y ON m.media_set_id = y.media_set_id
WHERE 
    (s.database_name = ‘databaseNamePrimaryServer’)
ORDER BY 
    s.backup_finish_date DESC;

Divulgation complète, je ne tire rien de ce "plug" et je ne travaille pas pour Red Gate, c'est un outil de surveillance en temps réel gratuit qui surveillera l'envoi des journaux.

Moniteur d'expédition de journaux Red Gate

Article Microsoft TechNet

1
Sean Perkins

Essayez de vérifier les tableaux suivants - voyez si vous avez des enregistrements qui ne devraient pas y être:

log_shipping_primary_databases log_shipping_secondary log_shipping_monitor_primary log_shipping_monitor_secondary

Si vous le faites, supprimez-les et l'alerte disparaîtra.

0
Some Guy

Merci d'avoir publié quelques conseils pour le dépannage. J'ai également rencontré le même problème et, pendant le dépannage, je n'ai pas reçu un bon article et une aide pertinente.

Ce message avait un problème similaire et presque tout concordait, mais toujours pas en mesure de résoudre. Je l'ai résolu en regardant les valeurs du tableau ci-dessous, puis en le mettant à jour pour résoudre ce problème.

Serveur principal

log_shipping_primary_databases log_shipping_monitor_primary

Serveur secondaire

log_shipping_secondary log_shipping_monitor_secondary

En regardant la table log_shipping_monitor_secondary, j'ai observé que les valeurs dans la colonne "last_restored_file" et "last_restored_latency" étaient nulles en raison des travaux qui réussissaient, mais SQL était désemparé de choisir le fichier précis à restaurer, j'ai donc mis à jour le "last_restored_file" vers le dernier restauré chemin du fichier journal à partir du serveur secondaire, qui a commencé à fonctionner pour moi.

Dans certains cas, nous pouvons également avoir besoin de mettre à jour la "last_restored_latency" (ce qui était mon cas) pour résoudre ce problème. Lors de la mise à jour de ce champ, indiquez le nombre exact de minutes écoulées depuis la dernière sauvegarde.

J'espère que cela t'aides :)

Cordialement, Bipin Singh, SQL Server DBA

0
Bipin Singh