处理数据库置疑的方法

处理数据库置疑的方法

先分离数据库

企业管理器--右键置疑的数据库--所有任务--分离数据库

然后备份你的置疑数据库的文件,再按下面的步骤处理:

1.新建一个同名的数据库

2.再停掉sql server

3.用置疑数据库的文件覆盖掉这个新建的同名数据库，只覆盖mdf文件，日志文件不要覆盖

4.再重启sql server

5.此时打开企业管理器时新建的同名数据库会出现置疑，先不管，打开查询分析器执行下面的语句（注意修改其中的数据库名)

重建日志文件，经过修复后数据就可以正常分离并附加了，语句中“C:\置疑的同名数据库名_Log.ldf”是重建日志日志文件存放路径，

在重建日志后，最好将数据库分离并将重新创建的日志文件拷贝到数据库文件所在目录，再重新进行附加。

--重建日志文件，修复损坏的日志

USE MASTER

GO

SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE

GO

UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的同名数据库名'

Go

dbcc rebuild_log('置疑的同名数据库名','C:\置疑的同名数据库名_Log.ldf')

GO

update sysdatabases set status =28 where name='置疑的同名数据库名'

Go

sp_configure 'allow updates', 0 reconfigure with override

Go

6、数据库修复后还需要进行数据库检测，看是否存在一些错误，数据库检测需要用DBCC CHECKDB命令，如下：

DBCC CHECKDB('置疑的同名数据库名')

如果检测到错误，需要进行修复，但修复数据库需要在单用户模式下，请使用以下语句,

ALTER DATABASE 置疑的同名数据库名 SET SINGLE_USER WITH ROLLBACK IMMEDIATE

GO

DBCC CHECKDB ('置疑的同名数据库名',REPAIR_REBUILD)

GO

ALTER DATABASE 置疑的同名数据库名 SET MULTI_USER WITH ROLLBACK IMMEDIATE

GO

如果还有错误，执行下面的语句

DBCC CHECKDB ('数据库名',REPAIR_ALLOW_DATA_LOSS )

-------(执行一次如果还有错误，可以多执行几次)

7、有时通过DBCC CHECKDB能够修复数据库中的错误，但有时不能修复，可能需要对单个有问题的数据表进行修复，需要使用

DBCC CHECKTABLE('有问题的数据表名',REPAIR_REBUILD) 命令，详细请看联机帮助

8、DBCC CHECKDB命令介绍

检查指定数据库中的所有对象的分配和结构完整性。

语法

DBCC CHECKDB

( 'database_name'

[ , NOINDEX

| { REPAIR_ALLOW_DATA_LOSS

| REPAIR_FAST

| REPAIR_REBUILD

} ]

) [ WITH { [ ALL_ERRORMSGS ]

[ , [ NO_INFOMSGS ] ]

[ , [ TABLOCK ] ]

[ , [ ESTIMATEONLY ] ]

[ , [ PHYSICAL_ONLY ] ]

}

]

参数

'database_name'

是要对其中的所有对象分配和结构完整性进行检查的数据库。如果未指定，则默认为当前数据库。数据库名称必须符合标识符的规则。有关更多信息，请参见使用标识符。

NOINDEX

指定不检查非系统表的非聚集索引。NOINDEX 减少执行总时间，因为它不对用户定义的表的非聚集索引进行检查。NOINDEX 对系统表没有影响，因为 DBCC CHECKDB 总是对所有系统表索引进行检查。

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

指定 DBCC CHECKDB 修复发现的错误。给定的 database_name 必须在单用户模式下以使用修复选项，它可以是下列值之一。

值 描述

REPAIR_ALLOW_DATA_LOSS 执行由 REPAIR_REBUILD 完成的所有修复，包括对行和页进行分配和取消分配以改正分配错误、结构行或页的错误，以及删除已损坏的文本对象。这些修复可能会导致一些数据丢失。修复操作可以在用户事务下完成以允许用户回滚所做的更改。如果回滚修复，则数据库仍会含有错误，应该从备份进行恢复。如果由于所提供修复等级的缘故遗漏某个错误的修复，则将遗漏任何取决于该修复的修复。修复完成后，备份数据库。 REPAIR_FAST 进行小的、不耗时的修复操作，如修复非聚集索引中的附加键。这些修复可以很快完成，并且不会有丢失数据的危险。

REPAIR_REBUILD 执行由 REPAIR_FAST 完成的所有修复，包括需要较长时间的修复（如重建索引）。执行这些修复时不会有丢失数据的危险。

WITH

指定有关下列内容的选项：返回错误信息的数量、获得的锁或估计的 tempdb 要求。

ALL_ERRORMSGS

显示每个对象不受限制的错误数。如果没有指定 ALL_ERRORMSGS，每个对象至多显示 200 个错误信息。按对象 ID 对错误信息进行排序（从 tempdb 中生成的消息除外）。

NO_INFOMSGS

禁止显示所有信息性消息（严重级别 10）和关于所用空间的报告。

TABLOCK

导致 DBCC CHECKDB 获得共享表锁。TABLOCK 可使 DBCC CHECKDB 在负荷较重的数据库上

运行得更快，但 DBCC CHECKDB 运行时会减少数据库上可获得的并发性。

ESTIMATE ONLY

显示估计的 tempdb 空间大小，要运行带有所有其它指定选项的 DBCC CHECKDB 则需要该空间。不执行该检查。

PHYSICAL_ONLY

仅限于检查页和记录标题物理结构的完整性，以及页对象 ID 和索引 ID 与分配结构之间的一致性。该检查旨在以较低的开销检查数据库的物理一致性，同时还检测会危及用户数据安全的残缺页和常见的硬件故障。PHYSICAL_ONLY 始终意味着 NO_INFOMSGS，并且不能与任何修复选项一起使用。

注释

DBCC CHECKDB 对索引视图执行物理一致性检查。只用于向后兼容的 NOINDEX 选项也适用于索引视图上的任何辅助索引。

DBCC CHECKDB 是最安全的修复语句，因为它对最多的可能出现的各种错误进行标识和修复。如果只报告数据库中有分配错误，请执行带修复选项的 DBCC CHECKALLOC 以对这些错误进行修复。然而，若要确保正确修复所有错误（包括分配错误），请执行带修复选项的 DBCC CHECKDB，而不要执行带修复选项的 DBCC CHECKALLOC。

DBCC CHECKDB 对数据库中所有内容的完整性进行验证。如果当前正在执行或最近已执行 DBCC CHECKDB，则不需要运行 DBCC CHECKALLOC 或 DBCC CHECKTABLE。

DBCC CHECKDB 执行同样的检查，仿佛是对数据库中的每个表执行 DBCC CHECKALLOC 语句和 DBCC CHECKTABLE 语句。

默认情况下，DBCC CHECKDB 不获取表锁。但它获取架构锁，该锁防止对元数据进行更改，但允许更改数据。获取的架构锁将防止用户得到排它表锁，在生成聚集索引、除去任何索引或截断表时需要排它表锁。

DBCC 语句收集信息，然后扫描日志以查找所做的任何其它更改，并在扫描的结尾将两组信息合并在一起以产生数据的一致视图。

如果指定 TABLOCK 选项，DBCC CHECKDB 将获取共享表锁。这样可允许某些类别的错误有更详细的错误信息，并通过避免使用事务日志数据而将所要求的 tempdb 空间大 …… 此处隐藏：3345字，全部文档内容请下载后查看。喜欢就下载吧 ……