SQL2000数据库置疑解决方法
按下面的步骤处理:
1.新建一个同名的数据库
2.再停掉sql server
3.用备份的数据库MDF的文件覆盖掉这个新建的同名数据库文件
4.再重启sql server
5.此时打开企业管理器时新建的同名数据库会出现置疑,先不管,执行下面的语句(注意修改其中的数据库名)
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.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还有问题,解决办法是,利用
数据库的脚本创建一个新的数据库,并将数据导进去就行了.
企业管理器--右键你的数据库--所有任务--导出数据
--目标标数据库选择新建
--选择"在两个sql数据库之间复制对象和数据"
--把"包含扩展属性"选上,其他的根据需要选择
--最后完成
SQLSERVER数据库文件损坏处理2例
WINDOWS2000
SQLSERVER2000
这段时间遇到了好几起由于数据库文件损坏,而造成客户系统暂停使用的情况。在恢复过程中查阅参考了几篇网上的技术文章,实际操作过后感觉有必要承前启后一下,因此将恢复过程做个记录。
参考文献书写格式
案例1:
客户报告中午正常使用的系统,下午无法打开,报告的是连接数据库错误。电话中初步判断是数据库启动失败。首先告知客户无法立即恢复,先转成手工操作。
到达客户处,首先检查“事件查看器”,发现系统日志文件损坏,事件查看器无法显示系统日志。只能首先删除清空,并重建事件日志文件。然后再启动sqlserver,这时候就可以在事件查看器中看到sqlserver启动失败的错误信息了。错误大概是说 “启动过程中master数据文件损坏,数据库无法恢复”。由于master是系统数据库,因此SQLSERVER无法启动。
此服务器以前曾经发生过windows2000操作系统崩溃,曾经备份过SQLSERVER的 DATA 目录,万幸,把master的两个数据文件覆盖过来(master.mdf,mastlog.ldf)后,数据库就可以启动了。
测试一下,怎么程序还是不能打开,都快出汗了。一看,客户数据库居然是“质疑”的。再看事件查看器有"Disk"错误,连忙备份,好在管理员在前一天中午做过数据备份。恢复并将数据文件转移到另一个硬盘分区上,至此系统操作正常。至于丢失的一天数据让客户时间再补入系统。
分析原因:客户表示没有非法关机,停电等故障。因此有可能是硬盘出现坏道,或者是
内存品质不良。因此与客户协商,准备先更换一块硬盘,再跟踪使用情况。
案例二:
某天给客户升级报表,第二天早上,客户打电话来说系统不能打开。初步判断也是数据库启动失败。询问客户也没有修改过机器名,管理员密码。通过VNC连上客户服务器发现,还是MASTER数据库损坏。
这时候情况比较复杂,由于是新安装的系统,运行还不满一个月。实施时由于疏忽没有做过任何备份。只能尝试将其他电脑上的master数据文件拷贝过来。我笔记本上的SQLSERVER是desktop版,与服务器上安装的不符。 没办法,只能死马当活马医了。压缩,发送,折腾了半个小时才把文件发送到客户服务器上。覆盖... 启动... ,绿箭头出来了。居然成功了。
打开企业管理器,这时,客户数据库的属性都变成和我笔记本上的数据库一样了。密码,用户数据库。当然由于部分数据文件不一样,所有的用户数据库都是质疑的。删除不存在的用户数据库,然后附加客户自己的数据库。
孙红雷姚晨通常,附加数据库后,系统应该就可以使用了。但没想到的是这个客户数据文件也是损坏的,附加数
据库失败。这下恢复过程陷入僵局。虽然数据没用多少天,但库中有关键数据必须恢复。
头像1附加数据库错误提示:
“错误3456:未能恢复日志记录(***:***:x)事务 ID(0:***xx)......等等”
动物笑谈怀疑是日志文件损坏,只能寄希望于数据文件没有损坏。删除数据库日志文件,单独附加数据库文件,结果还是失败,报告“日志文件不符”。
由于远程操作过于缓慢,只能将客户数据文件压缩传回本地,再想办法进行修复。
首先上网了几篇丢失数据库日志文件的恢复数据的文章。
www.jaron/chs_db/20/20 ... ticle_view_1587.htm
由于数据日志中还有活动事务,文中第一种方法显然不适用我这种情况。遂按照第二种方法将数据库设置为紧急模式。当做到 DBCC CHECKDB 时。结果就与文章表示的不同了。
服务器: 消息 3908,级别 16,状态 1,行 2
未能在数据库 'sttzjg' 中运行 BEGIN TRANSACTION,因为该数据库处于回避恢复模式。
此时网上的文章都没有提示不到进一步的处理方法了。这时直接做DTS数据导出也是报错:DTS Wizard报告说“初始化上下文发生错误”。
不过万幸的是,这时候已经可以SELECT数据了。但有几个表 SELECT的时候报告:
服务器: 消息 601,级别 12,状态 3,行 1
由于数据移动,未能继续以 NOLOCK 方式扫描。
不能使用DTS, 常用的mssql2工具也不行。没有办法了,只能用SELECT手工恢复数据。首先新建一个新的业务数据库new,然后使用 "insert into new.dbo.table select * from *** "一个一个拷贝数据表。化了一个多小时
,最后只剩下那三个SELECT也报错的表了。
试试bcp,也报错,不过数据倒是导出来了,这下就好办了。用bcp把能导出的数据导到新库。至此数据库基本恢复。检查报表,发现也是丢失了一天的数据。时间节点上看,大概就是增加报表之后的一天的数据全部丢失, 主要就是那三张SELECT报错的表中。
婚俗改革实验区名单继续检查事件查看器中的内容,没有发现严重的磁盘错误。开关机的日志也很正常,很奇怪,不知道
什么情况会造成一整天的事务日志没有完成,而且还造成master数据库损坏。想不出来原因,还是先给客户设置好每日的数据自动备份。以后再出现这种情况也好处理一些。
总结:我们的客户使用的服务器都很一般,数据库备份相当重要,培训客户做好备份,减少由于系统故障造成的数据损失。