[数据库故障]数据库突然显示“质疑”是什么回事？如何恢复?(急)

[PI_2002]

数据库突然显示“质疑”，显示为灰色。
如何恢复？

[bflovesnow]

两种方法44：
一、这个问题比较复杂，引起的原因页很多。另外，你备份后的数据如果是在置疑之后备份的恢复之后也是置疑的。
数据库置疑之后，你可以查看系统数据库maseter中的sysdatabase中的status列，如果该列值是256表示置疑
你可以手工恢复
必须以sa登陆
USE master
GO
sp_configure 'allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO
sp_resetstatus
go

update sysdatabase
set status = status -256
where dbname="your database name here"
and status&256= 256(或者直接写256)
go
sp_configure 'allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO
sp_resetstatus
go
这样一般能恢复


二、
右键置疑状态的数据库-->所有任务-->脱机
右键脱机状态的数据库-->所有任务-->联机

[PI_2002]

我的数据库文件有4G，日志文件有18G，是不是文件过大引起的？
如果是的话，如何管理呢？

[jingxijun]

转贴日志维护

方法一此方法适用于7.0和2000。

1、在查询分析器中执行： exec sp_detach_db 'DB_Name','true'
2、在我的电脑中将日志的物理文件xxx_Log.LDF改名。
3、在查询分析器中执行： exec sp_attach_single_file_db 'DB_Name','C:\Program Files\Microsoft SQL Server\MSSQL\Data\DB_Name.MDF'
4、如果上一步成功，将步骤2中改名后的文件删除。如果上一步不成功，改回原来的文件名，用sp_attach_db将数据库附加到服务器，然后用方法二。

方法二
6.X中 DUMP TRANSACTION test2 with NO_LOG DUMP TRANSACTION test2 with TRUNCATE_ONLY 将上面的语句多次执行，直到日志缩小。7.0和2000中 backup log test2 with NO_LOG backup log test2 with TRUNCATE_ONLY DBCC SHRINKDATABASE(test2) 将上面的语句多次执行，直到日志文件缩小。上面的方法治标不治本，标本兼治要用下面的方法。

方法三：
--6.X和7.0中改为日志处于截断模式，2000中恢复模型改为简单恢复 exec sp_dboption 'test2','trunc. log on chkpt.','on' --7.0和2000中设为自动收缩,6.x中不用执行。 exec sp_dboption 'test2','autoshrink','on' 通常用于测试环境。

方法四: --7.0中改为日志不处于截断模式，2000中恢复模型改为完全恢复
exec sp_dboption 'test2','trunc. log on chkpt.','off' --7.0和2000中设为自动收缩,6.x中不用执行。
exec sp_dboption 'test2','autoshrink','on' 建立作业,每半个小时一次日志备份,每天一次完全数据库备份。 7.0和2000中：在Log收缩到正常大小后，将autoshrink选项设置为off。通常用于真实环境。 在产品化系统中将autoshrink选项设置为开启状态并非明智之举（除非您真的需要这样做），这是因为，当您的系统正在忙于完成其它任务时，autoshrink选项可能会同时启动，从而降低系统运行速度。然而，对于那些数据库管理员无暇估计并且数据库尺寸有可能在您毫无察觉的情况下超出控制范围的桌面或远程系统来说，开启这一选项却是一种非常有效的措施。 收缩事务日志 在下列情况下，日志文件的物理大小将减少：

[jingxijun]

*执行 DBCC SHRINKDATABASE 语句时。
*执行引用日志文件的 DBCC SHRINKFILE 语句时。
*自动收缩操作发生时。 日志收缩操作依赖于最初的日志截断操作。日志截断操作不减小物理日志文件的大小，但减小逻辑日志的大小，并将没有容纳逻辑日志任何部分的虚拟日志标记为不活动。日志收缩操作会删除足够多的不活动虚拟日志，将日志文件减小到要求的大小。 按下面任一方式控制事务日志的大小：
*在维护日志备份序列时，调度BACKUP LOG语句按间隔发生，以使事务日志不致增长到超过预期的大小。
*当不维护日志备份序列时，指定简单恢复模式。 详情请参考 MS SQL Server 2000 联机丛书： 目录--> SQL Server构架-->数据库构架-->物理数据库构架-->事务日志构架-->收缩事务日志 目录--> SQL Server构架-->数据库构架-->物理数据库构架-->事务日志构架-->截断事务日志

