巧用parallel极速提升数据加载速度(r2第21天)

并行在平时工作中可能不是很注意,因为有时候即使设定了parallel 相关的hint,感觉性能也好不到哪去。这是我以前的感觉。 今天通过一个案例来分享一下通过parallel来使数据加载的速度达到极速提升。 现有一个很让人头疼的表,里面还有clob字段,通过exp/imp来导出导入数据,导出慢还可以接受,导入的速度大概在一秒钟1000条的速度,对于千万,上亿的数据来说,简直就是噩梦。对于数据泵,也测试了各种可能的改进方法。但是效果都不让人满意,首先就是对于undo的消耗极大,还有impdp中parallel选项因为clob无法激活。在测试环境中反复测试,时间大概保持在2个小时的样子(数据量是5千万),而且还得不断的去查看undo的使用率,有一次测试中还报了undo空间不足的错误,整个数据导入得重头再来,而且还使得高水位线受到影响。 个人反复的尝试,最后使用外部表来进行数据的分批导入,这样能够降低undo使用率,对于进度也比较好把握,比如对于大表big_table,我生成了20个外部表,把big_table里的数据分摊到了20个外部表中,这样每个外部表做完insert之后,马上commit,可以减少undo使用竞争。测试环境中测试,时间在40~60分钟左右,刚开始的时候速度很快,一分钟将近160万的数据加载速度,但是到后面速度就开始逐渐降下来了。最后150万的数据基本在5分钟左右。 一方面是外部原因,另一方面和数据库内部的机理也有关联,有些块不会很快的释放。 使用外部表Insert的方式性能要好一些,但是得改进一些地方,尤其是对于大表来说,parallel比想象中的效果要好很多, 首先来看一下一般的数据插入速度。速度在40秒左右。为了保证测试的可评估性,我每次都会换一个数据量基本一致的外部表来插入数据。 SQL> insert into big_table select *from big_table_ext_33; 820374 rows created. Elapsed: 00:00:40.80 SQL> commit; 尝试使用append方式插入数据,表big_table已经设置为nologging模式,有4个local partitioned 的index,都是logging模式。 速度一下子提升了不少达到了16秒。 SQL> insert /*+append*/ into big_table select *from big_table_ext_30; 960461 rows created. Elapsed: 00:00:16.11 然后继续换一个表,使用parallel hint来插入数据。但是时间好像没有任何提升。 SQL> insert /*+append parallel(big_table 8) */ into big_table select *from big_table_ext_2; 988140 rows created. Elapsed: 00:00:16.14 这个时候可以使用v$pq_sesstat来查看使用parallel被启用了。 SQL> select * from v$pq_sesstat; STATISTIC LAST_QUERY SESSION_TOTAL ------------------------------ ---------- ------------- Queries Parallelized 0 0 DML Parallelized 0 0 DDL Parallelized 0 0 DFO Trees 0 0 Server Threads 0 0 Allocation Height 0 0 Allocation Width 0 0 Local Msgs Sent 0 0 Distr Msgs Sent 0 0 Local Msgs Recv'd 0 0 Distr Msgs Recv'd 0 0 11 rows selected. 可以看到parallel的hint被oracle给忽略了。parallel dml的优先级是session >hint> object 所以继续设置session级的hint,启用parallel,这个时候如果想保证启用paralell可以使用force选项。 SQL> alter session force parallel dml parallel 8; Session altered. Elapsed: 00:00:00.00 再次插入数据,时间一下子降低到了6秒钟。 SQL> insert /*+append parallel(big_table 8) */ into big_table select *from big_table_ext_31; 930198 rows created. Elapsed: 00:00:06.49 SQL> commit; 清空数据,稍候继续插入数据,来看看是否parallel被启用了。 SQL> truncate table big_table; Table truncated. Elapsed: 00:00:01.34 SQL> select * from v$pq_sesstat; STATISTIC LAST_QUERY SESSION_TOTAL ------------------------------ ---------- ------------- Queries Parallelized 0 0 DML Parallelized 0 1 DDL Parallelized 0 0 DFO Trees 0 1 Server Threads 0 0 Allocation Height 0 0 Allocation Width 0 0 Local Msgs Sent 0 16191 Distr Msgs Sent 0 0 Local Msgs Recv'd 0 16191 Distr Msgs Recv'd 0 0 11 rows selected. 将近100万的数据在6秒钟导入了,如果是5000万的数据大概需要6分钟左右的时间,来简单验证一下 做一个大的数据插入。大概用了7分钟的时间,速度还是不错的。 SQL> insert /*+append parallel(big_table 8) */ into big_table select *from big_table_ext; 58303757 rows created. Elapsed: 00:07:26.48 SQL> commit; Commit complete. Elapsed: 00:00:01.92 SQL> select * from v$pq_sesstat; STATISTIC LAST_QUERY SESSION_TOTAL ------------------------------ ---------- ------------- Queries Parallelized 0 0 DML Parallelized 1 2 DDL Parallelized 0 0 DFO Trees 1 2 Server Threads 16 0 Allocation Height 8 0 Allocation Width 1 0 Local Msgs Sent 994995 1011186 Distr Msgs Sent 0 0 Local Msgs Recv'd 994995 1011186 Distr Msgs Recv'd 0 0 11 rows selected. 在数据导入的过程中,启用了相应的并行进程。 26388 testdbn 15 0 11.5g 1.4g 1.1g S 38.3 0.4 2:41.80 ora_p012_TESTDB 26394 testdbn 15 0 11.5g 1.4g 1.1g S 38.3 0.4 2:40.87 ora_p015_TESTDB 26380 testdbn 15 0 11.5g 1.4g 1.2g S 37.6 0.4 3:50.61 ora_p008_TESTDB 26390 testdbn 15 0 11.5g 1.4g 1.1g S 37.6 0.4 2:44.64 ora_p013_TESTDB 26392 testdbn 15 0 11.5g 1.4g 1.1g S 37.3 0.4 2:43.63 ora_p014_TESTDB 26382 testdbn 15 0 11.5g 1.4g 1.1g S 37.0 0.4 2:43.43 ora_p009_TESTDB 7080 testdbn 16 0 11.3g 68m 28m S 9.7 0.0 2:38.05 ora_arc2_TESTDB 4101 testdbn 15 0 11.2g 6.1g 6.1g S 6.1 1.7 10:54.46 ora_dbw1_TESTDB 4105 testdbn 15 0 11.2g 6.1g 6.1g S 6.1 1.7 11:27.73 ora_dbw3_TESTDB 4099 testdbn 15 0 11.2g 6.1g 6.1g R 5.8 1.7 11:49.40 ora_dbw0_TESTDB 4103 testdbn 15 0 11.2g 6.1g 6.1g S 4.8 1.7 10:47.55 ora_dbw2_TESTDB 所以在cpu资源充足的情况下,启用并行也是一个不错的选择。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2014-07-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏北京马哥教育

