生产环境sqlldr加载性能问题及分析之一

在测试环境中进行了多轮测试，使用sqlldr批量加载数据，csv文件大概有120G左右，在一致的数据量的情况下，测试环境都在一个小时左右，但是在生产环境中竟然跑了将近2个小时，性能差了一倍。而且生产环境的服务器配置还要好一些。对于这个奇怪的问题，尽管说数据第一轮数据迁移已经完成了，对于之后的数据迁移还是很好的参考和经验借鉴。

今天对生产环境和测试环境中的信息进行了比对。先拿到对应的awr报告。
测试环境的数据库情况如下。

Host Name Platform CPUs Cores Sockets Memory (GB)
test_db Linux x86 64-bit 40 20 2 354.11
Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 1996 23-Jun-14 23:30:34 264 2.3
End Snap: 1998 24-Jun-14 00:30:18 105 3.0
Elapsed:   59.74 (mins)    
DB Time:   5,864.54 (mins)    

生产环境的数据库情况如下：

Host Name Platform CPUs Cores Sockets Memory (GB)
prod_db Linux x86 64-bit 40 20 2 180.89
Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 12852 27-Jun-14 03:00:55 760 2.5
End Snap: 12853 27-Jun-14 04:00:22 780 2.5
Elapsed:   59.45 (mins)    
DB Time:   8,861.63 (mins)    

通过上面的信息可以得到，
1.在生产库的负载将近是测试库的两倍，数据加载速度却是测试库的50%,从这个角度来看，也确实是合理的。
2.对于session的情况，测试库和生产库有着明显的差别，测试库中的session在105-264左右，但是在生产库中却有760-780左右，我之前建议在生产数据迁移的时候把listener的端口改了，这样，开发测试部分的人就连不到库了，能从一定程度上减少额外的干扰，但是限于时间紧迫，需要考虑的因素比较多，客户不太愿意这么做。
3.基于第二点，有人在数据迁移的过程中访问数据库，进行了一些查询，从某种程度上降低了数据库的响应速度。但是活跃的session有那么多嘛，因为在测试和生产中，并行的插入线程都基本控制在150个左右。怎么有这么大的差别啊。如果想得到一些更为有效的信息，可以通过ash，下面就是通过ash得到的数据。
测试环境：

CPUs SGA Size Buffer Cache Shared Pool ASH Buffer Size
40 11,198M (100%) 6,144M (54.9%) 783M (7.0%) 80.0M (0.7%)
Sample Time Data Source
Analysis Begin Time: 23-Jun-14 23:30:00 DBA_HIST_ACTIVE_SESS_HISTORY
in AWR snapshot 1996
Analysis End Time: 24-Jun-14 00:30:00 DBA_HIST_ACTIVE_SESS_HISTORY
in AWR snapshot 1998
Elapsed Time: 60.0 (mins)  
Sample Count: 37,692  
Average Active Sessions: 104.70  
Avg. Active Session per CPU: 2.62  
Report Target: None specified  

生产环境

CPUs SGA Size Buffer Cache Shared Pool ASH Buffer Size
40 12,233M (100%) 6,144M (50.2%) 1,891M (15.5%) 80.0M (0.7%)
Sample Time Data Source
Analysis Begin Time: 27-Jun-14 03:00:00 DBA_HIST_ACTIVE_SESS_HISTORY
in AWR snapshot 12852
Analysis End Time: 27-Jun-14 04:00:00 DBA_HIST_ACTIVE_SESS_HISTORY
in AWR snapshot 12853
Elapsed Time: 60.0 (mins)  
Sample Count: 55,608  
Average Active Sessions: 154.47  
Avg. Active Session per CPU: 3.86  
Report Target: None specified  

可以看到活跃的session数确实比测试库多了不少。这个可以稍后做确认。

还有一个是归档的问题
下面是查看数据库归档的情况，可以看到生产库归档在119次左右，而测试库在130次左右，日志切换的次数多，说明在那个时间段内处理了更多的数据操作。

最后，比较top event的情况作为一个引子，明天来详细的阐述这些等待事件后面的一些问题。
测试库的情况

Top User Events

Event Event Class % Event Avg Active Sessions
log buffer space Configuration 46.82 49.03
db file sequential read User I/O 14.00 14.66
log file sync Commit 7.07 7.40
CPU + Wait for CPU CPU 5.98 6.26
buffer busy waits Concurrency 5.64 5.90

Back to Top Events 
Back to Top

Top Background Events

Event Event Class % Activity Avg Active Sessions
db file parallel write System I/O 2.48 2.60

生产库的情况

Top User Events

Event Event Class % Event Avg Active Sessions
free buffer waits Configuration 22.29 34.43
buffer busy waits Concurrency 15.20 23.48
log buffer space Configuration 13.97 21.58
enq: TX - index contention Concurrency 10.16 15.70
log file switch (checkpoint incomplete) Configuration 9.94 15.35

Back to Top Events 
Back to Top

Top Background Events

Event Event Class % Activity Avg Active Sessions
db file async I/O submit System I/O 2.56 3.96
时间： 2024-10-24 01:04:59

生产环境sqlldr加载性能问题及分析之一的相关文章

sqlldr加载性能问题的排查

