数据库日志文件丢失时的恢复步骤
微软有一篇文章讲如何只靠日志文件恢复数据库的,这里的问题是日志文件丢失的情况
最终成功恢复的全部步骤
设置数据库为紧急模式
ü 停掉SQL Server服务；
ü 把应用数据库的数据文件XXX_Data.mdf移走；
ü 重新建立一个同名的数据库XXX；
ü 停掉SQL服务；
ü 把原来的数据文件再覆盖回来；
ü 运行以下语句，把该数据库设置为紧急模式；
运行“Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go”
执行结果：
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
已将配置选项 'allow updates' 从 0 改为 1。请运行 RECONFIGURE 语句以安装。
接着运行“update sysdatabases set status = 32768 where name = 'XXX'”
执行结果：
（所影响的行数为 1 行）
ü 重启SQL Server服务；
ü 运行以下语句，把应用数据库设置为Single User模式；
运行“sp_dboption 'XXX', 'single user', 'true'”
执行结果：
命令已成功完成。
ü 做DBCC CHECKDB；
运行“DBCC CHECKDB('XXX')”
执行结果：
'XXX' 的 DBCC 结果。
'sysobjects' 的 DBCC 结果。
对象 'sysobjects' 有 273 行，这些行位于 5 页中。
'sysindexes' 的 DBCC 结果。
对象 'sysindexes' 有 202 行，这些行位于 7 页中。
'syscolumns' 的 DBCC 结果。
………
ü 运行以下语句把系统表的修改选项关掉；
运行“sp_resetstatus "XXX"
go
sp_configure 'allow updates', 0
reconfigure with override
Go”
执行结果：
在 sysdatabases 中更新数据库 'XXX' 的条目之前，模式 = 0，状态 = 28（状态 suspect_bit = 0），
没有更新 sysdatabases 中的任何行，因为已正确地重置了模式和状态。没有错误，未进行任何更改。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
已将配置选项 'allow updates' 从 1 改为 0。请运行 RECONFIGURE 语句以安装。
ü 重新建立另外一个数据库XXX.Lost；
DTS导出向导
ü 运行DTS导出向导；
ü 复制源选择EmergencyMode的数据库XXX，导入到XXX.Lost；
ü 选择“在SQL Server数据库之间复制对象和数据”，试了多次，好像不行，只是复制过来了所有表结构，但是没有数据，也没有视图和存储过程，而且DTS向导最后报告复制失败；
ü 所以最后选择“从源数据库复制表和视图”，但是后来发现，这样总是只能复制一部分表记录；
ü 于是选择“用一条查询指定要传输的数据”，缺哪个表记录，就导哪个；
ü 视图和存储过程是执行SQL语句添加的。
这样，XXX.Lost数据库就可以替换原来的应用数据库了。
18:16 | 添加评论 | 阅读评论 (1) | 固定链接 | 引用通告 (0) | 记录它 | SQL Server
Sql Server数据库被置疑后解决方法
现象：数据库Log日志太大了，shrink不掉。于是想把数据库文件卸下来，删除log，再附加上。附加失败。
提示错误：
服务器: 消息 1813，级别 16，状态 2，行
1
未能打开新数据库 'metadb'。CREATE DATABASE 将终止。
设备激活错误。物理文件名 'd:/metadb.LDF' 可能有误。
环境:MSSQL SERVER 2000 企业版
解决过程：
1.建一个新库newdb
2.停掉数据库。删除新库的log文件,将metadb.mdf覆盖newdb.mdf。
3.启动数据库服务器。数据库newdb的状态为“置疑”。
4. 允许对系统目录直接修改
USE MASTER
GO
SP_CONFIGURE'ALLOW UPDATES',1
GO
RECONFIGUREWITH
GO
UPDATESET STATUS=-32768 WHERE DBID=DB_ID('NEWDB')
5．重建LOG
DBCC('NEWDB','C:/PROGRAM FILES/MICROSOFT SQL SERVER/MSSQL/DATA/NEWDB_LOG.LDF')
6.DBCC检查
DBCC('NEWDB')
7.设置数据库为正常状态
UPDATESET STATUS =28 WHERE NAME='NEWDB'
GO
8 不允许对系统目录直接修改
SP_CONFIGURE'ALLOW UPDATES',0
GO
RECONFIGUREWITH
GO
另外:
Zach说他每次遇到这种数据库置疑情况，就运行下面这个脚本，屡试不爽：
======================================================
--before running any script, run the following to set the
master database to allow updates
USE master
GO
sp_configure 'allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO
--Run the following script
UPDATE master..sysdatabases SET status = status ^ 256
WHERE name = 'Database_Name'
--Run the following script
exec SP_resetstatus Database_Name
--stop and start the MSDTC at this stage
--After the procedure is created, immediately disable
updates to the system tables:
exec sp_configure 'allow updates', 0
GO
RECONFIGURE WITH OVERRIDE
GO
=====================================
处理置疑的基本步骤：
执行 sp_configure 以允许对系统表进行更新，然后用 RECONFIGURE WITH OVERRIDE 语句强制实施该配置；
数据库重置紧急模式；
执行sp_resetstatus关闭数据库的置疑标志，但是原封不动地保持数据库的其它选项（只有系统管理员才能执行）。执行该过程后，立即重启 SQL Server服务；
执行 sp_configure 以禁止对系统表进行更新，然后用 RECONFIGURE WITH OVERRIDE 语句强制实施该配置。
status ^ 256的意思就是：
--------------------------------------------------------------------------------------------------------
Constant Value Description
SQLDMODBStat_Suspect 256 Database integrity is suspect for the referenced database.
--------------------------------------------------------------------------------------------------------
不同的是，有时候丢失了数据库日志文件，额外需要以下步骤：
? 把应用数据库设置为Single User模式；
? 做DBCC CHECKDB；
才可以。
但是几位网友的实践结果就是这个DBCC CHECKDB执行失败。一位网友yang说：“但是 DBCC CHECKDB就是执行不了，总是说“该数据库处于回避恢复模式”。我已经试了很多次了，就是改变不了这个状态。”
还有一位Rui执行DBCC CHECKDB时报错：“Server: Msg 943, Level 14, State 1, Line 1 Database 'his_yb' cannot be opened because its version (539) is later than the current server version (515).”
对于Yang，可能他没有一步一步做，。我的切身体会是，把应用数据库设置为Single User模式后就可以做DBCC CHECKDB。之后呢，也许SQL Server重启后自动检查数据库是否正常。但是数据应该是可以读出来的，至少可以被DTS Wizard读出来的。这时候的数据库还存在问题，比如我的组件使用数据库时，报告说：“发生错误：-2147467259,未能在数据库 'XXX' 中运行 BEGIN TRANSACTION，因为该数据库处于回避恢复模式。”
对于Rui，他碰到的那个错误
Server: Msg 943, Level 14, State 1, Line 2
Database 'XXXX' cannot be opened because its version (536) is later than
the current server version (515).
这表明Rui正试图：
从一个SQL Server 2000(version 539,536之类的)的数据库备份恢复到一个SQL Server 7.0中
或者
把一个SQL Server 2000(version 539,536之类的)的数据库attach到一个SQL Server 7.0中，
这是不允许的。如果你必须使用这个SQL Server 2000的数据备份，那么请您首先把这个备份倒入SQL Server 2000，最后用DTS把数据库从SQL Server 2000上transfer到SQL Server 7.0上。
