操做系统已经向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。