文章详情广告pc

如何科学的诊断exp导出问题

余毅
原创 78       2018-11-07  


exp做导出时可能遇到各种问题,往往都是通过现象关联过往经验来排错,本篇希望用更科学的方法来跟踪exp问题过程,找到问题的关键。


(一)  对于所有exp问题提供:


A. 用于完成export的完整命令,包括参数文件内容(如果使用了的话)。
B. Exp的日志文件
C. 当执行export时完整的数据库alert.log
D. 提供以下问题的答案:

1) Exp问题何时发生的 ?
2) 以前是否正常?

3) 最近有打过数据库或者操作系统补丁吗?

4) 是否在数据库或者系统层面做过改动?

 

(二) 在执行export过程中遇到错误,则需要完成并收集以下内容:


A. 对以下问题提供是/否的答案:
1) 任何类型的export都会失败, 例如 schema, full, table ?
2) 使用rows=n export也会失败?
 
B. 如果发生了一个ORA-nnnnn,并且我们没有Oracle自动生成的跟踪文件,那么配置一个系统范围的“触发”类型事件来收集跟踪文件,如下所示:

SQL> CONN / AS SYSDBA
SQL> ALTER SYSTEM SET EVENTS '<error code> trace name errorstack level 12';
SQL> ALTER SYSTEM set MAX_DUMP_FILE_SIZE= unlimited ;
                                                                              
重新执行
                                 
SQL> ALTER SYSTEM SET EVENTS '<error code> trace name errorstack off';
                                                                              
注意
- 当使用ALTER SYSTEM SET EVENTS命令时,只有新的会话才能启用这个命令设置的事件。
- 将错误号替换为遇到的错误号(不含字符串'ORA-')。
例如,如果遇到ORA-00904,设置跟踪的命令是:alter system set events '904 trace name ERRORSTACK level 12';
 

然后从由user_dump_destdiagnostic_dest参数指定的目录找到产生的trace或发给DBA


C. 收集以下SQL脚本的spool文件

SQL> connect / as sysdba

SQL> @srdc_exp_error.sql

 

(三) 如果在exp执行过程中遇到hang或性能问题,需要完成和收集以下内容:


A. 对以下问题提供是/否的答案:
1) 如果使用direct = y,是否有改进?
2) 数据结构是否改变或数据量增加了?
3) 是否只有特定对象遇到性能问题? 如果是,则提供对象名称。
 

B. 如下所述生成并收集exportSQL trace

1) 通过在命令行执行命令来启动export shadow进程
   $ exp username/password
(在下面的步骤
 
2) 识别shadow进程ospid
   $ ps -ef | grep exp
或者使用
   SQL> SELECT p.spid,p.addr,p.pid,s.sid,SUBSTR(s.username,1,15) "USERNAME",SUBSTR(s.program,1,15) "PROGRAM"
        FROM v$process p,v$session s
        WHERE s.paddr=p.addr
        AND addr=(SELECT paddr FROM v$session WHERE UPPER(program) LIKE 'EXP%');
 
3) 通过sqlplus, 使用 oradebug附加到 (O)SPID, 设置trace文件大小为unlimited 并打开level 1210046 event
   SQL> oradebug setospid xxx   (xxx = ospid)
   SQL> oradebug unlimit
   SQL> oradebug Event 10046 trace name context forever, level 12
 
4) 通过回复export会话中的交互问题来启动export
 
5) 对于hang问题,让export运行至少1小时。 对于性能问题等待导出完成,并停止trace
   SQL> oradebug Event 10046 trace name context off;
 
6) 找到生成的trace文件
   SQL> oradebug tracefile_name
 
C. 收集问题发生时的AWR 信息。
SQL> CONNECT / AS SYSDBA
SQL> @?/rdbms/admin/awrrpt.sql
 
D. 在问题发生时运行脚本srdc_exp_performance.sql

SQL> connect / as sysdba
SQL> @srdc_exp_performance.sql
--等待10分钟
SQL> @srdc_exp_performance.sql
--等待10分钟
SQL> @srdc_exp_performance.sql
收集三个 SRDC_EXP_PERFORMANCE_*.htm spool 文件
 
SQL> connect / as sysdba
SQL> set long 20000
SQL> select owner,object_type,data_object_id from dba_objects where object_name='<OBJECT_NAME>';
SQL> select dbms_metadata.get_ddl('<OBJECT_TYPE>','<OBJECT_NAME>','<SCHEMA_NAME>') from dual;

 

 

(四) 案例分析


新时代证券北京中心切换到上海中心后,使用hstool备份hs_asset非常慢,花了1个半小时,而相同数据量在北京中心只要28分钟

 

根据上述诊断计划


A. 拿到代码
select object_name from hsobjects where object_type in ('U', 'T') order by object_name; --表名取这个语句取出来的
    exp + User + '/' + Password
      + '@' + 实例名
      + ' file=' + 'XXX.fdm'
      + ' tables=(' 表名 ')'
      + ' log=' + 'XXX.fdm.out'
      + ' compress=n'

可以看到并没有特别参数


B. 针对导出从头开始跟踪:
oradebug setospid xxx
oradebug dump errorstack 3
 
C. 发现底层调用这句sql时候,耗费时间较久
SELECT CNO, CNAME, TYPE, CONDITION, CONDLENGTH, ENABLED, DEFER, INAME, IDXSYSGEND FROM SYS.EXU8CON WHERE
OBJID = 535520 AND TYPE IN (1, 2, 3, 7, 11, 12, 14, 15, 16, 17) ORDER BY CNO ;
 
SYS.EXU8CON是一个视图,深入研究这个视图,主要消耗都在sys.obj$上,理论上我们对象表没有这么多。
CREATE OR REPLACE VIEW exu8con (
objid, owner, ownerid, tname, type, cname,
cno, condition, condlength, enabled, defer,
sqlver, iname) AS
SELECT o.obj#, u.name, c.owner#, o.name,
decode(cd.type#, 11, 7, cd.type#),
c.name, c.con#, cd.condition, cd.condlength,
NVL(cd.enabled, 0), NVL(cd.defer, 0),
sv.sql_version, NVL(oi.name, '')
FROM sys.obj$ o, sys.user$ u, sys.con$ c,
sys.cdef$ cd, sys.exu816sqv sv, sys.obj$ oi
WHERE u.user# = c.owner# AND
o.obj# = cd.obj# AND
cd.con# = c.con# AND
cd.spare1 = sv.version# (+) AND
cd.enabled = oi.obj# (+) AND
NOT EXISTS (
SELECT owner, name
FROM sys.noexp$ ne
WHERE ne.owner = u.name AND
ne.name = o.name AND
ne.obj_type = 2) 
 
 
SQL> select count(*) from dba_recyclebin;
  COUNT(*)
----------
    130541
 
E. 故清除了垃圾表
purge  dba_recyclebin;

 

F. 目前测试下来,情况良好,全部只有18分钟。 检查北京那边,回收站数据也有3万多,那边导出时间大致为26分钟,建议也清空。

 

 


恒生技术之眼原创文章,未经授权禁止转载。详情见转载须知

联系我们

恒 生 技 术 之 眼