日韩欧美人妻无码精品白浆,夜夜嗨AV免费入口,国产欧美官网在线看,高校回应聋哑女生因长相完美被质疑

單個(gè)48TB大小SQL Server數(shù)據(jù)庫備份導(dǎo)致日志文件無法截?cái)?/h3>

當(dāng)前位置：點(diǎn)晴教程→知識管理交流 →『 技術(shù)文檔交流 』

freeflydom 2025年5月15日 10:16 本文熱度 575

SQL Server 版本：SQL Server 2019
背景
在一個(gè)48T大小的單數(shù)據(jù)庫環(huán)境中，采用簡單恢復(fù)模式，日志文件大小限制為600G。執(zhí)行一次完整備份時(shí)，耗時(shí)超過12小時(shí)，導(dǎo)致日志文件無法截?cái)嗖⑦_(dá)到上限，后續(xù)事務(wù)無法正常寫入，導(dǎo)致整個(gè)數(shù)據(jù)庫不可用。

問題現(xiàn)象
LDF日志文件中的虛擬日志文件 (VLF) 全部為活動狀態(tài)，導(dǎo)致日志無法正常截?cái)?。由于日志文件大小達(dá)到了600G的限制，后續(xù)的事務(wù)寫入失敗，導(dǎo)致數(shù)據(jù)庫操作停滯。

排查思路
排查思路一般有下面幾個(gè)：
1、大事務(wù)導(dǎo)致日志無法截?cái)啵嚎赡苁俏刺峤坏拇笫聞?wù)阻止了日志的截?cái)唷?br>2、特殊環(huán)境：如復(fù)制 (Replication)、鏡像 (Mirroring)、可用性組 (AG)、變更數(shù)據(jù)捕獲 (CDC) 等場景下，備用端異常會導(dǎo)致主端無法截?cái)嗳罩尽?br>3、未及時(shí)備份事務(wù)日志：在完整恢復(fù)模式下，未及時(shí)備份事務(wù)日志導(dǎo)致日志文件增長。
4、數(shù)據(jù)庫恢復(fù)時(shí)間設(shè)置：修改過數(shù)據(jù)庫恢復(fù)時(shí)間，可能導(dǎo)致checkpoint延遲，從而延長日志文件的截?cái)鄷r(shí)間。

排查步驟
按照下面思路進(jìn)行逐一排查
1、確認(rèn)數(shù)據(jù)庫恢復(fù)模式：數(shù)據(jù)庫為簡單恢復(fù)模式，排除事務(wù)日志備份問題（思路3）。
2、檢查運(yùn)行環(huán)境：數(shù)據(jù)庫為單機(jī)模式，排除復(fù)制、鏡像、AG等場景（思路2）。
3、檢查長時(shí)間事務(wù)：使用 `DBCC OPENTRAN` 檢查，未發(fā)現(xiàn)長時(shí)間運(yùn)行的事務(wù)，排除大事務(wù)問題（思路1）。
4、檢查數(shù)據(jù)庫恢復(fù)設(shè)置：`TARGET_RECOVERY_TIME` 和 `recovery interval` 為默認(rèn)值，排除恢復(fù)時(shí)間問題（思路4）。
5、檢查阻塞情況：未發(fā)現(xiàn)阻塞問題。
6、檢查SQL Agent作業(yè)：除了完整備份外，未發(fā)現(xiàn)其他作業(yè)運(yùn)行。
7、檢查寫入邏輯：與開發(fā)人員溝通得知，該數(shù)據(jù)庫為日常批量數(shù)據(jù)寫入，日志寫入量超過400G。

問題原因分析
這里面我們需要從數(shù)據(jù)庫完整備份的原理入手，解剖備份的細(xì)節(jié)，分析原因，一般來說，數(shù)據(jù)庫完整備份分為兩個(gè)階段：
1、第一階段：對數(shù)據(jù)庫做一個(gè)Checkpoint，然后記錄備份開始時(shí)的LSN，生成快照式備份。
2、第二階段：快照備份結(jié)束后，記錄最新的LSN，并將這兩次LSN之間的事務(wù)日志寫入備份。

