南通系統(tǒng)性能調(diào)優(yōu)與評估報告

1、南通社保系統(tǒng)性能調(diào)優(yōu)與診斷報告東軟集團股份有限公司2013年12月目 錄1、系統(tǒng)性能問題與解決概述32、系統(tǒng)運行現(xiàn)狀與性能問題分析32.1從系統(tǒng)錯誤日志角度分析32.2從系統(tǒng)參數(shù)角度分析42.3從系統(tǒng)資源角度分析42.4 從應(yīng)用程序效率角度分析53、優(yōu)化方法與結(jié)果53.1資源調(diào)優(yōu)53.2軟件調(diào)優(yōu)74、下一步系統(tǒng)優(yōu)化建議84.1 資源調(diào)整84.2 應(yīng)用調(diào)整95、系統(tǒng)維護(hù)建議95.1空間方面95.2操作系統(tǒng)資源方面95.3系統(tǒng)應(yīng)用阻塞處理106、業(yè)務(wù)模塊SQL語句調(diào)優(yōu)106.1解決放大鏡彈出窗口錄入查詢慢問題106.2靈活就業(yè)人員實收分配146.3解決養(yǎng)老應(yīng)付核定慢問題156.4加快每個業(yè)務(wù)提交記

2、錄日志時間151、 系統(tǒng)性能問題與解決概述自2013年10月以來，南通核心業(yè)務(wù)系統(tǒng)各模塊，尤其是批量業(yè)務(wù)相繼報告越來越慢，尤其養(yǎng)老應(yīng)付核定更是慢的離譜，由自2012年5月系統(tǒng)上線的12分鐘到13年11月份的12小時。因此東軟公司特就此現(xiàn)象組織專門隊伍對業(yè)務(wù)及服務(wù)器運行情況進(jìn)行跟蹤分析，總體評估是南通社保系統(tǒng)硬件平臺資源無法高性能地滿足業(yè)務(wù)高峰時段的辦公要求，調(diào)整與改造已經(jīng)迫在眉睫。同時由于一年多的數(shù)據(jù)積累，以及新區(qū)縣的并入，無論從業(yè)務(wù)量到數(shù)據(jù)量都有了較快的增長，這樣對原有的個別語句和模式提出了更高要求，通過對系統(tǒng)資源的調(diào)整，程序的優(yōu)化使得多數(shù)主要業(yè)務(wù)已經(jīng)完全滿足要求。2、 系統(tǒng)運行現(xiàn)狀與性能問

3、題分析南通業(yè)務(wù)系統(tǒng)的主數(shù)據(jù)庫運行在兩臺16cores ，64g內(nèi)存的ibm570上，目前運行核三3.0系統(tǒng)，主要包括五險和和勞動就業(yè)等，幾乎所有的業(yè)務(wù)系統(tǒng)都運行在這兩臺服務(wù)器上，另外還有兩臺ibm550運行醫(yī)院的托管his，數(shù)據(jù)庫的版本為10.2.0.5，運行的是oracle rac。業(yè)務(wù)系統(tǒng)性能出現(xiàn)嚴(yán)重問題的原因有很多，需要逐個的來排查，主要有以下幾個方面：2.1從系統(tǒng)錯誤日志角度分析l 是否有硬件錯誤？#errpt 未發(fā)現(xiàn)系統(tǒng)有明顯的硬件錯誤，初步排除硬件故障問題。l 是否有系統(tǒng)網(wǎng)絡(luò)丟包現(xiàn)象？#netstat -in未發(fā)現(xiàn)有丟包現(xiàn)象，排除。l 是否有數(shù)據(jù)庫的嚴(yán)重錯誤？通過oracle al

4、ert 日志等分析，未發(fā)現(xiàn)嚴(yán)重的系統(tǒng)錯誤日志。l 是否有數(shù)據(jù)庫bug？經(jīng)發(fā)現(xiàn)有oracle系統(tǒng)的bug，但經(jīng)過在oracle support網(wǎng)站查詢該錯誤，發(fā)現(xiàn)僅僅是一個垃圾輸出問題，并不影響系統(tǒng)性能。因此也排除這個問題。2.2從系統(tǒng)參數(shù)角度分析l 操作系統(tǒng)參數(shù)#prtconf經(jīng)分析未發(fā)現(xiàn)明顯的參數(shù)問題。l 數(shù)據(jù)庫參數(shù)sql>show parameter經(jīng)排查，數(shù)據(jù)庫參數(shù)設(shè)置基本合理，沒有大的問題。 2.3從系統(tǒng)資源角度分析l 通過系統(tǒng)工具topas觀察發(fā)現(xiàn)系統(tǒng)資源明顯短缺主要體現(xiàn)在內(nèi)存和I/O資源匱乏上，以下幾點說明：1、通過操作系統(tǒng)工具觀察高峰時段發(fā)現(xiàn)，db1 64g內(nèi)存幾乎耗盡，一

