RAC下的ERP系统 业务繁忙时cpu90%以上,老大们给点建议

rollingpig

1。
PROD1 更多用于查询(Query)
PROD2更多用于修改数据(DML)
这从Load Profile里面的 REDO Size 和 Logical Read可以很轻松的看出来。

2。
至于总体的，相对Server的能力来说，至少在收集的区间里面，系统资源都算得上是绰绰有余, 可能收集的并不是系统最繁忙的时候？
prod 1 :  18 min 的时间 ，12 CPU, 总的server CPU能力是 18.15*60*12= 13000 sec ,而实际的CPU Time 4500 , 也就是 35%的CPU使用率
prod 2 : 22 min , CPU Time 4000, CPU使用率也就25%

3。
parse 方面完全没有问题， Parse CPU to Parse Elapsd % 和 Memory Usage %都不能说明有性能问题
Parse CPU to Parse Elapsd % 一定要和  % Non-Parse CPU一起看才有意义。至于Memory Usage %，高并不代表有问题

4。
Prod 1/2 都有个很明显的Top SQL
  Buffer Gets    Executions  Gets per Exec  %Total Time (s)  Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
     51,145,739           90      568,286.0   67.9  3068.09   3143.19 1016919851
Module: TSORDSHP_NEW
select tov.lot_status , tov.lot_id, tov.lot_no, (tov.loct_onhand
-nvl((select thv.HOLDQTY from tiens_holdquantity_v thv where thv
.item_id=tov.item_id and thv.whse_code=tov.whse_code and thv.LOT
_ID=tov.lot_id and thv.LOT_STATUS=tov.lot_status),0)) usefulqty,
tov.expire_date from tiens_onhandqty_v tov,ic_lots_sts ils wher
处理掉的话会使CPU的总体CPU占有率降低为原来的 1/4左右 ,值得一做。

5。PROD1的另两个Top SQL( order by Read) 处理一下，也就很容易把性能提高很明显
Physical Reads  Executions  Reads per Exec %Total Time (s)  Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
        799,160            1      799,160.0   82.6   285.66   1827.69 1908206396
Module: TSORDWKB
SELECT ord.ORDER_HEADER_ID,ord.ORDER_NUMBER,ord.CUSTOMER_REF_NUM
BER,ord.CUSTOMER_NAME,ord.CURRENCY_CODE,ord.FREIGHT_AMOUNT,ord.C
HARGE_AMOUNT,ord.BONUS_DATE,ord.ORDER_TYPE_MEANING,ord.ORDER_STA
TUS_MEANING,ord.ORDER_DATE,ord.BATCH_NUMBER,ord.CUSTOMER_NAME_EN
,ord.LOCAL_LEVEL_MEANING,ord.GLOBAL_LEVEL_MEANING,ord.HONOR_LEVE

        704,473            8       88,059.1   72.8    78.82    926.22 2979013543
Module: TIENS_INV_INOUT_PKG
SELECT NVL(SUM(IP.LOCT_ONHAND),0) ON_HAND, NVL(SUM(CUX_FUN_GET_C
OST(B.ITEM_ID,IP.WHSE_CODE,SUBSTR('0'||IP.PERIOD,-2)||SUBSTR(IP.
FISCAL_YEAR,-2))*IP.LOCT_ONHAND),0) ON_COST FROM IC_PERD_BAL IP,
IC_ITEM_MST_B B ,IC_WHSE_MST IWM , ORG_ORGANIZATION_DEFINITIONS
OOD WHERE IP.ITEM_ID = B.ITEM_ID AND IP.WHSE_CODE=IWM.WHSE_CODE

rollingpig

总体结论：
Server 没问题， DB 设置没问题， RAC没问题，IO也没有问题，问题就在3个Top SQL上，解决掉即可。

cyt2005

从斑竹的话中学到不少东西。。。

五“宅”一生

受教了，看版主的分析的确是种享受。

jane_oracle

rollingpig ，谢谢你的分析。我也受教了。

chenzhen232

rollingpig 老大终于发话了,谢谢指点.

skelly_huang

从实例1的TOP 5 wait event 中看出
db file scattered read                            118,726       1,164    18.85
db file sequential read                            31,109         241     3.91

建议到v$sqlarea 中找disk_reads+buffer_gets 比较大的SQL

sisney100

原帖由 rollingpig 于 2008-3-13 09:06 发表
总体结论：
Server 没问题， DB 设置没问题， RAC没问题，IO也没有问题，问题就在3个Top SQL上，解决掉即可。

还是集中在这三个top sql上 执行次数不多 但对db buffer的占用相当严重.分析下索引,表结构,查看下执行计划.优化执行避免fts
这三个sql解决了高占用应该会降下来

StudyCow

第一台机器搞定前面的sql就可以了,你的cpu等待
有70%都是这两个sql消耗掉了.

Buffer Gets    Executions  Gets per Exec  %Total Time (s)  Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
     66,366,375          320      207,394.9   44.3   820.03   1027.55  424956757
Module: TSSSC
SELECT /*+index(toh,TIENS_ORDER_HEADERS_N1) */ SUM(TOL.QUANTITY
* NVL(TOL.SHIPPING_SIGN, 1) * DECODE(TOL.LINE_TYPE_ID, 1607, 0,
4318, 0, 1) * DECODE(TOH.ORDER_TYPE_ID, 3752, 0, 1) * NVL((SELEC
T QLL.OPERAND FROM QP_LIST_LINES_V QLL WHERE QLL.LIST_HEADER_ID
= :B5 AND QLL.PRODUCT_ID = TOL.INVENTORY_ITEM_ID AND QLL.PRODUCT

     66,154,947          118      560,635.1   44.2  3882.24   4533.97 1016919851
Module: TSORDSHP_NEW
select tov.lot_status , tov.lot_id, tov.lot_no, (tov.loct_onhand
-nvl((select thv.HOLDQTY from tiens_holdquantity_v thv where thv
.item_id=tov.item_id and thv.whse_code=tov.whse_code and thv.LOT
_ID=tov.lot_id and thv.LOT_STATUS=tov.lot_status),0)) usefulqty,
tov.expire_date from tiens_onhandqty_v tov,ic_lots_sts ils wher

[ 本帖最后由 StudyCow 于 2008-3-13 14:40 编辑 ]

iops

1. 你的问题解决了吗？18分钟的sp, 是你的系统繁忙的时间段吗？
2. 繁忙时间段，应用运行缓慢吗？
3. 建议从系统的负载和sp 结合一起分析，才容易找到瓶颈。
4.  从prd1上看到GMID 大量的读，prd2上的APPLSYSD 有大量的读写， 你的存储系统配置是什么？