Avamar: Auswirkungen der Ausführung von nativen inkrementellen SQL-Backups auf Avamar Operations

Summary: In diesem Artikel wird beschrieben, wie sich die native Ausführung inkrementeller SQL-Backups über SQL Management Studio auf Avamar SQL-Backups auswirkt. Aus diesem Grund wird erwartet, dass inkrementelle Avamar-Backups eine Protokolllücke aufgrund einer Unterbrechung in der LSN-Sequenz der Protokollkette melden. ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Instructions

Die folgenden Schritte wurden entwickelt, um die Avamar-Protokollkettensequenz zu unterbrechen, was zu "Protokolllücken"-Fehlern führt:
  1. Führen Sie ein komplettes Backup gefolgt von einem inkrementellen Avamar-Backup durch. Behalten Sie die Datenbankeinträge in der sqlmeta.xml Datei im Auge.
  2. Führen Sie ein natives inkrementelles SQL-Backup auf der Datenbank durch, um die LSN-Änderung auf der SQL-Seite zu erzwingen. Behalten Sie die Datenbankeinträge in der sqlmeta.xml Datei im Auge.
  3. Führen Sie nun das inkrementelle Avamar-Backup aus, das voraussichtlich einen Protokolllückenfehler in der Datenbank meldet. Hier stellen wir fest, dass der Eintrag aus der sqlmeta.xml Datei entfernt wird. Das Löschen erfolgt nur bei Policy-gesteuerten inkrementellen Backups. Wenn Sie ein inkrementelles On-Demand-Backup ausführen, werden die Einträge in der sqlmeta.xml Datei beibehalten.
Schritt #1:
  • Führen Sie die folgende Abfrage im Fenster "SQL Management Studio Query Analyzer" aus, um Details zur Protokollsequenznummer abzurufen.
SELECT msdb.dbo.backupset.database_name,
msdb.dbo.backupset.backup_start_date,
msdb.dbo.backupset.backup_finish_date,
msdb.dbo.backupset.type,
msdb.dbo.backupset.database_backup_lsn,
msdb.dbo.backupset.first_lsn,
msdb.dbo.backupset.last_lsn
FROM msdb.dbo.backupmediafamily
INNER JOIN msdb.dbo.backupset
ON msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id 
WHERE database_name IN ('test_db_1')
--and msdb.dbo.backupset.backup_finish_date between '1/20/2020' and '1/27/2020'
ORDER BY 
2 DESC,
3 DESC
Die Ausgabe dieser Abfrage ist unten dargestellt: 
database_name    backup_start_date    backup_finish_date    type   
database_backup_lsn    first_lsn    last_lsn
test_db_1    2020-02-12 16:37:31.000    2020-02-12 16:37:31.000    D   
34000000085100037    34000000089600037    34000000091300001
test_db_1    2020-02-05 20:29:23.000    2020-02-05 20:29:23.000    L   
34000000085100037    34000000083100001    34000000087600001
test_db_1    2020-02-05 20:28:55.000    2020-02-05 20:28:55.000    D   
34000000080600037    34000000085100037    34000000086800001
test_db_1    2020-02-05 20:17:30.000    2020-02-05 20:17:30.000    L   
34000000080600037    34000000078600001    34000000083100001
test_db_1    2020-02-05 20:17:02.000    2020-02-05 20:17:03.000    D   
34000000074600075    34000000080600037    34000000082300001
test_db_1    2020-02-05 11:53:18.000    2020-02-05 11:53:18.000    L   
34000000074600075    34000000050200075    34000000078600001
test_db_1    2020-02-05 11:52:50.000    2020-02-05 11:52:50.000    D   
34000000050200075    34000000074600075    34000000077800001
test_db_1    2020-02-04 15:05:18.000    2020-02-04 15:05:18.000    D    0   
34000000050200075    34000000053600001
Schritt #2:
  • Ausführen eines kompletten Avamar-Backups für die Datenbanken
  • Führen Sie die Abfrage aus, um die LSN-Nummern erneut zu überprüfen