5、般剩余幾M或十幾M，db2 略有剩余。2、db1系統(tǒng)交換空間使用了18g ，占整體32g的57%，db2還好，但也有20%的swap使用率，這對數(shù)據(jù)庫類型業(yè)務(wù)來說是極其糟糕的，明顯體現(xiàn)內(nèi)存不足，一般理想業(yè)務(wù)系統(tǒng)不可超過10%，否則用戶感覺系統(tǒng)很慢。3、磁盤一直保持繁忙，cpu等待I/O情況很多。4、db1 cpu利用率高峰一般在70-80%左右，db2也能達(dá)到60-70%，雖然沒有體現(xiàn)cpu嚴(yán)重資源不足， 但cpu利用率一旦過70%，前臺的響應(yīng)速度也會受到影響。l 通過統(tǒng)計發(fā)現(xiàn)兩臺數(shù)據(jù)庫服務(wù)器會話過多，嚴(yán)重影響資源利用#ps -ef|grep ora|wc發(fā)現(xiàn)兩臺db 每個的會話連接數(shù)都達(dá)到1

6、200上下，而激活會話不過十幾個到幾十個，多余的連接占用內(nèi)存資源，數(shù)據(jù)庫也需要維護(hù)。l 通過觀察發(fā)現(xiàn)db1比db2上多出兩個資源使用來源一個是數(shù)據(jù)庫復(fù)制軟件dsg，動態(tài)實時做復(fù)制，另外一個是在db1節(jié)點上還有另外一個數(shù)據(jù)庫在運行，版本是oracle9i，主要是老庫，用來備用查詢老數(shù)據(jù)，它的sga區(qū)占4g，有100個左右的連接，占用空間有2T。l 通過觀察數(shù)據(jù)庫表空間發(fā)現(xiàn)資源不足通過觀察發(fā)現(xiàn)業(yè)務(wù)用戶的兩個主要的表空間data和idx都已經(jīng)接近90%，這對I/O數(shù)據(jù)的訪問帶來很大的影響，一般理想情況應(yīng)該不超過60%。2.4 從應(yīng)用程序效率角度分析通過數(shù)據(jù)庫awr報告分析，數(shù)據(jù)庫內(nèi)部慢的等待事件如下

7、圖：如上圖抓拍的等待視圖所示，對系統(tǒng)事件等待情況進(jìn)行分析，發(fā)現(xiàn)系統(tǒng)等待事件最多的是cpu，這說明cpu的運算量比較大，需要重點分析。其次單塊讀占50%多。說明等待事件主要是索引和表rowid讀。這些讀動作其實都是正常I/O操作，而存儲的讀寫性能直接影響這個指標(biāo)，也影響到系統(tǒng)的響應(yīng)速度。一般來說為了減少上述等待事件，都采取兩個動作，一個是調(diào)整索引訪問路徑，使用合理的索引，消除不必要的索引，消除索引碎片，調(diào)整索引和表的存儲參數(shù)等。二是調(diào)整存儲性能，消除硬件瓶頸。3、 優(yōu)化方法與結(jié)果3.1資源調(diào)優(yōu)主要在以下三方面l 消除多余數(shù)據(jù)庫連接通過減少應(yīng)用服務(wù)器中間件連接池的連接數(shù)配置，由原來的每臺1200左

8、右連接，減少到現(xiàn)在的每臺600-700個連接，預(yù)計每臺因此釋放的內(nèi)存資源至少有5g以上。這在很大程度上緩解的內(nèi)存資源的使用，也會使oracle 對swap區(qū)的使用大大減少，調(diào)整后資源如下圖，db1的swap區(qū)由原來57%下降到29%。l 表空間調(diào)整由于快到年終結(jié)轉(zhuǎn)，單位應(yīng)收核定等，會產(chǎn)生大量數(shù)據(jù)，經(jīng)協(xié)調(diào)臨時增加部分空間，已達(dá)到緩解的目的，由原來的表空間利用率89%下降的81%，這樣短缺內(nèi)基本夠用，但i/o性能問題還是不能得到充分緩解。遷移3.2軟件調(diào)優(yōu)由于現(xiàn)場主要反饋的是業(yè)務(wù)模塊運行較慢，模擬測試調(diào)優(yōu)比較困難，所以我們基本采用讓業(yè)務(wù)人員實際運行業(yè)務(wù)我們后臺監(jiān)控運行的方式來進(jìn)行，同時在運行結(jié)束后

