数据置疑 
数据置疑
数据置疑数据库置疑的处理方法1
数据置疑
数据置疑步骤1:
数据置疑
数据置疑创建一个新的数据库,命名为原来数据库的名字。
数据置疑
数据置疑步骤2:
数据置疑
数据置疑停止SQL Server
数据置疑
数据置疑步骤3:
数据置疑
数据置疑把老数据库的MDF文件替换新数据库的相应的MDF文件,并把LDF文件删除。
数据置疑
数据置疑步骤4:
数据置疑
数据置疑重新启动SQL Server服务,然后运行如下命令:
数据置疑
数据置疑
Use Master
数据置疑
数据置疑Go
数据置疑
数据置疑sp_configure @
#allow updates@#, 1
数据置疑
数据置疑reconfigure with override
数据置疑
数据置疑Go
数据置疑
数据置疑begin tran
数据置疑
数据置疑update sysdatabases 
set status = 32768 where name = @#db_name@#
数据置疑
数据置疑--
Verify one row is updated before committing
数据置疑
数据置疑commit tran
数据置疑
数据置疑步骤5:
数据置疑
数据置疑停止SQL然后重新启动SQL Server服务,然后运行如下命令:
数据置疑
数据置疑DBCC TRACEON(
3604
数据置疑
数据置疑DBCC REBUILD_LOG(@
#db_name@#,@#c:\mssql7\data\dbxxx_3.ldf@#
数据置疑
数据置疑Go
数据置疑
数据置疑步骤6:
数据置疑
数据置疑停止SQL然后重新启动SQL Server服务,然后运行:
数据置疑
数据置疑
use master
数据置疑
数据置疑update sysdatabases 
set status = 8 where name = @#db_name@#
数据置疑
数据置疑Go
数据置疑
数据置疑sp_configue @
#allow updates@#, 0
数据置疑
数据置疑reconfigure with override
数据置疑
数据置疑Go
数据置疑
数据置疑步骤7:
数据置疑
数据置疑运行dbcc checkdb
(db_name) 检查数据库的完整性
数据置疑
数据置疑注:都要替换成真实的数据库名字。
数据置疑
数据置疑
数据置疑数据库置疑的处理方法2
数据置疑 
数据置疑既然它认为这个ndf文件已经建立好了,  那你就建立一个嘛:  
数据置疑 
数据置疑
1.  备份你的数据文件和日志文件  
数据置疑
2.  创建一个新的空数据库,  要求数据文件和日志文件与你损坏的那个数据库的文件是一样的,当然也要包含创建一个与不成功创建的ndf文件名一样的ndf文件  
数据置疑 
数据置疑
3.  停止sql服务,  复制你备份的数据文件和日志文件,  覆盖你新建的数据库的对应文件,ndf文件保留不动  
数据置疑 
数据置疑
4.  启动sql服务,  这时步骤2中创建的数据库应该是质疑的、  
数据置疑 
数据置疑
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'  
数据置疑Go  
数据置疑 
数据置疑---------------------------------------------------------------  
数据置疑 
数据置疑经过近6个小时的艰苦奋斗
.总于搞好了.先谢谢各位.我的水平有限制,希望各位指正.  
数据置疑 
数据置疑 
数据置疑由于我试数据库添加多一个ndf文件的时候
,由于我的机器出问题了,中断了操作,结果数据库出现错误,其实我的ndf文件根本没有生成,只是数据库存在一条记录罢了.  
数据置疑 
数据置疑 
数据置疑
1)创建一个新的空数据库,  要求数据文件和日志文件与你损坏的那个数据库的文件是一样的,当然也要包含创建一个与不成功创建的ndf文件名一样的ndf文件.  
数据置疑 
数据置疑
2)关键  在master的系统表sysaltfiles里面存在每个数据库文件的记录,我把我错误的记录删除.  
数据置疑SP_CONFIGURE  'ALLOW  UPDATES'
,1  RECONFIGURE  WITH  OVERRIDE  
数据置疑GO  
数据置疑 
数据置疑delete  from  sysaltfiles  where  name
='错误的记录'  
数据置疑go  
数据置疑SP_CONFIGURE  'ALLOW  UPDATES'
,0  RECONFIGURE  WITH  OVERRIDE  
数据置疑GO  
数据置疑 
数据置疑
2)重新启动数据库.你会发现数据库置疑了.  
数据置疑 
数据置疑
3)UPDATE  SYSDATABASES  SET  STATUS  =32768  WHERE  NAME='置疑的数据库名'  
数据置疑 
数据置疑
4)数据库状态变成了  "紧急模式"  .我发现在紧急模式下,用查询分析器可以查询到数据里面的表(在企业管理器不行).搜索一下数据中sysfiles和sysfiles1,你会发现,一个表中有错误记录,而一个表就因为master里面删除了它也跟着删除了.  
数据置疑 
数据置疑
5)UPDATE  SYSDATABASES  SET  STATUS  =28WHERE  NAME='置疑的数据库名',把数据库状态还原.  
数据置疑 
数据置疑
6)我的天啊,企业管理器里面正常显示了.这个时候,你先别高兴,你会发现在查询分析器里面正常查询,但建表失败,在企业管理器里面直接查询表失败,导入导出失败.  
数据置疑 
数据置疑
7)查看数据库属性,发现错误的ndf记录没有了.但sysfile1里面还有,如是,重新建立一个ndf,成功后,你会发现所有的操作都成功了,数据库还原了  
数据置疑 
数据置疑然后我马上把ndf删除  
数据置疑
数据置疑联机丛书的方法
数据置疑
数据置疑
数据置疑重置置疑状态
数据置疑如果 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
数据置疑

相关文章:

  • 2022-12-23
  • 2022-12-23
  • 2021-12-15
  • 2022-03-05
  • 2021-12-03
  • 2022-01-17
  • 2021-10-29
  • 2021-12-09
猜你喜欢
  • 2021-12-16
  • 2021-07-19
  • 2022-12-23
  • 2021-05-20
  • 2021-07-23
  • 2022-02-07
  • 2022-12-23
相关资源
相似解决方案