操做系統已經向SQL Server 返回了錯誤21

轉】，操做系統已經向SQL Server 返回了錯誤21(設備未就緒
在文件'G:\LedDB\LedDB.mdf' 中、偏移量爲0x00000001a9a000 的位置執行 讀取 期間，操做系統已經向SQL Server 返回了錯誤21(設備未就緒。)。SQL Server 錯誤日誌和系統事件日誌中的其餘消息可能提供了更詳細信息。這是一個威脅數據庫完整性的嚴重系統級錯誤條件，必須當即糾正。請執行完整的數據庫一致性檢查(DBCC CHECKDB)。此錯誤能夠由許多因素致使；有關詳細信息，請參閱SQL Server 聯機叢書。

說明: 執行當前Web 請求期間，出現未處理的異常。請檢查堆棧跟蹤信息，以瞭解有關該錯誤以及代碼中致使錯誤的出處的詳細信息。

異常詳細信息: System.Data.SqlClient.SqlException: 在 文件'G:\LedDB\LedDB.mdf' 中、偏移量爲0x00000001a9a000 的位置執行 讀取 期間，操做系統已經向SQL Server 返回了錯誤21(設備未就緒。)。SQL Server 錯誤日誌和系統事件日誌中的其餘消息可能提供了更詳細信息。這是一個威脅數據庫完整性的嚴重系統級錯誤條件，必須當即糾正。請執行完整的數 據庫一致性檢查(DBCC CHECKDB)。此錯誤能夠由許多因素致使；有關詳細信息，請參閱SQL Server 聯機叢書。

解決方法

重啓SqlServer服務,確保沒有其餘連接鏈接到當前錯誤數據庫

執行

usemaster

declare@databasename varchar(255)

set@databasename='leddb'

execsp_dboption @databasename, N'single', N'true'--將目標數據庫置爲單用戶狀態

dbcccheckdb(@databasename,REPAIR_ALLOW_DATA_LOSS)

dbcccheckdb(@databasename,REPAIR_REBUILD)

execsp_dboption @databasename, N'single', N'false'--將目標數據庫置爲多用戶狀態

便可

相關資料:

MS Sql Server 提供了不少數據庫修復的命令，當數據庫質疑或是有的沒法完成讀取時能夠嘗試這些修復命令。

　　1. DBCC CHECKDB
重啓服務器後，在沒有進行任何操做的狀況下，在SQL查詢分析器中執行如下SQL進行數據庫的修復，修復數據庫存在的一致性錯誤與分配錯誤。

use master
declare @databasename varchar(255)
set @databasename='須要修復的數據庫實體的名稱'
exec sp_dboption @databasename, N'single', N'true' --將目標數據庫置爲單用戶狀態
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb(@databasename,REPAIR_REBUILD)
exec sp_dboption @databasename, N'single', N'false'--將目標數據庫置爲多用戶狀態

而後執行 DBCC CHECKDB('須要修復的數據庫實體的名稱') 檢查數據庫是否仍舊存在錯誤。注意：修復後可能會形成部分數據的丟失。

2. DBCC CHECKTABLE
   若是DBCC CHECKDB 檢查仍舊存在錯誤，可使用DBCC CHECKTABLE來修復。
   use 須要修復的數據庫實體的名稱
   declare @dbname varchar(255)
   set @dbname='須要修復的數據庫實體的名稱'
   exec sp_dboption @dbname,'single user','true'
   dbcc checktable('須要修復的數據表的名稱',REPAIR_ALLOW_DATA_LOSS)
   dbcc checktable('須要修復的數據表的名稱',REPAIR_REBUILD)
   ------把’ 須要修復的數據表的名稱’更改成執行DBCC CHECKDB時報錯的數據表的名稱
   exec sp_dboption @dbname,'single user','false'

3. 其餘的一些經常使用的修復命令
   DBCC DBREINDEX 重建指定數據庫中表的一個或多個索引
   用法：DBCC DBREINDEX (表名,’’) 修復此表全部的索引。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

SQL SERVER數據庫的檢測及修復方法

隨 着K/3產品的推廣，要求客戶服務人員對SQL SERVER數據庫的瞭解也進一步提升。在K/3的使用過程當中，數據庫文件被頻繁地使用，因爲某些緣由，數據庫有可能被損壞，本文將針對這種狀況的數據庫 檢測及修復方法作一簡單講解。但願各位在實際工做過程當中有新的發現時，及時給咱們提供信息，以便作進一步的更新。

1.1 SQL SERVER數據庫的檢測

SQL SERVER提供了數據庫檢測的命令，可用DBCC CHECKDB對數據庫中各個對象的分配及結構的正確性進行檢測，並可經過一參數控制，將全部的錯誤信息顯示出來。其語法以下：

DBCC CHECKDB

('database_name' [,NOINDEX | { REPAIR_ALLOW_DATA_LOSS

| REPAIR_FAST

| REPAIR_REBUILD

}]

) [WITH {ALL_ERRORMSGS | NO_INFOMSGS}]

參數說明：

'database_name'表明被檢測的數據庫實體名；

NOINDEX指非系統表的非聚族索引不檢測；

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST| REPAIR_REBUILD 指直接修復發現的錯誤，其中REPAIR_ALLOW_DATA_LOSS表明，若此錯誤不能修復時，系統將直接刪除相關數據。帶此三個參數的任一個時， 數據庫必須處於單用戶模式，可在Enterprise Manager中的數據庫屬性中設置；

ALL_ERRORMSGS表明將檢測到的錯誤信息所有顯示出來，不然，對於每張表最多隻顯示200條錯誤信息；

NO_INFOMSGS表明隱藏全部的信息及佔用空間的報告。

通過檢測，對於錯誤的對象，將以OBJECT ID的形式報告具體出錯的信息，可根據OBJECT ID到系統表sysobjects中查找到相關的表，即NAME。

1.2 SQL SERVER問題數據庫的修復

通過數據庫檢測後，可針對出現的問題採起相應的措施進行處理。如經過檢測後，發現對象的物理存放存在問題，可用DBCC CHECKALLOC來進行修復：

DBCC CHECKALLOC ('database_name' | REPAIR_REBUILD }] ) [WITH {ALL_ERRORMSGS | NO_INFOMSGS}]

