ITPUB论坛-中国最专业的IT技术社区

 找回密码
 注册
查看: 1196|回复: 5

[原创] 风险预警·11g容易被忽略的导入性能问题

[复制链接]
认证徽章
论坛徽章:
0
发表于 2017-7-26 14:08 | 显示全部楼层 |阅读模式
前言       某大型国有银行一套关键系统10g升级到11g,老K负责升级后第一天早上的运行保障;在升级前甲方客户已经先后做了各种测试,以保证升级后不会存在任何性能问题。然而,事与愿违,老K刚到现场,客户应用团队就已经反馈到客户说批量慢了一段时间,根据应用日志与现场负责协助升级的友商DBA的核查,初步定位问题为升级后使用的存储变慢导致的导出缓慢,拖慢了批量的执行时间。对于这一结论,客户在调动存储相关工程师进行核查的同时,还存在疑惑,于是老K便开始参与这一问题的追查;现在问题就可以描述为:oracle从10g升级到11g后,导入操作变慢。

01开始思考
   因为是升级前后导入的效率变化,于是老K首先将生产系统分别在10g和11g的环境下导入的日志来进行对比,主要核对导入的时间点后再进一步查看相关时间点数据库的状态。然而,在看过两个日志后,老K就有了自己的疑惑,于是,我就启动自己的虚拟机,开始自己的验证探索之旅。
