MS-SQLSERVER數據庫SUSPECT狀態如何解決


如何重置數據庫Suppect(置疑)狀態
一、? ? ? ? 出現這種情況的原因
如果在日常運行當中，數據庫的文件或日志增長方式設為以下兩種模式：
1、? ? ? ? 文件不自動增長
此種狀態下，如果數據庫中的數據或日志增長到設定的文件大小時，繼續添加數據時就沒有足夠的空間時，MS SQL SERVER將把數據庫標記為Suspect（置疑）
2、? ? ? ? 文件自動增長但限制最大文件大小

此種狀態下，如果數據庫中的數據或日志增長到設定的最大文件大小時，繼續添加數據時就沒有足夠的空間時，MS SQL SERVER將把數據庫標記為Suspect（置疑）
3、? ? ? ? 文件自動增長也沒限制文件大小，但存放文件的磁盤剩余空間不夠了

4、? ? ? ? 意外掉電，造成磁盤文件損壞
5、? ? ? ?

二、解決方法：
3、
方法一：
釋放含有相關數據庫日志文件的任意磁盤驅動器上的磁盤空間。釋放的磁盤空間使恢復系統可以自動地增長數據或事務日志文件。
執行 sp_resetstatus 重置置疑狀態。
通過執行 DBCC DBRECOVER（數據庫）運行恢復操作。


方法二：
釋放另一個磁盤驅動器上的磁盤空間。
把可用磁盤空間不足的事務日志文件移動到第一步所指的磁盤驅動器上。
執行 sp_detach_db 分離數據庫。
執行 sp_attach_db 附加數據庫，指向被移動的文件。

方法三：
向置疑數據庫添加一個日志文件，然后執行 sp_add_log_file_recover_suspect_db 以便在數據庫上運行恢復操作。
解決錯誤信息 1105，然后使數據庫聯機
對于任意一個含有錯誤信息 1105 提到的文件組中文件的磁盤，釋放其磁盤空間。釋放磁盤空間使得文件組中的文件可以增長。
執行 sp_resetstatus 重置置疑狀態。
執行 DBCC DBRECOVER（數據庫）運行恢復操作。

方法四：
釋放另一個磁盤驅動器上的磁盤空間。
將可用磁盤空間不足的文件組中的數據文件移動到第一步所指的磁盤驅動器上。
執行 sp_detach_db 分離數據庫。
執行 sp_attach_db 附加數據庫，指向被移動的文件。

方法五：
向置疑數據庫添加一個數據文件，然后執行 sp_add_data_file_recover_suspect_db 以便在數據庫上運行恢復操作。

執行 sp_resetstatus。

用 ALTER DATABASE 向數據庫添加一個數據文件或日志文件。

停止并重新啟動 SQL Server。
用新的數據文件或日志文件所提供的額外空間，SQL Server 應該能完成數據庫的恢復。

釋放磁盤空間并且重新運行恢復操作。

sp_resetstatus 關閉數據庫的置疑標志，但是原封不動地保持數據庫的其它選項。
注意??只有在您的主要支持提供者指導下或有疑難解答建議的做法時，才可以使用 sp_resetstatus。
否則，可能會損壞數據庫。
由于該過程修改了系統表，系統管理員必須在創建這個過程前，啟用系統表更新。要啟用更新，使用下面的過程：
USE master
GO
sp_configure 'allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO

過程創建后，立即禁用系統表更新：
sp_configure 'allow updates', 0
GO
RECONFIGURE WITH OVERRIDE
GO

只有系統管理員才能執行 sp_resetstatus。執行該過程后，立即關閉 SQL Server。
語法為：
sp_resetstatus database_name

下面的例子將關閉 PRODUCTION 數據庫的置疑標志。
sp_resetstatus PRODUCTION

下面是結果集：
Database 'PRODUCTION' status reset!
WARNING: You must reboot SQL Server prior to accessing this database!
注釋
sp_resetstatus 關閉數據庫上的置疑標記。此過程更新 sysdatabases 中的命名數據庫的模式和狀態列。
在運行此過程之前，應參考 SQL Server 錯誤日志并解決所有問題。執行 sp_resetstatus 后停止并重新啟動 SQL Server。

由于某些原因，數據庫可能成為置疑狀態。可能的原因包括操作系統拒絕對數據庫資源的訪問，以及一個或多個數據庫文件不可用性或已損壞。

權限
只有 sysadmin 固定服務器角色成員才能執行 sp_resetstatus。

示例
下例重置 PUBS 數據庫的狀態。

EXEC sp_resetstatus 'PUBS'

