昨天开发的同事找到我说，生产有个job处理数据的速度很慢，想让我帮忙看看是怎么回事，最近碰到这种问题相对比较多了，但是问题的原因也是五花八门。我还是大体找他们了解了下情况，说有一个Job是处理文件传输的，但是从目前的运行情况来看，处理速度很慢，基本没什么进展，我向他们确认这几天是否有数据变更的操作，他们说没有。得到这个确认查看问题的方向就有明显的不同，我还是照例查看了一下数据库负载，锁情况。但是么有发现什么信息。从数据库的负载来看，负载倒不高。

Load Profile

接下来看看等待事件，还是没有发发现特殊之处。

Top 5 Timed Foreground Events

从时间模型的情况来看，资源消耗还在在I/O上。

这个时候和开发做一个简短的沟通，最起码得明确一些信息，要不大海捞针的查问题还是针对性不强，他们说Job处理速度慢，是哪个job呢，他们反馈说是MF1ppMD的job我从Sql Order by Elapsed time中查得MFppMD的相关top sql有几个，但是这几个语句执行时间都很短，都在0.01秒以内，性能算是不错的了。

从系统优化的角度来说，ppMD的性能问题还是比较奇怪的。继续查看其它的指标类型，一边注意ppMD相关的job，一边留意是否是其它的原因导致的。当我看到Sql Order by Executions的时候。注意到一个奇怪的地方，执行频率最高的正是ppMD这个job

但是仔细查看会发现一个奇怪的现象， Rows Processed却是0.这是一个比较特殊的情况，这个参数代表的意思是SQL在快照时间内累计执行所处理的总行数。代表0说明执行了几百万次，但是没有任何数据处理，相当于空跑。来看看执行的sql语句是什么。

select ROWID,

PRIM_RESOURCE_TP,

PRIM_RESOURCE_VAL,

TO_CHAR(EFFECTIVE_DATE, 'YYYYMMDDHH24MISS'),

TO_CHAR(EXPIRATION_DATE, 'YYYYMMDDHH24MISS'),

TO_CHAR(SYS_CREATION_DATE, 'YYYYMMDDHH24MISS'),

TO_CHAR(SYS_UPDATE_DATE, 'YYYYMMDDHH24MISS'),

OPERATOR_ID,

APPLICATION_ID,

DL_SERVICE_CODE,

DL_UPDATE_STAMP,

FUTURE_1,

FUTURE_2,

FUTURE_3

into :b0 :b1,

:b2 :b3,

:b4 :b5,

:b6 :b7,

:b8 :b9,

:b10 :b11,

:b12 :b13,

:b14 :b15,

:b16 :b17,

:b18 :b19,

:b20 :b21,

:b22 :b23,

:b24 :b25,

:b26 :b27

from MI9_PAID_SUBSCR

where (((PRIM_RESOURCE_TP = :b2 and PRIM_RESOURCE_VAL = :b4) and

EFFECTIVE_DATE <= TO_DATE(:b6, 'YYYYMMDDHH24MISS')) and

(EXPIRATION_DATE is null or

EXPIRATION_DATE > TO_DATE(:b6, 'YYYYMMDDHH24MISS')))

这是一个很简单的查询，一看这个表，我就恍然大悟了，这个表是在这两天才做的变更，在最新的需求中需要创建这个表，从目前的需求来看，这个表需要同步一些数据，但是数据的同步机制还没有达成共识，所以最后临时决定先把这个表创建好，让job在校验的时候不出错，但是表里面没有数据，暂时先按照dummy表来处理。但是在升级中没有包含这个变更,只是提供了临时的补丁做了修复。