数据库“置疑”该怎么处理

解决由于sql2000日志文件引起的“置疑”。

日志有错误--------重新附加提示日志有错误。

日志文件丢失-----丢失了ldf文件，只有mdf文件的数据库重建。

步骤：

一、备份“置疑”数据库的数据文件，因为日志文件ldf出错，可以只备份mdf文件。

二、打开企业管理器（SQL Server Enterprise Manager），删除“置疑”数据库，如果提示删除错误，可以重启数据库服务器，然后再试。

三、在企业管理器中，新建同名数据库（假如数据库为test），注意建立的数据库名称，还有数据文件名要保持和原数据库一致。

四、停止数据库服务器。

五、将刚才新建数据库生成的数据库的日志文件test_logldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_datamdf。

六、启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何 *** 作。

七、设置数据库允许直接 *** 作系统表。此 *** 作可以在企业管理器（SQL Server Enterprise Manager）里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。

use master

go

sp_configure 'allow updates',1

go

reconfigure with override

go

八、设置test为紧急修复模式 。

update sysdatabases set status=-32768 where dbid=DB_ID('test')

此时可以在企业管理器（SQL Server Enterprise Manager）里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表。

九、下面执行真正的恢复 *** 作，用dbcc rebuild_log命令来重建数据库日志文件（重建路径根据你实际的数据库路径来）。

dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_logldf')

执行过程中，如果遇到下列提示信息：

服务器: 消息 5030，级别 16，状态 1，行 1

未能排它地锁定数据库以执行该 *** 作。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

说明您的其他程序正在使用该数据库，如果刚才您在八步骤中使用企业管理器打开了test库的系统表，那么退出企业管理器就可以了。

正确执行完成的提示应该类似于：

警告: 数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

此时打开在企业管理器里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。

十、验证数据库一致性。（次步骤可省略）

dbcc checkdb('test')

一般执行结果如下：

CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test'中）。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

十一、设置数据库为正常状态

sp_dboption 'test','dbo use only','false'

如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。

十二、最后一步，我们要将步骤七中设置的“允许对系统目录直接修改”一项恢复。因为平时直接 *** 作系统表是一件比较危险的事情。当然，我们可以在企业管理器里面恢复，也可以使用如下语句完成

sp_configure 'allow updates',0

go

reconfigure with override

go

对于只有mdf文件的sql2000数据库恢复，从第三步开始做就行了。

最好的方法为先分离然后附加看下

1．我们SQL SERVER企业管理器新建立一个供恢复使用的同名数据库(注意：要跟问题数据库同名，本例中为myDb)。

2．停掉数据库服务器。

3．将刚才生成的数据库的日志文件myDb_logldf删除（本例中的示列数据库名，实际使用您自己的数据库名称），用刚才备份的数据库mdf文件覆盖新生成的数据库数据文件myDb_datamdf。

4．启动数据库服务器。此时会看到数据库myDb的状态为“置疑”。这时候不能对此数据库进行任何 *** 作。

5．设置数据库允许直接 *** 作系统表。此 *** 作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右--键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。

use master

go

sp_configure 'allow updates',1

go

reconfigure with override

go F．设置myDb为紧急修复模式

在查询管理器里设置如下命令：

update sysdatabases set status=-32768 where dbid=DB_ID('stib')此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表

6．下面执行真正的恢复 *** 作，重建数据库日志文件

dbcc rebuild_log('stib','E:\zz\stib_logldf')警告: 数据库 'myDb' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。

7．验证数据库一致性（可省略）

dbcc checkdb('stib')一般执行结果如下：

CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'myDb' 中）。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

sp_dboption 'stib','single user','true'--设置为单用户

dbcc checkdb('stib','REPAIR_ALLOW_DATA_LOSS')--这个语句可能执行几遍之后有效

sp_dboption 'stib','single user','false'--取消单用户

8．设置数据库为正常状态

sp_dboption 'stib','dbo use only','false'

9．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接 *** 作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成

sp_configure 'allow updates',0

go

reconfigure with override

go

到此数据库置疑问题解决。