SELECT last_lsn, type, user_name FROM msdb..backupset WHERE
database_name=N'test_db_1' AND type LIKE 'L' ORDER by last_lsn DESC
Die Ausgabe dieser Abfrage ist unten dargestellt: 
last_lsn    type    user_name
34000000087600001    L    NT AUTHORITY\SYSTEM
34000000083100001    L    NT AUTHORITY\SYSTEM
34000000078600001    L    NT AUTHORITY\SYSTEM
Schritt #3:
  • Ausführen eines inkrementellen Avamar-Backups
  • Überprüfen Sie die LSN-Nummern, indem Sie die folgende Abfrage ausführen:
  • Überprüfen Sie, ob die backup_lsn von sqlmeta.xml mit den Ergebnissen der folgenden Abfrage übereinstimmt: 
SELECT last_log_backup_lsn FROM sys.database_recovery_status "WHERE database_id
= DB_ID(N'test_db_1')"
Die Ausgabe dieser Abfrage ist unten dargestellt: 
test_db_1    2020-02-12 16:44:40.000    2020-02-12 16:44:40.000    L   
34000000089600037    34000000087600001    34000000092500001
test_db_1    2020-02-12 16:37:31.000    2020-02-12 16:37:31.000    D   
34000000085100037    34000000089600037    34000000091300001
test_db_1    2020-02-05 20:29:23.000    2020-02-05 20:29:23.000    L   
34000000085100037    34000000083100001    34000000087600001
test_db_1    2020-02-05 20:28:55.000    2020-02-05 20:28:55.000    D   
34000000080600037    34000000085100037    34000000086800001
test_db_1    2020-02-05 20:17:30.000    2020-02-05 20:17:30.000    L   
34000000080600037    34000000078600001    34000000083100001
test_db_1    2020-02-05 20:17:02.000    2020-02-05 20:17:03.000    D   
34000000074600075    34000000080600037    34000000082300001
test_db_1    2020-02-05 11:53:18.000    2020-02-05 11:53:18.000    L   
34000000074600075    34000000050200075    34000000078600001
test_db_1    2020-02-05 11:52:50.000    2020-02-05 11:52:50.000    D   
34000000050200075    34000000074600075    34000000077800001
test_db_1    2020-02-04 15:05:18.000    2020-02-04 15:05:18.000    D    0      
             34000000050200075    34000000053600001
Schritt #4:
Schritt #5:
  • Führen Sie ein weiteres Policy-gesteuertes inkrementelles Avamar-Backup aus, bei dem der Fehler "log gap" generiert werden soll.
  • Führen Sie die LSN-Validierungsabfrage erneut aus.
  • Überprüfen Sie die Protokolle, um zu bestätigen, dass das Backup mit einem Protokolllückenfehler fehlschlägt, wie im Ausschnitt unten gezeigt:
