[20180829]減少日誌生成量.txt

[20180829]減少日誌生成量.txt

--//最近一段時間最佳化一下生產資料庫,主要是問題比我預計要嚴重,實際上exadata實在太快了,把許多問題都給掩蓋了.
--//實際上這個問題很早就存在,我實在不想提,基於國內許多應用都可能存在類似問題,還是寫一下.

SQL ordered by Executions

    %CPU - CPU Time as a percentage of Elapsed Time
    %IO - User I/O Time as a percentage of Elapsed Time
    Total Executions: 13,385,158
    Captured SQL account for 65.4% of Total
Executions  Rows Processed     Rows per Exec     Elapsed Time (s)     %CPU     %IO     SQL Id            SQL Module     SQL Text
....
140,257     139,411                     0.99                14.74     101.1      0     5f2atm993xz6w     PORTAL.EXE     update PD_PMXS SET PDBZ =:"SYS..."
140,256     140,256                     1.00                19.11     102        0     bs2qwd0crz5f3     PORTAL.EXE     update PD_DLB SET PDBZ =:"SYS_..."

--//一天不到1萬人次就診,修改PD_DLB表在1個小時內就14萬次,注意看Rows per Exec,每次修改1條.很明顯在做無效刷頻.
--//我曾經跟一些開發講過,在寫程式碼時注意這些刷頻語句.這些語句單條執行很快,但是執行很頻繁,累積起來就很可怕.
--//甚至最終就是這樣執行模式導致執行緩慢..
--//真心感到可悲的是,我們團隊大部分比我熟悉表結構,PD_DLB(排隊表)這個表當天處理完後要刪除裡面的記錄的.
--//也就是最大記錄量當天就診人次,不大可能出現每小時14萬次的修改,這麼多人看awr報表,就沒人注意到這麼簡單的問題嗎?

5f2atm993xz6w
update PD_PMXS SET PDBZ =:"SYS_B_0" , STATUS =:"SYS_B_1" WHERE RDID =:1
修改為
update PD_PMXS SET PDBZ =:"SYS_B_0" , STATUS =:"SYS_B_1" WHERE RDID =:1 and  PDBZ <> :"SYS_B_0" and STATUS <>:"SYS_B_1"

--//錯誤,應該修改如下:

修改為
update PD_PMXS SET PDBZ =:"SYS_B_0" , STATUS =:"SYS_B_1" WHERE RDID =:1 and  (PDBZ,STATUS) not in(( :"SYS_B_0" , :"SYS_B_1" );

bs2qwd0crz5f3
update PD_DLB SET PDBZ =:"SYS_B_0" WHERE RDID =:1  
修改為
update PD_DLB SET PDBZ =:"SYS_B_0" WHERE RDID =:1 and  PDBZ <> :"SYS_B_0"

--//補充一下實際上不能這樣1條1條改,猜測是開啟brid的遊標,然後迴圈修改相關記錄.
--//這樣執行效率很低,而是一氣呵成,一次修改需要的記錄.
--//不想使用logminer探查,隨手找一個brid查詢,使用as of查詢方式.

SELECT ROWID x
        ,versions_starttime
        ,versions_endtime
        ,versions_xid
        ,versions_operation
        ,versions_startscn
        ,versions_endscn
        ,PD_DLB.PDBZ,pd_dlb.*
    FROM PD_DLB VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE;
   WHERE RDID =11327282
ORDER BY versions_endscn;

--//這樣執行10分鐘都沒結果出來,只能改成查詢10分鐘之前的變化.

SELECT ROWID x
        ,versions_starttime
        ,versions_endtime
        ,versions_xid
        ,versions_operation
        ,versions_startscn
        ,versions_endscn
        ,PD_DLB.PDBZ,pd_dlb.*
    FROM PD_DLB VERSIONS BETWEEN TIMESTAMP sysdate-15/1440 and sysdate
   WHERE RDID =11327282
ORDER BY versions_endscn;

--//結果不貼出了.15分鐘內查詢到112條,基本在做無用功.可以看出15*60/112 = 8.035, 8秒有一次重新整理.

SELECT ROWID x
        ,versions_starttime
        ,versions_endtime
        ,versions_xid
        ,versions_operation
        ,versions_startscn
        ,versions_endscn
        ,PD_PMXS.status,PDBZ,PD_PMXS.*
    FROM PD_PMXS VERSIONS BETWEEN TIMESTAMP sysdate-15/1440 and sysdate
   WHERE RDID =11327282
ORDER BY versions_endscn;

--//看到開發這樣寫程式碼,真心的很無語.這樣問題已經存在多年,這麼多人,無數的眼睛在看程式碼沒人提出異議嗎?可悲可嘆..