尧图网页设计 
简介这是一款面向SQL Server数据库管理员与运维人员的专业数据恢复工具ApexSQL系列以日志解析和细粒度恢复见长适用于误删数据、表结构损坏、事务日志异常等场景。资源包为绿色便携版解压即可运行共72个文件、整体约21.7MB主要包含程序主控exe、日志解析与恢复引擎dll、运行环境manifest/config以及必要的VC运行库模块划分清晰便于按需调用。已有340人学习下载适合需要快速构建SQL Server应急恢复环境的开发者参考。压缩包内提供ApexSQLLog主程序、联机日志审计组件、离线元数据解析模块及多种界面库可辅助完成日志查看、操作审计与数据还原演练帮助使用者理解常见恢复流程。 上午十点开发同事火急火燎地跑过来“订单表被误删了能恢复吗”我第一反应是问备份结果他挠头说日常只做了完整备份上次备份是三天前。那一瞬间我反而松了一口气——只要数据库是完整恢复模式Full Recovery Model事务日志里就还留着这三天所有的增删改记录这时候就需要ApexSQL这类SQL Server数据恢复工具登场了。我用ApexSQL处理过不少类似的事故误删数据、误更新全表、甚至误放DROP TABLE。它不是那种只能靠全量备份还原的笨办法而是直接解析数据库的事务日志把每一条操作记录“翻译”成人能看懂的SQL语句再反推出一条逆操作脚本把删除的行重新插回去、把误更新的值改回原值。如果你平时写过SQL Server查询对SSMS不陌生那么这篇内容基本就是为你准备的——即使以前没接触过数据恢复也能照着流程把数据捞回来。1. 先搞清楚ApexSQL 到底能帮你恢复什么1.1 不止一个工具ApexSQL 全家桶的分工ApexSQL现在也集成在Quest生态里并不是一个单独的小软件而是一个工具集。很多人一上来就搜“ApexSQL数据恢复工具”其实真正负责恢复的有好几个角色功能边界并不一样工具主要场景我的使用频率ApexSQL Log从事务日志中恢复/审计误操作生成UNDO脚本最高ApexSQL Recover数据库损坏、文件删除后的底层恢复较低ApexSQL CompleteSSMS智能提示插件写SQL时补全与格式化日常高ApexSQL Diff / Data Diff库结构和数据比较、同步高频运维如果你遇到的是“表被误删了几行”“UPDATE把A列全改成了同一个值”多半用ApexSQL Log就够了。如果整个数据库物理文件损坏才需要考虑ApexSQL Recover。至于ApexSQL Data Diff这类同步工具是在恢复后做数据对账时顺手用的我后面会提到。1.2 为什么优先选 ApexSQL Log恢复模式是关键ApexSQL Log能恢复的核心前提是SQL Server数据库处于完整恢复模式Full Recovery Model。这里要解释一个很多人忽略的基础知识SQL Server的日志文件.ldf像一台摄像机的存储卡当你把数据库设为Full后它会持续记录每条修改操作的“底片”。即便是Simple恢复模式日志文件也会短暂记录操作但SQL Server会尽快把无用的日志部分标记为可重用旧日志一旦被覆盖工具就再也读不到那些操作了。所以“能不能恢复”在事故发生前就已经决定了大半。数据库如果设置成Simple模式哪怕你装了再贵的恢复工具也拿不到被截断的日志。同理即便在Full模式下如果你长时间不做日志备份日志文件无限膨胀也可能因为checkpoint和自动收缩机制把可恢复时间窗口搞得很窄。这就是为什么在正式部署时就要把恢复模式、日志备份策略一起定下来而不是等出事了再找工具。2. 事务日志恢复的核心原理你的数据库里其实有个“黑匣子”2.1 一条DELETE语句在日志里留下了什么很多人以为数据库日志存的是“最终结果”其实不是。SQL Server的事务日志记录的是“操作过程”。每次INSERT、UPDATE、DELETE至少会写一条日志记录包含事务ID、操作类型、修改前后的键值、文件号和页号、LSNLog Sequence Number日志序列号等。ApexSQL Log做的事和飞机失事后解读黑匣子类似它逐条读取日志记录把二进制/内部格式翻译成T-SQL语句。比如你执行了DELETE FROM Orders WHERE OrderID 10248;日志里会留下一个删除操作的记录ApexSQL Log会同时生成两条可读脚本Redo脚本重新执行一次DELETE用于重建当时的操作Undo脚本反向操作实际上是一条INSERT语句把10248这行数据补回去。这也是它比“备份还原”优雅的地方不需要停服、不需要覆盖当前库只要日志还在就能精准地把那一条数据捞回来。2.2 日志截断、备份位置与恢复边界那么问题来了日志到底能保存多久答案是看备份节奏和日志重用机制。完整恢复模式会自动记录所有事务但日志文件不会无限增长。当发生下列情况之一日志中的部分记录会被标记为可重用执行了事务日志备份设置了简单恢复模式且发生checkpoint某些操作如TRUNCATE TABLE触发的日志截断即使Full模式也可能降低该点的恢复能力。因此恢复的边界大致是“最近一次事务日志备份之后到日志文件被覆盖/截断之前”。如果你的环境里设置了每15分钟备份一次事务日志那么最坏情况也只能恢复到最后一个日志备份时间点而不是精确到误操作那一刻。不过ApexSQL Log支持读取在线日志和备份文件你可以把多个备份放到一个列表里形成一条完整的日志链然后按时间点过滤事务。这里面还有一个细节如果误操作发生在很久以前而期间的日志已经被覆盖ApexSQL Log会尽量从备份文件链中读取但别指望它能穿越回日志重用之前。所以“日志备份连续性”比“完整备份频率”更关键我甚至很少为这个和开发团队吵架了——因为他们终于明白日志备份不是为了还原而是为了紧急时能用日志恢复。3. 实操从安装到生成回滚脚本3.1 安装前检查SQL Server实例与工具安装先说环境。我之前在一台测试机上装的是SQL Server 2016标准版配好完整恢复模式。如果你还在用旧版本操作逻辑基本一样ApexSQL Log对2008到2022都有支持。安装工具本身很简单官网下载安装包一路Next即可。正式开工前我一般会做三件事确认当前数据库恢复模式SELECT name, recovery_model_desc FROM sys.databases;看到Full字样再继续。如果是Simple先改ALTER DATABASE YourDB SET RECOVERY FULL;注意切换后立刻做一次完整备份否则日志链起点不完整。用SSMS连上实例检查SQL Server服务有没有启用TCP/IP协议——这一步经常被忽略ApexSQL连接本机实例时可能走TCP/IP不开启会连接失败。在“SQL Server配置管理器”里找到对应实例的协议启用TCP/IP后重启服务即可。顺手装一个ApexSQL Complete插件。它是挂在SSMS边上的智能提示不参与恢复但在我临时写查询、查看表结构时特别好用减少手滑写错字段名的情况。3.2 连接实例并加载事务日志启动ApexSQL Log界面很直观左边选择数据源类型右边填服务器名和认证信息。连上实例后选中目标数据库ApexSQL Log会自动列出当前在线日志Online Log。如果你把日志备份文件.trn保存在本地也可以点“Add Backup Files”把备份加进来它会自动按LSN顺序排队。这里我的心得是把Online Log和所有相关备份文件都加载进去别只选一个。恢复工具不是只能看当前日志而是要把从“误操作前最近一次备份”开始的整个日志链拼起来这样时间范围才完整。3.3 定位误操作过滤时间、用户、表和操作类型数据加载完界面会变成一个巨大的事务列表。我先做过滤避免在一堆增删改里大海捞针时间范围误操作前10分钟到当前时间操作类型勾选DELETE或UPDATE取决于场景对象只选目标表比如Orders用户如果知道是谁误操作的可以填登录名。过滤后列表里会剩下几条事务记录。点开某一条下方能看到它对应的原始SQL和Undo SQL。原始SQL就是当时执行的语句Undo SQL则是ApexSQL帮你反向生成的恢复语句。以DELETE为例Undo SQL会是一条INSERT里面带着被删除行所有字段的原值。这时候不要急着复制执行。先点“Open in Query Editor”或者在工具里“Generate Undo Script”把脚本保存成.sql文件。我习惯在目标表名后面加一个临时后缀比如Orders_Recovered先恢复到临时表验证没问题再合并回主表。3.4 生成回滚脚本小心数据类型和主键ApexSQL Log生成的Undo脚本总体是准的但有两个地方一定要手工检查第一WHERE条件是否精确。如果是UPDATE误操作Undo脚本会带着一串WHERE条件把影响范围限定到原来真正更新过的行。但若原表有自增主键或唯一键脚本会比较准确如果原表连主键都没有恢复出来的WHERE可能不够窄执行时容易误伤其他行。所以我每次都会检查脚本里的WHERE段必要时手动加上AND 主键 具体值。第二字段类型转换。SQL Server里存在隐式转换坑特别是“字符串转数字”这种场景。比如某个订单号字段类型是varchar但值是纯数字Undo脚本里可能会出现WHERE OrderNo 1001 AND Amount 1001这类混合比较。看起来没问题但等你的执行计划碰上索引就很可能因为类型转换导致慢查询甚至转换错误。稳妥办法是先把脚本里的条件手工改成显式CAST/ CONVERT例如WHERE CAST(OrderNo AS INT) 1001或者反过来把数字改成NVARCHAR再比较。执行前我的标准动作是在测试库先跑一遍Undo脚本用“影响行数”和“COUNT(*)”核对正式库执行时用事务包裹先执行BEGIN TRAN;跑完立刻SELECT校验确认无误再COMMIT有异常直接ROLLBACK恢复完成后记录操作时间和事务ID方便后续审计。4. 常见问题、避坑技巧与备份兜底4.1 典型问题排查表我把实操中遇到最多的问题整理成了一张表基本覆盖了90%的情况问题现象原因处理方式工具读不到误操作时段恢复模式是Simple日志已被截断切换Full做完整备份日志备份提前设置Online Log能读但恢复时间点不准确缺少误操作前的日志备份日志链断裂把所有.trn备份按顺序加载重新读取权限不足连接失败当前账号不是sysadmin或缺少VIEW SERVER STATE权限用具备sysadmin权限的账号连接Undo脚本执行后影响行数明显偏多表没有主键/唯一键WHERE条件太宽手工加主键条件或恢复临时表后按ID合并恢复工具报“日志已损坏”日志文件被压缩/碎片化/另一实例接管停止服务用只读方式读取当前.ldfSQL Server实例连不上配置管理器里TCP/IP未启用启用TCP/IP重启SQL Server服务4.2 我的三条独家心得第一条不是所有误操作都能靠日志恢复。TRUNCATE TABLE和DROP TABLE这种操作虽然也发生在日志里但ApexSQL Log通常无法直接反推出完整的INSERT脚本因为日志没有记录被删除行的所有原始数据值。这种情况下我只能去还原最近一次完整备份然后做日志尾部恢复或者用ApexSQL Recover这类底层文件恢复工具碰碰运气。所以我在团队规范里强调永远不要用TRUNCATE删业务表要对行级数据操作加审批。第二条恢复不等于还原。很多DBA一遇到事故第一反应是“还原昨天晚上的完整备份”然后业务数据会丢一整天。ApexSQL Log的核心价值是“精准逆转”它能把事故窗口内的事务挑出来只回滚那些错误操作其他正常事务不受影响。这要求我们在恢复前勤做事务日志备份养成“短周期日志备份、长周期完整备份”的组合习惯。第三条工具只能救急日常兜底还得靠自动备份和审计。我推荐在SQL Server Agent里建一个自动化job每天做一次完整备份每15分钟做一次事务日志备份保留最近48小时。出问题之后备份文件按时间点排好再配合ApexSQL Log的备份文件读取功能恢复时间通常能控制在半小时以内。另外我还用ApexSQL的审计功能定期导出一份DDL/DML操作报表哪个用户什么时候改过哪张表一目了然省得每次出事都靠猜。最后再分享一个小技巧在执行任何批量操作前先写一句“影响行数验证”的SQLSELECT COUNT(*) FROM Orders WHERE 你的条件;等工具生成Undo脚本后也先对比一下脚本里事务影响的行数和这个COUNT偏差大就赶紧停手检查。我踩过太多次“脚本跑完发现多恢复了半小时数据”的坑后来所有恢复流程都先走临时表再合并。数据安全这件事工具再强也只是保险丝真正能兜底的是你平时对备份和恢复模式的规划。自从那次“三天无日志备份”的教训后我再也没有相信过“生产库出不了事”这种鬼话。ApexSQL Log在有准备的环境里确实能当后悔药但最好的后悔药永远是你在事故前就做好了完整恢复模式和日志备份配置。本文还有配套的精品资源点击获取 SQL Server误删数据恢复：ApexSQL Log事务日志回滚实战
简介这是一款面向SQL Server数据库管理员与运维人员的专业数据恢复工具ApexSQL系列以日志解析和细粒度恢复见长适用于误删数据、表结构损坏、事务日志异常等场景。资源包为绿色便携版解压即可运行共72个文件、整体约21.7MB主要包含程序主控exe、日志解析与恢复引擎dll、运行环境manifest/config以及必要的VC运行库模块划分清晰便于按需调用。已有340人学习下载适合需要快速构建SQL Server应急恢复环境的开发者参考。压缩包内提供ApexSQLLog主程序、联机日志审计组件、离线元数据解析模块及多种界面库可辅助完成日志查看、操作审计与数据还原演练帮助使用者理解常见恢复流程。 上午十点开发同事火急火燎地跑过来“订单表被误删了能恢复吗”我第一反应是问备份结果他挠头说日常只做了完整备份上次备份是三天前。那一瞬间我反而松了一口气——只要数据库是完整恢复模式Full Recovery Model事务日志里就还留着这三天所有的增删改记录这时候就需要ApexSQL这类SQL Server数据恢复工具登场了。我用ApexSQL处理过不少类似的事故误删数据、误更新全表、甚至误放DROP TABLE。它不是那种只能靠全量备份还原的笨办法而是直接解析数据库的事务日志把每一条操作记录“翻译”成人能看懂的SQL语句再反推出一条逆操作脚本把删除的行重新插回去、把误更新的值改回原值。如果你平时写过SQL Server查询对SSMS不陌生那么这篇内容基本就是为你准备的——即使以前没接触过数据恢复也能照着流程把数据捞回来。1. 先搞清楚ApexSQL 到底能帮你恢复什么1.1 不止一个工具ApexSQL 全家桶的分工ApexSQL现在也集成在Quest生态里并不是一个单独的小软件而是一个工具集。很多人一上来就搜“ApexSQL数据恢复工具”其实真正负责恢复的有好几个角色功能边界并不一样工具主要场景我的使用频率ApexSQL Log从事务日志中恢复/审计误操作生成UNDO脚本最高ApexSQL Recover数据库损坏、文件删除后的底层恢复较低ApexSQL CompleteSSMS智能提示插件写SQL时补全与格式化日常高ApexSQL Diff / Data Diff库结构和数据比较、同步高频运维如果你遇到的是“表被误删了几行”“UPDATE把A列全改成了同一个值”多半用ApexSQL Log就够了。如果整个数据库物理文件损坏才需要考虑ApexSQL Recover。至于ApexSQL Data Diff这类同步工具是在恢复后做数据对账时顺手用的我后面会提到。1.2 为什么优先选 ApexSQL Log恢复模式是关键ApexSQL Log能恢复的核心前提是SQL Server数据库处于完整恢复模式Full Recovery Model。这里要解释一个很多人忽略的基础知识SQL Server的日志文件.ldf像一台摄像机的存储卡当你把数据库设为Full后它会持续记录每条修改操作的“底片”。即便是Simple恢复模式日志文件也会短暂记录操作但SQL Server会尽快把无用的日志部分标记为可重用旧日志一旦被覆盖工具就再也读不到那些操作了。所以“能不能恢复”在事故发生前就已经决定了大半。数据库如果设置成Simple模式哪怕你装了再贵的恢复工具也拿不到被截断的日志。同理即便在Full模式下如果你长时间不做日志备份日志文件无限膨胀也可能因为checkpoint和自动收缩机制把可恢复时间窗口搞得很窄。这就是为什么在正式部署时就要把恢复模式、日志备份策略一起定下来而不是等出事了再找工具。2. 事务日志恢复的核心原理你的数据库里其实有个“黑匣子”2.1 一条DELETE语句在日志里留下了什么很多人以为数据库日志存的是“最终结果”其实不是。SQL Server的事务日志记录的是“操作过程”。每次INSERT、UPDATE、DELETE至少会写一条日志记录包含事务ID、操作类型、修改前后的键值、文件号和页号、LSNLog Sequence Number日志序列号等。ApexSQL Log做的事和飞机失事后解读黑匣子类似它逐条读取日志记录把二进制/内部格式翻译成T-SQL语句。比如你执行了DELETE FROM Orders WHERE OrderID 10248;日志里会留下一个删除操作的记录ApexSQL Log会同时生成两条可读脚本Redo脚本重新执行一次DELETE用于重建当时的操作Undo脚本反向操作实际上是一条INSERT语句把10248这行数据补回去。这也是它比“备份还原”优雅的地方不需要停服、不需要覆盖当前库只要日志还在就能精准地把那一条数据捞回来。2.2 日志截断、备份位置与恢复边界那么问题来了日志到底能保存多久答案是看备份节奏和日志重用机制。完整恢复模式会自动记录所有事务但日志文件不会无限增长。当发生下列情况之一日志中的部分记录会被标记为可重用执行了事务日志备份设置了简单恢复模式且发生checkpoint某些操作如TRUNCATE TABLE触发的日志截断即使Full模式也可能降低该点的恢复能力。因此恢复的边界大致是“最近一次事务日志备份之后到日志文件被覆盖/截断之前”。如果你的环境里设置了每15分钟备份一次事务日志那么最坏情况也只能恢复到最后一个日志备份时间点而不是精确到误操作那一刻。不过ApexSQL Log支持读取在线日志和备份文件你可以把多个备份放到一个列表里形成一条完整的日志链然后按时间点过滤事务。这里面还有一个细节如果误操作发生在很久以前而期间的日志已经被覆盖ApexSQL Log会尽量从备份文件链中读取但别指望它能穿越回日志重用之前。所以“日志备份连续性”比“完整备份频率”更关键我甚至很少为这个和开发团队吵架了——因为他们终于明白日志备份不是为了还原而是为了紧急时能用日志恢复。3. 实操从安装到生成回滚脚本3.1 安装前检查SQL Server实例与工具安装先说环境。我之前在一台测试机上装的是SQL Server 2016标准版配好完整恢复模式。如果你还在用旧版本操作逻辑基本一样ApexSQL Log对2008到2022都有支持。安装工具本身很简单官网下载安装包一路Next即可。正式开工前我一般会做三件事确认当前数据库恢复模式SELECT name, recovery_model_desc FROM sys.databases;看到Full字样再继续。如果是Simple先改ALTER DATABASE YourDB SET RECOVERY FULL;注意切换后立刻做一次完整备份否则日志链起点不完整。用SSMS连上实例检查SQL Server服务有没有启用TCP/IP协议——这一步经常被忽略ApexSQL连接本机实例时可能走TCP/IP不开启会连接失败。在“SQL Server配置管理器”里找到对应实例的协议启用TCP/IP后重启服务即可。顺手装一个ApexSQL Complete插件。它是挂在SSMS边上的智能提示不参与恢复但在我临时写查询、查看表结构时特别好用减少手滑写错字段名的情况。3.2 连接实例并加载事务日志启动ApexSQL Log界面很直观左边选择数据源类型右边填服务器名和认证信息。连上实例后选中目标数据库ApexSQL Log会自动列出当前在线日志Online Log。如果你把日志备份文件.trn保存在本地也可以点“Add Backup Files”把备份加进来它会自动按LSN顺序排队。这里我的心得是把Online Log和所有相关备份文件都加载进去别只选一个。恢复工具不是只能看当前日志而是要把从“误操作前最近一次备份”开始的整个日志链拼起来这样时间范围才完整。3.3 定位误操作过滤时间、用户、表和操作类型数据加载完界面会变成一个巨大的事务列表。我先做过滤避免在一堆增删改里大海捞针时间范围误操作前10分钟到当前时间操作类型勾选DELETE或UPDATE取决于场景对象只选目标表比如Orders用户如果知道是谁误操作的可以填登录名。过滤后列表里会剩下几条事务记录。点开某一条下方能看到它对应的原始SQL和Undo SQL。原始SQL就是当时执行的语句Undo SQL则是ApexSQL帮你反向生成的恢复语句。以DELETE为例Undo SQL会是一条INSERT里面带着被删除行所有字段的原值。这时候不要急着复制执行。先点“Open in Query Editor”或者在工具里“Generate Undo Script”把脚本保存成.sql文件。我习惯在目标表名后面加一个临时后缀比如Orders_Recovered先恢复到临时表验证没问题再合并回主表。3.4 生成回滚脚本小心数据类型和主键ApexSQL Log生成的Undo脚本总体是准的但有两个地方一定要手工检查第一WHERE条件是否精确。如果是UPDATE误操作Undo脚本会带着一串WHERE条件把影响范围限定到原来真正更新过的行。但若原表有自增主键或唯一键脚本会比较准确如果原表连主键都没有恢复出来的WHERE可能不够窄执行时容易误伤其他行。所以我每次都会检查脚本里的WHERE段必要时手动加上AND 主键 具体值。第二字段类型转换。SQL Server里存在隐式转换坑特别是“字符串转数字”这种场景。比如某个订单号字段类型是varchar但值是纯数字Undo脚本里可能会出现WHERE OrderNo 1001 AND Amount 1001这类混合比较。看起来没问题但等你的执行计划碰上索引就很可能因为类型转换导致慢查询甚至转换错误。稳妥办法是先把脚本里的条件手工改成显式CAST/ CONVERT例如WHERE CAST(OrderNo AS INT) 1001或者反过来把数字改成NVARCHAR再比较。执行前我的标准动作是在测试库先跑一遍Undo脚本用“影响行数”和“COUNT(*)”核对正式库执行时用事务包裹先执行BEGIN TRAN;跑完立刻SELECT校验确认无误再COMMIT有异常直接ROLLBACK恢复完成后记录操作时间和事务ID方便后续审计。4. 常见问题、避坑技巧与备份兜底4.1 典型问题排查表我把实操中遇到最多的问题整理成了一张表基本覆盖了90%的情况问题现象原因处理方式工具读不到误操作时段恢复模式是Simple日志已被截断切换Full做完整备份日志备份提前设置Online Log能读但恢复时间点不准确缺少误操作前的日志备份日志链断裂把所有.trn备份按顺序加载重新读取权限不足连接失败当前账号不是sysadmin或缺少VIEW SERVER STATE权限用具备sysadmin权限的账号连接Undo脚本执行后影响行数明显偏多表没有主键/唯一键WHERE条件太宽手工加主键条件或恢复临时表后按ID合并恢复工具报“日志已损坏”日志文件被压缩/碎片化/另一实例接管停止服务用只读方式读取当前.ldfSQL Server实例连不上配置管理器里TCP/IP未启用启用TCP/IP重启SQL Server服务4.2 我的三条独家心得第一条不是所有误操作都能靠日志恢复。TRUNCATE TABLE和DROP TABLE这种操作虽然也发生在日志里但ApexSQL Log通常无法直接反推出完整的INSERT脚本因为日志没有记录被删除行的所有原始数据值。这种情况下我只能去还原最近一次完整备份然后做日志尾部恢复或者用ApexSQL Recover这类底层文件恢复工具碰碰运气。所以我在团队规范里强调永远不要用TRUNCATE删业务表要对行级数据操作加审批。第二条恢复不等于还原。很多DBA一遇到事故第一反应是“还原昨天晚上的完整备份”然后业务数据会丢一整天。ApexSQL Log的核心价值是“精准逆转”它能把事故窗口内的事务挑出来只回滚那些错误操作其他正常事务不受影响。这要求我们在恢复前勤做事务日志备份养成“短周期日志备份、长周期完整备份”的组合习惯。第三条工具只能救急日常兜底还得靠自动备份和审计。我推荐在SQL Server Agent里建一个自动化job每天做一次完整备份每15分钟做一次事务日志备份保留最近48小时。出问题之后备份文件按时间点排好再配合ApexSQL Log的备份文件读取功能恢复时间通常能控制在半小时以内。另外我还用ApexSQL的审计功能定期导出一份DDL/DML操作报表哪个用户什么时候改过哪张表一目了然省得每次出事都靠猜。最后再分享一个小技巧在执行任何批量操作前先写一句“影响行数验证”的SQLSELECT COUNT(*) FROM Orders WHERE 你的条件;等工具生成Undo脚本后也先对比一下脚本里事务影响的行数和这个COUNT偏差大就赶紧停手检查。我踩过太多次“脚本跑完发现多恢复了半小时数据”的坑后来所有恢复流程都先走临时表再合并。数据安全这件事工具再强也只是保险丝真正能兜底的是你平时对备份和恢复模式的规划。自从那次“三天无日志备份”的教训后我再也没有相信过“生产库出不了事”这种鬼话。ApexSQL Log在有准备的环境里确实能当后悔药但最好的后悔药永远是你在事故前就做好了完整恢复模式和日志备份配置。本文还有配套的精品资源点击获取