impdp时不报错地hang住
2020-11-09
来源：筏尚旅游网
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
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，搞定。显示全文