你用'管理'->'数据库维护计划'来做
选择数据库->从数据库文件中删除未使用的空间
当数据库的大小超过n MB 时收缩数据库 保留 10 % 的数据空间作为可用空间,这样可以调度执行,不需要手工操作了

[jingxijun]

再转贴：
数据库suspect后如何进行恢复
右键置疑状态的数据库-->所有任务-->脱机
右键脱机状态的数据库-->所有任务-->联机

这个问题比较复杂，引起的原因页很多。另外，你备份后的数据如果是在置疑之后备份的恢复之后也是置疑的。
数据库置疑之后，你可以查看系统数据库maseter中的sysdatabase中的status列，如果该列值是256表示置疑
你可以手工恢复
必须以sa登陆
USE master
GO
sp_configure 'allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO
sp_resetstatus
go

update sysdatabase
set status = status -256
where dbname="your database name here"
and status&256= 256(或者直接写256)
go
sp_configure 'allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO
sp_resetstatus
go
这样一般能恢复

如果还不行：

重置置疑状态
如果 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

[lynx1111]

搜索一下“置疑”

[zjcxc]

/*--重置置疑状态
1.系统方法:
如果 sql server 因为磁盘驱动器不再有可用空间，而不能完成数据库的恢复，
那么 microsoft® sql server™ 2000 会返回错误 1105
并且将 sysdatabases 中的 status 列设为置疑。按下面的步骤解决这个问题：

执行 sp_resetstatus。
语法为：
sp_resetstatus '数据库名'


用 alter database 向数据库添加一个数据文件或日志文件。

停止并重新启动 sql server。

用新的数据文件或日志文件所提供的额外空间，sql server 应该能完成数据库的恢复。

释放磁盘空间并且重新运行恢复操作。

sp_resetstatus 关闭数据库的置疑标志，但是原封不动地保持数据库的其它选项。
--*/

--2.手工重置置疑状态
use master
go
sp_configure 'allow updates',1 reconfigure with override
go
declare @dbname varchar(30)
set @dbname='你要处理的数据库名'

if @@trancount > 0
print '正在进行事务处理,操作不能进行'
else if suser_id()!=1
print '你不是系统管理员(sa),不能进行此操作'
else if not exists(select 1 from master..sysdatabases where name=@dbname)
print '你要操作的数据库不存在'
else if not exists(select 1 from master..sysdatabases where name= @dbname and status & 256 = 256)
print '你的数据库没有被置疑'
else
begin
begin tran
update master..sysdatabases set status = status ^ 256 where name = @dbname
if @@error != 0 or @@rowcount != 1
rollback tran
else
begin
commit tran
print '操作成功,请重新启动SQL'
end
end
go
sp_configure 'allow updates', 1 reconfigure with override
go

[zjcxc]

如果上面的方法不行,按下面的步骤处理:

0.企业管理器--右键你的数据库--所有任务--分离数据库.然后在我的电脑中备份你的数据文件

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

[ghosthjt]

这是微软关于数据库置疑的解决办法：
重置置疑状态
如果 SQL Server 因为磁盘驱动器不再有可用空间，而不能完成数据库的恢复，那么 Microsoft® SQL Server™ 2000 会返回错误 1105 并且将 sysdatabases 中的 status 列设为置疑。按下面的步骤解决这个问题：

执行 sp_resetstatus。


用 ALTER DATABASE 向数据库添加一个数据文件或日志文件。


停止并重新启动 SQL Server。
用新的数据文件或日志文件所提供的额外空间，SQL Server 应该能完成数据库的恢复。

释放磁盘空间并且重新运行恢复操作。
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

[ghosthjt]

如果这不能解决问题，那真是没有办法了，你试试将数据库分件分成几个文件组存在足够大的空间里试试

[lsp97]

上次我公司出現相似情況
我用 zjcxc(邹建) 的方法處理
最導出數可以
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

[shizi_mhy]

mark

[-狙击手-]

兄弟们全说，我还有什么要说的呢？就用上面的试试吧

[cgsun]

雖然沒有實踐過,但是還是頂一下

[leeboyan]

我不会，帮你顶！