如果非系統對象的索引出錯，則可用DBCC DBREINDEX進行修復：

DBCC DBREINDEX ( [ 'database.owner.table_name' [, index_name [, fillfactor ] ] ] ) [WITH NO_INFOMSGS]

以上兩種狀況，也可直接使用DBCC CHECKDB(‘db_name’,repair_rebuild)來修復。

另一種狀況是在進行檢測時，提示沒法創建數據鏈接，此時代表，數據庫已損壞。對於這種狀況，咱們可採起以下措施來嘗試修復。

首 先，在SQL Enterprise中新建一數據庫（如數據庫名爲test）,建好數據庫後，中止SQL Server Service Manager，並將客戶數據庫的MDF文件改名爲test _data.mdf(即新建數據庫的主文件名)，而後用改名後的文件覆蓋新建數據庫同名文件，接着，啓動SQL Server Service Manager。對Master數據庫將系統表設置爲可更改狀態

Use Master

Go

sp_configure 'allow updates', 1

reconfigure with override

Go

將數據庫設爲緊急狀態：

update sysdatabases set status = 32768 where database '

中止並從新啓動SQL Server Service Manager，並重建Log文件：

DBCC TRACEON (3604)

DBCC REBUILD_LOG(' test ','test _log_ldf')

將數據庫設置爲單用戶模式，而後進行檢測：

sp_dboption ' test ', 'single user', 'true'

DBCC CHECKDB(' test ')

Go

此數據庫執行CHECKDB的過程當中發現一些表的索引被破壞，因而針對具體的表進行重建索引的操做：

DBCC DBREINDEX（表名）

如執行以上操做仍然不能解決，若索引破壞的表是臨時表或不是關鍵表，則可重新建帳套中引入，如果主表，則可能經過近期的備份來（部份）恢復。若沒有一個備份，則沒法修復。

1.3 SQL Server數據庫爲何易損壞呢？

如下是微軟提供的一些可能引發數據庫損壞的緣由及一些預防措施：

操做問題，包括冷起動機器、熱拔硬盤、刪除一些數據庫文件；

硬件問題，包括磁盤控制器的問題；

操做系統問題，包括與系統相關的一些致命錯誤。

1.4 預防措施：

一、按期/不按期執行CHKDSK(不帶參數)，以檢測硬盤物理結構並修復一些CHKDSK報告的問題；

二、常備份數據。

1.5 應用數據庫修復舉例

declare @databasename varchar(255)

set @databasename='AIS20021224170730'------必定要手工輸入

---------執行通常性修復還存在問題時,進行容許數據丟失的修復

---------許數據丟失的修復要求在單用戶下進行,此時請退出中間層,客戶端,sql的其餘模塊

---全部功能退出,在查詢分析器master裏設置數據庫爲單用戶

exec sp_dboption @databasename, N'single', N'true'

-----在查詢分析器master裏,進行修復數據庫

dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)

dbcc checkdb(@databasename,REPAIR_REBUILD)

------還原數據庫狀態

exec sp_dboption @databasename, N'single', N'false'

第2章數據庫日誌損壞的修復

請遵守以下步驟來試圖重建數據庫事務日誌.

注意: 因爲事務日誌丟失, 數據庫可能有沒有提交的數據.

注:都要替換成真實的數據庫名字

2.1 步驟1:

建立一個新的數據庫,命名爲原來數據庫的名字.

2.2步驟2:

中止SQL Server

2.3步驟3:

把老數據庫的MDF文件替換新數據庫的相應的MDF文件, 並把LDF文件刪除

2.4步驟4:

從新啓動SQL Server 服務,而後運行以下命令:

Use Master

Go

sp_configure 'allow updates', 1

reconfigure with override

Go

begin tran

update sysdatabases set status = 32768 where db_name'

-- Verify one row is updated before committing

commit tran

2.5步驟5:

中止SQL而後從新啓動SQL Server 服務,而後運行以下命令:

DBCC TRACEON (3604)

DBCC REBUILD_LOG('db_name','c:\mssql7\data\dbxxx_3.LDF')

Go

2.6步驟6:

中止SQL而後從新啓動SQL Server 服務,而後運行:

use master

update sysdatabases set status = 8 where

Go

sp_configure 'allow updates', 0

reconfigure with override

Go

2.7步驟7:

運行dbcc checkdb(db_name)檢查數據庫的完整性.

第3章 數據庫質疑的通常處理

一、執行以下SQL（打開修改系統表的開關）：

EXEC sp_configure 'allow updates', 1

RECONFIGURE WITH OVERRIDE

二、修改數據庫Master中的表：sysdatabases

將 status字段數值更改成4

三、再執行以下SQL：

EXEC sp_configure 'allow updates', 0

RECONFIGURE WITH OVERRIDE。