SQL Server：无日志恢复数据库

事情的起因 昨天 系统管理员告诉我 我们一个内部应用数据库所在的磁盘空间不足了 我注意到数据库事件日志文件XXX_Data ldf文件已经增长到了 GB 于是我决意缩小这个日志文件 经过收缩数据库等 *** 作未果后 我犯了一个自进入行业以来的最大最愚蠢的错误:竟然误删除了这个日志文件!后来我看到所有论及数据库恢复的文章上都说道: 无论如何都要保证数据库日志文件存在 它至关重要 甚至微软甚至有一篇KB文章讲如何只靠日志文件恢复数据库的 我真是不知道我那时候是怎么想的!这下子坏了!这个数据库连不上了 企业管理器在它的旁边写着 (置疑) 而且最要命的 这个数据库从来没有备份了 我唯一找得到的是迁移半年前的另外一个数据库服务器 应用倒是能用了 但是少了许多记录 表和存储过程 真希望这只是一场噩梦!数据库日志文件的误删或别的原因引起数据库日志的损坏 方法一 新建一个同名的数据库 再停掉sql server(注意不要分离数据库) 用原数据库的数据文件覆盖掉这个新建的数据库 再重启sql server 此时打开企业管理器时会出现置疑 先不管 执行下面的语句(注意修改其中的数据库名) 完成后一般就可以访问数据库中的数据了 这时 数据库本身一般还要问题 解决办法是 利用数据库的脚本创建一个新的数据库 并将数据导进去就行了 USE MASTERGOSP_CONFIGURE ALLOW UPDATES RECONFIGURE WITH OVERRIDEGOUPDATE SYSDATABASES SET STATUS = WHERE NAME= 置疑的数据库名 Gosp_dboption 置疑的数据库名 single user true GoDBCC CHECKDB( 置疑的数据库名 )Goupdate sysdatabases set status = where name= 置疑的数据库名 Gosp_configure allow updates reconfigure with overrideGosp_dboption 置疑的数据库名 single user false Go 方法二 事情的起因昨天 系统管理员告诉我 我们一个内部应用数据库所在的磁盘空间不足了 我注意到数据库事件日志文件XXX_Data ldf文件已经增长到了 GB 于是我决意缩小这个日志文件 经过收缩数据库等 *** 作未果后 我犯了一个自进入行业以来的最大最愚蠢的错误:竟然误删除了这个日志文件!后来我看到所有论及数据库恢复的文章上都说道: 无论如何都要保证数据库日志文件存在 它至关重要 甚至微软甚至有一篇KB文章讲如何只靠日志文件恢复数据库的 我真是不知道我那时候是怎么想的!这下子坏了!这个数据库连不上了 企业管理器在它的旁边写着 (置疑) 而且最要命的 这个数据库从来没有备份了 我唯一找得到的是迁移半年前的另外一个数据库服务器 应用倒是能用了 但是少了许多记录 表和存储过程 真希望这只是一场噩梦!没有效果的恢复步骤附加数据库_Rambo讲过被删除日志文件中不存在活动日志时 可以这么做来恢复: 分离被置疑的数据库 可以使用sp_detach_db 附加数据库 可以使用sp_attach_single_file_db但是 很遗憾 执行之后 SQL Server质疑数据文件和日志文件不符 所以无法附加数据库数据文件 DTS数据导出不行 无法读取XXX数据库 DTS Wizard报告说 初始化上下文发生错误 紧急模式怡红公子讲过没有日志用于恢复时 可以这么做: 把数据库设置为emergency mode 重新建立一个log文件 把SQL Server 重新启动一下 把应用数据库设置成单用户模式 做DBCC CHECKDB 如果没有什么大问题就可以把数据库状态改回去了 记得别忘了把系统表的修改选项关掉我实践了一下 把应用数据库的数据文件移走 重新建立一个同名的数据库XXX 然后停掉SQL服务 把原来的数据文件再覆盖回来 之后 按照怡红公子的步骤走 但是 也很遗憾 除了第 步之外 其他步骤执行非常成功 可惜 重启SQL Server之后 这个应用数据库仍然是置疑!不过 让我欣慰的是 这么做之后 倒是能够Select数据了 让我大出一口气 只不过 组件使用数据库时 报告说: 发生错误: 未能在数据库 XXX 中运行 BEGIN TRANSACTION 因为该数据库处于回避恢复模式 最终成功恢复的全部步骤设置数据库为紧急模式停掉SQL Server服务;把应用数据库的数据文件XXX_Data mdf移走;重新建立一个同名的数据库XXX;停掉SQL服务;把原来的数据文件再覆盖回来;运行以下语句 把该数据库设置为紧急模式;运行 Use MasterGosp_configure allow updates reconfigure with overrideGo 执行结果:DBCC 执行完毕 如果 DBCC 输出了错误信息 请与系统管理员联系 已将配置选项 allow updates 从 改为 请运行 RECONFIGURE 语句以安装 接着运行 update sysdatabases set status = where name = XXX 执行结果:(所影响的行数为 行)重启SQL Server服务;运行以下语句 把应用数据库设置为Single User模式;运行 sp_dboption XXX single user true 执行结果:命令已成功完成 ü 做DBCC CHECKDB;运行 DBCC CHECKDB( XXX ) 执行结果: XXX 的 DBCC 结果 sysobjects 的 DBCC 结果 对象 sysobjects 有 行 这些行位于 页中 sysindexes 的 DBCC 结果 对象 sysindexes 有 行 这些行位于 页中 syscolumns 的 DBCC 结果 ………ü 运行以下语句把系统表的修改选项关掉;运行 sp_resetstatus XXX gosp_configure allow updates reconfigure with overrideGo 执行结果:在 sysdatabases 中更新数据库 XXX 的条目之前 模式 = 状态 = (状态 suspect_bit = ) 没有更新 sysdatabases 中的任何行 因为已正确地重置了模式和状态 没有错误 未进行任何更改 DBCC 执行完毕 如果 DBCC 输出了错误信息 请与系统管理员联系 已将配置选项 allow updates 从 改为 请运行 RECONFIGURE 语句以安装 重新建立另外一个数据库XXX Lost;DTS导出向导运行DTS导出向导;复制源选择EmergencyMode的数据库XXX 导入到XXX Lost;选择 在SQL Server数据库之间复制对象和数据 试了多次 好像不行 只是复制过来了所有表结构 但是没有数据 也没有视图和存储过程 而且DTS向导最后报告复制失败;所以最后选择 从源数据库复制表和视图 但是后来发现 这样总是只能复制一部分表记录;于是选择 用一条查询指定要传输的数据 缺哪个表记录 就导哪个;视图和存储过程是执行SQL语句添加的 维护Sql Server中表的索引在使用和创建数据库索引中经常会碰到一些问题 在这里可以采用一些另类的方法解决… 第一步:查看是否需要维护 查看扫描密度/Scan Density是否为 %declare @table_id intset @table_id=object_id( 表名 )dbcc showcontig(@table_id) 第二步:重构表索引dbcc dbreindex( 表名 pk_索引名 ) 重做第一步 如发现扫描密度/Scan Density还是小于 %则重构表的所有索引 并不一定能达 % dbcc dbreindex( 表名 ) lishixinzhi/Article/program/SQLServer/201311/22169

