本文讲述了作者在排查一起生产环境中Oracle Job处理速度慢的问题，通过检查数据库负载、等待事件和SQL执行情况，发现Job执行的是一个处理行数为0的SQL查询，原因是新创建的空表导致的空跑。这提示我们在解决问题时不仅要关注硬件和资源使用，还要考虑业务层面的因素。
昨天开发的同事找到我说，生产有个job处理数据的速度很慢，想让我帮忙看看是怎么回事，最近碰到这种问题相对比较多了，但是问题的原因也是五花八门。我还是大体找他们了解了下情况，说有一个Job是处理文件传输的，但是从目前的运行情况来看，处理速度很慢，基本没什么进展，我向他们确认这几天是否有数据变更的操作，他们说没有。得到这个确认查看问题的方向就有明显的不同，我还是照例查看了一下数据库负载，锁情况。但是么有发现什么信息。
从数据库的负载来看，负载倒不高。
Snap Id
Snap Time
Sessions
Cursors/Session
Begin Snap:
17844
16-Jan-15 12:00:37
303
4.2
End Snap:
17845
16-Jan-15 13:00:40
303
4.4
Elapsed:
60.04 (mins)
DB Time:
119.10 (mins)
Load Profile
Per Second
Per Transaction
Per Exec
Per Call
DB Time(s):
2.0
0.1
0.00
0.00
DB CPU(s):
1.2
0.1
0.00
0.00
Redo size:
1,222,354.8
56,665.6
Logical reads:
54,092.4
2,507.6
Block changes:
4,395.0
203.7
Physical reads:
5,172.7
239.8
Physical writes:
273.2
12.7
User calls:
4,952.3
229.6
Parses:
12.9
0.6
Hard parses:
1.1
0.1
W/A MB processed:
1.0
0.1
Logons:
0.1
0.0
Executes:
3,000.2
139.1
Rollbacks:
0.0
0.0
Transactions:
21.6
接下来看看等待事件，还是没有发发现特殊之处。
Top 5 Timed Foreground Events
Event
Waits
最低0.47元/天 解锁文章
扫一扫
499
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
