想请教一个Oracle EBS performance 问题

[CCL]

借人气问一个Oracle EBS performance 问题：

我们的Oracle EBS application 最近老是出现performance 问题。 用户投诉越来越频繁，老大越来越恼火，我们的日子越来越难过，可是我们不肯定问题原因是什么。只是系统经常很慢，老是一堆pending concurrent job.各处用户投诉一个接一个。

我不懂database，我们DBA 总在提什么我们系统产生的OI是别的N个系统的总和。还有我们的每天大约有37000 个concurrent jobs（有的是我们Scheduled 的，有的是用户manually submit 的，有的是transaction 自动trigger 的。 我们DBA 认为我们应该减少concurrent job 数量，但我们functonal team 研究了又研究，感觉减少不了多少。而且有新的模块要implement，我们一定会有更多的concurrent job 要run 。

总之，现状就是，operation system team 认为operation system 正常，server hardware 也正常，DBA认为他database maintain 够好了，funcitonal team 也不认为减少百十个concurrent job 会解决根本问题。


对了，我们用Oracle 有十多年了。在03，04年做过部分purge。

多谢多谢各路高手，集思广益支支招，我真怕哪天系统真的撑不住了，我可不想半夜呆办公室疏导系统"交通＂呀。


一点背景资料：

 

[lazycatcat]

借人气问一个Oracle EBS performance 问题：

我们的Oracle EBS application 最近老是出现performance 问题。 用户投诉越来越频繁，老大越来越恼火，我们的日子越来越难过，可是我们不肯定问题原因是什么。只是系统经常很慢，老是一堆pending concurrent job.各处用户投诉一个接一个。

我不懂database，我们DBA 总在提什么我们系统产生的OI是别的N个系统的总和。还有我们的每天大约有37000 个concurrent jobs（有的是我们Scheduled 的，有的是用户manually submit 的，有的是transaction 自动trigger 的。 我们DBA 认为我们应该减少concurrent job 数量，但我们functonal team 研究了又研究，感觉减少不了多少。而且有新的模块要implement，我们一定会有更多的concurrent job 要run 。

总之，现状就是，operation system team 认为operation system 正常，server hardware 也正常，DBA认为他database maintain 够好了，funcitonal team 也不认为减少百十个concurrent job 会解决根本问题。


对了，我们用Oracle 有十多年了。在03，04年做过部分purge。

多谢多谢各路高手，集思广益支支招，我真怕哪天系统真的撑不住了，我可不想半夜呆办公室疏导系统"交通＂呀。


一点背景资料：

Which EBS ? CRM or what ? You mean IO instead of OI ?

For concurrency, the key is number of jobs in a given moment instead of a daily summary. What is peak concurrent job ?

 

[CCL]

Oracle EBS=Oracle e-Business Suite, 是ERP 不是CRM application

我们系统run 24 hour per day. 除了月末月初几天，别的时候白天黑夜都不停有concurrent jobs 被submited，我们没有明显的peak time。 现在感觉是时刻都是peak time。 稍微有个lock 啥的影响一个job，后面的job都会受影响，然后exing循环，最后到一堆concurrent job pending 在那里，系统慢得跟跳太空步似的，我们很多次不得不挑选low risk 的job 一个一个的teminate。

我们想知道是database 需要优化， 老数据需要purge？ 买个大点的server hardware？ 还是别的？ 减少concurrent job 的数量和频率不是长久之计，因为模块和功能会越来越多。

多谢多谢！

 

[lazycatcat]

Oracle EBS=Oracle e-Business Suite, 是ERP 不是CRM application

我们系统run 24 hour per day. 除了月末月初几天，别的时候白天黑夜都不停有concurrent jobs 被submited，我们没有明显的peak time。 现在感觉是时刻都是peak time。 稍微有个lock 啥的影响一个job，后面的job都会受影响，然后exing循环，最后到一堆concurrent job pending 在那里，系统慢得跟跳太空步似的，我们很多次不得不挑选low risk 的job 一个一个的teminate。

我们想知道是database 需要优化， 老数据需要purge？ 买个大点的Do hardware？ 还是别的？ 减少concurrent job 的数量和频率不是长久之计，因为模块和功能会越来越多。

多谢多谢！

ERP is a generic term. EBS includes packages like CRM etc ...

Do you have CPU usage ? If CPU usage is low, then it is probably due to IO and potentially thrashing...Or an unfinished job in the queue is blocking other jobs ...

 

[lazycatcat]

By the way, concurrent jobs mean jobs being scheduled by CPU for service. They are not the jobs all waiting in the queue. I guess you mean the former rather than the latter.

