簡介Log Explorer 4.2是一款專業(yè)的日志分析與管理系統(tǒng)工具面向數(shù)據(jù)庫管理員、運(yùn)維工程師及IT技術(shù)支持人員用于快速檢索、分析SQL Server及系統(tǒng)日志定位故障、審計操作與性能瓶頸。資源包共138個文件壓縮包約8.62MB主要包含htm幫助文檔、chm使用手冊、exe主程序、dll動態(tài)庫以及sql腳本等類型既有可執(zhí)行程序也有配套說明便于安裝后對照學(xué)習(xí)。4.2版本特別加入對64位操作系統(tǒng)的完整支持能夠有效利用大內(nèi)存與多核處理能力應(yīng)對更大規(guī)模的日志數(shù)據(jù)提升排障效率同時包內(nèi)81個htm文件與2個chm手冊構(gòu)成較詳細(xì)的文檔體系可幫助用戶快速掌握日志篩選、恢復(fù)與分析流程。目前已有271人學(xué)習(xí)下載獲取后可直接安裝使用結(jié)合附帶腳本與配置示例適合從入門到進(jìn)階的IT人員實(shí)踐參考。 做數(shù)據(jù)庫維護(hù)的人估計都經(jīng)歷過這種場面一條UPDATE少加了WHERE條件整表數(shù)據(jù)被改得面目全非或者一個DELETE誤執(zhí)行核心業(yè)務(wù)數(shù)據(jù)說沒就沒。如果當(dāng)時沒有做完整備份很多人第一反應(yīng)是“完蛋了只能從備份恢復(fù)丟一天數(shù)據(jù)”。但如果你手頭有Log Explorer 4.2事情還有回旋余地。這個誕生于SQL Server 2000時代的日志分析工具直到今天依然是不少DBA和開發(fā)者在緊急事故中用來翻盤的最后一根稻草。Log Explorer 4.2的核心能力一句話概括讀取在線數(shù)據(jù)庫的LDF事務(wù)日志把里面記錄的每一次操作解析成可讀的明細(xì)并自動生成對應(yīng)的UNDO撤銷或REDO重放T-SQL腳本。有了這些腳本你就能在被誤刪、誤改之后把數(shù)據(jù)“摳”回來而不是只能依賴一個時間點(diǎn)之后的所有業(yè)務(wù)停機(jī)。這篇文章我會從日志原理、工具實(shí)操、踩坑記錄三個維度完整拆解這套恢復(fù)流程適合所有SQL Server DBA、后端開發(fā)以及需要自己維護(hù)數(shù)據(jù)庫的人參考。1. 為什么這個老工具到現(xiàn)在還沒過時1.1 它解決的核心問題誤操作后的數(shù)據(jù)回滾Log Explorer 4.2定位非常明確它不是一個日常備份工具而是一個“事故現(xiàn)場分析器”。它解決的場景主要有這么幾類誤執(zhí)行了UPDATE或DELETE影響大量行數(shù)據(jù)且沒有對應(yīng)時間點(diǎn)的備份。需要追溯某張表在某個時間段內(nèi)的全部變更歷史搞清楚是誰在什么時候改了哪些數(shù)據(jù)。表被TRUNCATE清空希望通過日志找回數(shù)據(jù)。某個事務(wù)被手動回滾后需要重新執(zhí)行REDO場景。它的工作原理說穿了并不復(fù)雜。SQL Server在運(yùn)行過程中會把每一個事務(wù)的詳細(xì)信息按順序?qū)懭隠DF日志文件包括事務(wù)ID、操作類型、涉及的表和頁、修改前/修改后的數(shù)據(jù)鏡像、執(zhí)行時間等。Log Explorer就是把這些底層二進(jìn)制日志翻譯成普通SQL語句和可讀列表然后基于這些信息反向生成恢復(fù)腳本。1.2 相比備份恢復(fù)和其他工具它強(qiáng)在哪很多人會問數(shù)據(jù)庫有備份機(jī)制干嘛還要用第三方工具我實(shí)際對比過幾種常見恢復(fù)路徑區(qū)別非常明顯方案優(yōu)點(diǎn)缺點(diǎn)/限制完整備份 日志備份還原最正統(tǒng)數(shù)據(jù)一致性有保障需要停機(jī)或搭建臨時實(shí)例備份時間點(diǎn)可能早于誤操作恢復(fù)流程長操作繁瑣系統(tǒng)函數(shù) fn_dblog免費(fèi)可讀日志記錄輸出字段極其晦澀解析復(fù)雜度高對普通DBA不友好Log Explorer 4.2輕量、直接讀在線日志、自動生成腳本版本老對SQL Server 2012支持不佳要求日志未被截斷ApexSQL Log 等現(xiàn)代工具功能全面、UI現(xiàn)代商業(yè)授權(quán)價格不低安裝體量較大臨時救急不夠輕便實(shí)測下來在老版本SQL Server2000/2005/2008環(huán)境Log Explorer 4.2確實(shí)是效率最高的選擇。它不需要恢復(fù)整個數(shù)據(jù)庫也不用等備份系統(tǒng)響應(yīng)只要日志文件還在幾分鐘內(nèi)就能生成可執(zhí)行的回滾腳本。這在實(shí)際故障處理中往往就是“業(yè)務(wù)停5分鐘”和“業(yè)務(wù)停半天”的區(qū)別。2. 開始操作前先理解日志為什么能救我2.1 LDF文件里到底存了什么很多人天天見LDF文件但未必清楚里面具體裝了什么。拿快遞物流來類比每個包裹從發(fā)貨到簽收中間每一個節(jié)點(diǎn)都會有掃描記錄。LDF文件就是數(shù)據(jù)庫的“物流掃描臺賬”每一次插入、更新、刪除都會以日志記錄Log Record的形式追加寫入。每條日志記錄大致包含這些關(guān)鍵信息事務(wù)ID標(biāo)識這條記錄屬于哪個事務(wù)。操作類型INSERT、DELETE、UPDATE、TRUNCATE等。數(shù)據(jù)頁號與槽位定位到具體是哪一行數(shù)據(jù)。修改前鏡像Before Image操作執(zhí)行前的數(shù)據(jù)值。修改后鏡像After Image操作執(zhí)行后的數(shù)據(jù)值。LSN日志序列號每條記錄的全局唯一編號用來保證順序。我早期不懂這些概念時總覺得Log Explorer像個黑魔法。后來看了一部分日志原始結(jié)構(gòu)才明白它本質(zhì)上就是一個“日志翻譯器”把二進(jìn)制記錄轉(zhuǎn)換成我們能讀懂的列表和腳本。2.2 為什么UNDO腳本能恢復(fù)數(shù)據(jù)UNDO腳本能恢復(fù)數(shù)據(jù)的根本原因是日志里保存了修改前鏡像。舉個例子假設(shè)原操作是一條UPDATE把某行數(shù)據(jù)的余額從1000改成了100。日志里會同時記錄“改前是1000”和“改后是100”。Log Explorer生成的UNDO腳本本質(zhì)上就是“反向操作”把100再改回1000。DELETE操作同理日志里記錄了被刪除行的完整數(shù)據(jù)鏡像UNDO腳本就會生成對應(yīng)的INSERT語句把那一行原樣插回去。INSERT操作反過來UNDO生成DELETE。這里有一個很關(guān)鍵的前提日志記錄必須還在。如果數(shù)據(jù)庫的恢復(fù)模式是SIMPLE系統(tǒng)會定期自動截斷日志老記錄會被覆蓋清理。一旦日志被截斷Log Explorer再強(qiáng)也讀不出那些操作記錄。所以我在后面會反復(fù)強(qiáng)調(diào)使用這個工具之前先確認(rèn)數(shù)據(jù)庫恢復(fù)模式是FULL以及日志還沒有被手動收縮或截斷。3. 實(shí)操完整走一遍 Log Explorer 4.2 恢復(fù)流程3.1 環(huán)境準(zhǔn)備與工具安裝Log Explorer 4.2的安裝包很輕量安裝過程基本是“下一步教主”。但因為是老軟件在現(xiàn)代Windows操作系統(tǒng)上會有兼容性問題我第一次裝的時候就在啟動界面卡了半天。后來發(fā)現(xiàn)解決辦法很簡單對主程序exe文件右鍵進(jìn)入“屬性 - 兼容性”。選擇“以兼容模式運(yùn)行”推薦Windows 7或Windows XP SP3。勾選“以管理員身份運(yùn)行此程序”。另外工具本身是32位程序在64位系統(tǒng)上運(yùn)行沒問題但如果要從遠(yuǎn)程連接到SQL Server實(shí)例需要確認(rèn)SQL Server的TCP/IP協(xié)議已啟用且防火墻放行了1433端口。數(shù)據(jù)庫這邊同樣要提前確認(rèn)一些基礎(chǔ)條件數(shù)據(jù)庫必須處于在線狀態(tài)且恢復(fù)模式為FULL。當(dāng)前賬號至少具備db_owner權(quán)限否則讀取日志會報權(quán)限不足。誤操作發(fā)生后盡量別再執(zhí)行大量寫操作避免日志鏈被后續(xù)事務(wù)沖淡。3.2 連接數(shù)據(jù)庫并開始分析日志啟動Log Explorer后主界面上選擇“Attach Log File”也就是附加日志文件。在彈出的窗口里填寫SQL Server實(shí)例信息、認(rèn)證方式然后選中你要分析的數(shù)據(jù)庫。這個時候工具會掃描LDF文件并加載全部日志記錄掃描時間取決于日志文件大小幾百M(fèi)B通常一分鐘內(nèi)能完成。掃描完成后進(jìn)入主界面你會看到三塊區(qū)域左側(cè)是日志記錄列表按時間順序排列可以點(diǎn)擊列頭排序。中間是選中記錄的詳細(xì)信息包括事務(wù)ID、操作時間、操作類型、涉及的表名等。右側(cè)是工具自動解析出的SQL語句。如果日志記錄很多千萬不要直接從頭翻。優(yōu)先使用頂部菜單的“Filter”功能按時間范圍、操作類型、表名做篩選。比如我只想查某張訂單表在昨天下午3點(diǎn)到4點(diǎn)之間的DELETE操作篩選條件設(shè)置好之后列表會瞬間收縮到幾十條定位效率高很多。3.3 定位誤操作并生成UNDO腳本找到目標(biāo)記錄后在記錄上右鍵選擇“Create UNDO Script”或類似選項。工具會彈出生成設(shè)置讓你選擇輸出方式保存為.sql文件還是復(fù)制到剪貼板還是直接在文本查看器里預(yù)覽。我習(xí)慣的做法是先預(yù)覽腳本確認(rèn)腳本里包含的事務(wù)范圍正確。保存成.sql文件拿到測試環(huán)境執(zhí)行一遍看影響行數(shù)是否匹配預(yù)期。確認(rèn)無誤后再回到生產(chǎn)環(huán)境執(zhí)行。生成的UNDO腳本有幾個特點(diǎn)需要注意。它會用BEGIN TRAN/COMMIT包裹整個恢復(fù)邏輯意味著整個恢復(fù)過程是一個事務(wù)要么全部成功要么全部回滾。腳本里還會包含一些輔助變量和臨時表操作用來處理多個事務(wù)的協(xié)調(diào)回滾不要手動刪除這些邏輯。執(zhí)行恢復(fù)時建議按這個順序來-- 1. 開啟顯式事務(wù) BEGIN TRAN; -- 2. 設(shè)置出錯立即回滾 SET XACT_ABORT ON; -- 3. 執(zhí)行Log Explorer生成的UNDO腳本內(nèi)容 -- ... 這里粘貼腳本 ... -- 4. 檢查影響行數(shù)和數(shù)據(jù)正確性 -- 確認(rèn)無誤后執(zhí)行 COMMIT COMMIT;如果執(zhí)行過程中發(fā)現(xiàn)錯誤直接讓事務(wù)回滾不要強(qiáng)行提交。3.4 補(bǔ)充REDO腳本的使用場景UNDO腳本用于回滾誤操作REDO腳本則用于重放操作。有一個實(shí)際場景某開發(fā)人員手動回滾了一個客戶端事務(wù)但事后發(fā)現(xiàn)這個回滾操作本身是個錯誤業(yè)務(wù)數(shù)據(jù)需要被重新執(zhí)行一遍。這種情況下就可以在Log Explorer中找到那個回滾的事務(wù)生成REDO腳本把事務(wù)重新執(zhí)行一次。生成方式與UNDO完全一致區(qū)別只在于腳本里的SQL方向。UNDO把數(shù)據(jù)改回去REDO把數(shù)據(jù)按原操作重放。我一般建議把兩個腳本都生成保存特別是重要事務(wù)以備不時之需。4. 真實(shí)踩坑記錄與排查技巧4.1 日志讀取失敗或附加時報錯這是大家最容易碰到的問題。Log Explorer啟動后無法列出目標(biāo)數(shù)據(jù)庫或者附加日志時直接報錯通常有以下幾個原因報錯/現(xiàn)象可能原因排查與解決無法連接到實(shí)例遠(yuǎn)程連接未開啟、端口不通確認(rèn)SQL Server TCP/IP協(xié)議已啟用防火墻放行1433附加日志時提示無效數(shù)據(jù)庫處于SIMPLE恢復(fù)模式日志已被截斷查看 sys.databases 的 recovery_model_desc若為SIMPLE只能對之前截斷點(diǎn)之后的記錄做分析且這部分有限權(quán)限不足當(dāng)前賬號不是db_owner/sysadmin用高權(quán)限賬號重新連接生產(chǎn)環(huán)境謹(jǐn)慎操作掃描超時或卡死日志文件太大或系統(tǒng)資源不足優(yōu)先用Filter減少掃描范圍或者把LDF文件拷貝出來在單獨(dú)實(shí)例上分析我踩過最深的坑是接手一個項目時發(fā)現(xiàn)生產(chǎn)庫恢復(fù)模式是SIMPLEDBA從來不做日志備份整個恢復(fù)鏈路是斷的。這種情況下Log Explorer基本幫不上忙唯一能做的就是把恢復(fù)模式改成FULL之后的故障才能有日志可查。4.2 生成的UNDO腳本執(zhí)行時頻繁報錯腳本生成成功執(zhí)行卻報錯這是另一個常見問題。報錯類型通常是主鍵沖突、外鍵約束沖突或者“無法更新行因為行不存在”。原因在于Log Explorer生成的恢復(fù)腳本依賴的是它掃描日志那一刻的數(shù)據(jù)狀態(tài)。如果數(shù)據(jù)庫在誤操作之后又發(fā)生了其他事務(wù)比如有程序自動插入了新數(shù)據(jù)、修改了主鍵、刪除了關(guān)聯(lián)行那恢復(fù)腳本執(zhí)行時就會撞上約束。我的應(yīng)對策略是這樣的執(zhí)行前關(guān)閉相關(guān)表的觸發(fā)器防止二次業(yè)務(wù)邏輯干擾?；謴?fù)過程中先把相關(guān)表設(shè)置為單用戶模式避免程序自動寫入。如果腳本因為外鍵約束失敗先恢復(fù)子表再恢復(fù)父表或者臨時禁用外鍵約束。逐個排查失敗事務(wù)不要指望一次跑完所有腳本。4.3 工具太老新版本SQL Server不支持Log Explorer 4.2誕生時最新版本是SQL Server 2000所以對SQL Server 2012及之后的內(nèi)核支持很差。我試過用它在SQL Server 2016上附加數(shù)據(jù)庫工具直接無法識別實(shí)例。碰到這種情況有幾個替代思路用fn_dblog系統(tǒng)函數(shù)做初級排查雖然輸出很原生但至少能看到操作記錄。考慮現(xiàn)代商業(yè)工具如ApexSQL Log、Quest Toad它們對新版本支持更好。如果只是救急可以嘗試把LDF文件拷貝到一臺裝有舊版SQL Server的測試實(shí)例上先附加數(shù)據(jù)庫再用Log Explorer分析。最后這個方法我實(shí)際用過幾次但必須強(qiáng)調(diào)一個前提數(shù)據(jù)文件和日志文件必須配套單獨(dú)拷貝LDF文件無法附加需要整個數(shù)據(jù)庫文件一起拷貝到測試環(huán)境。4.4 日志記錄太多定位不到目標(biāo)操作很多時候誤操作不是單一的一條SQL而是一整個事務(wù)批處理日志里可能有幾千條關(guān)聯(lián)記錄。這時候如果用Filter一頁頁翻效率很低。我的經(jīng)驗是先用對象類型篩選鎖定目標(biāo)表。按操作類型篩選優(yōu)先看DELETE和UPDATEINSERT通常不是主要恢復(fù)目標(biāo)。按時間范圍精確圈定不要給太寬的時間窗。在列表中隨機(jī)抽查幾條記錄確認(rèn)事務(wù)ID是否連續(xù)如果中斷說明日志有截斷或缺失。還有一點(diǎn)很重要誤操作發(fā)生后盡量不要再做大量寫操作。一方面新的事務(wù)可能覆蓋日志尾部另一方面后續(xù)操作產(chǎn)生的數(shù)據(jù)變更會讓恢復(fù)腳本的適用范圍變小。發(fā)現(xiàn)問題的第一時間應(yīng)該先斷開應(yīng)用連接把損失范圍控制住再慢慢分析。5. 幾點(diǎn)個人經(jīng)驗總結(jié)操作Log Explorer這么多年我最大的體會是工具只是最后一根救命稻草真正的安全網(wǎng)永遠(yuǎn)是備份。但我也確實(shí)見過太多“備份形同虛設(shè)”的項目備份文件損壞、日志模式錯誤、沒有定期做恢復(fù)演練出事了才發(fā)現(xiàn)所有備份都是白搭。如果你能把Log Explorer用熟至少在應(yīng)急處理時多一條路。最后分享幾個我養(yǎng)成的習(xí)慣給自己維護(hù)的所有核心數(shù)據(jù)庫設(shè)置定期日志備份確?；謴?fù)模式是FULL每次進(jìn)行批量UPDATE/DELETE之前先手動備份一張目標(biāo)表的數(shù)據(jù)哪怕只是導(dǎo)出成CSV在操作日志分析工具時永遠(yuǎn)先在測試環(huán)境驗證腳本再上生產(chǎn)。這些習(xí)慣看起來繁瑣但在事故現(xiàn)場每一條都能幫你節(jié)省至少半小時的恢復(fù)時間。本文還有配套的精品資源點(diǎn)擊獲取