在資料庫故障排查中,最棘手的問題莫過於多個應用程式同時存取同一筆資料時的交互影響。雖然每個應用程式本身邏輯正確,但彼此對資料的假設不同,導致資料列在毫無預警的情況下發生變更甚至消失。傳統做法是在重現問題時傾印資料,或使用 Log Miner 分析歸檔日誌,但操作繁瑣且效率低落。
Oracle 10g 引入了 閃回版本查詢,這項功能依賴自動撤銷管理與撤銷表空間,能完整保留資料列的歷史映像,讓您像瀏覽版本控制系統一樣查詢資料的演變過程,操作比 Log Miner 直觀得多。
語法置於 FROM 表名 之後、表別名之前:
VERSIONS BETWEEN { SCN | TIMESTAMP }
{ expr | MINVALUE } AND { expr | MAXVALUE }
這使得查詢中的每個物件都能在不同的時間點呈現不同版本。需注意:最遠只能回溯到 UNDO_RETENTION 參數指定的保留時間,或最近一次 DDL 操作(CREATE/ALTER/DROP)之前,以先到者為準。
假設兩位員工在 PARTS 表中針對同一零件描述反覆修改,雙方都以為自己的變更未被儲存,實則互相覆蓋。透過閃回版本查詢即可還原真相:
SELECT part_id, description,
VERSIONS_STARTSCN, VERSIONS_STARTTIME,
VERSIONS_ENDSCN, VERSIONS_ENDTIME,
VERSIONS_XID, VERSIONS_OPERATION
FROM parts
VERSIONS BETWEEN TIMESTAMP MINVALUE AND MAXVALUE
WHERE part_id = 'P-100';
關鍵偽欄位說明:
若需進一步識別「是誰在何時提交了變更」,可搭配 閃回交易查詢。先取得目標資料列的 ROWID,再查詢 FLASHBACK_TRANSACTION_QUERY 視圖:
SELECT XID, START_SCN, START_TIMESTAMP, COMMIT_SCN, COMMIT_TIMESTAMP,
LOGON_USER, UNDO_SQL
FROM FLASHBACK_TRANSACTION_QUERY
WHERE XID = HEXTORAW('版本查詢取得的 VERSIONS_XID');
注意:視圖中的 ROW_ID 欄位僅為普通欄位,並非 ROWID 偽欄位。
閃回版本查詢與閃回交易查詢強強聯手,讓 DBA 與開發人員無需傾印資料、無需複雜的 Log Miner 設定,即可快速定位資料異變的源頭、時間與責任人,大幅縮短故障排查週期。