數據文件空間不足：
sp_add_data_file_recover_suspect_db
當由于文件組上的"空間不足"(1105) 錯誤而導致一個數據庫上的恢復不能完成時，請為文件組添加一個數據文件。添加日志文件后，該存儲過程關閉置疑設置并完成數據庫的故障恢復。該參數和 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) 錯誤造成恢復不能完成時，請將日志文件添加到文件組中。添加日志文件后，該存儲過程關閉置疑設置并完成數據庫的故障恢復。參數與 ALTER DATABASE ADD LOG FILE 中的參數相同。
權限
執行權限默認賦予 sysadmin 固定服務器角色的成員。這些權限是不可傳遞的。

示例
在此示例中，數據庫 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 嚴重錯誤表的完整性置疑

這些消息表明消息中所指定的表或索引已因軟件或硬件問題而損壞。

嚴重級別 22 錯誤很少發生；但是，如果遇到該錯誤，請運行 DBCC CHECKDB 確定數據庫中是否有其它對象也受損壞。問題有可能只存在于超速緩存中，而不是存在于磁盤本身。如果是這樣，重新啟動 SQL Server 將修正該問題。要繼續工作，必須重新連接到 SQL Server。否則，用 DBCC 修復該問題。有些情況下，有必要還原數據庫。

如果重新啟動幫助不大，則問題存在于磁盤上。有時，摧毀在錯誤信息中指定的對象可以解決該問題。例如，如果消息說 SQL Server 在非聚集索引中發現長度為 0 的行，刪除該索引然后重建。

嚴重級別 23：SQL Server 嚴重錯誤：數據庫完整性置疑

這些消息表明由于硬件或軟件問題，整個數據庫完整性存在問題。

嚴重級別 23 錯誤很少發生；但是，如果遇到，請運行 DBCC CHECKDB 確定損壞的程度。問題有可能只存在于超速緩存中，而不是存在于磁盤本身。如果是這樣，重新啟動 SQL Server 將修正該問題。要繼續工作，必須重新連接到 SQL Server。否則，用 DBCC 修復該問題。有些情況下，有必要重新啟動數據庫。


DBCC CHECKDB 建議
在 Microsoft? SQL Server? 2000 中，可以在用戶使用數據庫時運行 DBCC CHECKDB，因為 DBCC CHECKDB 在檢查每個數據庫表時在表上控制的鎖的類型均更改。

在 SQL Server 7.0 和早期版本中，DBCC CHECKDB（依次在數據庫的每個表上運行 DBCC CHECKTABLE 和 CHECKALLOC）常常在表上控制共享鎖 (S)，因而阻塞了所有的數據修改語言 (DML) 語句。

在 SQL Server 2000 中，當檢查表時 DBCC CHECKDB 在表上控制架構鎖以防止元數據的更改，因而允許在正在檢查的表上使用除任何數據定義語言 (DDL) 語句之外的 DML 語句。該變化對于決定何時運行 DBCC CHECKDB 提供了更大的靈活性，因為 DBCC CHECKDB 并不完全拒絕用戶對系統的使用。

DBCC CHECKDB 是大量占用 CPU 和磁盤的操作。每一個需要檢查的數據頁都必須首先從磁盤讀入內存。另外，DBCC CHECKDB 使用 tempdb 排序。

如果在 DBCC CHECKDB 運行時動態執行事務，那么事務日志會繼續增長，因為 DBCC 命令在完成日志的讀取之前阻塞日志截斷。

建議在服務器負荷較少的時候運行 DBCC CHECKDB。如果在負荷高峰期運行 DBCC CHECKDB，那么事務吞吐量性能和 DBCC CHECKDB 完成時間性能都會受到影響。

要獲得好的 DBCC 性能的一些建議
在系統使用率較低時運行 CHECKDB。
請確保未同時執行其它磁盤 I/O 操作，例如磁盤備份。
將 tempdb 放到單獨的磁盤系統或快速磁盤子系統中。
允許 tempdb 在驅動器上有足夠的擴展空間。使用帶有 ESTIMATE ONLY 的 DBCC 估計 tempdb 將需要多少空間。
避免運行占用大量 CPU 的查詢或批處理作業。
在 DBCC 命令運行時，減少活動事務。
使用 NO_INFOMSGS 選項顯著減少處理和 tempdb 的使用。
考慮使用帶有 PHYSICAL_ONLY 選項的 DBCC CHECKDB 來檢查頁和記錄首部的物理結構。當硬件導致的錯誤被置疑時，這個操作將執行快速檢查。

總結

以上是生活随笔為你收集整理的MS-SQLSERVER数据库SUSPECT状态如何解决的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。