巧用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 条评论
登录 后参与评论

相关文章

来自专栏linux驱动个人学习

NFC驱动调试

1.NFC基本概念: NFC 又称为近场通信,是一种新兴技术,可以在彼此靠近的情况下进行数据交换,是由非接触式射频识别(RFID)及互连互通技术整合演变而来,通...

5445
来自专栏Samego开发资源

玩玩树莓派之OS装机初始化

1958
来自专栏用户画像

实验室3 sql server 产品销售数据库

某公司的产品销售数据库company,company数据库中存在人事表employee、客户表customer、销售表sales、销售明细表sale_item、...

613
来自专栏精讲JAVA

订单系统中并发问题和锁机制的探讨

问题由来 假设在一个订单系统中(以火车票订单系统为例),用户A,用户B都要预定从成都到北京的火车票,A、B在不同的售票窗口均同时查询到了某车厢卧铺中、下铺位有空...

42411
来自专栏PHP在线

php中关于mysqli和mysql区别的一些知识点分析

一: PHP-MySQL 是 PHP 操作 MySQL 资料库最原始的 Extension ,PHP-MySQLi 的 i 代表 Improvement ,...

26910
来自专栏Zchannel

Openload超简单无下载限制免费网盘推荐!支持影片在线播放还能赚钱

Openload有什么特色呢?如果要我以一句话推荐此服务,我会说:它简单到不行,而且几乎没有任何限制!若你有长期关注免费资源网路社群,一定知道Pseric向来喜...

6031
来自专栏24K纯开源

Premiere&After Effects的实时预览插件开发

一、介绍         Adobe Premiere和After Effects在影视编辑、渲染领域已经得到广泛应用。全景视频在相应工具拼接好后也可以导入Pr...

2219
来自专栏小文博客

良心压缩软件Bandizip——无广告超精简

1.7K5
来自专栏bboysoul

linux 服务器带宽测试脚本ZBench

很郁闷,今天我的vultr服务器的ip被ban了,无奈只能换服务器,今天给大家推荐一个vps的带宽测速脚本ZBench可以一键测试你的服务器到国内和国外的速度

1642
来自专栏数据和云

知己知彼-关于Oracle安全比特币勒索问题揭秘和防范

风险从来都不是臆想和草木皆兵,就在你不经意的时刻,可能风险就突然降临到我们的身边。 近期,国内很多用户的 Oracle 数据库,突然遭遇到莫名其妙的攻击事件,...

3195

扫码关注云+社区