在测试环境中进行了多轮测试，使用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 |
还有一个是归档的问题
下面是查看数据库归档的情况，可以看到生产库归档在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 |
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/29900508/viewspace-1275920/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
只言片语分析datapump的工作原理
下一篇：
生产环境数据迁移问题汇总
请登录后发表评论
登录
全部评论
