impdp时不报错地hang住
Import: Release 11.2.0.2.0 - Production on Wed Jan 22 12:27:27 2014
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
Master table "SYS"."IMPDP_FWY" successfully loaded/unloaded
Starting "SYS"."IMPDP_FWY": /******** AS SYSDBA parfile=impdp.par
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
. . imported "GBSMIS"."GM_ACCOUNT_MAIN" 20.37 GB 114580038 rows
. . imported "GBSMIS"."GM_CLAIM_SETTLED_BACKUP" 7.775 GB 24464956 rows
. . imported "GBSMIS"."GM_CLAIM_LIAB_CAL" 7.287 GB 27262351 rows
. . imported "GBSMIS"."GM_CLAIM_DOCU" 7.030 GB 24851389 rows
. . imported "GBSMIS"."GM_POL_MAIN_BACKUP" 3.896 GB 7287304 rows
. . imported "GBSMIS"."GM_POL_FEE_TABLE" 2.791 GB 16147645 rows
. . imported "GBSMIS"."GM_ANNUITY_ACHIEVE_INTF_NEW" 1.289 GB 16874511 rows
. . imported "GBSMIS"."GM_CLAIM_SCENE_CAL" 881.9 MB 2457482 rows
. . imported "GBSMIS"."GM_MANAGE_FEE_SUM" 14.71 MB 291045 rows
. . imported "GBSMIS"."PAYMENT_COMPANY_CARD_TABLE" 13.74 MB 113421 rows
. . imported "GBSMIS"."GM_UNDWRTTIMES" 5.596 MB 59175 rows
. . imported "GBSMIS"."GM_SYNC_ICSS_IPRS_COMMON" 1012. KB 2352 rows
. . imported "GBSMIS"."GM_DEPARTMENT_TABLE" 391.7 KB 4464 rows
. . imported "GBSMIS"."GM_DEPARTMENT_TABLE_NEW" 391.7 KB 4464 rows
. . imported "GBSMIS"."GM_DEPTFLAG" 10.13 KB 36 rows
. . imported "GBSMIS"."GM_THREE_DEPARTMENT" 318.2 KB 4424 rows
. . imported "GBSMIS"."GM_SYNC_ICSS_IPRS_QUESTION" 612.5 KB 9529 rows
. . imported "GBSMIS"."EXISTING_TRANSFER_CLIENT_PREM" 471.0 KB 4327 rows
. . imported "GBSMIS"."GM_SYNC_ICSS_IPRS_BUSINESS" 194.8 KB 2352 rows
. . imported "GBSMIS"."EXISTING_TRANSFER_CLIENT" 63.66 KB 1204 rows
. . imported "GBSMIS"."GM_LIAB_ITEM_TBL" 12.93 KB 86 rows
Processing object type TABLE_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
到Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX时hang住了，最大的表是20G，为其建索引虽慢，也用不着一晚都没完呀。
网上搜索了一下，说impdp时开并行可能遇到了bug，好吧我绕过它，我把parallel=4删掉。
重新发起，等了好几个小时后仍然在这里hang住了，看来不是parallel的问题。
登陆数据库看情况。
从datapump的视图看来，导入是正常运行的。
SQL> @datapump
-- dba_datapump_sessions
OWNER_NAME JOB_NAME INST_ID SADDR SESSION_TYPE
------------------------------ ------------------------------ ---------- ---------------- --------------
SYS IMPDP_FWY 1 0000000728748330 DBMS_DATAPUMP
SYS IMPDP_FWY 1 000000072C7B0918 MASTER
SYS IMPDP_FWY 1 000000073C7FEFC8 WORKER
-- dba_datapump_jobs
OWNER_NAME JOB_NAME OPERATION JOB_MODE STATE DEGREE ATTACHED_SESSIONS DATAPUMP_SESSIONS
------------------------------ ------------------------------ ------------------------------------------------------------ ------------------------------------------------------------ ------------------------------
---------- ----------------- -----------------
SYS IMPDP_FWY IMPORT FULL EXECUTING 1 1 3
看下我导入的用户，sys用户，在等什么。
SQL> @waitbyusr sys
--V$SESSION_WAIT displays the current or last wait for each session.
--@sid 19,25,232
SID EVENT 等待时间 STATE STATUS WAIT_CLASS
----- ------------------------------ ------------------------------ ------------------- -------- ----------------------------------------------------------------
721 wait for unread message on bro 已等1秒 WAITING ACTIVE Idle
adcast channel
993 wait for unread message on bro 已等1秒 WAITING ACTIVE Idle
adcast channel
网上搜了下这个等待，结合我的Impdp，好像也没啥线索。
从后台attach这个job登陆
Worker 1 Status:
Process Name: DW00
State: EXECUTING
Object Schema: GBSMIS
Object Name: IDX_GM_ACCOUNT_MAIN_LCD
Object Type: TABLE_EXPORT/TABLE/INDEX/INDEX
Completed Objects: 1
Worker Parallelism: 1
显示的确是在建索引IDX_GM_ACCOUNT_MAIN_LCD，因为是DDL语句，没建完我也不能从数据库层面看他是否存在以及是否在增长。
此时一切看来正常，难道我还得在等一晚上？
看到process name是DW00，再登陆到数据库中。
SQL> select * from v$process where program like ‘%DW00%‘;
ADDR PID SPID PNAME USERNAME SERIAL# TERMINAL PROGRAM TRACEID TRACEFILE BACKGROUND LATCHWAIT LATCHSPIN PGA_USED_MEM PGA_ALLOC_MEM PGA_FREEABLE_MEM PGA_MAX_MEM
---------------- ---------- ------------------------ ----- -------------------- ---------- ------------------------------ ------------------------------------------------ --------------------------------------------------------------------------------
-------------------------------------------------------------------------------- ---------- ---------------- ---------------- ------------ ------------- ---------------- -----------
000000075C5AA808 63 16224 DW00 otzj11g 47 UNKNOWN oracle@cnsh281003 (DW00) /paic/stg/oracle/11g/app/oracle/diag/rdbms/molapstg/molapstg/trace/molapstg_dw00 1 65156820 1187400836 1120534528 1187400836
这个DW00并不是DBWR进程。
DBW0 是dbwr进程,写datafile用的.
DW0是datapump worker进程,给 impdp/expdp用的.
通过spid16224可以得到会话sid是1009
SQL> @sidbyspid 16224
SID
-----
1009
SQL>
看看1009会话在等什么。
SQL> @waitbysid 1009
--V$SESSION_WAIT displays the current or last wait for each session.
--@sid 19,25,232
SID EVENT 等待时间 STATE STATUS WAIT_CLASS
----- ------------------------------ ------------------------------ ------------------- -------- ----------------------------------------------------------------
1009 statement suspended, wait erro 已等0秒 WAITING ACTIVE Configuration
r to be cleared
SQL>
statement suspended, wait erro to be cleared等待，此时百度一搜，惜分飞的文章映入眼帘，顿时春暖花开。
是因为表空间不足，所以hang住了。此时看了下表空间，是足够的，是表空间所在的asm dg已经满了。
所以申请存储扩diskgroup，搞定。