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

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

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

1) Exp 问题何时发生的 ？

2) 以前是否正常？

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

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

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

2)  使用 rows=n export 也会失败 ?

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_dest 或 diagnostic_dest 参数指定的目录找到产生的 trace 或发给 DBA 。

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

SQL> connect / as sysdba

SQL> @srdc_exp_error.sql

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

2) 数据结构是否改变或数据量增加了？

3)  是否只有特定对象遇到性能问题？ 如果是，则提供对象名称。

B.  如下所述生成并收集 export 的 SQL 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 12 的 10046 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

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

收集三个 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 分钟

根据上述诊断计划

exp + User + '/' + Password

+ '@' +  实例名

+ ' file=' + 'XXX.fdm'

+ ' tables=('  表名  ')'

+ ' log=' + 'XXX.fdm.out'

+ ' compress=n'

可以看到并没有特别参数

oradebug dump errorstack 3

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

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