診斷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）數據庫備份與恢復動作記錄
（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的內容出來講解
