這篇文章主要介紹SQLSERVER數(shù)據(jù)庫狀態(tài)的示例分析，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

創(chuàng)新互聯(lián)于2013年創(chuàng)立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目做網(wǎng)站、成都網(wǎng)站制作網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢想脫穎而出為使命，1280元平南做網(wǎng)站,已為上家服務(wù),為平南各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:18982081108

案例

前兩天在處理一個(gè)客戶問題，突然某個(gè)數(shù)據(jù)庫無法訪問了。數(shù)據(jù)庫下面的表也無法查看。從SSMS界面上看數(shù)據(jù)庫是正常的狀態(tài)（就是數(shù)據(jù)庫名字后面沒有顯示特別的狀態(tài)）。查看

SYS.DATABASES 查看狀態(tài)列，發(fā)現(xiàn)是ONLINE。此時(shí)其他數(shù)據(jù)庫是正常的，就這個(gè)庫有問題。肯定是數(shù)據(jù)庫狀態(tài)不對(duì)。 那么問題出在哪里呢？ 仔細(xì)觀察發(fā)現(xiàn)這個(gè)問題的數(shù)據(jù)庫 collation_name 是null 值。

原來問題在這，

剛剛聯(lián)機(jī)的數(shù)據(jù)庫不一定馬上能接受連接。 要確定數(shù)據(jù)庫何時(shí)可以接受連接，可以查詢 sys.databases 的 collation_name 列或 DATABASEPROPERTYEX 的 Collation 屬性。 在數(shù)據(jù)庫排序規(guī)則返回非 Null 值之后，數(shù)據(jù)庫就可以接受連接了。

于是用命令把數(shù)據(jù)庫設(shè)置為脫機(jī)，然后馬上聯(lián)機(jī)，再查看sys.databases 的 collation_name 列 變成了非null值。此時(shí)數(shù)據(jù)庫恢復(fù)正常。

狀態(tài)的轉(zhuǎn)換

數(shù)據(jù)庫有很多狀態(tài)。他們是如何在這些狀態(tài)之間進(jìn)行切換的呢？下面這個(gè)圖非常清晰的標(biāo)示了各個(gè)狀態(tài)的切換。在我剛學(xué)習(xí)數(shù)據(jù)庫的時(shí)候，這個(gè)圖給了我很大的幫助，

讓我對(duì)數(shù)據(jù)庫各個(gè)狀態(tài)的轉(zhuǎn)換有了很清楚的認(rèn)識(shí)。

ONLINE （在線）

數(shù)據(jù)庫可正常運(yùn)行

RESTORING （正在還原）

數(shù)據(jù)庫正在還原，當(dāng)我們還原數(shù)據(jù)庫使用NORECOVERY 模式時(shí)，數(shù)據(jù)庫就會(huì)變成該狀態(tài)

RECOVERING （正在恢復(fù)）

數(shù)據(jù)庫啟動(dòng)，數(shù)據(jù)庫創(chuàng)建，ALTER ONLINE,RESTORE WITH RECOERY 時(shí)，會(huì)經(jīng)過這個(gè)狀態(tài)，進(jìn)行REDO,UNDO等操作。此時(shí)如果遇到問題就進(jìn)入RECOVERY_PENDING。如果正常就會(huì)變成ONLINE。

RECOVERY_PENDING（等待恢復(fù)）

數(shù)據(jù)庫在還原時(shí)遇到跟資源相關(guān)的錯(cuò)誤，表明還原進(jìn)程被掛起，數(shù)據(jù)庫不能開始數(shù)據(jù)庫的數(shù)據(jù)和日志的還原進(jìn)程，這種情況下，最可能的原因是丟失數(shù)據(jù)文件或日志文件。

SUSPECT  （置疑）

數(shù)據(jù)庫可能損壞了

EMERGENCY （緊急）

供DBA用來修復(fù)數(shù)據(jù)庫的狀態(tài)

OFFLINE （脫機(jī)）

離線狀態(tài)

以上是“SQLSERVER數(shù)據(jù)庫狀態(tài)的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！