SQL2000数据库msdb质疑怎么

说实话，我过去曾多次遇到处理SQL2 000的MSDB数据库进入“可疑”状态的情况，这相当令人不安。
当时系统管理员老张有一台备用的服务器B，配置与有问题的服务器A相同，所以他勇敢地做了。

第一步，准备一个可以用的服务器B，说实话，我在选择B的时候是很小心的，生怕版本上会有细微的差别。
但后来我发现白白的不小心了——当时SQL2 000的补丁管理还比较原始，直接操作的话版本不兼容就会出现问题。

然后复制数据文件。
记得那天，老张先停止了B服务器上的SQLServer服务，然后手动将MSDB数据文件（MSDB.mdf）和日志文件（MSDB_log.LDF）复制到其中。
说实话，当我看到这个文件有多大时，我有点紧张，担心我会丢失其中的一部分。
复制完后直接在服务器A上覆盖即可。
这个阶段是最重要的，直接关系到后面能否启动。

重新启动SQLServer服务后，服务器A报告MSDB状态为“可疑”。
老张立即用SQL命令切换到单用户模式，然后才敢用DBCCCHECKDB扫描修复。
有趣的是，老张当时有DBCC的修复日志，不然真不知道怎么回滚。
维修之后，他手动将数据库状态改为正常，然后释放单用户模式。

最后一步是备份。
说实话，虽然操作很顺利，但老张还是完整备份了整个MSDB数据库，包括系统表。
他说：“万一操作出错，我还能从备份中恢复，这让我很安心。
”后来发现备胎是不需要的，不过这个预防措施没有白费。

现在想来，处理这种问题其实是相当考验经验的。
例如，复制文件时，最好在命令行中使用fc命令来确认文件是否完全一致，以避免丢失文件块。
修复DBCCCHECKDB时，如果数据库较大，最好先在测试环境中运行一下，看看需要多长时间，避免在生产环境中突然停机。
说实话，当时我并没有完全理解这些细节。
这些都是我事后的理解。

数据库“置疑”该怎么处理

恢复 SQL2 000 数据库中丢失的 ldf 文件的步骤 1 . 备份.mdf 文件。
2 . 删除可疑数据库。
3 、新建同名数据库，并保持文件名一致。
4 . 停止服务器。
5 、删除新建的数据库ldf文件，重写mdf文件。
6 .启动服务器，情况仍然可疑。
7 .允许直接操作表。
8 . 设置为紧急维护模式。
9 . 使用dbccrebuild_log 重建日志。
1 0. 如果遇到错误，请联系管理员。
1 1 . 恢复后检查一致性。
1 2 . 设置为正常。
1 3 . 恢复“允许直接更新系统目录”设置。