靠BCP恢复SQL Server 2000数据库

SQL Server 2000在很多企业、电子商务网站的信息化平台得到了普遍的应用。可在日常运行中，因种种原因会造成SQL Server 2000运行出现故障，轻则出现“置疑”，重则数据库系统崩溃。本文以图示的方式，阐述某个大学的一次数据库数据恢复过程。同时也详细阐述了BCP实用工具的详细用法，希望这个处理过程和处理方法能对大家有所启示。

本文恢复数据使用PC环境如下：

1）Windows 2000 Server（简体中文）+SP4

2）Microsoft SQL Server 2000企业版（简体中文）+SP3a

故障现象

1）游泳馆收费系统连接不上SQL Server 2000数据库。

2）启动SQL Server服务失败。

3）打开企业管理器，启动服务也是失败（看不到数据库树目录）。

要命的是当技术员发现问题，已经卸载SQL Server 2000后重新安装过了，想利用master数据库是不可能了。更要命的是，居然没有2005年的备份数据库，只有2004年6月的数据库备份文件。



恢复尝试

第一招：附加数据库

拷贝SQL Server 2000数据文件zytk.mdf到d:recovery下。在企业管理器中，右键数据库，选择所有任务→附加数据库。单击浏览（"..."）按钮选择要附加的数据库mdf文件d:recoveryzytk.mdf，发现日志文件是错误的（如图1）。

此时拷贝zytk.ldf到d:recovery目录下，再进行上述步骤，日志文件仍是错误（就是那个可恶的红叉叉）。单击确定按钮，提示日志文件错误（如图2和图3）。

发现提示的日志文件路径是D:Microsoft sql servermssql data zytk_log.ldf。于是在D盘建立D:Microsoft sql servermssqldata目录，并将zytk.mdf拷贝这个目录下。继续尝试上述附加数据库步骤，日志文件的路径已经变化，仍旧没能附加数据库成功（错误1813）（如图4与图1相比）。

第二招：用T-SQL附加数据库

在查询分析器中执行SQL脚本

use master

EXEC sp_attach_db "ZYTK", "D:Microsoft sql servermssqldataZYTK.mdf","D:Microsoft sql servermssqldataZYTK_log.ldf"

查询分析器提示：

服务器:消息5105，级别16，状态4，行1

设备激活错误。物理文件名 'D:Microsoft sql servermssql dataZYTK_log.ldf' 可能有误。

将D:recovery目录下zytk.mdf改名zytk-old.mdf。在企业管理器中新建数据库zytk，选择数据库文件路径为D:recoveryZYTK_Data.MDF，日志文件路径为D:recoveryZYTK_ log.LDF。在企业管理器中，右键停止，以便停止SQL Server服务。待SQL Server服务停止后将D:recoveryzytk.mdf改名zytk_data-new.mdf，同时将zytk-old.mdf改名为zytk_data.mdf，在企业管理器中启动SQL Server服务。数据库ZYTK将会置疑。

在查询分析器中执行SQL脚本：

Use master

select * from SysDatabases

where name='ZYTK'

看到数据库的status=1073741840，下面我们的目标是要将这个值修改到32768（紧急模式）再到16（假正常模式，这是我在这个故障处理中的叫法）。

缺省情况下，SQL Server不允许修改status值。直接作update，系统提示服务器: 消息 259，级别 16，状态 2，行 1未启用对系统目录的特殊更新。系统管理员必须重新配置 SQL Server 以允许这种操作。

所以先执行SQL脚本，让SQL Server允许我们修改status值：

sp_configure 'allow updates', 1

RECONFIGURE WITH OVERRIDE

修改status到32768（紧急模式），执行SQL脚本：

update SysDatabases

set status=32768

where name='zytk'

在查询分析器中执行SQL脚本，检查数据库完整性。

dbcc checkdb ('ZYTK') with ALL_ERRORMSGS

执行结果有很多错误（具体执行结果见03CheckDB-ZYTK结果.txt），跟笔者估计一致，数据库的索引出了大问题。下面摘录其中一个错误：

对象 'cw_Check_Detail' 有 0 行，这些行位于 0 页中。

服务器: 消息 8936，级别 16，状态 1，行 1

