?

SELECT ? CAST ( record? AS ? XML ) ? FROM ? sys . dm_os_ring_buffers
WHERE ?ring_buffer_type ? = ? 'RING_BUFFER_CONNECTIVITY'

?

上述指令會(huì)選擇所有記錄為 XML 類型 ; 在 Management Studio 中 , 你可以單擊記錄 , 從而獲得更具可讀性的版本。如果你想使用 SQL 查詢 XML 記錄從而找到相應(yīng)的問題 , 你可以使用 SQL server 的 XML? 支持 , 將之變?yōu)橐粋€(gè)臨時(shí)的表 , 從而查詢記錄。

?

一個(gè)基本的Buffer entry：Killed SPID

一個(gè)導(dǎo)致服務(wù)器發(fā)起的連接關(guān)閉的簡單方法是打開兩個(gè) SQL 服務(wù)器的連接，找到一個(gè)連接的 SPID ，然后從另一個(gè)連接中將該 SPID 殺死。

C:\>osql -E
1> SELECT @@spid
2> go
------
51
(1 row affected)

C:\>osql -E
1> kill 51
2> go
1>

如果你做了上述工作，然后查詢 Ring Buffer ，你會(huì)得到和如下類似的結(jié)果：

< Record ? id = " 2 " ? type = " RING_BUFFER_CONNECTIVITY " ? time = " 110448275 " >

< ConnectivityTraceRecord >

< RecordType > ConnectionClose </ RecordType >

< RecordSource > Tds </ RecordSource >

< Spid > 55 </ Spid >

< SniConnectionId > B7882F3C-3BA9-45A7-8D23-3C5C05F9BDF9 </ SniConnectionId >

< SniProvider > 4 </ SniProvider >

< RemoteHost > &lt; local ?machine &gt ; </ RemoteHost >

< RemotePort > 0 </ RemotePort >

< LocalHost ?/>

< LocalPort > 0 </ LocalPort >

< RecordTime > 5/6/2008 22:47:35.880 </ RecordTime >

< TdsBuffersInformation >

< TdsInputBufferError > 0 </ TdsInputBufferError >

< TdsOutputBufferError > 0 </ TdsOutputBufferError >

< TdsInputBufferBytes > 60 </ TdsInputBufferBytes >

</ TdsBuffersInformation >

< TdsDisconnectFlags >

< PhysicalConnectionIsKilled > 0 </ PhysicalConnectionIsKilled >

< DisconnectDueToReadError > 0 </ DisconnectDueToReadError >

< NetworkErrorFoundInInputStream > 0 </ NetworkErrorFoundInInputStream >

< ErrorFoundBeforeLogin > 0 </ ErrorFoundBeforeLogin >

< SessionIsKilled > 1 </ SessionIsKilled >

< NormalDisconnect > 0 </ NormalDisconnect >

< NormalLogout > 0 </ NormalLogout >

</ TdsDisconnectFlags >

</ ConnectivityTraceRecord >

< Stack >

< frame ? id = " 0 " > 0X01CA0B00 </ frame >

< frame ? id = " 1 " > 0X01CA0DB1 </ frame >

< frame ? id = " 2 " > 0X01DF6162 </ frame >

< frame ? id = " 3 " > 0X02E53C98 </ frame >

< frame ? id = " 4 " > 0X02E54845 </ frame >

< frame ? id = " 5 " > 0X02E57BE9 </ frame >

< frame ? id = " 6 " > 0X02E38F57 </ frame >

< frame ? id = " 7 " > 0X02E3B2C0 </ frame >

< frame ? id = " 8 " > 0X02E3C832 </ frame >

< frame ? id = " 9 " > 0X02E3D55E </ frame >

< frame ? id = " 10 " > 0X781329BB </ frame >

< frame ? id = " 11 " > 0X78132A47 </ frame >

</ Stack >

</ Record >

不同的記錄類型包括不同的信息。 Connectivity Ring Buffer? 記錄的三種記錄類型分別是： ConnectionClose ， Error ，和 LoginTimers 。上面的結(jié)果是一個(gè) ConnectionClose ，因?yàn)檫@不是一個(gè)登陸時(shí)超時(shí)，或者其它的登陸失敗的場景：

< RecordType > ConnectionClose </ RecordType >

我們可以看出， SPID??55 的連接關(guān)閉了：

<![endif]>

< Spid > 55 </ Spid >

我們可以看到連接是本地的（ <local machine> 表明其是一個(gè)本地的， shared memory 類型的連接）。

<![endif]>

< RemoteHost > &lt; local ?machine &gt ; </ RemoteHost >

?