在數(shù)據(jù)庫完整備份過程中，即使數(shù)據(jù)庫處于簡單恢復(fù)模式，完整備份依然會拷貝未提交事務(wù)的日志。對于長時(shí)間運(yùn)行的事務(wù)，完整備份需要包含足夠的日志信息來撤銷這些未提交的事務(wù)。用戶在還原完整備份的時(shí)候，實(shí)際上也是需要經(jīng)歷整個(gè)數(shù)據(jù)庫崩潰恢復(fù)（Crash Recovery）過程。由于客戶的數(shù)據(jù)庫實(shí)在太大，備份時(shí)間超過12個(gè)小時(shí)，導(dǎo)致備份操作一直處于第一階段，無法進(jìn)入到第二階段。這期間，事務(wù)日志文件中的日志無法截?cái)啵?2小時(shí)內(nèi)的事務(wù)量超過600GB，導(dǎo)致ldf事務(wù)日志文件被撐滿到閾值。

優(yōu)化建議
最后的解決方案是，開啟SQL Server 2019的ADR（加速數(shù)據(jù)庫恢復(fù)）功能，完整備份時(shí)候，日志文件只有少量增長，問題解決。
啟用 ADR 的步驟
確保使用的是 SQL Server 2019 或 SQL Server 2022，因?yàn)?ADR 是從 SQL Server 2019 開始引入的。

--開啟數(shù)據(jù)庫的ADR功能
ALTER DATABASE [YourDatabaseName]
SET ACCELERATED_DATABASE_RECOVERY = ON;
GO
--檢查 ADR 狀態(tài)
SELECT name, is_accelerated_database_recovery_on
FROM sys.databases
WHERE name = 'YourDatabaseName';
--關(guān)閉 ADR
ALTER DATABASE [YourDatabaseName]
SET ACCELERATED_DATABASE_RECOVERY = OFF;
GO

這里有如下幾個(gè)優(yōu)化思路：
1、多文件備份：將默認(rèn)的單文件備份改為多文件備份，可以提升備份效率，縮短備份時(shí)間。（之前介紹過SQL Server的一個(gè)不顯眼的功能備份文件分割）
2、升級SQL Server版本：升級到SQL Server 2019或SQL Server 2022，啟用ADR（加速數(shù)據(jù)庫恢復(fù)）功能，通過SLOG實(shí)現(xiàn)日志及時(shí)截?cái)唷?br>3、業(yè)務(wù)拆分：盡管不現(xiàn)實(shí)，但從業(yè)務(wù)上進(jìn)行拆分也可以減少單一數(shù)據(jù)庫的事務(wù)量。

總結(jié)
在SQL Server 2019中，一個(gè)48TB數(shù)據(jù)庫因備份耗時(shí)過長，導(dǎo)致日志文件無法截?cái)嗖⑦_(dá)到上限，阻礙事務(wù)寫入。
本文介紹了多種解決方案包括多文件分割備份、啟用數(shù)據(jù)庫ADR功能。
最終啟用數(shù)據(jù)庫ADR功能解決了問題。這里要注意的是，一定要盡量使用最新的數(shù)據(jù)庫版本，例如SQL Server 2019或者SQL Server 2022，
保證能使用到最新功能，可以擺脫很多麻煩。

補(bǔ)充：數(shù)據(jù)庫完整備份原理
在完整備份過程中，即使數(shù)據(jù)庫處于簡單恢復(fù)模式，備份依然會拷貝未提交事務(wù)的日志。對于長時(shí)間運(yùn)行的事務(wù)，備份會包含足夠的日志信息來撤銷這些未提交的事務(wù)。
因此，即使數(shù)據(jù)庫的MDF文件較小，日志文件（LDF）也可能會導(dǎo)致備份文件非常大。
這與MySQL的Xtrabackup的原理幾乎是一樣的，備份開始時(shí)生成一個(gè)開始LSN，結(jié)束時(shí)生成一個(gè)結(jié)束LSN，如果有未提交事務(wù)，MySQL8.0的undoxx文件會非常大

轉(zhuǎn)自https://www.cnblogs.com/lyhabc/p/18402109/

該文章在 2025/5/15 10:18:24 編輯過