impdp导入卡住,等待事件wait for unread message on broadcast channel

简介: impdp导入卡住,等待事件wait for unread message on broadcast channel

现象

Oracle 11.2.0.4 impdp导入数据,卡了很久不动,也不报错。

先说明我的问题吧:

我的环境是因为导入中包含了一个大的表,且该表包含CLOB字段,而CLOB占用了40G的空间,又因为是11.2.0.4的环境对CLOB导出导入有bug,所以特别慢。具体可以参考:https://www.xmmup.com/oracle-11-2-0-4-expdpdaochuhanclobziduanbasicfiledebiaochaojimandewenti.html

原因

一般造成该问题的原因有两种:出现可能是假死或者导入对象为大对象CLOB,造成表象为卡顿的现象。

判断是否彻底卡住了,可以通过如下几种办法:

1、查询表空间大小是否有变化,参考:https://www.xmmup.com/oracle-11gchaxunbiaokongjiandaxiao.html

2、通过ATTACH,进去后输入status命令进行查看:

impdp \'/ AS SYSDBA\'  ATTACH=SYS_IMPORT_FULL_01


-- 例如
Worker 1 Status:
  Process Name: DW00
  State: EXECUTING                      
  Object Schema: ABCLOGY
  Object Name: WORKFLOW_ABCLOG
  Object Type: SCHEMA_EXPORT/TABLE/TABLE_DATA
  Completed Objects: 1
  Completed Rows: 22,368,372
  Completed Bytes: 12,104,771,848
  Percent Done: 69
  Worker Parallelism: 1

3、查询v$session_longops视图获取进度:

SET LINE 9999  PAGESIZE 9999
col username format a10
col OSUSER format a10
col target format a20
col opname format a30
col WAIT_CLASS format a20
col wait_event format a30
col message format a80
col SQL_TEXT format a100
col sofar_TOTALWORK format a20
col session_info format a15
col progress format a8

SELECT a.USERNAME,
       (SELECT upper(nb.OSUSER) FROM v$session nb WHERE nb.SID = a.sid) OSUSER, 
       (SELECT nb.sid || ',' || nb.SERIAL# || ',' || pr.SPID
          FROM v$process pr, v$session nb
         WHERE nb.PADDR = pr.ADDR
           and nb.sid = a.SID
           and nb.SERIAL# = a.SERIAL#) session_info,
       a.opname,
       to_char(a.START_TIME, 'YYYY-MM-DD HH24:MI:SS') start_time,
       round(a.SOFAR * 100 / a.TOTALWORK, 2) || '%' AS progress,
       a.TIME_REMAINING  TIME_REMAINING,
       a.elapsed_seconds elapsed_seconds,
       message message,
       (SELECT nb.EVENT FROM V$session_Wait nb WHERE nb.SID = a.SID) wait_event,
       (SELECT nb.STATUS FROM v$session nb WHERE nb.SID = a.SID) STATUS
  FROM v$session_longops a
 WHERE a.time_remaining <> 0
 ORDER BY status, a.TIME_REMAINING DESC, a.SQL_ID, a.sid;

解决

WAITEVENT: "wait for unread message on broadcast channel" Reference Note (文档 ID 170464.1)

The Oracle process is waiting for a message on a broadcast channel. This is normally an idle wait - the process is waiting for an AQ message on a subscribed queue.

This event is classed as an "idle" wait so should be ignored when looking at systemwide timings. See <<61998.1>> for more information about "IDLE" waits.

该等待事件是由于oracle进程在请求message时出现等待,该等待是空闲(idle)等待,并且可以忽略

总结

1、首先需要弄懂是不是真的卡住了,还是导入非常慢。若是11.2.0.4的版本,表含有大的CLOB字段,则做导出操作会非常慢,这是一个bug,参考:https://www.xmmup.com/ruhetigaoshujubengdecaozuoxingneng.html#11204han_you_da_declob_zi_duan

2、别忘记检查告警日志,查看是否某个表空间满了或是闪回恢复区满了等问题。

目录
相关文章
|
7月前
【Bug】ERROR ResizeObserver loop completed with undelivered notifications.
【Bug】ERROR ResizeObserver loop completed with undelivered notifications.
|
7月前
|
SQL
oralce wait event
oralce wait event
33 1
|
7月前
|
Windows
如何在关闭socket连接的时候跳过TIME_WAIT的等待状态
如何在关闭socket连接的时候跳过TIME_WAIT的等待状态
104 0
|
Java Spring
Redisson BUG: Failed to submit a listener notification task. Event loop shut down?
Redisson BUG: Failed to submit a listener notification task. Event loop shut down?
1457 0
|
SQL Oracle NoSQL
gdb调试之--read by other session 等待事件的重现
发生read by other session 等待事件,肯定是两个会话同时物理读同一个数据块,假设有两个会话,会话1发生物理读,会话2正要去物理读发现会话1正在物读理产生,此时会话2发生等待,此等待就是read by other session 等待事件。
|
弹性计算 网络协议 Java
记一次time_wait & close_wait的讨论总结
记一次time_wait & close_wait的讨论总结
记一次time_wait & close_wait的讨论总结
|
数据采集 网络协议
一次TIME_WAIT和CLOSE_WAIT故障和解决办法
昨天解决了一个curl调用错误导致的服务器异常,具体过程如下: 里头的分析过程有提到,通过查看服务器网络状态检测到服务器有大量的CLOSE_WAIT的状态。   在服务器的日常维护过程中,会经常用到下面的命令:   它会显示例如下面的信息: TIME_WAIT 814CLOSE_WAIT 1FIN_WAIT1 1ESTABLISHED 634SYN_RECV 2LAST_ACK 1 常用的三个状态是:ESTABLISHED 表示正在通信,TIME_WAIT 表示主动关闭,CLOSE_WAIT 表示被动关闭。
2711 0