SQL Server誤區30日談 第10天 數據庫鏡像在毛病產生後 立時就可以發明。本站提示廣大學習愛好者：（SQL Server誤區30日談 第10天 數據庫鏡像在毛病產生後 立時就可以發明）文章只能為提供參考，不一定能成為您想要的結果。以下是SQL Server誤區30日談 第10天 數據庫鏡像在毛病產生後 立時就可以發明正文
誤區10.數據庫鏡像在毛病產生後，立時就可以發明
毛病
市情上年夜肆宣揚數據庫鏡像技巧可以在毛病產生後，立刻檢測到毛病並停止毛病轉移。
但現實其實不是如許，檢測到毛病產生的速度要取決於毛病的類型。
檢測毛病產生的最快的情形是，鏡像中的主體實例瓦解，從而鏡像辦事器每秒一次的PING就沒法前往值，從而曉得主體辦事器上不再有這個過程偵聽響應的TCP端口，這類情形下，鏡像辦事器簡直剎時就可以發明毛病。
檢測到毛病產生第二快的情形是主體辦事器的操作體系瓦解。此時主體辦事器不再呼應鏡像辦事器的PING，從而在鏡像辦事器PING超時後發明毛病。這個超時的阈值默許是10秒。但你也能夠延伸這個時光，這時候，毛病產生時光完整取決於PING的超不時間。
檢測到毛病第三快的情形是是主體的日記磁盤弗成用，此時SQL SERVER依然會提議IO要求，但20秒IO期待沒法寫入日記後發明日記磁盤弗成用，終究40秒後宣布磁盤日記弗成用，從而讓鏡像辦事器上線。SQL SERVER是非常有耐煩的,好比拿鎖來講，SQL SERVER關於鎖會無窮期待，除非碰到逝世鎖才停止干涉。
還有，破壞頁有能夠完整不會激發毛病，假如查詢報了823或是824毛病，鏡像技巧完整不會存眷(SQL SERVER 2008以後這個成績獲得修復: SQL Server 2008: Automatic Page Repair with Database Mirroring),假如數據回滾的進程中碰到823毛病或是824毛病，數據庫連忙會變成質疑狀況，也就是日記和數據不同一。這也會招致鏡像掉敗。
你在聖經上進修到的那些教條也不是須要完整遵守的嘛:-)