删除数据库中重复数据的几个方法 数据库的使用过程中由于程序方面的问题有时候会碰到重复数据 重复数据导致了数据库部分设置不能正确设置…… 方法一 declare @max integer @id integerdeclare cur_rows cursor local for select 主字段 count() from 表名 group by 主字段 having count() > open cur_rowsfetch cur_rows into @id @maxwhile @@fetch_status= beginselect @max = @max set rowcount @maxdelete from 表名 where 主字段 = @idfetch cur_rows into @id @maxendclose cur_rowsset rowcount 方法二 有两个意义上的重复记录 一是完全重复的记录 也即所有字段均重复的记录 二是部分关键字段重复的记录 比如Name字段重复 而其他字段不一定重复或都重复可以忽略 对于第一种重复 比较容易解决 使用select distinct from tableName就可以得到无重复记录的结果集 如果该表需要删除重复的记录（重复记录保留 条） 可以按以下方法删除select distinct into #Tmp from tableNamedrop table tableNameselect into tableName from #Tmpdrop table #Tmp发生这种重复的原因是表设计不周产生的 增加唯一索引列即可解决 这类重复问题通常要求保留重复记录中的第一条记录 *** 作方法如下假设有重复的字段为Name Address 要求得到这两个字段唯一的结果集select identity(int ) as autoID into #Tmp from tableNameselect min(autoID) as autoID into #Tmp from #Tmp group by Name autoIDselect from #Tmp where autoID in(select autoID from #tmp )最后一个select即得到了Name Address不重复的结果集（但多了一个autoID字段 实际写时可以写在select子句中省去此列） 更改数据库中表的所属用户的两个方法 大家可能会经常碰到一个数据库备份还原到另外一台机器结果导致所有的表都不能打开了 原因是建表的时候采用了当时的数据库用户…… 更改某个表 exec sp_changeobjectowner tablename dbo 存储更改全部表 CREATE PROCEDURE dbo User_ChangeObjectOwnerBatch@OldOwner as NVARCHAR( ) @NewOwner as NVARCHAR( )ASDECLARE @Name　 as NVARCHAR( )DECLARE @Owner　as NVARCHAR( )DECLARE @OwnerName　as NVARCHAR( )DECLARE curObject CURSOR FORselect Name = name Owner = user_name(uid)from sysobjectswhere user_name(uid)=@OldOwnerorder by nameOPEN　curObjectFETCH NEXT FROM curObject INTO @Name @OwnerWHILE(@@FETCH_STATUS= )BEGINif @Owner=@OldOwnerbeginset @OwnerName = @OldOwner + + rtrim(@Name)exec sp_changeobjectowner @OwnerName @NewOwnerend select @name @NewOwner @OldOwnerFETCH NEXT FROM curObject INTO @Name @OwnerENDclose curObjectdeallocate curObjectGOSQL SERVER中直接循环写入数据没什么好说的了 大家自己看 有时候有点用处declare @i intset @i= while @i< begininsert into test (userid) values(@i)set @i=@i+ end 无数据库日志文件恢复数据库方法两则 数据库日志文件的误删或别的原因引起数据库日志的损坏 方法一 新建一个同名的数据库 再停掉sql server(注意不要分离数据库) 用原数据库的数据文件覆盖掉这个新建的数据库 再重启sql server 此时打开企业管理器时会出现置疑 先不管 执行下面的语句（注意修改其中的数据库名) 完成后一般就可以访问数据库中的数据了 这时 数据库本身一般还要问题 解决办法是 利用数据库的脚本创建一个新的数据库 并将数据导进去就行了 USE MASTERGOSP_CONFIGURE ALLOW UPDATES RECONFIGURE WITH OVERRIDEGOUPDATE SYSDATABASES SET STATUS = WHERE NAME= 置疑的数据库名 Gosp_dboption 置疑的数据库名 single user true GoDBCC CHECKDB( 置疑的数据库名 )Goupdate sysdatabases set status = where name= 置疑的数据库名 Gosp_configure allow updates reconfigure with overrideGosp_dboption 置疑的数据库名 single user false 方法二 事情的起因 昨天 系统管理员告诉我 我们一个内部应用数据库所在的磁盘空间不足了 我注意到数据库事件日志文件XXX_Data ldf文件已经增长到了 GB 于是我决意缩小这个日志文件 经过收缩数据库等 *** 作未果后 我犯了一个自进入行业以来的最大最愚蠢的错误 竟然误删除了这个日志文件！后来我看到所有论及数据库恢复的文章上都说道 无论如何都要保证数据库日志文件存在 它至关重要 甚至微软甚至有一篇KB文章讲如何只靠日志文件恢复数据库的 我真是不知道我那时候是怎么想的？！这下子坏了！这个数据库连不上了 企业管理器在它的旁边写着 (置疑) 而且最要命的 这个数据库从来没有备份了 我唯一找得到的是迁移半年前的另外一个数据库服务器 应用倒是能用了 但是少了许多记录 表和存储过程 真希望这只是一场噩梦！ 没有效果的恢复步骤 附加数据库_Rambo讲过被删除日志文件中不存在活动日志时 可以这么做来恢复 分离被置疑的数据库 可以使用sp_detach_db 附加数据库 可以使用sp_attach_single_file_db但是 很遗憾 执行之后 SQL Server质疑数据文件和日志文件不符 所以无法附加数据库数据文件 DTS数据导出不行 无法读取XXX数据库 DTS Wizard报告说 初始化上下文发生错误 紧急模式怡红公子讲过没有日志用于恢复时 可以这么做 把数据库设置为emergency mode 重新建立一个log文件 把SQL Server 重新启动一下 把应用数据库设置成单用户模式 做DBCC CHECKDB 如果没有什么大问题就可以把数据库状态改回去了 记得别忘了把系统表的修改选项关掉我实践了一下 把应用数据库的数据文件移走 重新建立一个同名的数据库XXX 然后停掉SQL服务 把原来的数据文件再覆盖回来 之后 按照怡红公子的步骤走 但是 也很遗憾 除了第 步之外 其他步骤执行非常成功 可惜 重启SQL Server之后 这个应用数据库仍然是置疑！不过 让我欣慰的是 这么做之后 倒是能够Select数据了 让我大出一口气 只不过 组件使用数据库时 报告说 发生错误 未能在数据库 XXX 中运行 BEGIN TRANSACTION 因为该数据库处于回避恢复模式 最终成功恢复的全部步骤 设置数据库为紧急模式停掉SQL Server服务 把应用数据库的数据文件XXX_Data mdf移走 重新建立一个同名的数据库XXX 停掉SQL服务 把原来的数据文件再覆盖回来 运行以下语句 把该数据库设置为紧急模式 运行 Use MasterGosp_configure allow updates reconfigure with overrideGo 执行结果 DBCC 执行完毕 如果 DBCC 输出了错误信息 请与系统管理员联系 已将配置选项 allow updates 从 改为 请运行 RECONFIGURE 语句以安装 接着运行 update sysdatabases set status = where name = XXX 执行结果 （所影响的行数为 行）重启SQL Server服务 运行以下语句 把应用数据库设置为Single User模式 运行 sp_dboption XXX single user true 执行结果 命令已成功完成 ü 做DBCC CHECKDB 运行 DBCC CHECKDB( XXX ) 执行结果 XXX 的 DBCC 结果 sysobjects 的 DBCC 结果 对象 sysobjects 有 行 这些行位于 页中 sysindexes 的 DBCC 结果 对象 sysindexes 有 行 这些行位于 页中 syscolumns 的 DBCC 结果 ……… lishixinzhi/Article/program/SQLServer/201311/22060

