Avamar: Przyrostowe kopie zapasowe SQL AlwaysOn losowo kończą się niepowodzeniem z powodu błędów "luki w dzienniku"

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.

W przypadku przyrostowych kopii zapasowych SQL proces porównuje numer LSN pobrany z sys.database_recovery_status podczas znajdowania luki w dzienniku. Zapytanie używane do tego zadania to:

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

Dziennik wyglądałby następująco:

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 plik podczas tej aktualizacji przyrostowej przy użyciu następującej kwerendy:

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

Wyniki obu zapytań powinny zgłaszać ten sam numer LSN dla bazy danych.
Jeśli wynik nie jest zgodny, oznacza to, że podczas wykonywania przyrostowych kopii zapasowych spodziewana jest potwierdzona sekwencja "łańcucha dzienników" i błąd przerwy w dzienniku. W idealnym scenariuszu podczas tworzenia kopii zapasowych klastra po zakończeniu tworzenia kopii zapasowej program Microsoft SQL Server aktualizuje tabelę sys.database_recovery_status najnowszą wartością LSN. Wtyczka Avamar SQL wysyła zapytanie do tej tabeli o LSN i przechowuje wartość w metadanych SQL. Podczas następnej przyrostowej kopii zapasowej wtyczka Avamar SQL ponownie wysyła zapytanie do tabeli i pobiera najnowszą wartość LSN. Ten numer LSN jest następnie porównywany z numerem LSN przechowywanym w metadanych SQL i wykonywana jest kopia zapasowa.

W ruchliwych środowiskach klastrowych, gdy wtyczka Avamar SQL wysyła zapytanie do tabeli o wartość LSN, starsza wartość LSN jest uzyskiwana i przechowywana w metadanych SQL. Microsoft SQL Server zaktualizuje tabelę po pewnym czasie. Podczas następnej przyrostowej kopii zapasowej, gdy wtyczka SQL ponownie wysyła zapytanie do tabeli, pobiera najnowszą wartość LSN. Gdy ta wartość jest porównywana ze starą nazwą LSN zapisaną w pliku sqlmeta.xml, zostaje wykryta luka w dzienniku i kopia zapasowa jest promowana do pełnej.

Tymczasowe obejście problemu:

• Aby rozwiązać ten problem, wymuś pełną kopię zapasową tej bazy danych.
  • Spowoduje to ponowną synchronizację numeracji LSN dla określonej bazy danych w systemie sqlmeta.xml i programie SQL Server.
  • Wszystkie kolejne przyrostowe kopie zapasowe tej bazy danych powinny zostać zakończone pomyślnie. 

Trwałe rozwiązanie:

• Należy dodać znacznik "--latest-lsn-from-msdb=true" do pliku avsql.cmd i zastosować poprawkę awaryjną (HF) zgodnie z wersją wtyczki klienta:
  • v19.10-100-135 => Brak HF, uaktualnij do kompilacji 166 i zastosuj odpowiedni HF
  • v19.10-100-166 (SP1) => 338887 HF
  • v19.12-100-186 => 338888 HF

Aby pobrać poprawkę z działu pomocy technicznej firmy Dell, wykonaj czynności opisane w sekcji Avamar: Wyszukiwanie i pobieranie pakietu poprawek, poprawek, instalacji lub uaktualnień produktu z witryny pomocy technicznej firmy Dell

Aby zastosować poprawkę, postępuj zgodnie z instrukcjami podanymi przez dział pomocy technicznej firmy Dell przy użyciu pliku README lub zapoznaj się z artykułem z bazy wiedzy firmy Dell dotyczącym konkretnej poprawki.

Przestroga: Jeśli problem nie ustąpi po zastosowaniu poprawki, skontaktuj się z działem pomocy technicznej firmy Dell w celu uzyskania dalszego wsparcia.