impdp时不报错地hang住

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，搞定。