今天將一個測試庫中的數據導到另一個測試庫中，遇到了ORA-31623和ORA-06512錯誤，以下是大致過程的記錄：
源庫為10.2.0.3 64bit，目標庫為新裝的11.2.0.4 64bit，采用expdp方式開4個並行，並按schema的方式來導出數據，語句為：
expdp system/oracle parallel=4 directory=exppump dumpfile=sisver_20150831_%u.DMP schemas=sc1,sc2 logfile=expdp_sisver_20150831.log
導出沒有什么問題，16g左右的數據大概在10分鍾完成，然后將生成的4個DMP文件ftp到目標端，再通過IMPDP導入，以下是導入語句：
impdp system/oracle parallel=4 remap_schema=sc1:sc1new,sc2:sc2new directory=impdppump remap_tablespace=sc1tbs:sc1newtbs,sc2tbs:sc2newtbs dumpfile=sisver_20150831_%u.DMP full=y cluster=no logfile=impdp_sisver_20150831.log
導入前還做好了准備工作，如：在測試庫建好相應的表空間和用戶，設置用戶權限、設置用戶默認表空間、分配對默認表空間的quota等，
當然其實只要創建表空間就可以了，因為使用remap_schema時會自動創建相應用戶。
當在目標端進行導入的時候，就遇到了點問題：
Import: Release 11.2.0.4.0 - Production on Mon Aug 31 13:10:00 2015
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
UDI-31623: operation generated ORACLE error 31623
ORA-31623: a job is not attached to this session via the specified handle
ORA-06512: at "SYS.DBMS_DATAPUMP", line 3326
ORA-06512: at "SYS.DBMS_DATAPUMP", line 4551
ORA-06512: at line 1
開始以為是版本的問題，因為源端是10g的庫，而目標端是11g的庫，但其實只有在exp方式導出的時候可能需要考慮加上version參數導出，expdp是不需要的
然后又想到是不是因為system用戶是否對directory沒有權限，但對相應的directory加上read,write權限后，依然報相同的錯，於是查看了一下alert日志：
[oracle@sisdb:~]tail -100f /oracle/diag/rdbms/siststdb/siststdb/trace/alert_siststdb.log
Mon Aug 31 13:01:37 2015
Errors in file /oracle/diag/rdbms/siststdb/siststdb/trace/siststdb_ora_43843686.trc (incident=36272):
ORA-04031: unable to allocate 56 bytes of shared memory ("streams pool","unknown object","streams pool","fixed allocation callback")
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Mon Aug 31 13:01:40 2015
Sweep [inc][36272]: completed
Mon Aug 31 13:01:51 2015
Errors in file /oracle/diag/rdbms/siststdb/siststdb/trace/siststdb_ora_43843690.trc (incident=48001):
ORA-04031: unable to allocate 56 bytes of shared memory ("streams pool","unknown object","streams pool","fixed allocation callback")
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Mon Aug 31 13:02:20 2015
Errors in file /oracle/diag/rdbms/siststdb/siststdb/trace/siststdb_ora_327938.trc (incident=48002):
ORA-04031: unable to allocate 56 bytes of shared memory ("streams pool","unknown object","streams pool","fixed allocation callback")
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Mon Aug 31 13:02:40 2015
Sweep [inc][48002]: completed
Sweep [inc][48001]: completed
Mon Aug 31 13:10:00 2015
Errors in file /oracle/diag/rdbms/siststdb/siststdb/trace/siststdb_ora_42205274.trc (incident=36281):
ORA-04031: unable to allocate 56 bytes of shared memory ("streams pool","unknown object","streams pool","fixed allocation callback")
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Mon Aug 31 13:10:01 2015
Sweep [inc][36281]: completed
在alert日志中發現，在執行IMPDP導入的時候，數據庫報了ORA-04031的錯誤，我們都知道這是和SGA內存相關的一個報錯，
而且后面很清楚的提示了是由於SGA中的一個組件“stream pool”出現了內存不足，使用IMPDP竟然還會用到流池，這個是我沒有想到的，
一直以為只有用sream和AQ技術時才會使用到流池，那么再來看一下流池的大小：
SQL> set line 200 pages 200
SQL> select * from v$sgainfo;
NAME BYTES RES
-------------------------------- ---------- ---
Fixed SGA Size 2263488 No
Redo Buffers 9707520 No
Buffer Cache Size 134217728 Yes
Shared Pool Size 436207616 Yes
Large Pool Size 0 Yes
Java Pool Size 16777216 Yes
Streams Pool Size 0 Yes
Shared IO Pool Size 0 Yes
Granule Size 16777216 No
Maximum SGA Size 8551575552 No
Startup overhead in Shared Pool 363476736 No
Free SGA Memory Available 7952400384
由於這個庫安裝的時候只設置了MEMORY_MAX_TARGET=9G，而未設置SGA_TARGET（即，SGA_TARGET=0，不采用10g的內存自動管理）
和MEMORY_TARGET的值（即，也未采用了11g的ASMM方式），因此流池默認大小也是0
SQL> show parameter memory
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
hi_shared_memory_address integer 0
memory_max_target big integer 9G
memory_target big integer 0
shared_memory_address integer 0
SQL> show parameter sga
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 8G
sga_target big integer 0
SQL> select name,issys_modifiable from v$parameter where name like '%pool%';
NAME ISSYS_MOD
-------------------------------------------------------------------------------- ---------
shared_pool_size IMMEDIATE
large_pool_size IMMEDIATE
java_pool_size IMMEDIATE
streams_pool_size IMMEDIATE
shared_pool_reserved_size FALSE
buffer_pool_keep FALSE
buffer_pool_recycle FALSE
global_context_pool_size FALSE
olap_page_pool_size DEFERRED
SQL>
可以看到，streams_pool_size的issys_modifiable的值是“IMMEDIATE”，說明是動態參數（無須重啟數據庫生效），那么就手動分配給它一個值，我給了100M
SQL> alter system set streams_pool_size=100m scope=both;
System altered.
SQL> select * from v$sgainfo;
NAME BYTES RES
-------------------------------- ---------- ---
Fixed SGA Size 2263488 No
Redo Buffers 9707520 No
Buffer Cache Size 134217728 Yes
Shared Pool Size 436207616 Yes
Large Pool Size 0 Yes
Java Pool Size 16777216 Yes
Streams Pool Size 117440512 Yes
Shared IO Pool Size 0 Yes
Granule Size 16777216 No
Maximum SGA Size 8551575552 No
Startup overhead in Shared Pool 363476736 No
Free SGA Memory Available 7834959872
SQL>
后來還是不行，內存太小了，報錯如下：
是shared pool太小了設置為 320m，可以增加 shared pool 的大小為2G。
現在再來試一下剛才的導入命令，發現已經可以順利執行下去了
[oracle@sisdb:~]impdp system/oracle parallel=4remap_schema=sc1:sc1new,sc2:sc2newdirectory=impdppumpremap_tablespace=sc1tbs:sc1newtbs,sc2tbs:sc2newtbsdumpfile=sisver_20150831_%u.DMP full=y cluster=no logfile=impdp_sisver_20150831.log
Import: Release 11.2.0.4.0 - Production on Mon Aug 31 13:32:07 2015
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_FULL_01": system/******** parallel=4 remap_schema=cpibusi:cpibusitst,picsbusi:picsbusitst directory=impdppump remap_tablespace=CPIDATATBS:cpibusitsttbs,PICSDATATBS:picsbusitsttbs dumpfile=ccicver_20150831_%u.DMP full=y cluster=no logfile=impdp_ccicver_20150831.log
Processing object type SCHEMA_EXPORT/USER
ORA-31684: Object type USER:"PICSBUSITST" already exists --由於是先創建了用戶才執行的IMPDP導入，因此可以忽略
ORA-31684: Object type USER:"CPIBUSITST" already exists
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
. . imported "SC1NEW"."T_CPIMAIN_EXTEND" 604.1 MB 289303 rows
. . imported "SC1NEW"."T_CPIPROFIT_DETAIL" 316.8 MB 2286932 rows
......(略)
由於11g中加強了DATA PUMP在告警日志中的信息，此時繼續跟蹤alert日志可以發現，當增加了sreams pool的內存后，成功啟動了DM進程，開始進行導入操作了：
Mon Aug 31 13:31:13 2015
ALTER SYSTEM SET streams_pool_size='100M' SCOPE=BOTH;
Mon Aug 31 13:32:08 2015
DM00 started with pid=37, OS id=50593928, job SYSTEM.SYS_IMPORT_FULL_01
Mon Aug 31 13:32:09 2015
DW00 started with pid=38, OS id=31654248, wid=1, job SYSTEM.SYS_IMPORT_FULL_01
Mon Aug 31 13:32:18 2015
DW01 started with pid=39, OS id=19071422, wid=2, job SYSTEM.SYS_IMPORT_FULL_01
Mon Aug 31 13:32:18 2015
DW02 started with pid=40, OS id=40501314, wid=3, job SYSTEM.SYS_IMPORT_FULL_01
Mon Aug 31 13:32:18 2015
DW03 started with pid=41, OS id=29163926, wid=4, job SYSTEM.SYS_IMPORT_FULL_01
XDB installed.
XDB initialized.
Mon Aug 31 13:32:22 2015
Thread 1 advanced to log sequence 10 (LGWR switch)
Current log# 1 seq# 10 mem# 0: /oradata/siststdb/redo01.log
Mon Aug 31 13:32:27 2015
Archived Log entry 2 added for thread 1 sequence 9 ID 0xffffffff80ef0332 dest 1:
Thread 1 cannot allocate new log, sequence 11
Private strand flush not complete
Current log# 1 seq# 10 mem# 0: /oradata/siststdb/redo01.log
Thread 1 advanced to log sequence 11 (LGWR switch)
Current log# 2 seq# 11 mem# 0: /oradata/siststdb/redo02.log
Mon Aug 31 13:32:30 2015
Archived Log entry 3 added for thread 1 sequence 10 ID 0xffffffff80ef0332 dest 1:
Mon Aug 31 13:32:38 2015
最后用了13分鍾左右，完成了sc1new和sc2new這2個schema的導入，最后來看一下導入結果
SQL> select owner,tablespace_name,round(sum(bytes/1024/1024/1024),2) "Size(Gb)" from dba_segments where owner in ('SC1NEW','SC2NEW ') group by owner,tablespace_name;
OWNER TABLESPACE_NAME Size(Gb)
------------------------------ ------------------------------ ----------
SC1NEW SC1NEWTBS 15.39
SC2NEW SC2NEWTBS 1.09
可以看到，16g的數據都已經導入了目標端的測試環境，任務順利完成。
思路：
遇到 4031，首先增加共享池，然后再增加 streams pool 、large pool 等資源。