9、我們再利用oracle的awr報告反饋的運行期間各種統(tǒng)計信息，進(jìn)一步分析到底哪個包、哪個過程、哪個語句消耗資源，消耗什么資源。軟件調(diào)優(yōu)根據(jù)現(xiàn)場運行情況和業(yè)務(wù)周期來進(jìn)行：12月17-21日，主要對通用查詢、到賬、通用稅票、業(yè)務(wù)日志進(jìn)行分析排查和解決12月 23-28日，主要針對征集、養(yǎng)老核定、到賬實收排查和解決第一周涉及到所有應(yīng)用問題的分析和排查，具體過程如下：第一周解決的問題：1、在通用查詢和個別性能低下語句的排查中，發(fā)現(xiàn)了很多前臺傳參數(shù)和后臺調(diào)用類型不匹配的問題，主要是number型和varchar型的不匹配，這樣導(dǎo)致數(shù)據(jù)庫執(zhí)行計劃的改變，不能用上索引，執(zhí)行效率低下。通過調(diào)整后性能明顯改觀。

10、2、發(fā)現(xiàn)一些不能正確利用索引的現(xiàn)象比如一些給定索引條件在外層，內(nèi)層語句條件無法使用，通過調(diào)整獲得明顯改善。3、發(fā)現(xiàn)有些功能沒有用上，但語句還關(guān)聯(lián)這些視圖，如到賬模塊，南通沒用上壓縮表，但卻關(guān)聯(lián)相關(guān)條件，導(dǎo)致性能大幅下降。通過調(diào)整好，性能大幅得到改善。第一周遺留的問題：1、涉及靈活就業(yè)人員單位編號的查詢問題跟蹤發(fā)現(xiàn)，同樣的sql，在輸入不同aab001單位編號時執(zhí)行計劃是不同的，對于像靈活就業(yè)人員這種大單位（有好幾個是6-7萬人），無論是ab01，還是ab07、ab09等，它們的數(shù)據(jù)量產(chǎn)生的太大，正常關(guān)聯(lián)這些表的aab001的查詢是無法走索引的，而其他單位則可以。因此無法做進(jìn)一步調(diào)優(yōu)。2、到賬實

11、收跟蹤到賬實收性能問題比較棘手，一個是偶爾一天才有幾筆業(yè)務(wù)，有時一天都沒有，因此需跟業(yè)務(wù)人員定好時間才能進(jìn)行。另外，跟蹤發(fā)現(xiàn)總共有四個語句是影響性能的關(guān)鍵，在內(nèi)循環(huán)中，執(zhí)行量比較大，等待事件比較多，如果得到改善那將大大提高效率，但這些語句的執(zhí)行計劃沒問題，因此比較郁悶。第二周涉及到上一周應(yīng)用問題繼續(xù)分析和排查以及新業(yè)務(wù)的跟蹤，具體過程如下：1、征集征集告訴我們的時候，都說是比較慢，每每發(fā)現(xiàn)啟動后都有大量的row lock，但后來我們發(fā)現(xiàn)很多時候oracle rac的兩個節(jié)點都有相同這些業(yè)務(wù)鎖，而且還有很多gc cr request等鎖，這說明是兩個會話在爭奪資源，在殺掉這些資源鎖后，我們讓業(yè)務(wù)