备份数据文件,然后按下面的步骤处理: 1新建一个同名的数据库(数据文件与原来的要一致) 2再停掉sql server(注意不要分离数据库) 3用原数据库的数据文件覆盖掉这个新建的数据库 4再重启sql server 5此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名) 6完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用 数据库的脚本创建一个新的数据库,并将数据导进去就行了 USE MASTER GO SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE GO UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名' Go sp_dboption '置疑的数据库名', 'single user', 'true' Go DBCC CHECKDB('置疑的数据库名') Go update sysdatabases set status =28 where name='置疑的数据库名' Go sp_configure 'allow updates', 0 reconfigure with override Go sp_dboption '置疑的数据库名', 'single user', 'false 假设数据库为TEST： 按以下步骤执行 A．设置数据库允许直接 *** 作系统表。此 *** 作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。 use master go sp_configure 'allow updates',1 go reconfigure with override go B．设置test为紧急修复模式 update sysdatabases set status=-32768 where dbid=DB_ID('test') 此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表 C．下面执行真正的恢复 *** 作，重建数据库日志文件 dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_logldf') 执行过程中，如果遇到下列提示信息： 服务器: 消息 5030，级别 16，状态 1，行 1 未能排它地锁定数据库以执行该 *** 作。 DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。 说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。 正确执行完成的提示应该类似于： 警告: 数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。

