昨晚一條SQL更新了整個表

背景

在系統(tǒng)運(yùn)營中，經(jīng)常會有一些業(yè)務(wù)變更，需要直接更新表中的一些數(shù)據(jù)。最近我們遇到了一件棘手的生產(chǎn)事件，開發(fā)同事本來要更新表中的很少一部分?jǐn)?shù)據(jù)，但是由于UPDATE SQL編寫問題，將整個表的一個字段進(jìn)行了更新。SQL大概是長這樣的：

開發(fā)同事原意是希望根據(jù)tab_tmp b表的字段更新tab_order a 表的字段status值為'01'，但是由于exists里面不應(yīng)該再次出現(xiàn)tab_order c導(dǎo)致子查詢恒為真，全表的字段被更新。這么大量的表數(shù)據(jù)更新，將會導(dǎo)致不低于刪庫跑路的嚴(yán)重后果。

有幾個信息同步一下：數(shù)據(jù)庫是Oracle。tab_order 有1億行數(shù)據(jù)，表大小30G。undo表空間30G左右。更新動作執(zhí)行了40分鐘。

處理方案

處理誤更新數(shù)據(jù)我們有幾種方式：事務(wù)未結(jié)束，直接rollback

Oracle的事務(wù)是手動提交的，可能有挽回余地，因為修改的數(shù)據(jù)量較多，回滾時間會比較長。其它類型數(shù)據(jù)庫大部分是自動提交的，我們可以通過顯示打開事務(wù)的方式進(jìn)行操作。

2.使用閃回查詢

如果你的事務(wù)已經(jīng)提交了，那么可以優(yōu)先考慮閃回查詢恢復(fù)。當(dāng)數(shù)據(jù)庫undo表空間足夠，undo_retention保留時間足夠長，是可能會查到修改前的原數(shù)據(jù)的。

閃回查詢真的很好用，目前oracle、tidb、oceanbase等數(shù)據(jù)庫有這個功能的。

3.使用LogMinner挖掘日志，執(zhí)行undo sql恢復(fù)

如果閃回查詢無法查詢到數(shù)據(jù)，報錯ORA-01555，而且能準(zhǔn)確知道修改了多少行數(shù)據(jù)的情況下，可以優(yōu)先考慮LogMinner恢復(fù)原數(shù)據(jù)。LogMinner主要依托于挖掘DML SQL執(zhí)行期間生成的redo log中的原值來恢復(fù)數(shù)據(jù)，在LogMinner挖掘后日志后會看到 undo sql（回滾sql）可以用來直接恢復(fù)數(shù)據(jù)。

Mysql 的binlog 中記錄了新舊值，需要通過工具生成回滾SQL。

4.使用備份恢復(fù)異機(jī)恢復(fù)表，導(dǎo)出、導(dǎo)入恢復(fù)

本次恢復(fù)由于幾個方面因素不滿足，我們使用了最終的異機(jī)備份恢復(fù)的方案。異機(jī)恢復(fù)過程中，涉及的表空間較多，為了快速恢復(fù)表，我采取了部分恢復(fù)的方式，加速了表導(dǎo)出的過程。

鹽城數(shù)據(jù)恢復(fù)

總結(jié)

上面的4種方案，由上到下依次恢復(fù)成本增加，相關(guān)經(jīng)驗可以參考借鑒。

札記：“成長的經(jīng)歷會告訴你:每天早起五分鐘，人生將被賦予另一種可能!每天多付出一點努力，一天不見回報，一個月不見回報，一年不見回報但十年一定會有所回報的”。

南通數(shù)據(jù)恢復(fù)