2020-02-12 16:58:01 avsql Info <19487>: Start checking for SMO DLL version
12...
2020-02-12 16:58:02 avsql Info <7065>: Working on target '(local)/test_db_1'
2020-02-12 16:58:03 avsql Info <40399>: Last full backup of target
'(local)/test_db_1' was found, labelnum = '45'.
2020-02-12 16:58:20 avsql Info <15765>: A log gap was identified or a full
backup was not found.
2020-02-12 16:58:20 avsql Error <40418>: Skipping database '(local)/test_db_1'
due to the following reason: A log gap was identified or a full backup was not
found.
2020-02-12 16:58:20 avsql Info <14245>: Creating a thread pool with 2 worker
threads.
2020-02-12 16:58:20 avsql Info <14275>: There is no more tasks to process.
2020-02-12 16:58:20 avsql Info <14271>: Waiting for worker threads to finish
...
2020-02-12 16:58:20 avsql Info <16256>: Creating process summary ...
2020-02-12 16:58:20 avsql Info <18493>: Status wrapup summary for all tragets
was processed.
2020-02-12 16:58:20 avsql Info <16257>: Inserted task: 0, completed: 0,
aborted: 0.
2020-02-12 16:58:20 avsql Info <16260>: Generating sql metadata ...
2020-02-12 16:58:20 avsql Error <14272>: There are no successfully finished
database tasks!
2020-02-12 16:58:20 avsql Error <14294>: An error occurred when generating sql
metadata
Führen Sie die folgende Abfrage aus, um die Unterbrechung der LSN-Sequenz zu überprüfen 
SELECT last_log_backup_lsn FROM sys.database_recovery_status "WHERE database_id
= DB_ID(N'test_db_1')"
SQL-Abfrageausgabe zum Abrufen der last_lsn Informationen für Datenbanken: 
database_name    backup_start_date    backup_finish_date    type   
database_backup_lsn    first_lsn    last_lsn
test_db_1    2020-02-12 16:52:42.000    2020-02-12 16:52:42.000    L   
34000000089600037    34000000092500001    34000000095800001
test_db_1    2020-02-12 16:44:40.000    2020-02-12 16:44:40.000    L   
34000000089600037    34000000087600001    34000000092500001
test_db_1    2020-02-12 16:37:31.000    2020-02-12 16:37:31.000    D   
34000000085100037    34000000089600037    34000000091300001
test_db_1    2020-02-05 20:29:23.000    2020-02-05 20:29:23.000    L   
34000000085100037    34000000083100001    34000000087600001
test_db_1    2020-02-05 20:28:55.000    2020-02-05 20:28:55.000    D   
34000000080600037    34000000085100037    34000000086800001
test_db_1    2020-02-05 20:17:30.000    2020-02-05 20:17:30.000    L   
34000000080600037    34000000078600001    34000000083100001
test_db_1    2020-02-05 20:17:02.000    2020-02-05 20:17:03.000    D   
34000000074600075    34000000080600037    34000000082300001
test_db_1    2020-02-05 11:53:18.000    2020-02-05 11:53:18.000    L   
34000000074600075    34000000050200075    34000000078600001
test_db_1    2020-02-05 11:52:50.000    2020-02-05 11:52:50.000    D   
34000000050200075    34000000074600075    34000000077800001
test_db_1    2020-02-04 15:05:18.000    2020-02-04 15:05:18.000    D    0      
             34000000050200075    34000000053600001
sqlmeta.xml Datei wird die letzte backup_lsn wie folgt angezeigt: 34000000092500001: 
2020/02/12-21:58:20.86999 [avsql_assist]  avsql_metadata::avsql_metadata
sqlmetadata = '<sqlmetadata threadpool_size="2" version="1.1">
  <instance name="(local)">
    <database last_incremental_backup="1581525880" last_restore_backup="0"
backup_lsn="34000000092500001" last_differentail_backup="0" name="test_db_1"
is_system="false" last_full_backup="1581525451"
differential_base_lsn="34000000089600037">
      <backup_data stream_mark="stream" backup_lsn="34000000087600001"
av_group_replica="primary" num_vd_streams="1" name="f-0.test_db_1"
size="4915200" backup_time="1581525451">
        <file_group name="PRIMARY">
          <file file_type="Rows Data" physical_path="C:\Program Files\Microsoft
SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\test_db_1.mdf"
logical_name="test_db_1" />
        </file_group>
        <file file_type="Log" physical_path="C:\Program Files\Microsoft SQL
Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\test_db_1_log.ldf"
logical_name="test_db_1_log" />
      </backup_data>
      <backup_data stream_mark="stream" backup_lsn="34000000092500001"
av_group_replica="primary" num_vd_streams="1" name="i-1.test_db_1"
size="655360" backup_time="1581525880">
        <file_group name="PRIMARY">
          <file file_type="Rows Data" physical_path="C:\Program Files\Microsoft
SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\test_db_1.mdf"
logical_name="test_db_1" />
        </file_group>
        <file file_type="Log" physical_path="C:\Program Files\Microsoft SQL
Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\test_db_1_log.ldf"
logical_name="test_db_1_log" />
      </backup_data>
    </database>
  </instance>
</sqlmetadata>
Das folgende Snippet für Avamar-Debug-SQL-Protokolle zeigt, dass zwei LSN-Nummern aus der SQL-Abfrage und dem sqlmeta.xml nicht übereinstimmen: 
2020/02/12-21:58:20.87599 [avsql_assist]  <===
avsql_assist::evaluate_backup_lsn
2020/02/12-21:58:20.87599 [avsql_assist]  ===>
sqlconnectimpl_smo::get_last_backup_lsn
2020/02/12-21:58:20.87599 [avsql_assist]  retrieving last backup lsn for
'test_db_1' db from sys.database_recovery_status
2020/02/12-21:58:20.87599 [avsql_assist]  ===> sqlconnectimpl_smo::InitDll
2020/02/12-21:58:20.87599 [avsql_assist]  SMO dll already loaded.
2020/02/12-21:58:20.87599 [avsql_assist]  <=== sqlconnectimpl_smo::InitDll
2020/02/12-21:58:20.87899 [avsql_assist]  ==> SMOWrap::SMO_GetLastBackupLSN
2020/02/12-21:58:20.87899 [avsql_assist]  database 'test_db_1', last backup lsn
= '34000000095800001' 
2020/02/12-21:58:20.87899 [avsql_assist]  <===
sqlconnectimpl_smo::get_last_backup_lsn
2020/02/12-21:58:20.87899 [avsql_assist]  ===> avsql_metadata::get
2020/02/12-21:58:20.87899 [avsql_assist]  ===> avsql_metadata::get
2020/02/12-21:58:20.87899 [avsql_assist]  <=== avsql_metadata::get
2020/02/12-21:58:20.87899 [avsql_assist]  <=== avsql_metadata::get
2020/02/12-21:58:20.87899 [avsql_assist]  Last backup LSN: '34000000092500001',
Current LSN: '34000000095800001'
2020/02/12-21:58:20.87899 [avsql_assist]  ===>
avsql_assist::align_numeric_ustrings
2020/02/12-21:58:20.88000 [avsql_assist]  Before alignment - Str1:
'34000000092500001', Str2: '34000000095800001'
2020/02/12-21:58:20.88000 [avsql_assist]  After alignment - Str1:
'34000000092500001', Str2: '34000000095800001'
2020/02/12-21:58:20.88000 [avsql_assist]  <===
avsql_assist::align_numeric_ustrings
2020/02/12-21:58:20.88000 [avsql_assist]  Aligned before compare- Last backup
(metadata) LSN: '34000000092500001', Current (SQL Server) LSN:
'34000000095800001'
2020-02-12 16:58:20 avsql Info <15765>: A log gap was identified or a full
backup was not found.
2020/02/12-21:58:20.88199 [avsql_assist]  ===> sqlconnect::~sqlconnect
2020/02/12-21:58:20.89100 [avsql_assist]  <=== sqlconnect::~sqlconnect
2020/02/12-21:58:20.89100 [avsql_assist]  <===
avsql_assist::snapup_check_timestamps
2020-02-12 16:58:20 avsql Error <40418>: Skipping database '(local)/test_db_1'
due to the following reason: A log gap was identified or a full backup was not
found.

Um diesen Fehler zu beheben und die LSN-Informationen zu synchronisieren, führen Sie ein komplettes Backup für diese Datenbank aus.

Affected Products

Avamar Plug-in for SQL
Article Properties
Article Number: 000214572
Article Type: How To
Last Modified: 05 Sept 2025
Version:  2
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.