Python神技能 | 使用爬虫获取汽车之家全车型数据

最近想在工作相关的项目上做技术改进,需要全而准的车型数据,寻寻觅觅而不得,所以就只能自己动手丰衣足食,到网上获(窃)得(取)数据了。 汽车之家是大家公认的数据做...

4339
来自专栏大魏分享(微信公众号:david-share)

通过Swagger管理API:API Management学习第一篇

3 Scale有个很好的功能,它提供ActiveDocs实时文档。它基于Swagger框架,提供了一种记录API的方法,并包含在Developer Portal...

843
来自专栏FreeBuf

极客DIY:手机文件直传U盘,三步教你做一根OTG传输线

FreeBuf科普 OTG,即On-The-Go,该技术就是实现在没有电脑的情况下,实现从设备间的数据传送。例如数码相机直接连接到打印机上,通过OTG技术,连接...

1715
来自专栏更流畅、简洁的软件开发方式

通用权限的思路。带有数据库关系图

写完了就要提交了,想向上传一个图片,IE居然死掉了,白写了,还得重来一遍。郁闷。     上一篇主要是想说一下大体的思路,就是一个主要的框架,我觉得在做一件...

2086
来自专栏ThoughtWorks

被踢出去的用户

在还没有掌握全部证据之前就下结论会犯严重的错误,会使判断带有偏见。——《血字的研究》

582
来自专栏大数据挖掘DT机器学习

QQ空间(日志、说说、个人信息)python爬虫源码(一天可抓取 400 万条数据)

爬虫功能: QQSpider 使用广度优先策略爬取QQ空间中的个人信息、日志、说说、好友四个方面的信息。 判重使用“内存位”判重,理论上亿数量级的QQ可瞬间判...

3864
来自专栏农夫安全

Bwapp漏洞平台答案全解-A1(第二篇)

0x01 A1 - Injection(第二次) 1.11-Server-Side Includes (SSI) Injection 服务器端包含注入 <!--...

3098
来自专栏葡萄城控件技术团队

Winform文件下载之WebClient

最近升级了公司内部使用的一个下载小工具,主要提升了下面几点: 1. 在一些分公司的局域网中,连接不上外网 2. 服务器上的文件更新后,下载到的还是更新前的文件 ...

1795
来自专栏FreeBuf

仍有20%的VPN服务商未解决WebRTC漏洞泄露IP问题

其实自 2015 年 1 月开始,大约有 20% 的 VPN 方案提供商会因为 WebRTC 漏洞泄漏用户 IP 。但这个问题几遍在今天,一些 VPN 厂商也并...

922
来自专栏散尽浮华

Jira插件安装

一、Jira插件列表(可以将下面免费插件直接下载,然后登陆jira,在"插件管理"->"上传插件",将下载后的免费插件直接进行上传安装即可) 序号 ...

6474

扫描关注云+社区