|
|
問: 我最近升級了一個應用程序，使其可以在 SQL Server 2005 上運行。我利用了允許行長度超出 8,060 個字節(jié)這項功能，以便用戶可以創(chuàng)建較長的數(shù)據(jù)字段而不會收到從 SQL Server 返回的錯誤?，F(xiàn)在，將這個應用程序應用到實際環(huán)境之后，一些掃描查詢開始出現(xiàn)性能問題，在架構(gòu)更改之前，這些查詢運行正常。我也檢查過各種索引的碎片，一切正常。那為什么查詢在 SQL Server 2005 上運行時速度比較慢呢？
答: 您所利用的“行溢出”功能，對于在特定情況下允許行長度大于 8,060 個字節(jié)效果很好，但卻不適合大多數(shù)長度過大的行，而且可能使查詢性能大打折扣，正如您所遇到的情況那樣。
發(fā)生這種情況的原因是，當某行的長度開始變得過大時，該行中的其中一個可變長度列會被“推出行”。這意味著該列會在數(shù)據(jù)或索引頁上從行中移到文本頁中。至于原來列中的值，會由指針取代，指向該列中的值在數(shù)據(jù)文件中的新位置。
這與用來存儲 XML、文本、圖像或 varchar(max) 等常規(guī) LOB（大型對象）列的機制完全相同。請注意，如果表架構(gòu)包含多個可變長度列，就無法保證在多個行的長度變得過大時推出的會是同一列。
這種機制可能會產(chǎn)生性能問題。如果查詢從一個表格行中檢索的可變長度列已被推出該行，可能突然之間需要額外的 I/O 來讀取內(nèi)含行外位置的值的文本頁。如果有多個行的長度過大，從多個行中檢索相同的可變長度列的查詢，可能產(chǎn)生無法預料的性能問題，嚴重程度取決于被推出行的值的數(shù)量。
在您遇到的情況中，對包含可變長度列的選擇列表執(zhí)行范圍掃描或表掃描的查詢，正是因行溢出及其影響而導致性能下降。這與索引是否執(zhí)行過完全的碎片整理無關(guān)，當可變長度列被推出行時，因為必須使用隨機 I/O 讀取內(nèi)含行外的值的文本頁，所以之前有效的掃描作業(yè)已基本中斷。
雖然行溢出在特定的情況下對于長度過大的行仍然很有用，但如果查詢的性能至關(guān)重要，則不應該在您的設計里面過度利用。
問: 我們剛在兩個故障轉(zhuǎn)移群集之間引入了數(shù)據(jù)庫鏡像，作為以低于存儲區(qū)域網(wǎng)絡 (SAN) 復制的成本獲得地理冗余的方法。因為數(shù)據(jù)中心位于同一個城市，所以我們能夠使用同步鏡像。問題在于當本地群集上發(fā)生故障轉(zhuǎn)移時，鏡像數(shù)據(jù)庫會故障轉(zhuǎn)移到遠程群集，而這并不是我們希望發(fā)生的情況。我們該如何避免出現(xiàn)這種情況？我們只希望在本地群集無法使用的時才進行故障轉(zhuǎn)移。
答: 為了提高可用性，鏡像會安裝一個見證服務器，以便在主體服務器無法使用時自動發(fā)生故障轉(zhuǎn)移。其理論基礎(chǔ)是：如果整個本地群集出現(xiàn)故障，數(shù)據(jù)庫鏡像將故障轉(zhuǎn)移到第二個群集，這樣應用程序就可以繼續(xù)執(zhí)行了。
此問題出現(xiàn)在群集故障轉(zhuǎn)移期間。故障轉(zhuǎn)移所花的時間超過了數(shù)據(jù)庫鏡像的默認超時設置，而見證服務器和鏡像服務器（即第二個群集上活動的 SQL Server 實例）均認為它們看不到主體服務器，于是鏡像服務器便開始將鏡像故障轉(zhuǎn)移到第二個群集。
預防這種現(xiàn)象最簡單的方法是刪除見證服務器，以便數(shù)據(jù)庫鏡像在本地群集出現(xiàn)故障時不會自動進行故障轉(zhuǎn)移。當然，這種做法會降低可用性，因為這樣一來就需要人為啟動故障轉(zhuǎn)移。
第二種方法是更改數(shù)據(jù)庫鏡像的默認超時設置，也就是更改確定主體服務器不可用之前，它響應“ping”信息（每秒一次）失敗的次數(shù)。這種設置稱為“伙伴超時”(Parnter Timeout)，默認值為 10。可使用下列代碼找到數(shù)據(jù)庫當前的超時值：
1. SELECT mirroring_connection_timeout
2. FROM master.sys.database_mirroring
3. WHERE database_id = DB_ID ('mydbname');
4. GO
it知識庫：SQL問題與解答：行溢出、差異備份及更多內(nèi)容，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
