无日志文件恢复 MySQL

　　方法一

　　1.新建一个同名的数据库

　　2.再停掉 sql server(注意不要分离数据库)

　　3.用原数据库的数据文件覆盖掉这个新建的数据库

　　4.再重启 sql server

　　5.此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)

　　6.完成后一般就可以访问数据库中的数据了，这时,数据库本身一般还要问题,解决办法是,利用数据库的脚本创建一个新的数据库，并将数据导进去就行了。

　　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

　　方法二

　　事情的起因

　　昨天，系统管理员告诉我，我们一个内部应用数据库所在的磁盘空间不足了。我注意到数据库事件日志文件 XXX_Data.ldf 文件已经增长到了 3GB，于是我决意缩小这个日志文件。经过收缩数据库等操作未果后，我犯了一个自进入行业以来的最大最愚蠢的错误：竟然误删除了这个日志文件！后来我看到所有论及数据库恢复的文章上都说道：“无论如何都要保证数据库日志文件存在，它至关重要”，甚至微软甚至有一篇 KB 文章讲如何只靠日志文件恢复数据库的。我真是不知道我那时候是怎么想的？！

　　这下子坏了！这个数据库连不上了，企业管理器在它的旁边写着“(置疑)”。而且最要命的，这个数据库从来没有备份了。我唯一找得到的是迁移半年前的另外一个数据库服务器，应用倒是能用了，但是少了许多记录、表和存储过程。真希望这只是一场噩梦！

　　没有效果的恢复步骤

　　附加数据库

　　_Rambo 讲过被删除日志文件中不存在活动日志时，可以这么做来恢复：

　　1，分离被置疑的数据库，可以使用 sp_detach_db

　　2，附加数据库，可以使用 sp_attach_single_file_db

　　但是，很遗憾，执行之后，SQL Server 质疑数据文件和日志文件不符，所以无法附加数据库数据文件。

　　DTS 数据导出

　　不行，无法读取 XXX 数据库，DTS Wizard 报告说“初始化上下文发生错误”。

　　紧急模式

　　没有日志用于恢复时，可以这么做：

　　1，把数据库设置为 emergency mode

　　2，重新建立一个 log 文件

　　3，把 SQL Server 重新启动一下

　　4，把应用数据库设置成单用户模式

　　5，做 DBCC CHECKDB

　　6，如果没有什么大问题就可以把数据库状态改回去了，记得别忘了把系统表的修改选项关掉

　　我实践了一下，把应用数据库的数据文件移走，重新建立一个同名的数据库 XXX，然后停掉 SQL 服务，把原来的数据文件再覆盖回来。之后，按照怡红公子的步骤走。

　　但是，也很遗憾，除了第 2 步之外，其他步骤执行非常成功。可惜，重启 SQL Server 之后，这个应用数据库仍然是置疑！

　　不过，让我欣慰的是，这么做之后，倒是能够 Select 数据了，让我大出一口气。只不过，组件使用数据库时，报告说：“发生错误：-2147467259，未能在数据库 XXX 中运行 BEGIN TRANSACTION，因为该数据库处于回避恢复模式。”

　　最终成功恢复的全部步骤

　　设置数据库为紧急模式

　　1，停掉 SQL Server 服务；

　　2，把应用数据库的数据文件 XXX_Data.mdf 移走；

　　3，重新建立一个同名的数据库 XXX；

　　4，停掉 SQL 服务；

　　5，把原来的数据文件再覆盖回来；

　　6，运行以下语句，把该数据库设置为紧急模式；

　　运行“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 数据库就可以替换原来的应用数据库了。