表错误: 对象 ID 181575685，索引 ID 1。B 树链的链接不匹配。(1:4987)->next = (1:2601)，但 (1:2601)->Prev = (1:4947)。

在查询分析器中执行SQL脚本，将数据库ZYTK的status修改为16：

update SysDatabases

set status=16

where name='zytk'

刷新数据库，ZYTK（紧急模式）转变为ZYTK。注意此时不能重新启动SQL Server服务！否则数据库ZYTK的状态还会变成置疑。这时，数据库处理算是成功一半！这个假正常模式（我的叫法）还是不能做数据库备份的。否则会提示如图5的错误。

不过这时可以看到那些可恨又可爱的表及表中的数据了。

在d:recovery下建立目录BCP，再在d:recoveryBCP下建立error目录。利用SQL Server数据库的SysObjects表可以生成批量的BCP命令：

从数据库中各表导出所有表的数据：

Use  %1

Select 'BCP  %1..' + name +

' out  d:recoveryBCP' +name + '.txt -c -S%2  -U%3 -P%4 >D:recoveryBCPerror out_'+name+'.txt' from 　sysobjects where type = 'U' order by name

从数据文件导回到数据库中的各表：

Use  %1

Select 'BCP  %1..' + name +

' in  d:recoveryBCP' +name + '.txt -c -S%2  -U%3 -P%4 >D:recoveryBCPerrorin_'+name+'.txt' from sysobjects where type = 'U' order by name

　　注意：type = "U"，U必须大写，表用户自定义表。-S服务器，-P密码，%1为数据库，%2为本机SQL Server实例名，一般就是计算机名，%3为登录账户，一般为sa，%4为登录密码。

本文中具体的例子如下：

Select 'BCP  ZYTK..' + name +

' out  d:recoveryBCP' +name + '.txt -c -Stech  -Usa -P123456 >d: recoveryBCPerrorout_'+name+'.txt' from sysobjects where type = 'U' order by name

将上述SQL脚本的查询结果全选后另存为批处理文件zytk.bat。用于从数据库ZYTK中各表导出以表名命名的txt文件：

Select 'BCP  ZYTK015..' + name +

' in  d:recoveryBCP' +name + '.txt -c -Stech  -Usa -P123456 >d: recoveryBCPerrorin _'+name+'.txt' from sysobjects where type = 'U' order by name

将上述SQL脚本的查询结果全选后另存为批处理文件zytk015.bat。用于将上述各表的txt文件导回到数据库ZYTK015。执行zytk.bat，执行完毕后要检查D:recoveryBCPerror下的每个out_表名.txt文件（见Error_outFiles.rar），查看是否有误。当然导入后要检查in表名.txt文件，查看是否有误。这是必须的，笔者因想偷懒，结果因导入数据不完整而重新恢复多花了半天，教训啊！我处理的数据库表一共有166个，为了提高恢复准确性，最好能找个人一起帮助看着过程是否有误。

新建ZYTK015要保证跟ZYTK一样的表结构（如主键、索引等，本文不再赘述，本文是从ZYTK中生成SQL脚本，然后新建数据库（下转第71页）（上接第70页）ZYTK015后执行创建表、主键、索引脚本。当然一般还有视图、存储过程等加密过的，是不能导出为SQL脚本，那得想其它的办法，本文是还原2004年的数据库来实现的）。

执行zytk015.bat，执行完毕后要检查D:recoveryBCPerror每个in_表名.txt文件（见Error_inFiles.rar）。笔者遇到一个历史流水表导入失败，后来经过分时间段导入，多次试验才得以成功。恢复的时候一定要细心，并且记录关键步骤的操作内容，否则做到哪一步，自己都晕菜了，更不用说成功地恢复数据库了！如果在zytk015数据库中能看到数据，那就是大功告成了。不过不要得意哦，还得运行游泳收费系统来测试数据的正确性。测试之前记得要备份数据库哦。

最后，有个问题要说明一下：如果表间有关联，使用BCP恢复起来就麻烦一点。一般的做法可以把外键之类的表间关系去掉，等导入数据后在用SQL脚本重新创建这些关系。这个做法数据的有效性得由我们自己去判断了，如果有问题还得手工修改（一般需要开发人员协助，因为只有他们才能去查代码）。

查看本文来源