Avamar:執行原生 SQL 增量備份對 Avamar 作業的影響
摘要: 本文說明從 SQL Management Studio 原生執行 SQL 增量備份,如何影響 Avamar SQL 備份。因此,由於記錄鏈 LSN 順序中斷,Avamar 增量備份預期會報告記錄間隙。
本文章適用於
本文章不適用於
本文無關於任何特定產品。
本文未識別所有產品版本。
說明
下列步驟的設計目的是中斷 Avamar「記錄鏈結」順序,造成「記錄間隙」錯誤:
步驟#5:
若要解決此故障並同步 LSN 資訊,請為此資料庫執行完整備份。
- 先執行完整備份,然後再執行 Avamar 增量備份。保留 sqlmeta.xml 檔中資料庫條目的選項卡。
- 在資料庫上執行本機 SQL 增量備份,強制在 SQL 端進行 LSN 更改。在 sqlmeta.xml 檔中保留資料庫條目的選項卡。
- 現在執行 Avamar 增量備份,預期會報告資料庫 上的記錄差距錯誤。在這裡,我們注意到 sqlmeta.xml 檔中的條目被刪除。刪除僅適用於原則導向的增量備份,如果執行隨選增量備份,則會保留 sqlmeta.xml 檔案中的項目。
- 從 SQL 管理工作室查詢分析器視窗執行以下查詢,以獲取“日誌序列號”詳細資訊。
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 此查詢的輸出如下所示:
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 步驟#2:
- 在資料庫上執行完整的 Avamar 備份
- 執行查詢以再次檢查 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 此查詢的輸出如下所示:
last_lsn type user_name
34000000087600001 L NT AUTHORITY\SYSTEM
34000000083100001 L NT AUTHORITY\SYSTEM
34000000078600001 L NT AUTHORITY\SYSTEM 步驟#3:
- 執行 Avamar 增量備份
- 執行以下查詢來檢查 LSN 編號
- 確認 sqlmeta.xml中的backup_lsn與以下查詢顯示的內容相符:
SELECT last_log_backup_lsn FROM sys.database_recovery_status "WHERE database_id
= DB_ID(N'test_db_1')" 此查詢的輸出如下所示:
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 步驟#4:
- 執行原生 SQL 增量備份。
步驟#5:
- 執行另一個原則導向的 Avamar 增量備份,預期會產生「記錄差距」錯誤。
- 重新執行 LSN 驗證查詢
- 檢查記錄以確認備份失敗並出現 記錄差距錯誤,如以下截圖所示:
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
執行以下查詢以驗證 LSN 序列中的中斷
SELECT last_log_backup_lsn FROM sys.database_recovery_status "WHERE database_id
= DB_ID(N'test_db_1')" SQL 查詢輸出,以取得資料庫的last_lsn資訊:
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 檔案會將最後一個 backup_lsn 顯示為: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> 以下 Avamar Debug SQL 記錄片段顯示來自 SQL 查詢和 sqlmeta.xml 的兩個 LSN 數字不相符:
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.
若要解決此故障並同步 LSN 資訊,請為此資料庫執行完整備份。
受影響的產品
Avamar Plug-in for SQL文章屬性
文章編號: 000214572
文章類型: How To
上次修改時間: 05 9月 2025
版本: 2
向其他 Dell 使用者尋求您問題的答案
支援服務
檢查您的裝置是否在支援服務的涵蓋範圍內。