修复SQL2000数据库置疑时出现的错误

备份数据文件,然后按下面的步骤处理:

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 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。
D．验证数据库一致性（可省略）
dbcc checkdb('test')
一般执行结果如下：
CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test' 中）。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
E．设置数据库为正常状态
sp_dboption 'test','dbo use only','false'
如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。
F．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接 *** 作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成
sp_configure 'allow updates',0
go
reconfigure with override
go
上面的语句 *** 作步骤有点问题：
应该如下：
A．我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server Enterprise Manager里面建立。
B．停掉数据库服务器。
C．将刚才生成的数据库的日志文件test_logldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_datamdf。
D．启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何 *** 作。
E．设置数据库允许直接 *** 作系统表。此 *** 作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
F．设置test为紧急修复模式
update sysdatabases set status=-32768 where dbid=DB_ID('test')
此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表
G．下面执行真正的恢复 *** 作，重建数据库日志文件
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 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。
H．验证数据库一致性（可省略）
dbcc checkdb('test')
一般执行结果如下：
CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test' 中）。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
I．设置数据库为正常状态
sp_dboption 'test','dbo use only','false'
如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。
J．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接 *** 作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成
sp_configure 'allow updates',0
go
reconfigure with override
go

原理是先kill占用了数据库的那个进程，然后设置数据库为多用户模式。

USE master;

Go

DECLARE @SQL VARCHAR(MAX);

SET @SQL=''

SELECT @SQL=@SQL+'; KILL '+RTRIM(SPID)

FROM mastersysprocesses

WHERE dbid=DB_ID('数据库名');

EXEC(@SQL);

GO
ALTER DATABASE 数据库名 SET MULTI_USER;

扩展资料：

机制结构

SQL Server 是一种客户机/服务器系统

多年来，SQL Server 一直被认为是一种客户机/服务器系统。事实上，Sybase DataServer（以此为基础开发了原始的 SQL Server）正是第一个作为客户机/服务器系统开发的商用关系数据库系统。那这又说明了什么呢？这不只意味着 SQL Server 是一个双层系统。

从传统上看，双层系统意味着客户机应用程序运行在一台机器上，向另一台计算机上的服务器发送请求。而对于 SQL Server，客户机/服务器意味着 SQL Server 的组成部分，即客户机 API 部分，驻留在处理结构中的远端，与服务器组件本身是分开的。

在典型的双层模型中，客户机程序部分驻留在台式机上，具有大量客户机应用程序逻辑和业务逻辑，并且会直接向数据库系统发出请求。然后，客户机得到服务器响应这些请求所返回的数据。

三层系统也采用了同样的模型。多年以来，SQL Server 一直用在事务处理监视系统中，例如 BEA 的 Tuxedo 以及 Compaq 的 ACMSxp，这些系统早在二、三十年前就采用了典型的三层模型。

三层模型在今天基于 Web 的应用系统中占据了支配地位，这类系统以 Microsoft 的 MTS 以及新的 COM+ 10 为代表。从 SQL Server 的角度看，三层解决方案中的客户机程序是放在中间层的。

中间层直接与数据库交互。实际的桌面，或瘦客户机（Thin Client），使用其他机制并通常直接与中间层交互，而不是直接与数据库系统交互。

参考资料来源：百度百科-sql server

1、首先停掉sql
agent;
2、在"服务"中重启MSSQLSERVER服务，
3、打开企业管理器，找到相应的数据库，右键，属性——选项——访问——限制访问——单用户，确定。
问题解决

删除数据库中重复数据的几个方法 数据库的使用过程中由于程序方面的问题有时候会碰到重复数据 重复数据导致了数据库部分设置不能正确设置…… 方法一 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首先确认已经备份了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命令检查并修复数据库中。

---