Oracle provides many performance tools and I guess you have used them for diagnosis ?

 

[9981]

你们的系统有cluster么？你说的37000个concurrent job 是指37000个transaction 还是 process? 如果是transaction, 对oracle 数据库应该是很小的case. 一小时都有3600秒呢。

如果你说系统最近变慢， 是不是因为你们最近有release? 还有没有其他系统， 软硬件升级？应该可以有别的系统模拟吧。

我的感觉， 你们可能有某些新release 得 transaction 会 hang 住系统。如果你们用oracle ebs, 一般来说和以前的application系统设置没有太大的变化， 不太可能是application系统设置的问题。况且系统本身一定有设置database connection pool 来manage concurrent task的。再提供一些so far 你们troubleshoot 的信息。

 

[CCL]

不好意思， 我用iphone 上cfc，这样可以打中文，但是无法引用别人的发言。

1. Oracle EBS 一般指Oracle ERP 。 Oracle 的CRM 是近几年买来的，有单独的名字。 我们现在用的是11i。

2.37000是指concurrent request， 不是transactions。 我们一天的transaction 估计是这个数据的好几倍吧。

3. server 两年前升级的，application 是2004升级 的。

4. 我们DBA 试过设置两个Manager 去 manage 不同的concurrent tasks， 但是还是经常莫名其妙的就慢。

我不懂DBA 的东西， 我认为37000 concurrent job per day 一定不过份， 一定有更大的企业run更多的job，我是想找个实例 然后告诉我们DBA： 37000 个job per day 不是问题的原因。

多谢：｠

 

[西迈]

找系统管理员要CPU, MEMORY performance report. DBA也应该有数据.

 

[CCL]

刚联系了国内OSS的一个朋友，明天收集数据给他，然后他会帮我们分析分析。

感谢各位的回复，晚安：）

希望大家同行有机会多交流。：）

 

[David89]

不好意思， 我用iphone 上cfc，这样可以打中文，但是无法引用别人的发言。

1. Oracle EBS 一般指Oracle ERP 。 Oracle 的CRM 是近几年买来的，有单独的名字。 我们现在用的是11i。

2.37000是指concurrent request， 不是transactions。 我们一天的transaction 估计是这个数据的好几倍吧。

3. server 两年前升级的，application 是2004升级 的。

4. 我们DBA 试过设置两个Manager 去 manage 不同的concurrent tasks， 但是还是经常莫名其妙的就慢。

我不懂DBA 的东西， 我认为37000 concurrent job per day 一定不过份， 一定有更大的企业run更多的job，我是想找个实例 然后告诉我们DBA： 37000 个job per day 不是问题的原因。

多谢：｠

You can run some commands to see if the servers (both Application server and database servers) have reached their capacity limitation.

If the servers' CPU usage, memory usage, and disk performace (IO wait, bandwidth usage, read/write latency) look okay, then I would suggest that you ask your DBA to look into some hot spots at the database server level, such as which SQL statements have caused the high IO (looking into the SQL explain plan of the top activities) and which SQL statements blocks others. Based on the findings your DBA will have, he/she may give you or your functional teams some ideas to optimize their SQL statements and transaction logics.

 

[CCL]

谢谢各位。 经过N 多人观察分析测试，问题原因应该找到了：我们的server handle 不了那么多I／O。 我不懂具体原因，总之不是funciton 的问题， 是server 那机器撑不住，到底怎么个撑不住，我不懂也懒得问，今天把所有schedule 的job 都过了一遍，减少run的频率，希望在我值班这周别又玩慢动作。

谢谢各位。：）

 

[lazycatcat]

谢谢各位。 经过N 多人观察分析测试，问题原因应该找到了：我们的server handle 不了那么多I／O。 我不懂具体原因，总之不是funciton 的问题， 是server 那机器撑不住，到底怎么个撑不住，我不懂也懒得问，今天把所有schedule 的job 都过了一遍，减少run的频率，希望在我值班这周别又玩慢动作。

谢谢各位。：）

Another possibility is system and/or program memory - not large enough for caching etc ...

 

[David89]

谢谢各位。 经过N 多人观察分析测试，问题原因应该找到了：我们的server handle 不了那么多I／O。 我不懂具体原因，总之不是funciton 的问题， 是server 那机器撑不住，到底怎么个撑不住，我不懂也懒得问，今天把所有schedule 的job 都过了一遍，减少run的频率，希望在我值班这周别又玩慢动作。

谢谢各位。：）

Inefficient function code (SQL queries and transaction logics) might have caused tons of unnecessary I/O activities. This is an area worth for further investigations.