使用impdp不當導致的資料丟失問題
今天有個朋友問我們一個問題,說他在使用了impdp匯入資料的時候,使用了TABLE_EXISTS_ACTION=REPLACE這個選項,結果現在資料都給覆蓋了。現在沒有備份,想問問能不能做相應的恢復操作。
對於這個選項,自己看著熟悉,不過很少用到,碰到了這個問題,首先想到的就是閃回。
不過也不能敷衍,自己在本地做了一個測試,想看看閃回的效果怎麼樣。首先簡單模擬了一下這個問題。
conn n1/n1
SQL> create directory oradmp as '/home/ora11g/oradmp'; --建立目錄
SQL> grant read,write on directory oradmp to test; --賦予目錄許可權
SQL>create table test as select *from cat; --建立一個表test
然後嘗試匯出
[ora11g@oel1 oradmp]$ expdp n1/n1 dumpfile=a.dmp directory=oradmp tables=test
Export: Release 11.2.0.1.0 - Production on Thu Apr 9 14:13:33 2015
。。。
Starting "N1"."SYS_EXPORT_TABLE_01": n1/******** dumpfile=a.dmp directory=oradmp tables=test
. . exported "N1"."TEST" 5.476 KB 4 rows
Master table "N1"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
******************************************************************************
然後在測試使用者中也建立一個表test,只有一條資料。
SQL> create table test as select *from cat;
SQL> select count(*)from test;
COUNT(*)
----------
1
然後嘗試匯入,啟用TABLE_EXISTS_ACTION的選項
[ora11g@oel1 oradmp]$ impdp test/test dumpfile=a.dmp TABLE_EXISTS_ACTION=replace directory=oradmp
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORA-31655: no data or metadata objects selected for job
ORA-39154: Objects from foreign schemas have been removed from import
Master table "TEST"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "TEST"."SYS_IMPORT_FULL_01": test/******** dumpfile=a.dmp TABLE_EXISTS_ACTION=replace directory=oradmp
Job "TEST"
發現報了ORA錯誤,初步以為可能是11.2.0.1.0 的bug導致的,在公司64位的環境上模擬了一下,還是能夠復現。在MOS上查了下,文章Doc ID 1341446.1給出瞭解決方法,就是新增remap_schema即可。
再次匯入就沒有問題了。
impdp test/test dumpfile=a.dmp directory=oradmp TABLE_EXISTS_ACTION=replace remap_schema=n1:test
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "TEST"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "TEST"."SYS_IMPORT_FULL_01": test/******** dumpfile=a.dmp directory=oradmp TABLE_EXISTS_ACTION=replace remap_schema=n1:test
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
. . imported "TEST"."TEST" 5.476 KB 4 rows
Job "TEST"."SYS_IMPORT_FULL_01" successfully completed at 15:42:42
這個時候先來看看回收站裡的是否有原來的表,結果show recycle沒有查到任何東西。因為不確定replace的實際範圍,可能有truncate+insert,delete+insert,drop+create,自己使用閃回檢視了一下。
select versions_starttime v_starttime,versions_startscn v_startscn,versions_xid xid,versions_endtime
vendtime,versions_endscn vendscn,versions_operation oper,table_name from test
versions between scn minvalue and maxvalue;
裡面有4條記錄,都是匯入之後的資料,匯入之前的資料就丟失了。
至於show recyclebin中為什麼沒有drop後的表,自己又嘗試新建一個表,做drop操作就沒有問題。
SQL> show recycle
ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME
---------------- ------------------------------ ------------ -------------------
TEST1 BIN$E0Tq5KcMjSTgUKjAghtd2w==$0 TABLE 2015-04-09:14:40:03
所以這個時候就有些疑惑,檢視官方文件,文件中提到這個replace是一個drop+create的操作,如果這個時候回收站中還是沒有drop之前的表,只能說明是使用drop table test purge這樣的形式了。
但這個僅僅是猜想,怎麼驗證呢,可以開trace。
impdp本身有個trace選項,但是這個選項在--help中沒有提到。
自己試了下,能夠生成部分的trace,但是和自己的預期還是有差距。
我使用的trace如下。
impdp test/test dumpfile=a.dmp directory=test_dmp TABLE_EXISTS_ACTION=replace remap_schema=n1:test trace=4a0300
開啟trace的時候很可能報出下面的錯誤,只要賦予imp_full_database的許可權即可,可以在匯入之後回收許可權。
[ora11g@oel1 oradmp]$ impdp test/test dumpfile=a.dmp directory=test_dmp TABLE_EXISTS_ACTION=replace remap_schema=n1:test trace=4a0300
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORA-31631: privileges are required
SQL> grant imp_full_database to test;
Grant succeeded.
日誌生成了,得到的是一些呼叫dbms_datapump的語句,沒有找到drop相關的操作。
嘗試了10046,也貌似沒有生效。
最後來試試logon trigger吧,透過這個來設定10046得到的資訊還是很全的。
CREATE OR REPLACE TRIGGER set_trace_on_logon
AFTER LOGON ON DATABASE
BEGIN
if ( user not in ('SYS','SYSTEM' )) then
EXECUTE IMMEDIATE 'alter session set statistics_level=ALL';
EXECUTE IMMEDIATE 'alter session set max_dump_file_size=UNLIMITED';
EXECUTE IMMEDIATE 'alter session set tracefile_identifier='''||user||'_10046''';
EXECUTE IMMEDIATE 'alter session set events ''10046 trace name context forever, level 12''';
end if;
END set_10046_trace_on_logon;
/
直接透過grep來看看效果。發現執行的是一個drop cascade constraints purge選項。
[ora11g@oel1 trace]$ grep PURGE *
TEST11G_dm00_31816_TEST_10046.trc:DROP TABLE "TEST"."SYS_IMPORT_FULL_01" PURGE
TEST11G_dw00_31818_TEST_10046.trc:DROP TABLE "TEST"."TEST" CASCADE CONSTRAINTS PURGE
TEST11G_j001_12582.trc:*** ACTION NAME:(PURGE_LOG) 2015-04-08 18:00:00.378
所以能夠證明這個purge選項直接徹底清空了表和資料。
這樣的話,只能使用一些非常規手段來 恢復資料了,這個時候可以考慮使用DUL這個工具了。國內也有幾個牛人有自己的工具,ODU來嘗試了。
ODU的使用還是需要花些功夫的。可以參考下面的連結來試試。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-1561717/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 關於 iconv 轉碼導致資料丟失的問題
- cassandra tombstone導致寫資料丟失問題徵解
- Oracle全部索引丟失導致的效率問題處理Oracle索引
- 儲存互斥失敗導致資料丟失的資料恢復成功案例資料恢復
- memory_target設定不當導致資料庫無法啟動的問題資料庫
- 磁碟損壞導致資料檔案丟失的恢復
- 儲存崩潰導致資料丟失如何處理
- dfm檔案資料丟失問題
- 資料庫統計資訊不更新導致的效能問題資料庫
- 重灌系統導致分割槽丟失的資料恢復案例資料恢復
- 關閉資料庫會導致cache的sequence值丟失嗎?資料庫
- 伺服器當機會導致Kafka訊息丟失嗎伺服器Kafka
- Google Drive存在未知故障,導致部分使用者丟失雲盤資料Go
- Verdaccio publish 時包含 deprecated 導致歷史版本丟失問題原因分析
- rman恢復:資料檔案丟失,控制檔案丟失,聯機日誌檔案丟失(非當前使用與當前使用)
- Django資料庫連線丟失問題Django資料庫
- 【epoll問題】EPOLLRDHUP使用導致無法接受資料
- 一條sql語句導致的資料庫當機問題及分析SQL資料庫
- 一條sql語句“導致”的資料庫當機問題及分析SQL資料庫
- 關於Cordova框架對URL攔截導致通訊丟失問題的處理框架
- 使用資料庫處理併發可能導致的問題資料庫
- stream pool設定過小導致impdp失敗
- 【raid資料恢復案例】raid擴容導致的資料丟失的資料恢復AI資料恢復
- 伺服器不同的故障導致資料丟失都怎麼解決的伺服器
- 【資料庫資料恢復】斷電導致Oracle資料庫資料丟失的資料恢復案例資料庫資料恢復Oracle
- git合併丟失程式碼問題分析與解決(錯誤操作導致)Git
- 虛擬化還原快照導致資料丟失恢復過程
- EVA4400儲存斷電導致資料丟失如何恢復
- Elasticsearch如何保證資料不丟失?Elasticsearch
- ORACLE資料檔名導致的奇怪問題Oracle
- 【儲存資料恢復】esx vmfs的互斥導致儲存資料丟失的資料恢復案例資料恢復
- Nginx轉發導致請求頭丟失Nginx
- 伺服器資料恢復-誤操作導致mysql資料庫資料丟失的資料恢復案例伺服器資料恢復MySql資料庫
- “alter database switchover to xx“過程不當導致的primary-primary 雙主問題Database
- 用資料庫指令碼重建了資料庫,導致資料丟失,還能找回來麼?資料庫指令碼
- Oracle impdp遷移資料後主鍵丟失故障處理Oracle
- SAN LUN Mapping出錯導致的資料丟失恢復全過程APP
- 【北亞資料庫資料恢復】誤操作導致資料丟失的華為雲mysql資料恢復案例資料庫資料恢復MySql