SQL数据库修复的问题一定要用达思SQL数据库修复软件，是全球最棒的SQL数据库修复软件了。而且在数据库修复过程中遇到任何问题，还有数据库修复专家指导。此外，达思数据库修复软件还支持最新的SQL2008，最新更新的13版本支持碎片重组功能，即使数据库被覆盖了，也有比较好的解决方案。

找这个软件不难，在百度或谷歌搜索“达思数据库修复软件”即可！

当博途访问数据库发生这种 *** 作故障时，可以按如下 *** 作步骤可解决此方法，打开数据库里的Sql 查询编辑器窗口，运行以下的命令(注意：jd13dafa为对应可疑的数据库名称，执行时，请改为你的可疑的数据库名称)。

jd13dafa为数据库名称

1、修改数据库为紧急模式

ALTER DATABASE jd13dafa SET EMERGENCY

2、使数据库变为单用户模式

ALTER DATABASE jd13dafa SET SINGLE_USER

3、修复数据库日志重新生成，此命令检查的分配，结构，逻辑完整性和所有数据库中的对象错误。当您指定“REPAIR_ALLOW_DATA_LOSS”作为DBCC CHECKDB命令参数，该程序将检查和修复报告的错误。但是，这些修复可能会导致一些数据丢失。

DBCC CheckDB (jd13dafa , REPAIR_ALLOW_DATA_LOSS)

4、使数据库变回为多用户模式

您好，是这样的：

1首先确认已经备份了mdf和ldf文件。

2

在SQL

Server中新建一个同名的数据库，然后停止SQL

Server服务。

3

用原有的mdf和ldf文件覆盖新建数据库对应的mdf和ldf文件。

4

重新启动SQL

Server服务，这是应该会看到这个数据库处于置疑（Suspect）状态。

5

在SQL查询分析器中执行以下命令，以允许更新系统表：use

mastergosp_configure

"allow

updates",1reconfigurewithoverridego。

6

将这个数据库置为紧急模式：update

sysdatabases

set

status

=

32768

where

name="db_name"go。

7

使用DBCC

CHECKDB命令检查数据库中的错误：DBCC

CHECKDB("db_name")GO。

8

如果DBCC

CHECKDB命令失败，请转至第10步，否则先将数据库置为单用户模式，再尝试对其进行修复：sp_dboption

"db_name","single

user","true"DBCCCHECKDB("db_name",REPAIR_ALLOW_DATA_LOSS)GO

如果在执行DBCCCHECKDB("db_name",REPAIR_ALLOW_DATA_LOSS)命令时提示说数据库未处于单用户模式状态的话，则重新启动SQLServer服务，然后继续尝试。

9

如果DBCCCHECKDB("db_name",REPAIR_ALLOW_DATA_LOSS)命令失败，请转至第10步，否则若成功修复了数据库中的错误：

重新执行DBCC

CHECKDB("db_name")命令，确认数据库中已没有错误存在。

清除数据库的置疑状态：sp_resetstatus

"db_name"

清除数据库的单用户模式状态：sp_dboption

"db_name","single

user","false"

重新启动SQL

Server服务，如果一切正常的话，则数据库已经成功恢复。

10如果以上步骤都不能解决问题的话，请参考附件中的文档尝试通过重建事务日志来恢复数据库中的数据。如果您只有MDF文件，问题就更加复杂一些，我们需要直接重建事务日志了:

1

在SQL

Server中新建一个同名的数据库，然后停止SQL

Server服务。

2

用原有的ldf文件覆盖新建数据库对应的mdf文件，将其日志文件（ldf）删除。

3

启动SQL

Server服务，并将数据库置为紧急模式（同上:

步骤5和步骤6）。

4

停止并重新启动SQL

Server服务。

5

执行以下命令重建数据库日志文件：(下面是个示例，您要用您实际的数据库名)

DBCC

REBUILD_LOG（"cas_db",

"D:\cas_db\cas_db_LogLDF"）

6

重新将该数据库置为单用户模式。

7

再次尝试使用DBCC

CHECKTABLE或DBCC

CHECKDB命令检查并修复数据库中。

以上就是关于数据库“置疑”该怎么处理全部的内容，包括:数据库“置疑”该怎么处理、SQL Server实用经验技巧集（2）、修复SQL2000数据库置疑时出现的错误等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！