oracle数据库的导数-new3

oracle数据泵导数故障分析

导出前准备

导出前需调研

导出库的版本和数据库的类型

gis

大字段较多

预计导出的时间会较长

操作系统

hp

数据库版本

11.2.0

是否是集群

是

评估数据量

expdp命令导出评估

expdp 用户名/密码 SCHEMAS=对象名 estimate_only=y estimate=blocks

较准确，但是毕竟是统计，还是有误差

直接用语句查询

select sum(bytes/1024/1024/1024) from dba_segments where ower='导出的对象名';

会统计到碎片，不准确

评估存放dump的空间是否足够

系统负载

导出一般要选择系统比较空闲的下班时间导出

避免和业务争用系统资源

创建导出的目录

expdp导出不同于exp，需要创建导出的directory

存放dump文件的文件夹需授权

oracle:oinstall

755权限

授权directory的读写权限给导出用户

导出的语句

expdp \\'/ as sysdba\\' SCHEMAS=g_psr_nw directory=GIS_DIR parallel=6 cluster=N dumpfile=g_psr_nw_0308_%U.dmp logfile=exp_g_psr_nw_20170308.log exclude=statistics compression=ALL filesize=8g

expdp多次导出报错

ORA-39126: Worker unexpected fatal error in KUPW$WORKER.UNLOAD_DATA [TABLE_DATA:\"G_PSR_NW\".\"G_GADGETS_TC2_DF_370\":\"P397\"] ORA-01555: snapshot too old: rollback segment number 1058 with name \"_SYSSMU1058_2779099175$\" too smallORA-06512: at \"SYS.DBMS_SYS_ERROR\

top查看系统负载

cpu和内存占用都比较低，系统负载较低

导出awr查看

导出的时间段的没有什么异常的等待事件，数据库的io性能正常，没有异常的io等待

发现导数日志有大量的ora-01555报错

这种情况一般是undo表空间满了，快照过旧的报错，但是在报错时间段，查看undo的表空间使用是正常的，有正常可使用的空闲空间

总数据量400多g，开6个并行

导出非常缓慢，且导出缓慢的部分主要在导表的分区，而不是在导大字段hang住

导出hang住时通过查询v$session_wait有等待事件

“wait for unread message on broadcast channel”

与平时相比较多

总共导出花的时间用了12h+

查看导数job状态发现并行开启6个并行，实际只有一个并行在跑

attach

expdp 用户名/密码 attach=SYS_EXPORT_SCHEMA_02

尝试导入报错dump文件不完整

经过观察发现

在导分区特别缓慢，发现有较多“wait for unread message on broadcast channel”等待事件，然后在导表分区的时候报错异常终止

查找资料

发现类似“BUG 6236862 POOR PLAN FOR SQL WITH ROWNUM (OR FIRST_K_ROWS) WITH PARTITION EXTENDED NAMING”，导出时有等待事件：“wait for unread message on broadcast channel”。可能是由于在导出分区表数据时，数据泵选择了效率较差的索引和执行计划（A poor plan may be used for SQL with ROWNUM (or FIRST_K_ROWS) with partition extended naming.）但是生产环境较为复杂，具体原因还不能完全确定，只能初步推测可能有bug。

建议

尝试另一种方法，使用内部算法较为简单的exp导出

最终解决方法

尝试用exp导出

导数成功，导出数据比用expdp导出快，没有出现在导表分区时hang住和报错终止的现象。

总结

生产环境较为复杂，有时候解决问题的方法有很多种，一种方法不可行时，不一定拘泥于一种方式，多方面去考虑，有时候问题就迎刃而解了。expdp虽然功能性更强，但是expdp内部结构较为复杂，导数出现无法解决的问题，尝试用exp导出，虽然exp的功能不多，也没那么智能化，没有expdp复杂，内部结构较为简单，所以可以避免的问题更多，比如各种bug。要从多方面考虑尝试解决问题。