数据库置疑，再也无法恢复！是什么原因导致的？急！
今天我的数据库莫名其妙地置疑，再也无法连接上，用DETACH 或ATTACH也一直报错，不知有什么原因会导致这种错误，不过当时客户端正连着，且局域网时断时续。
求答中！
问题点数：100、回复次数：6Top
1 楼pengdali（）回复于 2003-09-03 19:47:28 得分 10
右键置疑状态的数据库-->所有任务-->脱机
右键脱机状态的数据库-->所有任务-->联机
Top
2 楼pengdali（）回复于 2003-09-03 19:49:06 得分 10
估计是应为你的日志文件太大，硬盘没有空间造成的，你用
清空日志 DUMP TRANSACTION 库名 WITH NO_LOG
再：企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了
Top
3 楼tqqonline（蜡烛）回复于 2003-09-03 19:49:46 得分 10
病毒Top
4 楼pengdali（）回复于 2003-09-03 19:49:53 得分 20
联机帮助：
重置置疑状态
如果 SQL Server 因为磁盘驱动器不再有可用空间，而不能完成数据库的恢复，那么
Microsoft? SQL Server? 2000 会返回错误 1105 并且将 sysdatabases 中的 status
列设为置疑。按下面的步骤解决这个问题：
1.. 执行 sp_resetstatus。
2.. 用 ALTER DATABASE 向数据库添加一个数据文件或日志文件。
3.. 停止并重新启动 SQL Server。
用新的数据文件或日志文件所提供的额外空间，SQL Server 应该能完成数据库的恢
复。
4.. 释放磁盘空间并且重新运行恢复操作。
sp_resetstatus 关闭数据库的置疑标志，但是原封不动地保持数据库的其它选项。
注意 只有在您的主要支持提供者指导下或有疑难解答建议的做法时，才可以使用
sp_resetstatus。否则，可能会损坏数据库。
由于该过程修改了系统表，系统管理员必须在创建这个过程前，启用系统表更新。要启
用更新，使用下面的过程：
USE master
GO
sp_configure 'allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO
过程创建后，立即禁用系统表更新：
sp_configure 'allow updates', 0
GO
RECONFIGURE WITH OVERRIDE
GO
只有系统管理员才能执行 sp_resetstatus。执行该过程后，立即关闭 SQL Server。
语法为：
sp_resetstatus database_name
下面的例子将关闭 PRODUCTION 数据库的置疑标志。
sp_resetstatus PRODUCTION
下面是结果集：
Database 'PRODUCTION' status reset!
WARNING: You must reboot SQL Server prior to accessing this database!
sp_resetstatus 存储过程代码
下面是 sp_resetstatus 存储过程的代码：
IF EXISTS ( SELECT * from sysobjects where name = 'sp_resetstatus' )
DROP PROCEDURE sp_resetstatus
GO
CREATE PROC sp_resetstatus @dbname varchar(30) AS
DECLARE @msg varchar(80)
IF @@trancount > 0
BEGIN
PRINT 'Can''t run sp_resetstatus from within a transaction.'
RETURN (1)
END
IF suser_id() != 1
BEGIN
SELECT @msg = 'You must be the System Administrator (SA)'
SELECT @msg = @msg + ' to execute this procedure.'
RETURN (1)
END
IF (SELECT COUNT(*) FROM master..sysdatabases
WHERE name = @dbname) != 1
BEGIN
SELECT @msg = 'Database ' + @dbname + ' does not exist!'
PRINT @msg
RETURN (1)
END
IF (SELECT COUNT(*) FROM master..sysdatabases
WHERE name = @dbname AND status & 256 = 256) != 1
BEGIN
PRINT 'sp_resetstatus can only be run on suspect databases.'
RETURN (1)
END
BEGIN TRAN
UPDATE master..sysdatabases SET status = status ^ 256
WHERE name = @dbname
IF @@error != 0 OR @@rowcount != 1
ROLLBACK TRAN
ELSE
BEGIN
COMMIT TRAN
SELECT @msg = 'Database ' + @dbname + ' status reset!'
PRINT @msg
PRINT ''
PRINT 'WARNING: You must reboot SQL Server prior to '
PRINT ' accessing this database!'
PRINT ''
END
GO
Top
5 楼test123789（蛋蛋）回复于 2003-09-23 16:46:37 得分 50
设置数据库为紧急模式
停掉SQL Server服务；
把应用数据库的数据X_Data.mdf移走；
重新建立一个同名的数据库；
停掉SQL服务；
把原来的数据文件再覆盖回来；
运行以下语句，把该数据库设置为紧急模式；
运行“Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go”
执行结果：
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
已将配置选项 'allow updates' 从 0 改为 1。请运行 RECONFIGURE 语句以安装。
接着运行“update sysdatabases set status = 32768 where name = 'X'”
执行结果：
（所影响的行数为 1 行）
重启SQL Server服务；
运行以下语句，把应用数据库设置为Single User模式；
运行“sp_dboption 'X', 'single user', 'true'”
执行结果：
命令已成功完成。
做DBCC CHECKDB；
运行“DBCC CHECKDB('X')”
执行结果：
'X' 的 DBCC 结果。
'sysobjects' 的 DBCC 结果。
对象 'sysobjects' 有 273 行，这些行位于 5 页中。
'sysindexes' 的 DBCC 结果。
对象 'sysindexes' 有 202 行，这些行位于 7 页中。
'syscolumns' 的 DBCC 结果。
………
运行以下语句把系统表的修改选项关掉；
运行“sp_resetstatus "XXX"
go
sp_configure 'allow updates', 0
reconfigure with override
Go”
执行结果：
在 sysdatabases 中更新数据库 'XXX' 的条目之前，模式 = 0，状态 = 28（状态 suspect_bit = 0），
没有更新 sysdatabases 中的任何行，因为已正确地重置了模式和状态。没有错误，未进行任何更改。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
已将配置选项 'allow updates' 从 1 改为 0。请运行 RECONFIGURE 语句以安装。
重新建立另外一个数据库XXX.Lost；
DTS导出向导
运行DTS导出向导；
复制源选择EmergencyMode的数据库XXX，导入到XXX.Lost；
选择“在SQL Server数据库之间复制对象和数据”，试了多次，好像不行，只是复制过来了所有表结构，但是没有数据，也没有视图和存储过程，而且DTS向导最后报告复制失败；
所以最后选择“从源数据库复制表和视图”，但是后来发现，这样总是只能复制一部分表记录；
于是选择“用一条查询指定要传输的数据”，缺哪个表记录，就导哪个；
视图和存储过程是执行SQL语句添加的。
这样，XXX.Lost数据库就可以替换原来的应用数据库了Top
6 楼htao007（）回复于 2003-09-23 22:36:19 得分 0
pengdali(大力 V3.0)
我根据你的建议作了，结果还是不行，脱机，然后就改不了了，
什么问题
Top
