oracle数据库的导数-new3
2017-04-12 23:52:54 0 举报AI智能生成
Oracle数据库的导数-new3是一种高级功能，它允许用户在查询结果中计算导数。这种功能对于需要对数据进行复杂分析和处理的用户非常有用，例如金融分析师、数据科学家和工程师等。通过使用导数-new3功能，用户可以快速准确地识别数据中的模式和趋势，从而做出更明智的决策。此外，Oracle数据库的导数-new3功能还具有高度的可扩展性和灵活性，可以满足各种规模的企业需求。总之，Oracle数据库的导数-new3功能为用户提供了一种强大而实用的工具，帮助他们更好地利用数据来推动业务发展。
作者其他创作
大纲/内容
导出前准备
导出前需调研
导出库的版本和数据库的类型
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 small
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.KUPW$WORKER", line 9715
----- PL/SQL Call Stack -----
object line object
handle number name
c000000de7fe8a88 21979 package body SYS.KUPW$WORKER
c000000de7fe8a88 9742 package body SYS.KUPW$WORKER
c000000de7fe8a88 3437 package body SYS.KUPW$WORKER
c000000de7fe8a88 10436 package body SYS.KUPW$WORKER
c000000de7fe8a88 1824 package body SYS.KUPW$WORKER
c000002058199470 2 anonymous block
Job "G_PSR_NW"."SYS_EXPORT_SCHEMA_01" stopped due to fatal error at Wed Mar 1 20:44:47 2017 elapsed 1 02:37:12
ORA-01555: snapshot too old: rollback segment number 1058 with name "_SYSSMU1058_2779099175$" too small
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.KUPW$WORKER", line 9715
----- PL/SQL Call Stack -----
object line object
handle number name
c000000de7fe8a88 21979 package body SYS.KUPW$WORKER
c000000de7fe8a88 9742 package body SYS.KUPW$WORKER
c000000de7fe8a88 3437 package body SYS.KUPW$WORKER
c000000de7fe8a88 10436 package body SYS.KUPW$WORKER
c000000de7fe8a88 1824 package body SYS.KUPW$WORKER
c000002058199470 2 anonymous block
Job "G_PSR_NW"."SYS_EXPORT_SCHEMA_01" stopped due to fatal error at Wed Mar 1 20:44:47 2017 elapsed 1 02:37:12
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。
但是生产环境较为复杂，具体原因还不能完全确定，只能初步推测可能有bug。
建议
尝试另一种方法，使用内部算法较为简单的exp导出
最终解决方法
尝试用exp导出
导数成功，导出数据比用expdp导出快，没有出现在导表分区时hang住和报错终止的现象。
总结
生产环境较为复杂，有时候解决问题的方法有很多种，一种方法不可行时，不一定拘泥于一种方式，多方面去考虑，有时候问题就迎刃而解了。
expdp虽然功能性更强，但是expdp内部结构较为复杂，导数出现无法解决的问题，尝试用exp导出，虽然exp的功能不多，也没那么智能化，没有expdp复杂，内部结构较为简单，所以可以避免的问题更多，比如各种bug。要从多方面考虑尝试解决问题。
expdp虽然功能性更强，但是expdp内部结构较为复杂，导数出现无法解决的问题，尝试用exp导出，虽然exp的功能不多，也没那么智能化，没有expdp复杂，内部结构较为简单，所以可以避免的问题更多，比如各种bug。要从多方面考虑尝试解决问题。
收藏
收藏
0 条评论
下一页