1、每日自动备份

打开企业管理器，进入“管理”-“数据库维护计划”，在右侧窗口点击右键，选择“新建维护计划”，启动“数据库维护计划向导”;点击“下一步”选择需要维护的数据库，维护特性数据库时，选择最后一个单选框并勾选需要维护的数据库名称;“下一步”选择更新数据优化信息、“下一步”检查数据库完整性、“下一步”指定数据库备份计划、“下一步”指定备份存放位置、“下一步”指定事务日志备份计划、“下一步”指定报表，“下一步”指定历史纪录维护，最后设定维护作业名称;通常来说，如果只需要备份数据库文件，则只需要指定备份计划以及存放位置即可，其他项目不做改动。

在指定备份计划时候，由于需要每日备份，因此要更改调度。点击“更改”编辑调度。发生频率选择每天;每日频率选择作业开始时间，最好选择数据库访问量小时进行，多为半夜时间，可根据流量图确定具体时间;持续时间通常不用做改动，开始日期为编辑日期，无结束日期。

编辑好上述维护计划后，还要注意下

sql

server代理服务是否启动了，因为每日调度维护计划是要启动这个服务才能执行的。如果该服务没有启动，需要手动启动一下，这是可以在其子项“作业”中看到刚刚添加过的数据库维护计划。

2、定期自动清理数据库日志文件

数据库日志文件是随着时间增长而增长的，如果长时间不清理，文件会变得特别大，因此需要定期清空，但是日至文件是恢复数据库的重要依据，不用日志文件也是不明智的。手工清除单个数据库的还好说，但数据库多了，或者临时没有来得及清理，可能硬盘空间就会占满了，影响访问。因此设置自动清理数据库日志文件还是比较实用的。

手动清理方法：右键单击需要清理的数据库，选择“属性”，在“选项”卡上，把故障还原模型设定为简单，确定后关闭;再右键单击该数据库，“所有任务”-“收缩数据库”，确认后即可清除日志文件，最后记得重新选择“属性”，将故障还原模型设置为完全。

自动清理方法：同样是利用sql

server代理服务，执行自动作业。

打开企业管理器，进入“管理”-“sql

server代理服务”-“作业”，在右侧窗口点击右键，选择“新建作业”。“常规”选项卡中，填写作业名称，具体描述，注意所有者最好还是用sa或者默认的管理帐号。

转到“步骤”选项卡，新建作业步骤，填写步骤名称，类型为脚本，数据库为需要清理日志的数据库，在下边命令中填写以下命令：

DUMP

TRANSACTION

数据库名称

WITH

NO_LOG

DBCC

SHRINKFILE(数据库日志文件名,1)

上边的数据库名称填写需要维护的数据库名称，数据库日志文件名填写其对应的日志文件名，注意，不是资源管理器里看到的带后缀名的那个名字，而是企业管理器里，数据库属性里日志选项卡中日志的名字(通常也只是差一个后缀名……)，确定后添加一个作业步骤。

如果需要维护多个数据库，用上述方法重复添加作业步骤，注意每个步骤成功或失败后的动作即可，最后选择一下开始的步骤。

在“调度”选项卡中，类似备份的维护计划，填写调度周期，即定期清理的周期，不再细述。如果需要，可以在最后的“通知”选项卡上设置作业完成后的通知项，需要设置 *** 作员，以及设置相应的服务，这里也不具体说明了，通常不用……

以上就是关于SQL Server：无日志恢复数据库全部的内容，包括:SQL Server：无日志恢复数据库、数据库log如何定期log备份、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！