详解Expdp/Impdp三种性能诊断方法--如何有效定位瓶颈?

概述

在导出导入过程中,偶尔会遇到一些性能问题,可以会因主机资源,数据库版本,PSU版本,datapump本身bug等原因导致。

这里首先可根据需求判断是在哪个环节出问题,导出/导入元数据还是数据时出现性能问题;是否是导出/导入特定对象遇到性能问题?

对于这些问题,MOS上提供了如下3种诊断方法(只演示第三种):

方法一

在expdp/imdp命令中添加参数METRICS=Y TRACE=480300 (或者 480301 捕获SQL trace) 并重新运行expdp/impdp

方法二

对DataPump Master (DM) 和 Worker (DW)进程启用level 12的10046 trace

-- 版本>= 11g and < 12c  
SQL> alter system set events 'sql_trace {process : pname = dw | pname = dm} level=12';  
-- 版本= 12c  
SQL> alter system set events 'sql_trace {process: pname = dw | process: pname = dm} level=12'; 
然后用参数METRICS = Y加入命令行启动expdp/impdp 

方法三:(推荐)

1、查看运行的DataPump 导出进程

connect / as sysdba  
set lines 350 pages 400 numwidth 7  
col program for a38  
col username for a10  
col spid for a7  
select to_char(sysdate, 'YYYY-MM-DD HH24:MI:SS') "DATE", 
 s.program, 
 s.sid, 
 s.status, 
 s.username, 
 d.job_name, 
 p.spid, 
 s.serial#, 
 p.pid 
 from v$session s, v$process p, dba_datapump_sessions d 
 where p.addr = s.paddr 
 and s.saddr = d.saddr 
 and (UPPER(s.program) LIKE '%DM0%' or UPPER(s.program) LIKE '%DW0%'); 

2、跟踪已经开始运行的DataPump 导出进程

--确认Data Pump Worker SID 和 SERIAL#(例如. 对于 DM 和DW 进程), 以level 12跟踪 Master/Worker 进程 (bind和wait信息): 
SQL> exec sys.dbms_system.set_ev (SID, SERIAL#, 10046, 12, ''); 

说明:

DM00是Data Pump Master Process 
The Data Pump master (control) process is started during job creation and coordinates all tasks performed by the Data Pump job. It handles all client interactions and communication, establishes all job contexts, and coordinates all worker process activities on behalf of the job. 
数据泵主(控制)过程在作业创建期间启动,并协调数据泵作业执行的所有任务。 它处理所有客户端交互和通信,建立所有作业上下文,并代表作业协调所有工作进程活动。 
DW00是Data Pump Worker Process 
The Data Pump worker process is responsible for performing tasks that are assigned by the Data Pump master process, such as the loading and unloading of metadata and data. 
Data Pump工作进程负责执行由Data Pump主进程分配的任务,例如元数据和数据的加载和卸载。 

3、结束跟踪

等待一段时间 (至少1 小时) 以捕获足够的信息。

--结束跟踪 
SQL> exec sys.dbms_system.set_ev (SID, SERIAL#, 10046, 0, ''); 

对于所有方法,DataPump Master 和Worker trace文件都被写到BACKGROUND_DUMP_DEST 或者/trace。

4、捕获trace文件

SQL> show parameter BACKGROUND_DUMP_DEST; 
SQL> select * from v$diag_info WHERE name='Default Trace File'; 

以上为MOS提供的诊断方法,可灵活的使用,查询出DataPump进程的SID后可以查询是否有会话阻塞,异常等待事件是什么?

比如由于“StreamsAQ: enqueue blocked on low memory”等待事件导致expdp / impdp命令出现严重性能问题,是因为Bug 27634991引起的(在版本19.1及更高版本中修复了)。

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章