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

简介: 在测试环境中进行了多轮测试,使用sqlldr批量加载数据,csv文件大概有120G左右,在一致的数据量的情况下,测试环境都在一个小时左右,但是在生产环境中竟然跑了将近2个小时,性能差了一倍。

在测试环境中进行了多轮测试,使用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


目录
相关文章
|
SQL 存储 并行计算
openGauss并行查询测试(一)
openGauss并行查询测试
584 0
|
SQL
openGauss并行查询测试(二)
openGauss并行查询测试
706 0
|
固态存储 关系型数据库 MySQL
|
SQL Oracle 关系型数据库
SRDC - 数据泵导入(IMPDP)性能问题的诊断收集 (文档 ID 2365615.1)
SRDC - 数据泵导入(IMPDP)性能问题的诊断收集 (文档 ID 2365615.1)MOS
1995 0