當(dāng)使用 TCP 協(xié)議進(jìn)行連接時(shí)，可以獲得更多的相關(guān)信息 - 例如，本地 IP 地址，端口，以及遠(yuǎn)程 IP 地址和端口，從而允許你唯一的確定客戶機(jī)及其應(yīng)用。另外， Ring Buffer 包括了一個(gè)時(shí)間戳以及與之相對(duì)應(yīng)的 SPID （如果有的話），這樣才能形成一個(gè)完整的對(duì)應(yīng)關(guān)系。（因?yàn)殡S著時(shí)間的推移 SPID 會(huì)被不同的連接所重用）。

我們同樣可以看到客戶發(fā)的 TDS 包中有多少 bytes ，并且可以知道是否在 TDS 中有任何的錯(cuò)誤：

< TdsInputBufferError > 0 </ TdsInputBufferError >
< TdsOutputBufferError > 0 </ TdsOutputBufferError >
< TdsInputBufferBytes > 60 </ TdsInputBufferBytes >

?

最相關(guān)的，最易于分析的信息記錄在 TdsDisconnectFlags 中，有一系列的值，記錄了關(guān)閉連接的狀態(tài)。這里，我們看到?jīng)]有發(fā)現(xiàn)錯(cuò)誤，但是這里記錄了這也不是一個(gè)正常的斷開或者一個(gè)正常的登出。從如下的 flag 中，這個(gè) session 是被殺死的：

< SessionIsKilled > 1 </ SessionIsKilled >

一個(gè)更有意思的例子：DC ?連接性問題

跟蹤被殺死的 SPID 看起來很 cool 。但是 Connectivity Ring Buffer 更重要的最用 是幫助我們可以在不使用 network monitor 的情況下來解決棘手的問題。以下是一個(gè) Connectivity Ring Buffer 中 Login Time 記錄的例子，如果沒有代價(jià)高昂的問題重現(xiàn)過程并且分析網(wǎng)絡(luò)抓獲的包，這個(gè)問題很難查明：

< Record ? id = " 3 " ? type = " RING_BUFFER_CONNECTIVITY " ? time = " 112254962 " >

< ConnectivityTraceRecord >

< RecordType > LoginTimers </ RecordType >

< Spid > 0 </ Spid >

< SniConnectionId > B401B045-3C82-4AAC-A459-DB0520925431 </ SniConnectionId >

< SniConsumerError > 17830 </ SniConsumerError >

< SniProvider > 4 </ SniProvider >

< State > 102 </ State >

< RemoteHost > &lt; local ?machine &gt ; </ RemoteHost >

< RemotePort > 0 </ RemotePort >

< LocalHost ?/>

< LocalPort > 0 </ LocalPort >

< RecordTime > 5/6/2008 23:17:42.556 </ RecordTime >

< TdsBuffersInformation >

< TdsInputBufferError > 0 </ TdsInputBufferError >

< TdsOutputBufferError > 232 </ TdsOutputBufferError >

< TdsInputBufferBytes > 198 </ TdsInputBufferBytes >

</ TdsBuffersInformation >

< LoginTimers >

< TotalLoginTimeInMilliseconds > 21837 </ TotalLoginTimeInMilliseconds >

< LoginTaskEnqueuedInMilliseconds > 0 </ LoginTaskEnqueuedInMilliseconds >

< NetworkWritesInMilliseconds > 2 </ NetworkWritesInMilliseconds >

< NetworkReadsInMilliseconds > 77 </ NetworkReadsInMilliseconds >

< SslProcessingInMilliseconds > 3 </ SslProcessingInMilliseconds >

< SspiProcessingInMilliseconds > 21756 </ SspiProcessingInMilliseconds >

< LoginTriggerAndResourceGovernorProcessingInMilliseconds > 0 </ LoginTriggerAndResourceGovernorProcessingInMilliseconds >

</ LoginTimers >

</ ConnectivityTraceRecord >

< Stack >

< frame ? id = " 0 " > 0X01CA0B00 </ frame >

…

< frame ? id = " 15 " > 0X02E3C832 </ frame >

</ Stack >

</ Record >

在這個(gè)情況下，在客戶端，我們可以看到：
[SQL Server Native Client 10.0]Shared Memory Provider: Timeout error [258].
[SQL Server Native Client 10.0]Login timeout?expired
[SQL Server Native Client 10.0]Unable to complete login process due to delay in login response

獲得操作系統(tǒng)的錯(cuò)誤消息，不能說明任何問題：

C:\>net?helpmsg ?258
The?wait operation timed out.

在服務(wù)器的 errorlogs 里面，什么都沒有。然而 Ring Buffer 中的記錄非常有意思。 LoginTimers 中記錄了整體處理時(shí)間（ overall processing time ）：

< TotalLoginTimeInMilliseconds > 21837 </ TotalLoginTimeInMilliseconds >

