impdp ORA-39002,ORA-39166,ORA-39164的問題及解決
今天在做imp和impdp的效能測試時,發現如果表中存在lob欄位,載入真是慢的厲害,每秒鐘大概1000條的樣子,按照這種速度,基本上不用幹活了。
比如5千萬條記錄,50000000/1000/60/60=13.89小時,時間是無法接受的。
所以嘗試使用impdp來看看效能的提升。
匯出的表裡面有9千萬條記錄,而且做了分割槽,分割槽大概有300個。如果使用全表匯出匯入,在之前的測試中,測試5千萬資料,大概會有3個多小時,也算是比較長的時間,而且隨著資料量的增大,時間還會不斷的增長。
個人嘗試從分割槽的角度做些工作。
匯出分割槽,然後按照分割槽匯入。
使用的impdp命令如下,已經做了remap_schema,但是不管怎麼嘗試,都會丟擲如下的錯誤。事實上這個分割槽是存在的。
impdp mig_test/mig_test directory=memo_dir dumpfile=par1_mo1_memo.dmp logfile=par1_mo1_memo_imp.log tables=mig_test.mo1_memo:P9_A0_E5 TABLE_EXISTS_ACTION=append REMAP_SCHEMA=prdappo:MIG_TEST DATA_OPTIONS=SKIP_CONSTRAINT_ERRORS
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORA-39002: invalid operation
ORA-39166: Object MIG_TEST.MO1_MEMO was not found.
ORA-39164: Partition MIG_TEST.MO1_MEMO:P9_A0_E5 was not found.
嘗試了各種方法。還是沒有效果。最後檢視metalink找到了一些思路。(Doc ID 550200.1)
Or:
2. Be sure to include the schema name in TABLES parameter so the correct table can be found to import from user/to user referenced in REMAP_SCHEMA, ie
最後嘗試使用如下的命令,終於有反應了,分割槽裡竟然還是空的。:)
impdp mig_test/mig_test directory=memo_dir dumpfile=par1_mo1_memo.dmp logfile=par1_mo1_memo_imp.log tables=prdappo.mo1_memo:P9_A0_E5 remap_schema=prdappo:mig_test TABLE_EXISTS_ACTION=append DATA_OPTIONS=SKIP_CONSTRAINT_ERRORS
Master table "MIG_TEST"."SYS_IMPORT_TABLE_01" successfully loaded/unloaded
Starting "MIG_TEST"."SYS_IMPORT_TABLE_01": mig_test/******** directory=memo_dir dumpfile=par1_mo1_memo.dmp logfile=par1_mo1_memo_imp.log tables=prdappo.mo1_memo:P9_A0_E5 remap_schema=prdappo:mig_test TABLE_EXISTS_ACTION=append DATA_OPTIONS=SKIP_CONSTRAINT_ERRORS
Processing object type TABLE_EXPORT/TABLE/TABLE
Table "MIG_TEST"."MO1_MEMO" exists. Data will be appended to existing table but all dependent metadata will be skipped due to table_exists_action of append
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
. . imported "MIG_TEST"."MO1_MEMO":"P9_A0_E5" 0 KB 0 rows
Job "MIG_TEST"."SYS_IMPORT_TABLE_01" successfully completed at 17:23:04
比如5千萬條記錄,50000000/1000/60/60=13.89小時,時間是無法接受的。
所以嘗試使用impdp來看看效能的提升。
匯出的表裡面有9千萬條記錄,而且做了分割槽,分割槽大概有300個。如果使用全表匯出匯入,在之前的測試中,測試5千萬資料,大概會有3個多小時,也算是比較長的時間,而且隨著資料量的增大,時間還會不斷的增長。
個人嘗試從分割槽的角度做些工作。
匯出分割槽,然後按照分割槽匯入。
使用的impdp命令如下,已經做了remap_schema,但是不管怎麼嘗試,都會丟擲如下的錯誤。事實上這個分割槽是存在的。
impdp mig_test/mig_test directory=memo_dir dumpfile=par1_mo1_memo.dmp logfile=par1_mo1_memo_imp.log tables=mig_test.mo1_memo:P9_A0_E5 TABLE_EXISTS_ACTION=append REMAP_SCHEMA=prdappo:MIG_TEST DATA_OPTIONS=SKIP_CONSTRAINT_ERRORS
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORA-39002: invalid operation
ORA-39166: Object MIG_TEST.MO1_MEMO was not found.
ORA-39164: Partition MIG_TEST.MO1_MEMO:P9_A0_E5 was not found.
嘗試了各種方法。還是沒有效果。最後檢視metalink找到了一些思路。(Doc ID 550200.1)
CAUSE
Unlike fromuser/touser and tables functionality in traditional imp, DataPump assumes that if TABLES parameter does not include schema name then the table is owned by current user doing import and will not find correct table to import unless the user doing import is same user which owns the tables in export dump and has IMP_FULL_DATABASE role so that user can import into other schemas.SOLUTION
1. Either grant IMP_FULL_DATABASE to user which owns the objects in the export dump so that user can import into other schema referenced REMAP_SCHEMA and run DataPump import as that schema, ie
SQL> grant IMP_FULL_DATABASE to old_user;
impdp old_user/passwd TABLES=TABLEA:TABLEA_PARTITION1 /
REMAP_SCHEMA=old_user:new_user DUMPFILE=exp01.dmp,exp02.dmp,exp03.dmp /
DIRECTORY=data_pump_dir
impdp old_user/passwd TABLES=TABLEA:TABLEA_PARTITION1 /
REMAP_SCHEMA=old_user:new_user DUMPFILE=exp01.dmp,exp02.dmp,exp03.dmp /
DIRECTORY=data_pump_dir
Or:
2. Be sure to include the schema name in TABLES parameter so the correct table can be found to import from user/to user referenced in REMAP_SCHEMA, ie
impdp system/passwd TABLES=old_user.TABLEA:TABLEA_PARTITION1 /
REMAP_SCHEMA=old_user:new_user DUMPFILE=exp01.dmp,exp02.dmp,exp03.dmp /
DIRECTORY=data_pump_dir
REMAP_SCHEMA=old_user:new_user DUMPFILE=exp01.dmp,exp02.dmp,exp03.dmp /
DIRECTORY=data_pump_dir
最後嘗試使用如下的命令,終於有反應了,分割槽裡竟然還是空的。:)
impdp mig_test/mig_test directory=memo_dir dumpfile=par1_mo1_memo.dmp logfile=par1_mo1_memo_imp.log tables=prdappo.mo1_memo:P9_A0_E5 remap_schema=prdappo:mig_test TABLE_EXISTS_ACTION=append DATA_OPTIONS=SKIP_CONSTRAINT_ERRORS
Master table "MIG_TEST"."SYS_IMPORT_TABLE_01" successfully loaded/unloaded
Starting "MIG_TEST"."SYS_IMPORT_TABLE_01": mig_test/******** directory=memo_dir dumpfile=par1_mo1_memo.dmp logfile=par1_mo1_memo_imp.log tables=prdappo.mo1_memo:P9_A0_E5 remap_schema=prdappo:mig_test TABLE_EXISTS_ACTION=append DATA_OPTIONS=SKIP_CONSTRAINT_ERRORS
Processing object type TABLE_EXPORT/TABLE/TABLE
Table "MIG_TEST"."MO1_MEMO" exists. Data will be appended to existing table but all dependent metadata will be skipped due to table_exists_action of append
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
. . imported "MIG_TEST"."MO1_MEMO":"P9_A0_E5" 0 KB 0 rows
Job "MIG_TEST"."SYS_IMPORT_TABLE_01" successfully completed at 17:23:04
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-1185290/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- impdp 10g/11g問題解決
- ORA-39002和ORA-39166報錯處理和探究
- 常見問題及解決
- 奇怪的登入問題及解決
- impdp操作產生大量UNDO的原因及解決方法
- Git常見問題及解決Git
- Harbor搭建及配置 問題解決
- 跨域問題及解決方案跨域
- redis安裝及問題解決Redis
- 常見問題及解決方案
- CAS導致的ABA問題及解決
- IPython的安裝及問題解決Python
- Kafka常見的問題及解決方案Kafka
- 解決「問題」,不要解決問題
- 近期工作遇到的問題及解決方式收藏
- nodejs 近期所遇到的問題及解決NodeJS
- JS中toFixed()方法的問題及解決方案JS
- 裝SAP GUI時遇到的問題及解決GUI
- Nacos 常見問題及解決方法
- UltraEdit常見問題及解決教程
- Homestead 使用問題及解決方式
- Segments by ITL Waits 問題及解決AI
- WordPress:常見問題及解決方案
- 多執行緒的安全問題及解決方案執行緒
- vue渲染時閃爍{{}}的問題及解決方法Vue
- Xcode 10.1 新特性及解決的問題XCode
- 代理伺服器的連線問題及解決伺服器
- 資料倉儲的效能問題及解決之道
- ArrayList的使用及ConcurrentModificationException問題解決Exception
- linux kernel引發的oracle問題及解決LinuxOracle
- redis 安裝及安裝遇到的問題解決Redis
- Oracle 常見的錯誤問題及解決方法Oracle
- 問卷調查中常見問題及解決方法
- 快取常見問題及解決方案快取
- 快取三大問題及解決方案快取
- 爬蟲常見問題及解決方式爬蟲
- Fabric 環境搭建遇到問題及解決
- WIN 8.1使用常見問題及解決