Avamar: Impatto di SQL dell'esecuzione del backup incrementale SQL nativo sulle operazioni di Avamar

Summary: Questo articolo descrive in che modo l'esecuzione di backup incrementali SQL in modo nativo da SQL Management Studio influisce sui backup SQL Avamar. Per questo motivo, si prevede che i backup incrementali di Avamar segnalino un gap nel registro a causa di un'interruzione nella sequenza LSN della catena del registro. ...

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

I seguenti passaggi sono progettati per interrompere la sequenza "log chain" di Avamar con conseguente errore "log gap":

Eseguire un backup completo seguito da un backup incrementale Avamar. Tenere sotto controllo le voci del database nel file di sqlmeta.xml .
Eseguire un backup incrementale SQL nativo sul database forzando la modifica LSN sul lato SQL. Tenere sotto controllo le voci del database nel file di sqlmeta.xml .
A questo punto, eseguire il backup incrementale di Avamar, che dovrebbe segnalare un errore di gap nel registro. Qui notiamo che la voce dal file sqlmeta.xml viene rimossa. L'eliminazione avviene solo per i backup incrementali basati su policy. Se si esegue un backup incrementale on-demand, le voci nel file di sqlmeta.xml vengono mantenute.

Passo #1:

Eseguire la query seguente dalla finestra SQL Management Studio Query analyzer per ottenere i dettagli del "numero di sequenza del log".

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

L'output di questa query è mostrato di seguito:

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

Passo #2:

Esecuzione del backup completo di Avamar sui database
Eseguire una query per controllare nuovamente i numeri LSN

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

L'output di questa query è mostrato di seguito:

last_lsn    type    user_name
34000000087600001    L    NT AUTHORITY\SYSTEM
34000000083100001    L    NT AUTHORITY\SYSTEM
34000000078600001    L    NT AUTHORITY\SYSTEM

Passo #3:

Esecuzione del backup incrementale di Avamar
Controllare i numeri LSN eseguendo la query seguente
Verificare che il backup_lsn di sqlmeta.xml corrisponda a quello mostrato nella query seguente:

SELECT last_log_backup_lsn FROM sys.database_recovery_status "WHERE database_id
= DB_ID(N'test_db_1')"

L'output di questa query è mostrato di seguito:

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

Passo #4:

Eseguire backup incrementali SQL nativi.
- Ci sono tre modi per farlo, come documentato di seguito.
- https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/back-up-a-transaction-log-sql-server?view=sql-server-ver16

Passo #5:

Eseguire un altro backup incrementale di Avamar basato su policy che dovrebbe generare l'errore "log gap".
Eseguire nuovamente la query di convalida LSN
Controllare i registri per verificare che il backup abbia esito negativo con errore di gap nel registro, come mostrato nella cattura riportata di seguito:

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

Eseguire la query riportata di seguito per verificare l'interruzione nella sequenza LSN

SELECT last_log_backup_lsn FROM sys.database_recovery_status "WHERE database_id
= DB_ID(N'test_db_1')"

Output della query SQL per ottenere le informazioni last_lsn per i database:

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 file mostra gli ultimi backup_lsn come: 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>

Il frammento di registro SQL di debug di Avamar riportato di seguito mostra che due numeri LSN della query SQL e del sqlmeta.xml non corrispondono:

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.

Per risolvere questo errore e sincronizzare le informazioni LSN, eseguire un backup completo per questo database.

Affected Products

Avamar Plug-in for SQL

Article Number: 000214572

Article Type: How To

Last Modified: 05 Sept 2025

Version: 2

Check if your device is covered by Support Services.

Avamar: Impatto di SQL dell'esecuzione del backup incrementale SQL nativo sulle operazioni di Avamar

Instructions

Affected Products

Article Properties

Find answers to your questions from other Dell users

Support Services

Article Properties

Find answers to your questions from other Dell users

Support Services

Avamar: Impatto di SQL dell'esecuzione del backup incrementale SQL nativo sulle operazioni di Avamar

Detailed Article

Instructions

Affected Products

Instructions

Affected Products

Article Properties

Find answers to your questions from other Dell users

Support Services

Article Properties

Find answers to your questions from other Dell users

Support Services