如何重置數據庫Suppect(置疑)狀態(tài)
一、 出現這種情況的原因
如果在日常運行當中，數據庫的文件或日志增長(cháng)方式設為以下兩種模式：
1、 文件不自動(dòng)增長(cháng)
此種狀態(tài)下，如果數據庫中的數據或日志增長(cháng)到設定的文件大小時(shí)，繼續添加數據時(shí)就沒(méi)有足夠的空間時(shí)，MS SQL SERVER將把數據庫標記為Suspect（置疑）
2、 文件自動(dòng)增長(cháng)但限制最大文件大小
此種狀態(tài)下，如果數據庫中的數據或日志增長(cháng)到設定的最大文件大小時(shí)，繼續添加數據時(shí)就沒(méi)有足夠的空間時(shí)，MS SQL SERVER將把數據庫標記為Suspect（置疑）
3、 文件自動(dòng)增長(cháng)也沒(méi)限制文件大小，但存放文件的磁盤(pán)剩余空間不夠了
4、 意外掉電，造成磁盤(pán)文件損壞
5、
二、解決方法：
3、
方法一：
釋放含有相關(guān)數據庫日志文件的任意磁盤(pán)驅動(dòng)器上的磁盤(pán)空間。釋放的磁盤(pán)空間使恢復系統可以自動(dòng)地增長(cháng)數據或事務(wù)日志文件。
執行 sp_resetstatus 重置置疑狀態(tài)。
通過(guò)執行 DBCC DBRECOVER（數據庫）運行恢復操作。
方法二：
釋放另一個(gè)磁盤(pán)驅動(dòng)器上的磁盤(pán)空間。
把可用磁盤(pán)空間不足的事務(wù)日志文件移動(dòng)到第一步所指的磁盤(pán)驅動(dòng)器上。
執行 sp_detach_db 分離數據庫。
執行 sp_attach_db 附加數據庫，指向被移動(dòng)的文件。
方法三：
向置疑數據庫添加一個(gè)日志文件，然后執行 sp_add_log_file_recover_suspect_db 以便在數據庫上運行恢復操作。
解決錯誤信息 1105，然后使數據庫聯(lián)機
對于任意一個(gè)含有錯誤信息 1105 提到的文件組中文件的磁盤(pán)，釋放其磁盤(pán)空間。釋放磁盤(pán)空間使得文件組中的文件可以增長(cháng)。
執行 sp_resetstatus 重置置疑狀態(tài)。
執行 DBCC DBRECOVER（數據庫）運行恢復操作。
方法四：
釋放另一個(gè)磁盤(pán)驅動(dòng)器上的磁盤(pán)空間。
將可用磁盤(pán)空間不足的文件組中的數據文件移動(dòng)到第一步所指的磁盤(pán)驅動(dòng)器上。
執行 sp_detach_db 分離數據庫。
執行 sp_attach_db 附加數據庫，指向被移動(dòng)的文件。
方法五：
向置疑數據庫添加一個(gè)數據文件，然后執行 sp_add_data_file_recover_suspect_db 以便在數據庫上運行恢復操作。
執行 sp_resetstatus。
用 ALTER DATABASE 向數據庫添加一個(gè)數據文件或日志文件。
停止并重新啟動(dòng) SQL Server。
用新的數據文件或日志文件所提供的額外空間，SQL Server 應該能完成數據庫的恢復。
釋放磁盤(pán)空間并且重新運行恢復操作。
sp_resetstatus 關(guān)閉數據庫的置疑標志，但是原封不動(dòng)地保持數據庫的其它選項。
注意 只有在您的主要支持提供者指導下或有疑難解答建議的做法時(shí)，才可以使用 sp_resetstatus。
否則，可能會(huì )損壞數據庫。
由于該過(guò)程修改了系統表，系統管理員必須在創(chuàng )建這個(gè)過(guò)程前，啟用系統表更新。要啟用更新，使用下面的過(guò)程：
USE master
GO
sp_configure 'allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO
過(guò)程創(chuàng )建后，立即禁用系統表更新：
sp_configure 'allow updates', 0
GO
RECONFIGURE WITH OVERRIDE
GO
只有系統管理員才能執行 sp_resetstatus。執行該過(guò)程后，立即關(guān)閉 SQL Server。
語(yǔ)法為：
sp_resetstatus database_name
下面的例子將關(guān)閉 PRODUCTION 數據庫的置疑標志。
sp_resetstatus PRODUCTION
下面是結果集：
Database 'PRODUCTION' status reset!
WARNING: You must reboot SQL Server prior to accessing this database!
注釋
sp_resetstatus 關(guān)閉數據庫上的置疑標記。此過(guò)程更新 sysdatabases 中的命名數據庫的模式和狀態(tài)列。
在運行此過(guò)程之前，應參考 SQL Server 錯誤日志并解決所有問(wèn)題。執行 sp_resetstatus 后停止并重新啟動(dòng) SQL Server。
由于某些原因，數據庫可能成為置疑狀態(tài)?？赡艿脑虬ú僮飨到y拒絕對數據庫資源的訪(fǎng)問(wèn)，以及一個(gè)或多個(gè)數據庫文件不可用性或已損壞。
權限
只有 sysadmin 固定服務(wù)器角色成員才能執行 sp_resetstatus。
示例
下例重置 PUBS 數據庫的狀態(tài)。
EXEC sp_resetstatus 'PUBS'
數據文件空間不足：
sp_add_data_file_recover_suspect_db
當由于文件組上的"空間不足"(1105) 錯誤而導致一個(gè)數據庫上的恢復不能完成時(shí)，請為文件組添加一個(gè)數據文件。添加日志文件后，該存儲過(guò)程關(guān)閉置疑設置并完成數據庫的故障恢復。該參數和 ALTER DATABASE ADD FILE 的參數相同。
示例
在下面的示例中，由于文件組 fg1 中空間不足（錯誤 1105），數據庫 db1 被標記為置疑。
sp_add_data_file_recover_suspect_db db1, fg1, file2,
'c:\Program Files\Microsoft SQL Server\MSSQL\Data\db1_file2.mdf', '1MB'
日志空間不足：
sp_add_log_file_recover_suspect_db
由于數據庫上"日志空間不足"(9002) 錯誤造成恢復不能完成時(shí)，請將日志文件添加到文件組中。添加日志文件后，該存儲過(guò)程關(guān)閉置疑設置并完成數據庫的故障恢復。參數與 ALTER DATABASE ADD LOG FILE 中的參數相同。
權限
執行權限默認賦予 sysadmin 固定服務(wù)器角色的成員。這些權限是不可傳遞的。
示例
在此示例中，數據庫 db1 在故障恢復期間由于日志空間不足（錯誤 9002）而標記為置疑。
sp_add_log_file_recover_suspect_db db1, logfile2,
'c:\Program Files\Microsoft SQL Server\MSSQL\Data\db1_logfile2.ldf',
'1MB'
嚴重級別 22：SQL Server 嚴重錯誤表的完整性置疑
這些消息表明消息中所指定的表或索引已因軟件或硬件問(wèn)題而損壞。
嚴重級別 22 錯誤很少發(fā)生；但是，如果遇到該錯誤，請運行 DBCC CHECKDB 確定數據庫中是否有其它對象也受損壞。問(wèn)題有可能只存在于超速緩存中，而不是存在于磁盤(pán)本身。如果是這樣，重新啟動(dòng) SQL Server 將修正該問(wèn)題。要繼續工作，必須重新連接到 SQL Server。否則，用 DBCC 修復該問(wèn)題。有些情況下，有必要還原數據庫。
如果重新啟動(dòng)幫助不大，則問(wèn)題存在于磁盤(pán)上。有時(shí)，摧毀在錯誤信息中指定的對象可以解決該問(wèn)題。例如，如果消息說(shuō) SQL Server 在非聚集索引中發(fā)現長(cháng)度為 0 的行，刪除該索引然后重建。
嚴重級別 23：SQL Server 嚴重錯誤：數據庫完整性置疑
這些消息表明由于硬件或軟件問(wèn)題，整個(gè)數據庫完整性存在問(wèn)題。
嚴重級別 23 錯誤很少發(fā)生；但是，如果遇到，請運行 DBCC CHECKDB 確定損壞的程度。問(wèn)題有可能只存在于超速緩存中，而不是存在于磁盤(pán)本身。如果是這樣，重新啟動(dòng) SQL Server 將修正該問(wèn)題。要繼續工作，必須重新連接到 SQL Server。否則，用 DBCC 修復該問(wèn)題。有些情況下，有必要重新啟動(dòng)數據庫。
DBCC CHECKDB 建議
在 Microsoft? SQL Server? 2000 中，可以在用戶(hù)使用數據庫時(shí)運行 DBCC CHECKDB，因為 DBCC CHECKDB 在檢查每個(gè)數據庫表時(shí)在表上控制的鎖的類(lèi)型均更改。
在 SQL Server 7.0 和早期版本中，DBCC CHECKDB（依次在數據庫的每個(gè)表上運行 DBCC CHECKTABLE 和 CHECKALLOC）常常在表上控制共享鎖 (S)，因而阻塞了所有的數據修改語(yǔ)言 (DML) 語(yǔ)句。
在 SQL Server 2000 中，當檢查表時(shí) DBCC CHECKDB 在表上控制架構鎖以防止元數據的更改，因而允許在正在檢查的表上使用除任何數據定義語(yǔ)言 (DDL) 語(yǔ)句之外的 DML 語(yǔ)句。該變化對于決定何時(shí)運行 DBCC CHECKDB 提供了更大的靈活性，因為 DBCC CHECKDB 并不完全拒絕用戶(hù)對系統的使用。
DBCC CHECKDB 是大量占用 CPU 和磁盤(pán)的操作。每一個(gè)需要檢查的數據頁(yè)都必須首先從磁盤(pán)讀入內存。另外，DBCC CHECKDB 使用 tempdb 排序。
如果在 DBCC CHECKDB 運行時(shí)動(dòng)態(tài)執行事務(wù)，那么事務(wù)日志會(huì )繼續增長(cháng)，因為 DBCC 命令在完成日志的讀取之前阻塞日志截斷。
建議在服務(wù)器負荷較少的時(shí)候運行 DBCC CHECKDB。如果在負荷高峰期運行 DBCC CHECKDB，那么事務(wù)吞吐量性能和 DBCC CHECKDB 完成時(shí)間性能都會(huì )受到影響。
要獲得好的 DBCC 性能的一些建議
在系統使用率較低時(shí)運行 CHECKDB。
請確保未同時(shí)執行其它磁盤(pán) I/O 操作，例如磁盤(pán)備份。
將 tempdb 放到單獨的磁盤(pán)系統或快速磁盤(pán)子系統中。
允許 tempdb 在驅動(dòng)器上有足夠的擴展空間。使用帶有 ESTIMATE ONLY 的 DBCC 估計 tempdb 將需要多少空間。
避免運行占用大量 CPU 的查詢(xún)或批處理作業(yè)。
在 DBCC 命令運行時(shí)，減少活動(dòng)事務(wù)。
使用 NO_INFOMSGS 選項顯著(zhù)減少處理和 tempdb 的使用。
考慮使用帶有 PHYSICAL_ONLY 選項的 DBCC CHECKDB 來(lái)檢查頁(yè)和記錄首部的物理結構。當硬件導致的錯誤被置疑時(shí)，這個(gè)操作將執行快速檢查。
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
