运维部落

一次客户由于硬盘损坏，种种原因下，我当时仅仅只拿到了备份了的mdf文件，那么恢复起来就是一件很麻烦的事情了。

SQL2000数据库置疑解决方法
按下面的步骤处理:
1.新建一个同名的数据库
2.再停掉sql server服务
3.用备份的数据库MDF的文件覆盖掉这个新建的同名数据库文件
4.再重启sql server服务
5.此时打开企业管理器时新建的同名数据库会出现”置疑”，先不管，执行下面的语句（注意修改其中的数据库名)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

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

ok数据能访问了

操作一下发现有部分表不能select不能写入操作错误：“发生错误：-2147467259,未能在数据库 ‘XXX’ 中运行 BEGIN TRANSACTION，因为该数据库处于回避恢复模式”
这时,数据库本身一般还有问题,解决办法是,利用
数据库的脚本创建一个新的数据库,并将数据导进去就行了.
企业管理器–右键你的数据库–所有任务–导出数据
–目标标数据库选择新建
–选择”在两个sql数据库之间复制对象和数据”
–把”包含扩展属性”选上,其他的根据需要选择
–最后完成

注：以上如果失败，一般会提示xxx用户不在。在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版，与服务器上安装的不符。没办法，只能死马当活马医了。压缩，发送，折腾了半个小时才把文件发送到客户服务器上。覆盖… 启动… ，绿色箭头出来了。居然成功了。
打开企业管理器，这时，客户数据库的属性都变成和我笔记本上的数据库一样了。密码，用户数据库。当然由于部分数据文件不一样，所有的用户数据库都是质疑的。删除不存在的用户数据库，然后附加客户自己的数据库。
通常，附加数据库后，系统应该就可以使用了。但没想到的是这个客户数据文件也是损坏的，附加数据库失败。这下恢复过程陷入僵局。虽然数据没用多少天，但库中有关键数据必须恢复。
附加数据库错误提示：
“错误3456：未能恢复日志记录（***:***:x）事务 ID（0:***xx）……等等”
怀疑是日志文件损坏，只能寄希望于数据文件没有损坏。删除数据库日志文件，单独附加数据库文件，结果还是失败，报告“日志文件不符”。
由于远程操作过于缓慢，只能将客户数据文件压缩传回本地，再想办法进行修复。
首先上网找了几篇丢失数据库日志文件的恢复数据的文章。
http://www.jaron.cn/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数据库损坏。想不出来原因，还是先给客户设置好每日的数据自动备份。以后再出现这种情况也好处理一些。
总结：我们的客户使用的服务器都很一般，数据库备份相当重要，培训客户做好备份，减少由于系统故障造成的数据损失。