1.jpg
2.jpg
上面两图是我在自己的虚拟机上直接测试导入得到的导入日志文件,细心的你在看完下图之后,是否也发现了一些疑惑呢?老K提示:
老K提示:
1.导入时启用了并行(并行为6,大于表的个数
2.导入时使用了content=data_only(说明数据库中原来已经有了表的定义
3.导入的表中存在分区表(A1,A2,A3共计24个分区)和非分区表(A6
02分析中。。。
3.jpg
4.jpg
如图所示,表A6比较大,有超过500万条记录(而且这里老K还在A6表上建了索引,在导入时还需要维护A6表的索引,其他表则没有索引),而其他所有的表占用空间加起来也不过300M大小而已。在10g的日志中,A6表的日志记录写在了最后一行,而在11g的日志中则出现在了第四行
正常来说,使用数据泵导入/导出多个表时,会在导入/导出完成时在日志中打出相应表的信息,如果这里A6表作为一个大表,却相较于其他表先完成导入操作,我们就可以怀疑分区表和非分区表同时导入时,11g数据泵的机制是存在问题的,特别是在对比了10g的导入情况后。
03猜测&验证
上面梳理出疑惑,我们应该怎么去验证呢?如果我们是正在执行导入/导出的操作,我们可以attach到导入/导出任务中进行实时观察;而如果是导入/导出已经完成了,那我们就需要从数据库的历史性能视图中去寻找答案了(这里我们主要针对11g数据库进行验证)。
首先,我们先来通过v$active_session_history视图来查看导入的整体情况:
5.jpg
这里使用v$active_session_history视图来核查,每秒做一次采样发现,导入期间,数据库确实启动了6个并行进程(worker),其中DW00进程采样次数最多,但是各进程的最早采样到的时间和最后采样到的时间相差无几,都是从12:36左右到12:51;显然,这个过程中有部分worker进程是空闲的
那么,是不是分区表导入存在问题呢?
我们先来分析分区表(以A1为例)的导入过程:
6.jpg
通过上面结果,我们能看到一个特征,就A1表而言,其各个分区的导入散落在不同的DW进程上,但是从采样的最大最小时间上看,没有重合时间区域,也就是说,在目前DATAPUMP启动了6个并行来导入4个表的时候,看起来分区表A1表并没有做到多个分区并行导入,同样我们核查A2、A3表的导入情况:
7.jpg
8.jpg
得出结论如下:导入时,虽然并行度是6,只导入4个表(含分区表)的情况下,所有的表的多个分区间没有并行地导入,至少有个两个DW进程是空闲的(实时attach到导入进程监控时更是一目了然)。
此类情况是不是与我们以往的经验相违背呢?
知识点:
1.数据泵导入时,并行主要是通过多个进程分别导入不同的表来提高导入速度的,而不同的分区作为不同的segment一般也被当做不同的表来处理;
2.数据泵导入时,默认使用的是insert append的方式,也就是说在导入时会持有对象的表锁;
本次的导入好像就是与第一条有所不符,导入时在存在空闲进程的情况下,同一个表的不同分区并没有做到并行,那是为什么呢?我们需要注意到我们在前面提到的几个导入特征,其中一个就是,我们使用了content=data_only; 使用这个参数就意味着,当前数据库中已经有了该分区表的定义,只是将数据导入到已存在的表中去,在数据库中已经存在分区表的定义而需要向其中导入数据时,则可能会遇到的一种情况是,数据库中分区表的定义与DUMP文件中分区表的定义不一致(比如分区键不一致),导致DUMP文件中的分区无法与数据库中的已有分区一一对应,而无法做到一一对应就意味着,如果启动多个WORKER同时导入一个表的不同分区,不同WORKER就有可能会同时向一个目标分区中执行insert append操作,前面提到,insert append操作会持有行锁,这样最后会出现导入worker间的互相阻塞的情况,而且有可能形成死锁,所以oracle较新的版本中,在导入已存在分区表时(使用了参数content=data_only等),同一表的多个分区是顺序导入的(虽然有可能是通过不同的worker来执行)。
04疑问&解答
那么10g数据库的导入是不是也是这样呢?我们用同样方法来测试观察,可以发现10g数据库的导入也是如此,那么客户在10g、11g环境中导入的数据、表的定义、导入命令,都没有变化,看起来并行+metadata_only并不是问题所在,那么真正的问题在哪里呢?我再次回到最开始的问题:
9.jpg
在10g的日志中,A6表的日志记录写在了最后一行,而在11g的日志中则出现在了第四行,也就是说,在10g中,A6表是最后完成的,而在11g中A6表却在A1、A2、A3表的大部分分区完成前已经完成了,是A1、A2、A3表的导入进程在等待什么吗?
还是要回到v$active_session_history视图上来:
10.jpg
可以看到,A6导入时间大约从12:36持续到12:49,包含索引维护
11.jpg
而在此期间其他活动的会话中,各分区表只导入了一个分区(即各表导入的第一个分区),而且各WORKER在导入完第一个分区后(12:37:32~12:42:17)并没有异常等待,而是处于空闲状态。
12.jpg
我们再回顾一下各个表的导入情况:
13.jpg
14.jpg
15.jpg
16.jpg
可以看到,各个表在导完第一个分区后,出现长时间的停顿,一直等到非分区表导入完,才继续后续的分区导入;
结合各worker的状态及各表导入的时间状态以及前面的结论我们可以确认一点:
在分区表和非分区表同时导入,而且是数据库中表定义已经存在(使用content=metadata_only等参数)时,分区表需要逐个导入无法使用并行,而在所有分区表分别导完第一个分区后,需要等待所有的非分区表导入完成,才能继续后面的分区表的分区导入,进而影响导入进度。
而以上问题在10g数据泵中不存在,宇宙行客户所遇到的问题正是这个问题,升级后多花费的时间也基本上就是单个非分区表导入的时间。以上问题已经提交的ORACLE官方并确认为11g导入的调度机制问题,目前正在开发解决中。
05
我们遇到了什么
看看我们遇到了什么问题吧:
1.在10g中,我们使用并行导入分区表和非分区表,并且目标库中已经有了表的定义,于是我们加上了content=data_only参数;
2.导入的过程中,分区表的各个分区逐个导入,在并行进程足够多的时候各个表之间实现并行导入;
3.升级到11g以后,各分区表仅仅导入第一个分区,然后开始等待;
4.非分区表导入完成后,各分区表继续完成导入。
而现在我们知道了,多花费的时间就是第三步的时间,在10g环境先,非分区表可以与分区表并行导入,而到了11g环境中,非分区表只能与分区表导入的第一个分区并行导入;假设,我们需要导入的是一个超大的非分区表和3个分区表,每个分区表3个分区,各分区大小一致,如果单独导所有的分区表需要1个小时,单独导所有非分区表需要1个小时,启用4个并行,在10g的环境里,理想情况下只需要1个小时即可导入完成(以导入最慢的非分区表导入完成,即整体导入完),而在11g的环境中,则需要1个小时+3/4个小时(即105分钟)。
我们可以做什么:
当我们需要追求导入的效率时:
1.导入分区表时尽量避免使用content=data_only或table_exists_action=appen/truncate的方式,如果已有表的数据量不大,而且dump中表的结构也与已存表的结构一致,我们不妨先存留已有表的数据,再使用table_exists_action=replace的方式;
2.如果导入分区表无法避免使用content=data_only或table_exists_action=appen/truncate,那么我们建议分区表和非分区表分开导入。

论坛徽章:
4
优秀写手
日期:2015-02-12 06:00:15优秀写手
日期:2015-02-01 06:00:14喜羊羊
日期:2015-03-04 14:52:462015年新春福章
日期:2015-03-06 11:58:18
发表于 2017-7-26 17:10 | 显示全部楼层
拜读了。牛

使用道具 举报

回复
认证徽章
论坛徽章:
2
秀才
日期:2017-06-14 16:27:23秀才
日期:2017-07-11 14:19:35
发表于 2017-7-27 11:24 | 显示全部楼层
分析的相当OK,学习了,大牛!

使用道具 举报

回复
认证徽章
论坛徽章:
8
ITPUB9周年纪念徽章
日期:2010-10-08 09:31:22SQL大赛参与纪念
日期:2011-04-13 12:08:17ITPUB十周年纪念徽章
日期:2011-11-01 16:25:222013年新春福章
日期:2013-02-25 14:51:242014年新春福章
日期:2014-02-18 16:43:09马上有钱
日期:2014-02-18 16:43:09秀才
日期:2016-03-24 09:10:24秀才
日期:2016-12-05 11:16:06
发表于 2017-7-28 10:52 | 显示全部楼层
感谢大神 分享

使用道具 举报

回复
论坛徽章:
0
发表于 2017-7-29 09:50 | 显示全部楼层
原文末尾处描述:
4.非分区表导入完成后,各分区表继续完成导入。
而现在我们知道了,多花费的时间就是第三步的时间,在10g环境先,非分区表可以与分区表并行导入,而到了11g环境中,非分区表只能与分区表导入的第一个分区并行导入;假设,我们需要导入的是一个超大的非分区表和3个分区表,每个分区表3个分区,各分区大小一致,如果单独导所有的分区表需要1个小时,单独导所有非分区表需要1个小时,启用4个并行,在10g的环境里,理想情况下只需要1个小时即可导入完成(以导入最慢的非分区表导入完成,即整体导入完),而在11g的环境中,则需要1个小时+3/4个小时(即105分钟)。

疑问:按我的理解,所有非分区表一个小时可以导完,而导入三个分区表的两个分区,需要2/3小时。  原文例子中开4个并行,第一个小时可以非分区表和三个分区表的第一个分区导入完成,剩下的三个分区表的2个分区可以在2/3小时内导完。总导入时间应该是1小时+2/3小时,即100分钟。

不知道是我理解的有问题还是笔者计算有误,望解释一下,谢谢!

使用道具 举报

回复
论坛徽章:
0
发表于 2017-8-19 14:39 | 显示全部楼层
感谢大神分享

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则

SACC2017购票7.8折优惠进行时

2017中国系统架构师大会(SACC2017)将于10月19-21日在北京新云南皇冠假日酒店震撼来袭。今年,大会以“云智未来”为主题,云集国内外顶级专家,围绕云计算、人工智能、大数据、移动互联网、产业应用等热点领域展开技术探讨与交流。本届大会共设置2大主会场,18个技术专场;邀请来自互联网、金融、制造业、电商等多个领域,100余位技术专家及行业领袖来分享他们的经验;并将吸引4000+人次的系统运维、架构师及IT决策人士参会,为他们提供最具价值的交流平台。
----------------------------------------
优惠时间:2017年8月30日前

活动链接>>
TOP技术积分榜 社区积分榜 徽章 电子杂志 团队 统计 虎吧 老博客 知识索引树 读书频道 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档 | IT博客
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛 | SAP ERP系统
CopyRight 1999-2011 itpub.net All Right Reserved. 北京皓辰网域网络信息技术有限公司版权所有 联系我们 网站律师 隐私政策 知识产权声明
京ICP证:060528号 北京市公安局海淀分局网监中心备案编号:1101082001 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表