在整個(gè)登陸過程中，根據(jù)不同階段所做的工作的不同， TotalLoginTimeInMilliseconds 被分解為一個(gè)個(gè)子項(xiàng)（由于取整的操作，這些數(shù)字最終加起來不會(huì)等于總體的時(shí)間。在上面所舉的例子中他們相差 1 ）。在這種情況下， SspiProcessingInMilliseconds ? 看起來很有趣，它用了近 22 秒：

<![endif]>

< SspiProcessingInMilliseconds > 21756 </ SspiProcessingInMilliseconds >

SSPI （ Security Support Provider Interface ），是一個(gè) SQL Server 使用 Windows Authentication 的接口。當(dāng) Windows login 是一個(gè) domain account ， SQL Server 使用 SSPI 和 Domain Controller 交互，從而驗(yàn)證用戶身份。記錄中可以看到， SSPI 過程占用了大量的時(shí)間，這表明和 Domain Controller 交互時(shí)有延時(shí)，很有可能是 SQL 服務(wù)器和 DC 之間的物理連接有問題，或者 DC 上的一些軟件問題。可以看到，我們沒有進(jìn)行網(wǎng)絡(luò)抓包，也沒有重現(xiàn)問題，我們就已經(jīng)把問題縮小到 SQL Server 和 Domain Controller 之間的交互上面來了。（ Connectivity Ring Buffer 默認(rèn)是打開的）

Trace Flags

Connectivity Ring Buffer? 默認(rèn)是打開的，它默認(rèn)跟蹤所有的由服務(wù)器發(fā)起的連接關(guān)閉。如果你在客戶端看到一個(gè)錯(cuò)誤，但是在 Ring Buffer 中沒有記錄，這就表明服務(wù)器看到的是一種“重置”類型的連接關(guān)閉，這種連接關(guān)閉類似于客戶端正常關(guān)閉連接的行為，或者是由于服務(wù)器外部因素所造成的連接關(guān)閉；（例如，一個(gè)網(wǎng)絡(luò)硬件的故障）。如果是這種情況，你就需要關(guān)注潛在的網(wǎng)絡(luò)互聯(lián)問題。如果你在 Ring Buffer 中看到了一個(gè)條目它可以指出為什么服務(wù)器要關(guān)閉這個(gè)鏈接，那么這個(gè)條目就很可能可以極大的幫助我們進(jìn)行故障排查。例如，如果你看到一個(gè)連接關(guān)閉是由于 TDS 包中的信息不合法，那么你就可以去檢查那些可能會(huì)損壞網(wǎng)絡(luò)包的設(shè)備，包括網(wǎng)卡，路由和集線器等。下面你會(huì)看到，通過使用一個(gè) trace flag ，你可以讓 Connectivity Ring Buffer 記錄所有連接關(guān)閉事件。這樣你就能觀察到客戶端發(fā)起的連接關(guān)閉的情形和潛在的錯(cuò)誤。

有兩個(gè) trace flag ，可以用于改變 Connectivity Ring Buffer? 的行為。

完全關(guān)閉 Connectivity Ring Buffer ，可以開啟 trace flag 7826 ：

DBCC ?TRACEON ? ( 7826 , ? - 1 )

默認(rèn)情況下客戶端發(fā)起的連接關(guān)閉是不被記錄的（因?yàn)檫@是正常的情況，而不是一個(gè)錯(cuò)誤）；當(dāng)一個(gè)客戶結(jié)束的它的 session ，它就斷開。一般來說，我們建議不要去跟蹤客戶端發(fā)起的連接關(guān)閉，因?yàn)檎嬲杏玫? Buffer 記錄會(huì)被覆蓋（當(dāng)你有很多正常表現(xiàn)的連接時(shí)，這種情況發(fā)生可能性會(huì)很大），或者會(huì)被隱藏在一個(gè)堆正常情況的記錄中。這會(huì)使你錯(cuò)過真正的錯(cuò)誤問題。如果你真的想要觀察客戶端的連接關(guān)閉，你可以使用 trace flag 7827 來開啟這個(gè)功能：

DBCC ?TRACEON ? ( 7827 , ? - 1 )

<Frame>tags 是什么？

通過 sys.dm_os_ring_buffers ?DMV? 可以訪問一系列內(nèi)部信息，它包含了但不僅限于 Connectivity Ring Buffer 。作為 DMV 基礎(chǔ)的一部分，大多數(shù)的 Ring Buffers? 提供了事件發(fā)生時(shí)的棧蹤跡（ stack trace ），每一個(gè) <frame> 提供了一個(gè)十六進(jìn)制的函數(shù)地址。這些都可以分解為函數(shù)名，并 dump Sqlservr.exe 進(jìn)程，在 WinDbg 打開 dump ，并采用基于函數(shù)的地址的 LM 命令。