有一種慘，叫做人還在，數據沒了
對，說的就是我......
大家好，我叫王大錘，一個平平無奇的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，迎娶白富美，走向人生巔峰。想想，還有點小激動呢！
