金仓数据库KingbaseES数据恢复方案
有一种惨，叫做人还在，数据没了
对，说的就是我......
大家好，我叫王大锤，一个平平无奇的IT打工人，就职于一家创业公司。
说起来是创业公司，其实主要业务是为一家北美商务公司提供电子商务平台开发和运维的外包服务。
作为一名初窥门径的数据库DBA，我深知数据备份的重要性。毕竟，小到病毒，电源故障乃至意外操作失误，大到自然灾害，都会影响系统的正常运行，甚至造成系统完全瘫痪。因此，机智如我，对正在开发和维护的电子商务平台数据库每周一备，力图做到有备无患。
可万万没想到，数据丢失的鬼故事依旧上演了，而我正是故事的主角......
电子商务平台使用了IBM的Informix数据库。这款数据库在美国还算流行，它运行稳定，性能也很不错。公司的CTO对这款数据库很是喜欢，可能这和他之前的美国留学经历有关吧。但这款数据库在国内使用的人数不是很高，网上实用的资料更是少之又少。
因此，相关的数据库运维知识只能靠自学。好在我勤学苦练，之前公司也出现过由于服务器磁盘损坏而导致的数据库故障，但均被我通过备份数据进行恢复，其间未丢失任何数据。工作之余，我也常常在笔记本上使用Informix数据库模拟数据演练，运用基于时间点的恢复将数据库恢复到数据被破坏前的时刻，熟练数据还原操作，以备不时之需。
然而，就在系统准备上线试运行的前一天，有研发人员反馈，数据库的一个表不见了，希望我尽快通过备份找回表数据。
作为创意小王子，我立即就有了一个*的idea，这不就是我平时玩的基于指定时间点的不完全恢复嘛，解决这个问题so easy。
我当即尝试使用onbar工具进行基于指定时间点的数据恢复，可是恢复的结果不尽如人意，不是依旧找不到丢失的表，就是所找到的表中的数据不完整。
与平时演练完全不同（我在删除表时记录了操作时间），此时的我完全不清楚丢失的表究竟是什么时候被删除的！
通过几次数据恢复操作，可以确定在昨天下午15点时表还存在，但在凌晨12点时，这个表已经丢失了。通过不停地恢复尝试（每次约半小时），可以缩小表被删除的时间范围。但问题关键在于，此时已经没有更多的时间让我慢慢尝试了。测试团队希望能在5个小时内解决这个问题，否则后续的一些测试工作将无法完成。
没有困难的工作，只有勇敢的打工人
在我发觉仅凭个人能力无法在短短5小时之内找回丢失的数据表后，我决定寻求外援。然而，询遍同学及大学老师，都没有得到可行的解决办法，这个数据库在国内的用户很少，我的大学老师甚至都没用过。上网查询解决方法，有网友说可以通过审计日志查看表的删除时间，可Informix的审计功能有140多项，当时看的我头大，根本来不及配置审计。
难道我的数据库DBA生涯要尽毁于此？
万万没想到，最终，我还是得到了高人的帮助。
危急之时，我想起了参加培训时认识的金仓工程师——夏洛克·福尔摩斯·K，便抱着病笃乱投医的心态尝试求助。没想到，在了解我的情况之后，福尔摩斯·K很快回应了我的难题。他让我先将表被删除那段时间的逻辑日志提取出来备用，然后我们开始一起分析定位Informix表被删除的精确时间。
与福尔摩斯·K联合确定解决方案
对于事务型数据库，通常都会有逻辑日志，用于记录数据库的各种操作。数据库系统在执行DDL操作时，都会操作系统表。数据库系统的逻辑日志中会记录全部的DML操作，可以通过分析对系统表的DELETE操作，来分析用户执行的实际的DDL操作。
通过与福尔摩斯·K近50分钟的电话沟通，我们初步确定如下方案：
1. 根据表的大概丢失时间段，初步确定需要分析的逻辑日志文件。
2. 使用onlog工具，将待分析的逻辑日志文件内容由二进制转化为文本格式，方便后续分析。
3. 过滤逻辑日志文本中包含HDELETE关键字的行，提取行中的表ID数据。
4. 使用oncheck工具，将表ID转换为实际的表名称。
5. 定位表名称为systables的行，记录该行的表ID。
6. 查找关键字包含HDELETE和表ID行，并输出该行的前后各n行记录。
7. 查找搜索结果中包含被删除表名称的行。找到信息后，在该行的前面查找包含BEGIN关键字的行，该行即为删除表的事务的开始记录行。在该记录行中，包含了事务的开始时间，这个时间就是表被删除时的精确时间。
福尔摩斯·K的方案验证
根据与福尔摩斯·K沟通的解决方案，我开始在自己的笔记本上进行技术验证。
模拟现场环境
首先编写脚本，模拟在Informix数据库mydb中删除t_user表的场景。
在上面测试中，用户在2022-05-09 16:49:16和2022-05-09 16:49:20之间，删除了t_user表。
在测试中，我需要找出最后一个逻辑日志文件，用于分析t_user表的精确删除时间。通过onstat命令可以看到，当前的逻辑日志文件的uniqid为18。
在下面的操作中，将演示如何分析这个逻辑日志文件中的内容，查询到删除表的精确时间。
使用逻辑日志，分析表的精确删除时间
1) 转换逻辑日志为文本格式
使用onlog命令将逻辑日志文件转换为文本格式，并输出到文件中。
2) 通过关键字搜索，确定要分析的表ID
通过过滤HDELETE关键字，查询出要分析的表ID。
得到的表ID会有重复，可以在去重后，用于后续的表名称分析。
使用oncheck解析出表名称，确定系统表对应的表ID
说明：上面数据为十六进制，在用oncheck分析时，需要加上0x。
根据上面的结果，使用oncheck确定4个表的名称。
命令会输出表名称，内容如下：
我们需要关注的是指定数据库mydb下的systables表。对于上面的结果，我们需要的表ID为0x80004b。详细信息见下面：
4) 根据系统表ID分析删除表的事务数据
本例中，用户删除了t_user表。需要查找80004b和HDELETE两个关键字附近中包含t_user的信息。下面的命令演示查询同时包含80004b和HDELETE两个关键字行，并输出该行的前后各10行信息（可根据实际情况适当增加）。
在本示例中，我们只查询到一行数据，并输出了该记录的前后各10行记录。通过分析输入的文本信息，可以看到该行信息的后面包含了t_user表的名称，说明该行即为删除t_user表的信息。在该行的前面，对应BEGIN关键字的行，为该事务的开始信息，其中包含了该事务的开始时间（05/09/2022 16:49:18）。
烦恼随风而逝，数据成功找回
联合解决方案令我拍案叫绝，通过和前面测试执行DROP TABLE时记录的时间（2022-05-09 16:49:16到2022-05-09 16:49:20）对比，得到实际执行DROP TABLE的时间（2022-05-09 16:49:18）完全正确。
验证方案正确后，我迅速通过脚本，对多个逻辑日志文件进行筛选并进行文本转换。
幸运的是，表被删除的那段时间，电子商务平台操作业务虽然非常多，但执行删除表的操作很少。通过对5个逻辑日志文件的分析，很快就精确定位了删除表的精确时间，并顺利找回了被删除表的全部数据，我司的电子商务平台也如期上线运行。
看到KingbaseES的数据恢复能力，我彻底服了
福尔摩斯·K的分析问题能力令我为之钦服。作为一名好学上进的青年，在问题复盘之时，亦不免对金仓数据库心驰神往。对于此类的表删除问题，在金仓数据库中应该如何去精确定位表的删除时间呢？
福尔摩斯·K告诉我，在金仓数据库中，虽然也可以通过分析日志来确定表的删除时间，并恢复数据。但此类方案的处理时间通常较长（整库的不完全恢复所涉及的数据量太大，在恢复数据并导出后，还需再进行一次数据库的完全恢复，并合并被删除的数据，因此耗时较长）。对于线上业务，过长的停机时间不仅会给企业带来严重的经济损失，而且会产生负面的社会影响，降低企业信誉。金仓数据库KingbaseES为解决这一难题，实现了数据库闪回功能，可将表删除的恢复时间由数小时缩短至分钟级。
在金仓数据库KingbaseES中使用闪回功能，只需要在kingbase.conf配置一个参数即可。
福尔摩斯·K给我做了一个演示。
他先创建两个表，并插入测试数据。
然后删除t_user表，并在t_goods表中继续插入数据。
金仓数据库KingbaseES提供了一个视图，可以查询出表的删除信息。
如果我们需要了解表的精确删除时间，可以直接查询recyclebin视图，快速得到表的精确删除时间。
相比Informix数据库的日志分析确定表删除时间方法，这简直太便捷了。然而更方便的还在后面。
通过闪回（flashback）这一特性，恢复被删除的表，根本无需了解表的精确删除时间，只需要在命令中指定before drop关键字即可。而且，不同于使用基于时间点的不完全恢复，使用flashback只恢复了这个被删除的表及其数据，对于在删除表之后进行的业务操作，则完全不受闪回操作的影响。
看了福尔摩斯·K的介绍，我深感自身能力不足，目前无法胜任公司的DBA一职，希望继续深造提升自我，于是决定向公司的CTO辞职。
我的生涯一片无悔， 我想起那天夕阳下的奔跑，那是我逝去的青春......
后记
大家好，我叫王大锤。
万万没想到，公司CTO对我的工作表示高度地认可，并极力地挽留我。他诚恳地表示是他自己的工作不到位，才会导致此类问题发生。
在CTO极力地挽留和高度地认可下，我还是留在了公司。
虽然现在电子商务平台已经成功上线，但后面随着业务增长，还会面临更多的困难。CTO希望我尽快调研，后续将电子商务平台迁移到我们有能力运维的数据库平台上。出于对福尔摩斯·K的信任和感激，我率先调研了人大金仓KingbaseES这款数据库：
1. KingbaseES在数据保护上，做了很多工作。不但有常规的备份与恢复，更提供了类似坏块自动修复功能，时刻保护数据安全。对于用户表被误删除此类问题，可通过闪回特性直接快速恢复，减少对业务的影响和用户损失。
2. 支持集群部署，当电子商务平台业务增长时，可以通过扩展集群节点，满足不断增长的业务要求。
3. 集群实现高可用，当服务器或操作系统出现故障时，可以自动进行节点切换，更好的支持电子商务平台的可用性需求。可以滚动升级，在不停止业务的情况下，更换服务器硬件，升级操作系统或升级集群组件。通过用户实际的验证，KingbaseES集群的高可用达99.999%。
4. 完善的技术支持体系，不但可以及时、高效解决客户问题，更可为客户规划方案，支撑客户不断发展的业务需求。
5. 免费的KCA/KCP培训，方便我们构建自己的技术支持团队。
6. 有KDMS、KDTS工具，方便将其它数据库业务迁移到KingbaseES中。借助KFS，更可实现业务的无停机平滑迁移。
在金仓数据库KingbaseES这款利器的帮助之下，相信用不了多久我就会升职加薪，当上总经理，出任CEO，迎娶白富美，走向人生*。想想，还有点小激动呢！