Avamar : Les sauvegardes incrémentielles SQL AlwaysOn échouent de manière aléatoire en raison d’erreurs « écart de log »

2021/03/22-04:30:53.62299 [avsql_assist]  Before alignment - Str1: '240000000392000001', Str2: '241000000328000001'
2021/03/22-04:30:53.62299 [avsql_assist]  After alignment - Str1: '240000000392000001', Str2: '241000000328000001'
2021/03/22-04:30:53.62299 [avsql_assist]  <=== avsql_assist::align_numeric_ustrings
2021-03-22 00:30:53 avsql Info <15765>: A log gap was identified or a full backup was not found.
2021/03/22-04:30:53.62299 [avsql_assist]  ===> sqlconnect::~sqlconnect
2021/03/22-04:30:53.62299 [avsql_assist]  <=== sqlconnect::~sqlconnect
2021/03/22-04:30:53.62299 [avsql_assist]  <=== avsql_assist::snapup_check_timestamps
2021-03-22 00:30:53 avsql Error <40418>: Skipping database 'oalistener07\OA05_AG/_Sync' due to the following reason: A log gap was identified or a full backup was not found.

Pour les sauvegardes incrémentielles SQL, le processus compare le numéro de LSN qui est récupéré à partir de sys.database_recovery_status tout en détectant les écarts de log. La requête utilisée pour cette tâche est la suivante :

SELECT last_log_backup_lsn FROM sys.database_recovery_status "WHERE database_id = DB_ID(N’db2-mi')"

Le journal se présente comme suit :

2022/08/24-03:28:01.12199 [avsql_assist]  retrieving last backup lsn for 'db2-mi' db from sys.database_recovery_status
2022/08/24-03:28:01.12199 [avsql_assist]  ===> sqlconnectimpl_smo::InitDll
2022/08/24-03:28:01.12199 [avsql_assist]  SMO dll already loaded.
2022/08/24-03:28:01.12299 [avsql_assist]  <=== sqlconnectimpl_smo::InitDll
2022/08/24-03:28:01.12400 [avsql_assist]  ==> SMOWrap::SMO_GetLastBackupLSN
2022/08/24-03:28:01.28200 [avsql_assist]  database 'db2-mi', last backup lsn = '315000000022400001' 
2022/08/24-03:28:01.28200 [avsql_assist]  <=== sqlconnectimpl_smo::get_last_backup_lsn
2022/08/24-03:28:01.28200 [avsql_assist]  ===> avsql_metadata::get
2022/08/24-03:28:01.28200 [avsql_assist]  ===> avsql_metadata::get
2022/08/24-03:28:01.28299 [avsql_assist]  <=== avsql_metadata::get
2022/08/24-03:28:01.28299 [avsql_assist]  <=== avsql_metadata::get
2022/08/24-03:28:01.28299 [avsql_assist]  Last backup LSN: '315000000022400001' (Get from sqlmeta.xml), Current LSN: '315000000022400001'

sqlmeta.xml fichier au cours de cette mise à jour incrémentielle à l’aide de la requête suivante :

SELECT last_lsn, type, user_name FROM msdb..backupset WHERE database_name=N'db2-mi' AND type LIKE 'L' ORDER by last_lsn DESC

Les résultats des deux requêtes doivent indiquer le même numéro de LSN pour la base de données.
Si le résultat ne correspond pas, une séquence d’interruption confirmée de « chaîne de logs » et une erreur d’écart de journal sont attendues lors des sauvegardes incrémentielles. Dans l’idéal, lors des sauvegardes de cluster, une fois la sauvegarde terminée, Microsoft SQL Server met à jour le tableau sys.database_recovery_status avec la dernière valeur LSN. Le plug-in Avamar SQL interroge le LSN de cette table et stocke la valeur dans les métadonnées SQL. Lors de la sauvegarde incrémentielle suivante, le plug-in Avamar SQL interroge à nouveau la table et obtient la dernière valeur LSN. Ce LSN est ensuite comparé au LSN stocké dans les métadonnées SQL, puis une sauvegarde est effectuée.

Dans les environnements de cluster Always occupés, alors que le plugin Avamar SQL interroge la table pour connaître la valeur LSN, l’ancienne valeur LSN est obtenue et stockée dans les métadonnées SQL. Microsoft SQL Server met à jour la table dans un moment. Au cours de la sauvegarde incrémentielle suivante, lorsque le plugin SQL interroge à nouveau la table, il obtient la dernière valeur LSN. Lorsque cette valeur est comparée au LSN obsolète, stocké dans le fichier sqlmeta.xml, un écart de log est détecté et la sauvegarde est promue comme complète.

Solution de contournement temporaire :

• Forcez une sauvegarde complète de cette base de données pour résoudre cette défaillance.
  • Cette opération permet de resynchroniser la séquence de numéros LSN de la base de données spécifique dans sqlmeta.xml et SQL Server.
  • Toutes les sauvegardes incrémentielles ultérieures de cette base de données devraient se terminer avec succès. 

Correctif permanent :

• Assurez-vous d’ajouter la balise « --latest-lsn-from-msdb=true » au fichier avsql.cmd et d’appliquer le correctif (HF) en fonction de la version du plug-in client :
  • v19.10-100-135 => Aucun HF disponible, mise à niveau vers le build 166 et application du HF correspondant
  • v19.10-100-166 (SP1) => HF 338887
  • v19.12-100-186 => HF 338888

Pour télécharger le correctif à partir du support technique Dell, reportez-vous aux étapes décrites dans la section Avamar : Comment trouver et télécharger un correctif, un correctif, une installation ou une mise à niveau d’un produit à partir du site Web de support Dell

Pour appliquer le correctif, suivez les instructions fournies par le support Dell à l’aide du fichier README ou reportez-vous à l’article de la base de connaissances Dell pour obtenir le correctif spécifique.

Attention : Si le problème persiste après l’application du correctif, contactez le support Dell pour obtenir de l’aide.