SQL Server誤區(qū)30日談第10天數(shù)據(jù)庫鏡像在故障發(fā)生后馬上就能發(fā)現(xiàn)

看見就非常 2015-05-25

展開全文

誤區(qū)10.數(shù)據(jù)庫鏡像在故障發(fā)生后，馬上就能發(fā)現(xiàn)

錯(cuò)誤

市面上大肆宣傳數(shù)據(jù)庫鏡像技術(shù)可以在故障發(fā)生后，立即檢測(cè)到錯(cuò)誤并進(jìn)行故障轉(zhuǎn)移。

但事實(shí)并不是這樣，檢測(cè)到故障發(fā)生的速度要取決于故障的類型。

檢測(cè)故障發(fā)生的最快的情況是，鏡像中的主體實(shí)例崩潰，從而鏡像服務(wù)器每秒一次的PING就無法返回值，從而知道主體服務(wù)器上不再有這個(gè)進(jìn)程偵聽相應(yīng)的TCP端口，這種情況下，鏡像服務(wù)器幾乎瞬間就能發(fā)現(xiàn)故障。

檢測(cè)到故障發(fā)生第二快的情況是主體服務(wù)器的操作系統(tǒng)崩潰。此時(shí)主體服務(wù)器不再響應(yīng)鏡像服務(wù)器的PING，從而在鏡像服務(wù)器PING超時(shí)后發(fā)現(xiàn)錯(cuò)誤。這個(gè)超時(shí)的閾值默認(rèn)是10秒。但你也可以延長這個(gè)時(shí)間，這時(shí)，故障發(fā)生時(shí)間完全取決于PING的超時(shí)時(shí)間。

檢測(cè)到故障第三快的情況是是主體的日志磁盤不可用，此時(shí)SQL SERVER仍然會(huì)發(fā)起IO請(qǐng)求，但20秒IO等待無法寫入日志后發(fā)現(xiàn)日志磁盤不可用，最終40秒后宣告磁盤日志不可用，從而讓鏡像服務(wù)器上線。SQL SERVER是十分有耐心的,比如拿鎖來說，SQL SERVER對(duì)于鎖會(huì)無限等待，除非遇到死鎖才進(jìn)行干預(yù)。

還有，損壞頁有可能完全不會(huì)引發(fā)故障，如果查詢報(bào)了823或是824錯(cuò)誤，鏡像技術(shù)完全不會(huì)關(guān)注(SQL SERVER 2008之后這個(gè)問題得到修復(fù): SQL Server 2008: Automatic Page Repair with Database Mirroring),如果數(shù)據(jù)回滾的過程中遇到823錯(cuò)誤或是824錯(cuò)誤，數(shù)據(jù)庫立刻會(huì)變?yōu)橘|(zhì)疑狀態(tài)，也就是日志和數(shù)據(jù)不統(tǒng)一。這也會(huì)導(dǎo)致鏡像失敗。

你在圣經(jīng)上學(xué)習(xí)到的那些教條也不是需要完全遵循的嘛:-)

您可能感興趣的文章:

SQL Server誤區(qū)30日談第29天有關(guān)堆碎片的誤區(qū)
SQL Server誤區(qū)30日談第28天有關(guān)大容量事務(wù)日志恢復(fù)模式的誤區(qū)
SQL Server誤區(qū)30日談第27天使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB
SQL Server誤區(qū)30日談第26天 SQL Server中存在真正的“事務(wù)嵌套”
SQL Server誤區(qū)30日談第25天有關(guān)填充因子的誤區(qū)
SQL Server誤區(qū)30日談第24天 26個(gè)有關(guān)還原(Restore)的誤區(qū)
SQL Server誤區(qū)30日談第23天有關(guān)鎖升級(jí)的誤區(qū)
SQL Server誤區(qū)30日談第22天資源調(diào)控器可以調(diào)控IO
SQL Server誤區(qū)30日談第21天數(shù)據(jù)損壞可以通過重啟SQL Server來修復(fù)
SQL Server誤區(qū)30日談第20天破壞日志備份鏈之后，需要一個(gè)完整備份來重新開始日志鏈
SQL Server誤區(qū)30日談第19天 Truncate表的操作不會(huì)被記錄到日志
SQL Server誤區(qū)30日談第18天有關(guān)FileStream的存儲(chǔ)，垃圾回收以及其它
SQL Server誤區(qū)30日談第17天有關(guān)頁校驗(yàn)和的誤區(qū)
SQL Server誤區(qū)30日談第16天數(shù)據(jù)的損壞和修復(fù)
SQL Server誤區(qū)30日談第15天 CheckPoint只會(huì)將已提交的事務(wù)寫入磁盤
SQL Server誤區(qū)30日談第14天清除日志后會(huì)將相關(guān)的LSN填零初始化
SQL Server誤區(qū)30日談第13天在SQL Server 2000兼容模式下不能使用DMV
SQL Server誤區(qū)30日談第12天 TempDB的文件數(shù)和需要和CPU數(shù)目保持一致
SQL Server誤區(qū)30日談第11天鏡像在檢測(cè)到故障后瞬間就能故障轉(zhuǎn)移
SQL Server誤區(qū)30日談第9天數(shù)據(jù)庫文件收縮不會(huì)影響性能
SQL Server誤區(qū)30日談第8天有關(guān)對(duì)索引進(jìn)行在線操作的誤區(qū)
SQL Server誤區(qū)30日談第7天一個(gè)實(shí)例多個(gè)鏡像和日志傳送延遲
SQL Server誤區(qū)30日談第6天有關(guān)NULL位圖的三個(gè)誤區(qū)
SQL Server誤區(qū)30日談第5天 AWE在64位SQL SERVER中必須開啟
SQL Server誤區(qū)30日談第4天 DDL觸發(fā)器就是INSTEAD OF觸發(fā)器
SQL Server誤區(qū)30日談第3天即時(shí)文件初始化特性可以在SQL Server中開啟和關(guān)閉
SQL Server誤區(qū)30日談第2天 DBCC CHECKDB會(huì)導(dǎo)致阻塞
SQL Server誤區(qū)30日談第1天正在運(yùn)行的事務(wù)在服務(wù)器故障轉(zhuǎn)移后繼續(xù)執(zhí)行
SQL Server誤區(qū)30日談第30天有關(guān)備份的30個(gè)誤區(qū)

本站是提供個(gè)人知識(shí)管理的網(wǎng)絡(luò)存儲(chǔ)空間，所有內(nèi)容均由用戶發(fā)布，不代表本站觀點(diǎn)。請(qǐng)注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購買等信息，謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)點(diǎn)擊一鍵舉報(bào)。

轉(zhuǎn)藏 分享

QQ空間 QQ好友新浪微博微信

獻(xiàn)花（0） +1

來自：看見就非常 > 《server》

舉報(bào)/認(rèn)領(lǐng)