如何解讀SQL Server日誌(3/3)

如何查看被截斷的日誌

若是數據庫作了日誌備份操做，則日誌會被截斷，而後原來活動的VLF會被重用。使用sys.fn_dblog將會看不到任何被截斷的日誌。那如何查看日誌備份中的日誌呢？使用fn_dump_dblog讀取日誌備份的內容。它的輸出和sys.fn_dblog是同樣的，因此進行查詢過濾時也能夠跟其同樣。

use master
go
backup log logtest to disk='d:\logtest.trn';
go
select [Current LSN], [Operation], [AllocUnitName], [Transaction Name]
    from fn_dump_dblog (
    NULL, NULL, 'DISK', 1, 'D:\logtest.trn',
    DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
    DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
    DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
    DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
    DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
    DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
    DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
    DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
    DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
    where  [Transaction ID]='0000:00000367'
go

當[Lock Infomation]的內容無用時

前面咱們使用[Lock Infomation]的內容幫助咱們定位和分析日誌操做，可是若是數據操做沒有單獨鎖定某個行時(e.g.鎖升級和使用表提示鎖定表)，則它的內容對咱們的幫助就不多了。

delete top(1) from demotable with (tablockx);

select [Current LSN], [Operation], [Transaction ID],
    [AllocUnitName], [Page ID], [Slot ID], [Lock Information]
    from fn_dblog(null, null)
where [transaction id]='0000:0000036a'

上面的刪除使用tablockx表提示，使得刪除是直接對錶使用X鎖，而不是行鎖。這樣在[Lock Information]就沒有包含鍵鎖的HASH值(Lockres)。如圖，咱們如今能獲取到Page ID、Slot ID和Object ID，可是不能定位到行。

可是日誌的有效工做負載仍是包含了全部的內容，所以能夠經過搜索[Log Record]或者 [RowLog Contents 0~5] 來找到具體的行。

最小化日誌操做也會讓查找日誌變得更困難。最小化日誌操做的日誌內容只掃描了某個頁包含了最小華日誌操做，SQL Server必需保證它在事務提交前被刷新到磁盤。在相關日誌中只看到LOP_FORMAT_PAGE操做及其操做(最小化日誌操做)的Page ID。最小化日誌只有INSERT、blob .WRITE和WRITETEXT/UPDATETEXT操做，其它的操做都會完整記錄日誌，這樣分析日誌要分析的內容就少了不少。有一種狀況會增長操做的日誌量：更新事務複製中的發佈表的數據。

實踐時的注意事項

本文的例子的日誌量很是少，搜索起來也很快。在真實環境中可能要透過數百萬行日誌才能找到所須要的日誌記錄，固然會很慢。最好將sys.fn_dblog返回的日誌行先存到表中，而後創建須要的索引，這樣查詢時會快不少。使用sys.fn_dblog時若是能傳入開始和結束的LSN，也會讓其它返回速度快一些。注意，若是傳入不正確的LSN給sys.fn_dblog，則會致使服務器內核轉儲( server core dump )，在生產環境這會致使SQL Server僵死一下子。

DDL 修改

分析DDL修改的思路跟分析數據修改的同樣。數據庫對象是存儲於一個或多個系統表中的數據，全部DDL修改最終會經過修改系統表的數據而完成。這樣會讓全部的DDL修改在分析日誌時看起來差很少，例如LOP_INSER_ROWS操做插入數據到sys.syschhobjs，它多是CREATE TABLE,也多是CREATE VIEW或者CREATE PROC，甚至CREATE TABLE foo和CREATE TABLE bar的日誌看起來是同樣的。

DDL操做和DML操做二者修改數據時的主要區別在於使用不一樣鎖。DDL使用元數據鎖(Metedata Lock)，通常狀況，DDL會以包含Object ID的SCH_M鎖開始。

另外，分析日誌中DDL，要與特定的版本和更新相匹配。不一樣的版本、SP甚至CU，元數據表和元數據表結構可能會不一樣。

利用OBJECT ID

找出某個對象的DDL具體操做的最好方法是經過找出在對象上請求SCH_M鎖的事務。先經過OBJECT_ID()得對象的ID，而後在[Lock Information]列中匹配搜索模式N'%SCH%