恒生大部分系统导出用hstools工具，其实内部就是调用exp做导出，导出时可能遇到各种问题，往往都是通过现象关联过往经验来排错，本篇希望用更科学的方法来跟踪exp问题过程，找到问题的关键。本篇也可以作为工程同事收集问题信息给hs dba组诊断的指导手册。
用于完成export的完整命令，包括参数文件内容（如果使用了的话）。
Exp的日志文件
当执行export时完整的数据库alert.log。
提供以下问题的答案：
1) Exp问题何时发生的 ？
2) 以前是否正常？
3) 最近有打过数据库或者操作系统补丁吗？
4) 是否在数据库或者系统层面做过改动？
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 ;
重新执行export命令来重现问题。
SQL> ALTER SYSTEM SET EVENTS '<error code> trace name errorstack off';
注意
- 当使用ALTER SYSTEM SET EVENTS命令时，只有新的会话才能启用这个命令设置的事件。
- 将错误号替换为遇到的错误号（不含字符串'ORA-'）。
例如.如果遇到ORA-00904，设置跟踪的命令是：altersystem set events '904 trace name ERRORSTACK level 12';
然后从由user_dump_dest或diagnostic_dest参数指定的目录找到产生的trace或发给DBA。
C. 收集以下SQL脚本的spool文件
SQL> connect as sysdba
SQL> @srdc_exp_error.sql
A. 对以下问题提供是/否的答案：
1) 如果使用direct = y，是否有改进？
2) 数据结构是否改变或数据量增加了？
3) 是否只有特定对象遇到性能问题？如果是，则提供对象名称。
B. 所述生成并收集export的SQL trace：
1) 通过在命令行执行命令来启动export shadow进程
$ exp username/password
（在下面的步骤4之前，不要回答屏幕上提出的问题）
2) 识别shadow进程ospid
$ ps -ef | grep exp
或者使用SQL*Plus
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 12的10046 event
SQL> oradebug setospid xxx (xxx = ospid)
SQL> oradebug unlimit
SQL> oradebug Event10046 trace name context forever, level 12
4) 通过回复export会话中的交互问题来启动export。
5) 对于hang问题，让export运行至少1小时。对于性能问题等待导出完成，并停止trace：
SQL> oradebug Event 10046 trace namecontext off;
6) 找到生成的trace文件
SQL> oradebugtracefile_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 文件
E. 如果性能问题发生在特定的对象上，提供以下输出：
SQL> connect as sysdba
SQL> set long 20000
SQL> select owner,object_type,data_object_id from dba_objectswhere object_name='<OBJECT_NAME>';
SQL> select dbms_metadata.get_ddl('<OBJECT_TYPE>','<OBJECT_NAME>','<SCHEMA_NAME>')from dual;
XX证券北京中心切换到上海中心后，使用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)
D. 经查发现系统垃圾表居然有13万之多，导致每次导表，哪怕是空表，都要全表扫描一遍13多万的sys.obj$表，性能就下降了。
SQL> select count(*) from dba_recyclebin;
COUNT(*)
----------
130541
E. 故清除了垃圾表
purge dba_recyclebin;
F.目前测试下来，情况良好，全部只有18分钟。检查北京那边，回收站数据也有3万多，那边导出时间大致为26分钟，建议也清空。
彩蛋: 关注公众号回复： exp 即可得到文章中涉及的脚本。