12、人員再做一次業(yè)務(wù)，發(fā)現(xiàn)很快，30分鐘做完。經(jīng)分析，發(fā)現(xiàn)很多時候在系統(tǒng)高峰階段，資源比較匱乏，業(yè)務(wù)人員在做批量業(yè)務(wù)時感覺比較慢，甚至前臺界面都灰掉，他們就關(guān)掉界面，然后再另開一個界面接著做，這樣又一次新提交產(chǎn)生，鎖就出現(xiàn)了，我們上周就發(fā)現(xiàn)業(yè)務(wù)人員連續(xù)提交了三次相同的征集動作，導(dǎo)致大量的行鎖存在。解決辦法是批量最好等資源不忙時做，如果真的無法出來，讓我們后臺人員先清掉占用資源然后再做。否則會堆積很多鎖更加重了系統(tǒng)的資源消耗。2、養(yǎng)老應(yīng)付核定這個問題一開始也是沒好的解決辦法，就是慢。但跟開發(fā)溝通后，打算現(xiàn)場跟蹤調(diào)試，結(jié)果發(fā)現(xiàn)，循環(huán)體有個最重要的條件字段在系統(tǒng)內(nèi)未啟用，每次支付核定時BAE074值默認(rèn)

13、都為0，這樣導(dǎo)致大量的相同的值，但oracle并未給出全表掃描，使用的是索引，因此給大家的感覺執(zhí)行計劃沒問題，實際上每次讀取的數(shù)據(jù)量卻是非常大的，因此，很慢。后來對這些0重新按日期做update，系統(tǒng)由原來的12小時提高到半小時。3、實收劃賬（第一周遺留問題）這個在這周有點眉目了，經(jīng)開發(fā)確認(rèn)，程序中存在在一次實收操作多個靈活就業(yè)人員時，內(nèi)循環(huán)中更新每個人的AB09時使用的BAZ002是相同的。在實收下一個人時，由于傳入?yún)?shù)只有一個，并且是相同的BAZ002，.這樣如果一次實收人數(shù)較多時，同一次業(yè)務(wù)操作多次循環(huán)， AB09會被重復(fù)更新。因此導(dǎo)致每次循環(huán)多讀取、跟新數(shù)據(jù)。系統(tǒng)變慢了，現(xiàn)在程序正在更

14、新測試。，下周應(yīng)該解決了。第二周遺留的問題靈活就業(yè)人員單位人員再細(xì)化分成小單位，以保證相關(guān)模塊的快速查詢。4、 下一步系統(tǒng)優(yōu)化建議目前系統(tǒng)處于平臺資源基本飽和工作情況，我們對影響性能的top-sql做了分析調(diào)優(yōu)工作，但目前代碼的總體優(yōu)化率已經(jīng)很高了，個別語句的調(diào)整空間不大了，不能解決整體性能問題。為了能使系統(tǒng)能維持工作，特提出以下幾點調(diào)優(yōu)建議：4.1 資源調(diào)整l 盡快完成對db1 上oracle9i的遷移工作目前通過調(diào)整使得系統(tǒng)存儲資源剩余有所提升，但利用率仍然達(dá)到81%多，這樣的情況對系統(tǒng)整體性能仍然面臨考驗，尤其2014年1月份，春節(jié)前可能提前做批量業(yè)務(wù)，這對系統(tǒng)資源又是一次沖擊。因此，盡

15、快完成oracle9i老庫的遷移工作，以使系統(tǒng)資源得到充分改善，db1節(jié)點能夠釋放4g的物理內(nèi)存，同時2T的存儲空間可以加入到業(yè)務(wù)的data和idx表空間，這樣對整體系統(tǒng)性能的提升有著明顯的好處，而且對下月的批量業(yè)務(wù)也就沒有擔(dān)心的必要了。l 著眼未來，希望能更新設(shè)備，緩解目前各種平臺資源的不足的問題。4.2 應(yīng)用調(diào)整將靈活就業(yè)人員單位分拆。這個問題是個核心問題，如果分拆成功，那么無論對通用查詢還是其他對業(yè)務(wù)模塊，凡是涉及靈活就業(yè)單位查詢的模塊將有非常大的好處，整體性能將得到進(jìn)一步改善，I/O 性能有個進(jìn)一步提升。5、 系統(tǒng)維護(hù)建議5.1空間方面以下幾方面容易導(dǎo)致系統(tǒng)出現(xiàn)異常，需定時監(jiān)控：l 各

