診斷SQLSERVER問題常用的日誌概述及使用_MsSql

診斷SQLSERVER問題常用的日誌

這裡主要有兩個：

（1）Windows事件記錄

（2）SQLSERVER ErrorLog

1、Windows事件記錄 Event Log

作為一個Windows開啟和管理的服務程式，Windows會在自己的系統日誌system log裡記錄SQLSERVER這個服務的啟動、正常關閉、異常關閉等資訊。

SQLSERVER也會把自己的一些概要資訊同時記錄在Windows的應用程式記錄檔裡Application Log而Windows日誌本身又能夠反映作業系統的健康情況，是否有任何軟體或硬體的異常。

如果Windows本身不能正常工作，SQLSERVER的運行一定會受到影響。

當遇到一些問題需要微軟的售後工程師解決的時候，Windows事件記錄是一個很好的界定問題性質的工具。

在Windows裡，點擊“開始”-》運行  -》輸入：eventvwr  點確定 就可以開啟事件檢視器Event Viewer

在Windows7、Windows2008和Windows2008R2裡面，介面會有所不同，但是主要內容還是類似的

Windows主要有三種日誌：應用程式，安全，系統 （我的系統是Windows7）

對於SQLSERVER會主要關心應用程式日誌和系統日誌。當處理一些串連認證問題時，可能會偶爾用上安全日誌。

日誌裡的每一條記錄，都屬於資訊、警告、錯誤中的一類。

每條記錄都會標明日期、時間、來源、事件ID。

如果在應用日誌裡，從SQLSERVER產生的記錄其來源名稱都會是MSSQLSERVER

雙擊某一條記錄，Windows會彈出一個對話方塊，顯示記錄的具體內容

 

在這裡說一下我遇到的機器記憶體不足，導致SQLSERVER需要把記憶體換出去硬碟的情況，導致經常SQLSERVER反應緩慢

事件檢視器顯示的資訊就是上面那個截圖，一句話概括就是：系統記憶體不足

我的機器情況：

 

8GB記憶體沒有用盡，因為32位作業系統的關係，遲一點打算更換為64位Windows7

 

所以平時多看一下事件檢視器或者遇到問題的時候就先看事件檢視器，一定能找到一些問題的蛛絲馬跡

另外一個，在事件檢視器裡，還能把日誌另存新檔*.evt檔案或*.txt檔案，以供DBA帶到其他機器上開啟分析。

開啟一個*.evt檔案的方法是：是右鍵點擊“事件檢視器（本地）”樹型結構---》開啟儲存的日誌

用這種方法，DBA就能像看本機上的日誌記錄一樣，分析從其他機器儲存下來的記錄檔了

儲存的時候可以儲存單個事件或者整個類別的事件

最後，用事件記錄查看器開啟的日誌，其時間會和時區有關係的，

不同時區設定的機器開啟一個*.evt檔案，其顯示的時間會不一樣。

例如，如果某個錯誤資訊發生在美國的白天，那麼用在中國的機器開啟，其時間會顯示在晚上

如果你按美國時間找，就會找不到了。但是儲存成 *.txt格式 文字檔格式就不會有這種問題

 

2、SQLSERVER ErrorLog檔案

檢查完Windows的基本狀況後，就可以開始檢查SQLSERVER的健康情況。

不管你是遇到什麼問題，建議第一個要檢查的是SQLSERVER的ErrorLog檔案

當SQLSERVER啟動的時候，會在某個固定的路徑下產生一個“errorlog”的檔案

SQLSERVER預設會保留7份errorlog檔案，按照時間順序，依次用檔案擴名.1,.2,.3,...,.6表示。

每重啟一次服務，副檔名都會加一，最早的那份會被刪除。

 

記錄檔的預設路徑是安裝路徑下的C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\LOG子目錄。

C:\Program Files是我的機器的安裝路徑，這個路徑是你安裝SQLSERVER的時候選擇的

當然DBA也能夠修改其設定（在組態管理員裡，雙擊sql服務-》進階-》轉儲目錄）

發覺Windows對錯誤記錄檔或者目錄都叫轉儲的，像某些軟體，例如QQ，有道詞典好像也是用dmp格式的轉儲檔案

 

說回正題o(∩_∩)o 

如果你要分析的是一台陌生的伺服器，可以用很多種方法找到errorlog路徑。

一種比較簡單的方法是在SQLSERVER 組態管理員裡選擇SQL服務，在其屬性-》進階裡找到一個“啟動參數”的進階屬性

在屬性字串裡，會有一個“-e”的參數。他的後面就是跟errorlog檔案的位置

 

或者乾脆在上面說的轉儲目錄就可以看到了

errorlog檔案以文本方式記錄，用任何檔案編輯器，包括記事本，SSMS都能開啟

一般來講，errorlog檔案的大小不會很大。用這些工具完全能夠滿足需求

但是，errorlog本身非常重要，他記錄了SQL的整個開啟、運行、終止過程。

如果SQLSERVER遇到了比較嚴重的問題，在errorlog裡都會有所顯示

ErrorLog顯示包括以下內容：

（1）SQL的版本，以及Windows和Processor基本資料

（2）SQL的啟動參數，以及認證模式，記憶體配置模式

（3）每個資料庫是否能夠被正常開啟。如果不能，原因是什麼

（4）資料庫損壞相關的錯誤

（5）Database Backup與恢複動作記錄

（6）DBCC CHECKDB記錄

（7）記憶體相關的錯誤和警告

（8）SQL調度出現異常時的警告。一般SERVER HANG 伺服器死機會伴隨著有這些警告

（9）SQL I/O操作遇到長時間延遲的警告

（10）SQL在運行過程中遇到的其他層級比較高的錯誤

（11）SQL內部的訪問越界錯誤（Access Violation）

（12）SQL服務關閉時間

在檢查SQLSERVER相關問題的時候，總是從errorlog著手，先確認errorlog裡是乾淨的。

如果errorlog裡有一些錯誤或警告，就要確認這些錯誤和警告發生的時間，是不是前端感覺到問題的時間。

如果時間能對得上，那就要著重分析一下

如果開啟一些設定，在errorlog裡還能看到的有用資訊有：

（1）所有使用者成功或失敗的登入

（2）死結以及其參與者的資訊：需要開啟追蹤旗標1222 或1204

複製代碼 代碼如下:

DBCC TRACEON(1222)
DBCC TRACEON(1204)

有時候errorlog也不是萬能的哦？他不能反映的問題有：

（1）阻塞問題。只要阻塞還沒有嚴重影響SQLSERVER的線程調度，errorlog裡是不會有體現

（2）普通效能問題，逾時問題。如果效能問題不是由於記憶體使用量異常、線程調度異常，或者是I/O子系統反應非常緩慢，

而是由於表格或語句設計導致，errorlog裡也不會有所反映

（3）Windows層面異常。如果Windows層面出現工作不正常，或者伺服器不響應，SQLSERVER很難自我判斷的

上面這三個問題，errorlog裡一般不會有所體現。這也是我們為什麽要第一步就要檢查Event Log的原因

下面給出一個errorlog的內容出來講解