最近根据业务需要加载一批数据,在生产环境中不到半个小时就完了,可是到了测试环境,竟然跑了6个多小时,另外测试环境和生产环境的数据情况都基本差不多,主机配置也基本类似. 大家的注意力都集中到了sqlldr的加载性能上.等到他们找到我时,已经讨论了不少关于direct,convention加载的各种情况了,看似工作也做了不少了. 然后我通过邮件历史记录看到大家还讨论了可能是index导致的结果. 等到邮件转到我这的时候,已经问题算升了一个等级了.我首先要确定的就是具体的环境,在那台服务器上跑sqll

使用 React.js 的渐进式 Web 应用程序：第 2 部分 - 页面加载性能

本文讲的是使用 React.js 的渐进式 Web 应用程序:第 2 部分 - 页面加载性能, 系列第二篇,来看看基于 React 路由分块的页面加载优化. 原文地址:Progressive Web Apps with React.js: Part 2 - Page Load Performance 原文作者:Addy Osmani 译文出自:掘金翻译计划 译者:markzhai 校对者:Romeo0906,AceLeeWinnie 使用 React.js 的渐进式 Web 应用程序:第 2 部

HTTP 推送，显著提升加载性能

上周我在斯达哥尔摩住了几天,出席了 HTTP 研讨会,参与了不少吸引人的讨论.其中一次是关于 HTTP 推送及其优缺点.早期实验结果的. 由于早期实验部署结果不那么理想,人们对 HTTP 推送大体持着怀疑态度,不过我想分享下自己更乐观一些的观点. HTTP 推送能做哪些预加载不能做的事? 从怀疑者那里一再听到的观点是,"推送相对于预加载来说,只不过节省了一次 RTT(Round Trip Time)而已".在实践中,这并非总是对的,有一个使用案例,推送可以完成,但预加载无法做到. 利用

Linux环境变量加载的研究

我们经常遇到在linux执行某条命令时出现xxx文件没找到的问题.很多情况都不是库没有安装,而是环境变量的错误. 但是,我明明是设置了环境变量啊.所以,我对此进行了试验. 我们登录linux有很多种,bash来交互式执行,或者直接非交互式执行命令.在我的试验后,发现,原来这几个的环境变量加载都是不同的. 相关文件: 从电脑上,我找到这么几个相关文件. 1 /etc/profile 2 /etc/environment 3 /etc/bashrc 4 ~/.bash_profile 5 ~/.ba

js的压缩及jquery压缩探讨(提高页面加载性能/保护劳动成果)_javascript技巧

问题缘由:负责公司的开发平台研发工作,考虑的知识产权的保护工作,必须要考虑java的加密技术和js脚本的加密技术.在目前java加密很容易破解的情况下,还是先搞定js的加密和压缩,一方面可以提高页面加载性能,另外一方面也希望辛苦研发出来的成果得到一定的保护. 研究过程: 1.先强烈鄙视一下哪些随便转载文章的家伙,给我制造了很大的麻烦!!网上很多帖子都不靠谱.. 2.首先想了解jquery使用什么压缩的, 网上找了半天,说法不一样,后来还是在jquery官网的最频繁问题中找到了答案,但这已经是绕了

Listview的异步加载性能优化_Android

 Android中ListView是使用平率最高的控件之一(GridView跟ListView是兄弟,都是继承AbsListView),ListView优化最有效的无非就是采用ViewHolder来减少频繁的对view查询和更新,缓存图片加快解码,减小图片尺寸. 关于listview的异步加载,网上其实很多示例了,中心思想都差不多,不过很多版本或是有bug,或是有性能问题有待优化,下面就让在下阐述其原理以探索个中奥秘在APP应用中,listview的异步加载图片方式能够带来很好的用户体验,同时也

Listview的异步加载性能优化

Android中ListView是使用平率最高的控件之一(GridView跟ListView是兄弟,都是继承AbsListView),ListView优化最有效的无非就是采用ViewHolder来减少频繁的对view查询和更新,缓存图片加快解码,减小图片尺寸. 关于listview的异步加载,网上其实很多示例了,中心思想都差不多,不过很多版本或是有bug,或是有性能问题有待优化,下面就让在下阐述其原理以探索个中奥秘在APP应用中,listview的异步加载图片方式能够带来很好的用户体验,同时也是

WebGL 启动加载触发更新流程分析

WebGL 启动加载触发更新流程分析 太阳火神的美丽人生 (http://blog.csdn.net/opengl_es) 本文遵循"署名-非商业用途-保持一致"创作公用协议 转载请保留此句:太阳火神的美丽人生 -  本博客专注于 敏捷开发及移动和物联设备研究:iOS.Android.Html5.Arduino.pcDuino,否则,出自本博客的文章拒绝转载或再转载,谢谢合作. requestAnimFrame(tick); 此命令是 HTML5 中新增的用于替换定时器触发更新的命令,

React Native JS Module 加载性能优化

关于React Native 性能 React Native 在手淘中已开始逐步推广, 在拍立淘首页的使用场景中,我们发现React Native并没有想 象中的那么快,实测效果在离线状态下性能甚至比不过H5 WindVane,React Native的UI会出现延迟渲 染存在视觉差,经过具体的代码性能测试,整个过程平均在300 ms (IPhone 5S机型下,整个JS文件 400K), 然后其核心系统调用代码加载解析整个JS (JSEvaluateScript)耗时在220 ms左右,在目前