問: 我最近升級(jí)了一個(gè)應(yīng)用程序，使其可以在 SQL Server 2005 上運(yùn)行。我利用了允許行長(zhǎng)度超出 8,060 個(gè)字節(jié)這項(xiàng)功能，以便用戶可以創(chuàng)建較長(zhǎng)的數(shù)據(jù)字段而不會(huì)收到從 SQL Server 返回的錯(cuò)誤。現(xiàn)在，將這個(gè)應(yīng)用程序應(yīng)用到實(shí)際環(huán)境之后，一些掃描查詢開始出現(xiàn)性能問題，在架構(gòu)更改之前，這些查詢運(yùn)行正常。我也檢查過(guò)各種索引的碎片，一切正常。那為什么查詢?cè)?SQL Server 2005 上運(yùn)行時(shí)速度比較慢呢？

　　答: 您所利用的“行溢出”功能，對(duì)于在特定情況下允許行長(zhǎng)度大于 8,060 個(gè)字節(jié)效果很好，但卻不適合大多數(shù)長(zhǎng)度過(guò)大的行，而且可能使查詢性能大打折扣，正如您所遇到的情況那樣。

　　發(fā)生這種情況的原因是，當(dāng)某行的長(zhǎng)度開始變得過(guò)大時(shí)，該行中的其中一個(gè)可變長(zhǎng)度列會(huì)被“推出行”。這意味著該列會(huì)在數(shù)據(jù)或索引頁(yè)上從行中移到文本頁(yè)中。至于原來(lái)列中的值，會(huì)由指針取代，指向該列中的值在數(shù)據(jù)文件中的新位置。

　　這與用來(lái)存儲(chǔ) XML、文本、圖像或 varchar(max) 等常規(guī) LOB（大型對(duì)象）列的機(jī)制完全相同。請(qǐng)注意，如果表架構(gòu)包含多個(gè)可變長(zhǎng)度列，就無(wú)法保證在多個(gè)行的長(zhǎng)度變得過(guò)大時(shí)推出的會(huì)是同一列。

　　這種機(jī)制可能會(huì)產(chǎn)生性能問題。如果查詢從一個(gè)表格行中檢索的可變長(zhǎng)度列已被推出該行，可能突然之間需要額外的 I/O 來(lái)讀取內(nèi)含行外位置的值的文本頁(yè)。如果有多個(gè)行的長(zhǎng)度過(guò)大，從多個(gè)行中檢索相同的可變長(zhǎng)度列的查詢，可能產(chǎn)生無(wú)法預(yù)料的性能問題，嚴(yán)重程度取決于被推出行的值的數(shù)量。

　　在您遇到的情況中，對(duì)包含可變長(zhǎng)度列的選擇列表執(zhí)行范圍掃描或表掃描的查詢，正是因行溢出及其影響而導(dǎo)致性能下降。這與索引是否執(zhí)行過(guò)完全的碎片整理無(wú)關(guān)，當(dāng)可變長(zhǎng)度列被推出行時(shí)，因?yàn)楸仨毷褂秒S機(jī) I/O 讀取內(nèi)含行外的值的文本頁(yè)，所以之前有效的掃描作業(yè)已基本中斷。

　　雖然行溢出在特定的情況下對(duì)于長(zhǎng)度過(guò)大的行仍然很有用，但如果查詢的性能至關(guān)重要，則不應(yīng)該在您的設(shè)計(jì)里面過(guò)度利用。

　　問: 我們剛在兩個(gè)故障轉(zhuǎn)移群集之間引入了數(shù)據(jù)庫(kù)鏡像，作為以低于存儲(chǔ)區(qū)域網(wǎng)絡(luò) (SAN) 復(fù)制的成本獲得地理冗余的方法。因?yàn)閿?shù)據(jù)中心位于同一個(gè)城市，所以我們能夠使用同步鏡像。問題在于當(dāng)本地群集上發(fā)生故障轉(zhuǎn)移時(shí)，鏡像數(shù)據(jù)庫(kù)會(huì)故障轉(zhuǎn)移到遠(yuǎn)程群集，而這并不是我們希望發(fā)生的情況。我們?cè)撊绾伪苊獬霈F(xiàn)這種情況？我們只希望在本地群集無(wú)法使用的時(shí)才進(jìn)行故障轉(zhuǎn)移。

　　答: 為了提高可用性，鏡像會(huì)安裝一個(gè)見證服務(wù)器，以便在主體服務(wù)器無(wú)法使用時(shí)自動(dòng)發(fā)生故障轉(zhuǎn)移。其理論基礎(chǔ)是：如果整個(gè)本地群集出現(xiàn)故障，數(shù)據(jù)庫(kù)鏡像將故障轉(zhuǎn)移到第二個(gè)群集，這樣應(yīng)用程序就可以繼續(xù)執(zhí)行了。

　　此問題出現(xiàn)在群集故障轉(zhuǎn)移期間。故障轉(zhuǎn)移所花的時(shí)間超過(guò)了數(shù)據(jù)庫(kù)鏡像的默認(rèn)超時(shí)設(shè)置，而見證服務(wù)器和鏡像服務(wù)器（即第二個(gè)群集上活動(dòng)的 SQL Server 實(shí)例）均認(rèn)為它們看不到主體服務(wù)器，于是鏡像服務(wù)器便開始將鏡像故障轉(zhuǎn)移到第二個(gè)群集。

　　預(yù)防這種現(xiàn)象最簡(jiǎn)單的方法是刪除見證服務(wù)器，以便數(shù)據(jù)庫(kù)鏡像在本地群集出現(xiàn)故障時(shí)不會(huì)自動(dòng)進(jìn)行故障轉(zhuǎn)移。當(dāng)然，這種做法會(huì)降低可用性，因?yàn)檫@樣一來(lái)就需要人為啟動(dòng)故障轉(zhuǎn)移。

　　第二種方法是更改數(shù)據(jù)庫(kù)鏡像的默認(rèn)超時(shí)設(shè)置，也就是更改確定主體服務(wù)器不可用之前，它響應(yīng)“ping”信息（每秒一次）失敗的次數(shù)。這種設(shè)置稱為“伙伴超時(shí)”(Parnter Timeout)，默認(rèn)值為 10。可使用下列代碼找到數(shù)據(jù)庫(kù)當(dāng)前的超時(shí)值：

   1. SELECT mirroring_connection_timeout  
   2.   FROM master.sys.database_mirroring   
   3.   WHERE database_id = DB_ID ('mydbname');  
   4. GO         

        

        
        
      
        
it知識(shí)庫(kù)：SQL問題與解答：行溢出、差異備份及更多內(nèi)容，轉(zhuǎn)載需保留來(lái)源！
        
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。