16、表空間使用率監(jiān)控通過em，或其他命令，空間滿，業(yè)務(wù)只能讀，不能寫。l 操作系統(tǒng)各文件系統(tǒng)日志使用情況df -g，主要是根文件系統(tǒng)，如果滿，則操作系統(tǒng)出現(xiàn)異常。l 數(shù)據(jù)庫軟件安裝文件系統(tǒng)這里如果產(chǎn)生大量的oracle trace文件，會導(dǎo)致數(shù)據(jù)hangl 數(shù)據(jù)庫歸檔歸檔滿也會導(dǎo)致數(shù)據(jù)庫hang。5.2操作系統(tǒng)資源方面使用topas或nmon等工具，隨時監(jiān)控系統(tǒng)資源，包括oracle進(jìn)程內(nèi)的所有進(jìn)程對系統(tǒng)資源的損耗。如果發(fā)現(xiàn)高耗cpu、內(nèi)存、I/O、網(wǎng)絡(luò)、swap區(qū)等，及時監(jiān)控，分析來源，如發(fā)現(xiàn)可疑進(jìn)程，及時記錄，以便排查，特殊情況下可殺掉，以釋放資源。5.3系統(tǒng)應(yīng)用阻塞處理l 大量鎖堵塞情況，應(yīng)

17、對措施：第一步，查詢有擁有大量鎖的sid，將其殺掉select * from gv$lock where lmode>0 and  type in ('TM','TX');如果還不行，一個一個重啟應(yīng)用，對于不正常的連接，oracle會回滾事務(wù) l 查找大批耗I/O全表掃描的對象 select inst_id,target,count(*) tt from gv$session_longops group by inst_id,sid,target order by inst_id,tt ;根據(jù)情況可以，影響大則對應(yīng)清除或加上索

18、引。6、 業(yè)務(wù)模塊sql語句調(diào)優(yōu)6.1解決放大鏡彈出窗口錄入查詢慢問題去除視圖內(nèi)的子查詢，使執(zhí)行時不再全表掃描原SQL:create or replace view v_ac01_ae10 asselect C.AAE044 AAE044, C.AAB999 AAB999, AC01.BAZ001 BAZ001, AC01.BAZ002 BAZ002, AC01.AAC001 AAC001, AC01.AAC001 AAC999, AC01.AAC058 AAC058, AC01.AAE135 AAE135, AC01.AAC003 AAC003, AC01.AAC004 AAC004, AC

19、01.AAC005 AAC005, AC01.AAC006 AAC006, AC01.AAC007 AAC007, AC01.AIC162 AIC162, AC01.BAE039 BAE039, AC01.AAC084 AAC084, AC01.AAC009 AAC009, AC01.AAC010 AAC010, AC01.AAC011 AAC011, AC01.BAC024 BAC024, AC01.AAC012 AAC012, AC01.AAC013 AAC013, AC01.AAC014 AAC014, AC01.AAC015 AAC015, AC01.AAC017 AAC017, AC

20、01.AAC020 AAC020, AC01.AAE013 AAE013, AC01.AAB301 AAB301, AC01.AAB034 AAB034, AC01.AKC021 AKC021, AC01.AAC033 AAC033, AC01.BAC057 BAC057, AC01.BAC058 BAC058, AC01.BAC059 BAC059, AC01.BAC060 BAC060, AC01.BAC061 BAC061, AC01.BAC062 BAC062, AC01.AAC028 AAC028, AC01.BAC064 BAC064, AC01.BAC065 BAC065, AC

21、01.AAZ500 AAZ500, AC01.BAB302 BAB302, AC01.BAB303 BAB303, AC01.BAC066 BAC066, AC01.BAC067 BAC067, AC01.BAC130 BAC130, AC01.BAC131 BAC131, AC01.BAC132 BAC132, AC01.BAC140 BAC140, AC01.BAB305 BAB305, AC01.BAB306 BAB306, AC01.BAB307 BAB307, AC01.BAB304 BAB304, AC01.BAC141 BAC141, AC01.AAA027 AAA027, AC

22、01.BAC068 BAC068, AC01.BAC082 BAC082, AC01.BAC083 BAC083, AC01.BAC084 BAC084, AC01.BAC152 BAC152, AC01.BAC085 BAC085, AC01.BAC086 BAC086, AC01.AAE011 AAE011, AC01.AAE036 AAE036, AC01.BAC134 BAC134, AC01.AAC019 AAC019, AC01.BAC020 BAC020, AC01.BAC087 BAC087, AC01.BAC088 BAC088, AC01.BAC089 BAC089, AC

23、01.BAC157 BAC157, AC01.BAC170 BAC170, AC01.BAC133 BAC133, AC01.BAC056 BAC056, AC01.BAC173 BAC173 from ac01, (select distinct AE10.AAE044,AE10.AAB999,AC02.AAC001 from AE10,AC02 where AE10.AAB001 = AC02.AAB001) C where AC01.AAC001 = C.AAC001 AND AC01.BAC062 <> '3'新SQL：reate or replace vi

24、ew v_ac01_ae10 asselect distinct ae10.AAE044 AAE044, ae10.AAB999 AAB999, AC01.BAZ001 BAZ001, AC01.BAZ002 BAZ002, AC01.AAC001 AAC001, AC01.AAC999 AAC999, AC01.AAC058 AAC058, AC01.AAE135 AAE135, AC01.AAC003 AAC003, AC01.AAC004 AAC004, AC01.AAC005 AAC005, AC01.AAC006 AAC006, AC01.AAC007 AAC007, AC01.AI

25、C162 AIC162, AC01.BAE039 BAE039, AC01.AAC084 AAC084, AC01.AAC009 AAC009, AC01.AAC010 AAC010, AC01.AAC011 AAC011, AC01.BAC024 BAC024, AC01.AAC012 AAC012, AC01.AAC013 AAC013, AC01.AAC014 AAC014, AC01.AAC015 AAC015, AC01.AAC017 AAC017, AC01.AAC020 AAC020, AC01.AAE013 AAE013, AC01.AAB301 AAB301, AC01.AA

26、B034 AAB034, AC01.AKC021 AKC021, AC01.AAC033 AAC033, AC01.BAC057 BAC057, AC01.BAC058 BAC058, AC01.BAC059 BAC059, AC01.BAC060 BAC060, AC01.BAC061 BAC061, AC01.BAC062 BAC062, AC01.AAC028 AAC028, AC01.BAC064 BAC064, AC01.BAC065 BAC065, AC01.AAZ500 AAZ500, AC01.BAB302 BAB302, AC01.BAB303 BAB303, AC01.BA

27、C066 BAC066, AC01.BAC067 BAC067, AC01.BAC130 BAC130, AC01.BAC131 BAC131, AC01.BAC132 BAC132, AC01.BAC140 BAC140, AC01.BAB305 BAB305, AC01.BAB306 BAB306, AC01.BAB307 BAB307, AC01.BAB304 BAB304, AC01.BAC141 BAC141, AC01.AAA027 AAA027, AC01.BAC068 BAC068, AC01.BAC082 BAC082, AC01.BAC083 BAC083, AC01.BA

28、C084 BAC084, AC01.BAC152 BAC152, AC01.BAC085 BAC085, AC01.BAC086 BAC086, AC01.AAE011 AAE011, AC01.AAE036 AAE036, AC01.BAC134 BAC134, AC01.AAC019 AAC019, AC01.BAC020 BAC020, AC01.BAC087 BAC087, AC01.BAC088 BAC088, AC01.BAC089 BAC089, AC01.BAC157 BAC157, AC01.BAC170 BAC170, AC01.BAC133 BAC133, AC01.BA

29、C056 BAC056, AC01.BAC173 BAC173 from ac01,AC02,ae10 where AC01.AAC001 = ac02.AAC001 and ac02.aab001 = ae10.AAB001 AND AC01.BAC062 <> '3'6.2靈活就業(yè)人員實收分配在一次實收操作多個靈活就業(yè)人員時，內(nèi)循環(huán)中更新每個人的AB09時使用的BAZ002是相同的。在實收下一個人時，由于傳入?yún)?shù)只有一個，并相同的BAZ002，.這樣如果一次實收人數(shù)較多時，同一次業(yè)務(wù)操作多次循環(huán)， AB09會被重復(fù)更新。UPDATE AB09SET BAE159

30、 = :B1, BAZ002 = PKG_DATA_TYPE.FUN_GETBAZ002WHERE EXISTS (SELECT 1FROM AB07WHERE AB07.BAZ001 = AB09.BAE999AND AB07.BAZ002 = PKG_DATA_TYPE.FUN_GETBAZ002 )AND EXISTS (SELECT 1FROM AB14WHERE AB14.BAE203 = AB09.BAE203AND AB14.BAZ002 = PKG_DATA_TYPE.FUN_GETBAZ002)AND NVL(BAE159, '0') = '1'以下SQL默認(rèn)執(zhí)行計劃走IDX_AB07_AAB001索引，通過加入強制索引 /*+index(ab07 IDX_AB07_TMP)*/ 使讀取數(shù)據(jù)量變小 SELECT /*+index(ab07 IDX_AB07_TMP)*/ SUM(AAE020) INTO N_欠費金額 FROM AB07 WHERE (