Oracle故障和性能診斷流程V01_20120116

1、1 編寫目的介紹在現(xiàn)場出現(xiàn)Oracle故障和性能問題時(shí)的診斷流程，讓項(xiàng)目支撐人員在解決Oracle問題時(shí)有據(jù)可依。2 適用場景當(dāng)現(xiàn)場出現(xiàn)以下問題時(shí)，可依照本文檔進(jìn)行處理：1） Oracle異常關(guān)閉、重啟、Hang住等故障。2） PM相關(guān)程序出現(xiàn)性能急劇下降的情況。3） PM相關(guān)程序出現(xiàn)Hang住等故障。3 分析流程3.1 信息收集及初步診斷本節(jié)介紹以下知識(shí)點(diǎn)：1） 出現(xiàn)問題時(shí)，需要收集什么樣的信息？2） 這些信息的作用是什么？3） 如何進(jìn)行收集？4） 如何對(duì)這些信息進(jìn)行分析，從而得到初步診斷結(jié)論？初步診斷結(jié)論是指引起問題的原因，但不是根因。例如，初步診斷結(jié)論是內(nèi)存問題、IO問題、等待事件的問題

2、、執(zhí)行計(jì)劃的問題、統(tǒng)計(jì)信息的問題。3.1.1 PM運(yùn)行情況（黃）反映PM運(yùn)行情況的數(shù)據(jù)主要包括運(yùn)行日志以及存儲(chǔ)運(yùn)行數(shù)據(jù)的表（例如COUNTERLOADMESSAGE、SUM_SUMMARYTASKQUEUE表等）。從以上內(nèi)容中，可以分析出PM在運(yùn)行過程中是否有錯(cuò)誤發(fā)生，以及是否存在性能問題。以下內(nèi)容均以C03版本為準(zhǔn)，C02和V4.5可能有變化，需結(jié)合實(shí)際情況作相應(yīng)調(diào)整。1) 如何收集：a) 運(yùn)行日志：加載環(huán)境變量后，使用cd $PM4H_LOG進(jìn)入日志目錄b) 運(yùn)行數(shù)據(jù)表：Table NameSchema NameDescriptionCOUNTERLOADMESSAGEpm4h_db反映入

3、庫程序的運(yùn)行狀態(tài)PILOADMESSAGEpm4h_db反映PIMapping程序的運(yùn)行狀態(tài)SUM_SUMMARYTASKQUEUEpm4h_ad反映匯總程序的運(yùn)行狀態(tài)SUM_BHTASKQUEUEpm4h_ad反映忙時(shí)程序的運(yùn)行狀態(tài)2) 如何分析：a) 運(yùn)行日志：i. 可以使用cat <logfilename> | grep ERROR的方式，搜索指定日志中是否存在錯(cuò)誤信息。<logfilename>可以是具體的日志文件名，也可以是使用了通配符的表達(dá)式。例如搜索所有的匯總?cè)罩局惺欠翊嬖阱e(cuò)誤，可使用如下命令：cat Summarize* | grep ERRORii.

4、如果某個(gè)日志文件中存在ERROR信息，可以使用vi命令編輯該文件，依次輸入/ERROR和回車，搜索ERROR信息，查看詳細(xì)的錯(cuò)誤信息。（/是vi編輯器中的搜索命令）iii. 對(duì)于性能分析，可以分為兩種情況，一種是程序出現(xiàn)Hang住的情況，表現(xiàn)為日志長時(shí)間無內(nèi)容輸出；另一種是程序沒有Hang住，但在單位周期內(nèi)無法處理完一周期的性能數(shù)據(jù)。iv. 出現(xiàn)Hang住的情況時(shí)，可以使用兩種方式找到Hang住的任務(wù)。一種是通過日志分析出當(dāng)前正在執(zhí)行的任務(wù)。以匯總執(zhí)行日志為例，可以分析Hang住時(shí)那一輪的日志中，哪些任務(wù)只有start日志，沒有end日志，這些任務(wù)就是Hang住的任務(wù)；另一種是在DB服務(wù)器上使

5、用top命令查看當(dāng)前正在運(yùn)行的Oracle進(jìn)程，找到進(jìn)程運(yùn)行時(shí)間長的進(jìn)程，并找到進(jìn)程對(duì)應(yīng)的SQL，進(jìn)而分析出Hang住的任務(wù)。v. 出現(xiàn)整體性能下降時(shí)，可以通過其它方面的信息來查找問題。b) 運(yùn)行數(shù)據(jù)表：i. 運(yùn)行數(shù)據(jù)表的數(shù)據(jù)主要用于分析核心模塊的運(yùn)行效率以及工作量的變化。ii. 分析COUNTERLOADMESSAGE表中每天產(chǎn)生的MSG數(shù)量，可以得出入庫程序的工作量和性能情況。PILOADMESSAGE和COUNTERLOADMESSAGE類似。iii. 分析SUM_SUMMARYTASKQUEUE表中每小時(shí)執(zhí)行完成的TASK數(shù)量，可以得出匯總執(zhí)行程序的工作量和性能情況。SUM_BHTAS

6、KQUEUE和SUM_SUMMARYTASKQUEUE類似。3.1.2 操作系統(tǒng)資源情況（孫）l CPUu 信息收集登錄系統(tǒng)后，使用top、vmstat、iostat、mpstat等命令，都可以查看到操作系統(tǒng)的CPU使用情況。相關(guān)的解釋如下。top命令（CPU部分）load averageCPU負(fù)載。1分鐘、5分鐘、15分鐘前到現(xiàn)在的平均值% us用戶進(jìn)程占用CPU百分比% sy內(nèi)核空間占用CPU百分比% ni用戶進(jìn)程空間內(nèi)改變過優(yōu)先級(jí)的進(jìn)程占用CPU百分比% id空閑CPU百分比% wa等待輸入輸出的CPU時(shí)間百分比% hi硬件中斷CPU時(shí)間百分比% si軟件中斷CPU時(shí)間百分比% st虛擬

7、CPU等待實(shí)際CPU的時(shí)間的百分比(Steal Time)表1-1 TOP命令中的CPU信息vmstat命令（CPU部分）usCPU 用戶進(jìn)程使用CPU時(shí)間百分比syCPU 系統(tǒng)進(jìn)程使用CPU時(shí)間百分比idCPU 閑置時(shí)間百分比waCPU 等待輸入輸出的CPU時(shí)間百分比stCPU虛擬CPU等待實(shí)際CPU的時(shí)間的百分比(Steal Time)表1-2 vmstat命令中的CPU信息iostat命令（CPU部分）%user用戶進(jìn)程占用CPU百分比%nice用戶進(jìn)程空間內(nèi)改變過優(yōu)先級(jí)的進(jìn)程占用CPU百分比%system內(nèi)核空間占用CPU百分比%iowait等待輸入輸出的CPU時(shí)間百分比%steal虛

8、擬CPU等待實(shí)際CPU的時(shí)間的百分比(Steal Time)%idle空閑CPU百分比表1-2 iostat命令中的CPU信息u 初步診斷使用CPU利用率和負(fù)載來進(jìn)行CPU的初步診斷。1. CPU利用率的參考值： 正常情況下<=70%1） 如果CPU的利用率長期大約70%，說明CPU的已經(jīng)比較繁忙；2） 如果故障時(shí)刻，連續(xù)超過95%以上，說明可能是CPU存在瓶頸。2. CPU負(fù)載的參考值范圍：CPU核數(shù)*0 - CPU核數(shù)*31） CPU負(fù)載越小越好；如果負(fù)載=CPU核數(shù)，還可以接受；2） 如果負(fù)載>= CPU核數(shù)*3，則說明系統(tǒng)負(fù)載非常高。u 更詳細(xì)的資料，見附錄一TOP命令詳解

9、、附錄二iostat命令詳解、附錄三vmstat命令詳解。l 內(nèi)存u 信息收集登錄系統(tǒng)后，使用top、vmstat、free等命令，都可以查看到操作系統(tǒng)的CPU使用情況。相關(guān)的解釋如下（以free命令為例）。total總計(jì)物理內(nèi)存的大小used已使用多大free可用有多少Shared多個(gè)進(jìn)程共享的內(nèi)存總額Buffers磁盤緩存之：Buffer Cache內(nèi)存數(shù)cached磁盤緩存之：Page Cache內(nèi)存數(shù)表1-3 free命令中的內(nèi)存信息l 更詳細(xì)的資料，見附錄四free命令詳解。u 初步診斷診斷內(nèi)存是是否是瓶頸的標(biāo)準(zhǔn)：swap和+buffers/cache。1） 只要不用swap的交換空

10、間，就不用擔(dān)心自己的內(nèi)存太少。如果常常swap用很多，可能你就要考慮加物理內(nèi)存了。這也是linux看內(nèi)存是否夠用的標(biāo)準(zhǔn)。2） 如果是應(yīng)用服務(wù)器的話，一般只看第二行，+buffers/cache，即對(duì)應(yīng)用程序來說free的內(nèi)存太少了，也是該考慮優(yōu)化程序或加內(nèi)存了。l IOu 信息收集登錄系統(tǒng)后，使用iostat命令獲取服務(wù)器的I/O使用情況。如下：iostat命令rrqm/s每秒進(jìn)行merge的讀操作數(shù)目。即delta(rmerge)/swrqm/s每秒進(jìn)行merge的寫操作數(shù)目。即delta(wmerge)/sr/s每秒完成的讀I/O設(shè)備次數(shù)。即delta(rio)/sw/s每秒完成的寫I/O

11、設(shè)備次數(shù)。即delta(wio)/srsec/s每秒讀扇區(qū)數(shù)。即delta(rsect)/swsec/s每秒寫扇區(qū)數(shù)。即delta(wsect)/srkB/s每秒讀K字節(jié)數(shù)。是rsect/s的一半，因?yàn)槊可葏^(qū)大小為512字節(jié)。wkB/s每秒寫K字節(jié)數(shù)。是wsect/s的一半。avgrq-sz平均每次設(shè)備I/O操作的數(shù)據(jù)大小(扇區(qū))。即delta(rsect+wsect)/delta(rio+wio)avgqu-sz平均I/O隊(duì)列長度。即delta(aveq)/s/1000(因?yàn)閍veq的單位為毫秒)。await平均每次設(shè)備I/O操作的等待時(shí)間(毫秒)。即delta(ruse+wuse)/del

12、ta(rio+wio)svctm平均每次設(shè)備I/O操作的服務(wù)時(shí)間(毫秒)。即delta(use)/delta(rio+wio)%util一秒中有百分之多少的時(shí)間用于I/O操作，或者說一秒中有多少時(shí)間I/O隊(duì)列是非空的。即delta(use)/s/1000(因?yàn)閡se的單位為毫秒)表1-4 iostat命令中的I/O信息u 初步診斷表1-4中是最主要的I/O參數(shù)，使用他們來進(jìn)初步的診斷：1） 如果 %util 接近 100%，說明產(chǎn)生的I/O請(qǐng)求太多，I/O系統(tǒng)已經(jīng)滿負(fù)荷，該磁盤可能存在瓶頸。2） 如果%util接近100%，表明I/O請(qǐng)求太多，I/O系統(tǒng)已經(jīng)滿負(fù)荷，磁盤可能存在瓶頸，一 般%u

13、til大于70%，I/O壓力就比較大，讀取速度有較多的wait.同時(shí)可以結(jié)合vmstat查看查看b參數(shù)(等待資源的進(jìn)程數(shù))和wa參數(shù)(IO 等待所占用的CPU時(shí)間的百分比，高過30%時(shí)IO壓力高)。3） await 的大小一般取決于服務(wù)時(shí)間(svctm) 以及 I/O 隊(duì)列的長度和 I/O 請(qǐng)求的發(fā)出模式。如果 svctm 比較接近 await，說明 I/O 幾乎沒有等待時(shí)間；如果 await 遠(yuǎn)大于 svctm，說明 I/O 隊(duì)列太長，應(yīng)用得到的響應(yīng)時(shí)間變慢。l 持續(xù)收集資源信息u 信息收集需要在系統(tǒng)上部署NMON軟件。具體的部署方法見附錄五NMON的部署方法。u 初步診斷見附錄六NMON的

14、診斷方法3.1.3 Alert日志和Trace文件（孫）u 信息收集收集方法：第一步：ftp到alert日志的目錄，將alert日志收集下來。方法一：Alert日志的目錄可以通過oracle的參數(shù)background_dump_dest找到。如圖1-1所示。方法二：使用這個(gè)語句select value from v$diag_info where name ='Diag Trace'得到alert日志的位置。另外，RAC節(jié)點(diǎn)下的日志文件結(jié)構(gòu)和普通的日志文件結(jié)構(gòu)不一樣。請(qǐng)參考附件附錄五：Oracle RAC集群環(huán)境下日志文件結(jié)構(gòu)。第二步：找到故障發(fā)生時(shí)的時(shí)間段的log日志進(jìn)行分析

15、。第三步：如果通過alert日志看不到具體的信息，可以通過alert日志的提示，轉(zhuǎn)到相應(yīng)的trace文件，進(jìn)行信息收集。示例如下：其中：“/opt/oracle/db/diag/rdbms/vmos5200/vmos52001/trace/vmos52001_ora_8723.trc”和“/opt/oracle/db/diag/rdbms/vmos5200/vmos52001/incident/incdir_28441/vmos52001_ora_8723_i28441.trc”就是trace文件。第四步：也可以登錄網(wǎng)站，查找具體的錯(cuò)誤代碼。例如：錯(cuò)誤代碼：kksfbc-wrong-kkscs

16、flgs。u 初步診斷在alert日志中能夠看到大部分嚴(yán)重錯(cuò)誤、警告，以及一些重要的操作產(chǎn)生的日志。從ORACLE的角度來看，alert日志的信息可以分為如下幾類：Ø 所有的內(nèi)部錯(cuò)誤（ORA-00600），塊損壞錯(cuò)誤（ORA-01578），死鎖（ORA-00060）。Ø 管理性的操作，如create，alter，drop語句和start，shutdown，archivelog語句Ø MTS模式（多線程服務(wù)器。區(qū)別于專用服務(wù)器）下共享服務(wù)器進(jìn)程和調(diào)度進(jìn)程的信息和錯(cuò)誤Ø 自動(dòng)刷新物化視圖時(shí)發(fā)生的錯(cuò)誤Ø 非默認(rèn)的啟動(dòng)參數(shù)Ø 各個(gè)后臺(tái)進(jìn)程運(yùn)行

17、產(chǎn)生的錯(cuò)誤。Oracle的后臺(tái)進(jìn)程見附錄六Oracle的后臺(tái)進(jìn)程。同時(shí)用戶也可以使用Oracle的DBMS_SYSTEM包的KSDWRT過程向alert日志書寫自定義信息Ø Job執(zhí)行失敗錯(cuò)誤從用戶的角度，或者DBA的角度來看，alert日志的信息可以分為如下幾類：1） 故障級(jí)錯(cuò)誤：這種信息需要優(yōu)先定位；故障類信息如：Sat Nov 05 10:13:37 2011Errors in file /opt/oracle/db/diag/rdbms/vmos5200/vmos52001/trace/vmos52001_ora_8723.trc (incident=28441):ORA-0

18、0600: internal error code, arguments: kksfbc-wrong-kkscsflgs, 10327733560, 45, , , , , , , , , Incident details in: /opt/oracle/db/diag/rdbms/vmos5200/vmos52001/incident/incdir_28441/vmos52001_ora_8723_i28441.trc2） 警告級(jí)信息。如：TNS-12535: TNS:operation timed out ns secondary err code: 12606 nt main err c

19、ode: 0 nt secondary err code: 0 nt OS err code: 0 Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=8)(PORT=2243)WARNING: inbound connection timed out (ORA-3136)3） 操作級(jí)信息：Errors in file /opt/oracle/db/diag/rdbms/vmos5200/vmos52001/trace/vmos52001_ora_8480.trc:ORA-00942: table or view does not ex

20、ist更詳細(xì)的信息請(qǐng)參見：1） 附錄七：讀懂a(chǎn)lert日志2） 附錄八：讀懂trace文件3.1.4 AWR報(bào)告（房）3.1.5 ADDM報(bào)告（張）（1）出現(xiàn)問題時(shí)，需要收集什么樣的信息？ADDM(Automatic Database Diagnostic Monitor) 是植入Oracle數(shù)據(jù)庫的一個(gè)自診斷引擎。ADDM 通過檢查和分析AWR獲取的數(shù)據(jù)來判斷Oracle數(shù)據(jù)庫中可能的問題。ADDM會(huì)找到數(shù)據(jù)庫當(dāng)前的瓶頸，找出等待時(shí)間或占用CPU處理時(shí)間較長的事件（比如不合理的SQLID等），并可以給出相應(yīng)的建議，達(dá)到減小系統(tǒng)吞吐量的目的。（2）這些信息的作用是什么？通過ADDM我們可以找到

21、當(dāng)前占用數(shù)據(jù)庫資源的事件，并根據(jù)Oracle自動(dòng)給出這些事件的建議來降低對(duì)系統(tǒng)資源的占用。（3）如何進(jìn)行收集？收集方法：用sqlplus登陸Oracle。輸入?/rdbms/admin/addmrpt準(zhǔn)備生成ADDM報(bào)告SQL> ?/rdbms/admin/addmrptOracle會(huì)把最近的snapshotID號(hào)及對(duì)應(yīng)的時(shí)間段顯示出來，并提示輸入snapshotID。根據(jù)需要診斷的時(shí)間段，輸入需要的snapshotID開始號(hào)和結(jié)束號(hào)。Enter value for begin_snap: 191Enter value for end_snap: 194輸入ADDM報(bào)告的名字，沒有的話O

22、racle會(huì)默認(rèn)為addmrpt_1_（起始snapshot）_（終止snapshot）.txt；這里就用默認(rèn)的，敲回車即可。Oracle會(huì)把ADDM報(bào)告輸出到屏幕上并同時(shí)寫入addmrpt_1_（起始snapshot）_（終止snapshot）.txt文件。生成的文件默認(rèn)在$ORACLE_HOME/rdbms/admin下。這樣ADDM報(bào)告就生成完畢了。（4）如何對(duì)這些信息進(jìn)行分析，從而得到初步診斷結(jié)論？Oracle 11G的ADDM報(bào)告分為3部分：ADDM報(bào)告的生成環(huán)境概述：Analysis Period-AWR snapshot range from 191 to 194.Time pe

23、riod starts at 07-DEC-11 07.00.35 AMTime period ends at 07-DEC-11 10.00.16 AMAnalysis Target-Database 'MOS5200' with DB ID 3304876993.Database version .0.ADDM performed an analysis of instance mos5200, numbered 1 and hosted atcreede.Activity During the Analysis Period-Total database

24、time was 437 seconds.The average number of active sessions was .04.Analysis Period說明ADDM生成的snapshot范圍和時(shí)間段；Analysis Target說明ADDM生成的Oracle實(shí)例、主機(jī)及版本；Activity During the Analysis Period說明ADDM生成的數(shù)據(jù)庫消耗時(shí)間，活動(dòng)回話信息。問題列表（這是ADDM的主要部分）：Summary of Findings- Description Active Sessions Recommendations Percent of Ac

25、tivity - - -1 Top SQL by DB Time .02 | 37.36 52 Hard Parse 0 | 10.74 03 "User I/O" wait Class 0 | 7.81 04 Soft Parse 0 | 4.82 25 Undersized SGA 0 | 4.81 16 Java Execution 0 | 4.3 17 CPU Usage 0 | 2.24 1Summary of Findings是ADDM找出的Oracle存在的瓶頸總覽。下面Description每一行代表一個(gè)導(dǎo)致系統(tǒng)瓶頸的事件、對(duì)系統(tǒng)的影響比例，以及Oracle

26、自己給出建議的條數(shù)。下面就是對(duì)每個(gè)事件的具體分析，拿Top SQL by DB Time這個(gè)首要問題為例： Findings and Recommendations -Finding 1: Top SQL by DB TimeImpact is .02 active sessions, 37.36% of total activity.-SQL statements consuming significant database time were found. Recommendation 1: SQL Tuning Estimated benefit is .01 active sessio

27、ns, 23.39% of total activity. - Action Investigate the SQL statement with SQL_ID "a9bacd1uu35ga" for possible performance improvements. Related Object SQL statement with SQL_ID a9bacd1uu35ga and PLAN_HASH 2060173346. SELECT /*+NESTED_TABLE_GET_REFS+*/ "PM4H_AD"."SYS_INTERGRA

28、TION".* FROM "PM4H_AD"."SYS_INTERGRATION" Rationale SQL statement with SQL_ID "a9bacd1uu35ga" was executed 1 times and had an average elapsed time of 79 seconds. Recommendation 2: SQL Tuning Estimated benefit is 0 active sessions, 9.29% of total activity. - Action

29、Tune the PL/SQL block with SQL_ID "6gvch1xu9ca3g". Refer to the "Tuning PL/SQL Applications" chapter of Oracle's "PL/SQL User's Guide and Reference". Related Object SQL statement with SQL_ID 6gvch1xu9ca3g. DECLARE job BINARY_INTEGER := :job; next_date DATE := :m

30、ydate; broken BOOLEAN := FALSE; BEGIN EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS(); :mydate := next_date; IF broken THEN :b := 1; ELSE :b := 0; END IF; END; Rationale SQL statement with SQL_ID "6gvch1xu9ca3g" was executed 179 times and had an average elapsed time of 0.3 seconds. Recommendat

31、ion 3: SQL Tuning Estimated benefit is 0 active sessions, 5.2% of total activity. - Action Run SQL Tuning Advisor on the SQL statement with SQL_ID "fqmpmkfr6pqyk". Related Object SQL statement with SQL_ID fqmpmkfr6pqyk and PLAN_HASH 2805031759. select s.synonym_name object_name, o.object_t

32、ype from sys.all_synonyms s, sys.all_objects o where s.owner in ('PUBLIC', user) and o.owner = s.table_owner and o.object_name = s.table_name and o.object_type in ('TABLE', 'VIEW', 'PACKAGE','TYPE', 'PROCEDURE', 'FUNCTION', 'SEQUENCE')

33、Action Investigate the SQL statement with SQL_ID "fqmpmkfr6pqyk" for possible performance improvements. Related Object SQL statement with SQL_ID fqmpmkfr6pqyk and PLAN_HASH 2805031759. select s.synonym_name object_name, o.object_type from sys.all_synonyms s, sys.all_objects o where s.owner

34、 in ('PUBLIC', user) and o.owner = s.table_owner and o.object_name = s.table_name and o.object_type in ('TABLE', 'VIEW', 'PACKAGE','TYPE', 'PROCEDURE', 'FUNCTION', 'SEQUENCE') Rationale SQL statement with SQL_ID "fqmpmkfr6pqyk"

35、; was executed 4 times and had an average elapsed time of 3.4 seconds. Recommendation 4: SQL Tuning Estimated benefit is 0 active sessions, 3.35% of total activity. - Action Run SQL Tuning Advisor on the SQL statement with SQL_ID "1rswbxwhbpmr7". Related Object SQL statement with SQL_ID 1r

36、swbxwhbpmr7 and PLAN_HASH 2506064221. select decode(bitand(a.flags, 16384), 0, a.next_run_date, a.last_enabled_time), a.obj#, decode(bitand(a.flags, 16384), 0, 0, 1), a.sch_job from (select p.obj# obj#, p.flags flags, p.next_run_date next_run_date, p.job_status job_status, p.class_oid class_oid, p.l

37、ast_enabled_time last_enabled_time, p.instance_id instance_id, 1 sch_job from sys.scheduler$_job p UNION ALL select q.obj#, q.flags, q.next_run_date, q.job_status, q.class_oid, q.last_enabled_time, q.instance_id, 1 from sys.scheduler$_lightweight_job q UNION ALL select j.job, 0, cast(j.next_date as

38、timestamp with time zone), 1, NULL, cast(j.next_date as timestamp with time zone), NULL, 0 from sys.job$ j where (:1 = 1) and (j.field1 is null or j.field1 = 0) and j.job not in (select v.id2 from v$lock v where v.type = 'JQ') a where bitand(a.job_status, 3) = 1 and (bitand(a.flags, 13421772

39、8 + 268435456) = 0) or (bitand(a.job_status, 1024) <> 0) and bitand(a.flags, 4096) = 0 and a.instance_id is NULL and (a.class_oid is null or (a.class_oid is not null and a.class_oid in (select b.obj# from sys.scheduler$_class b where b.affinity is null) and decode(bitand(a.flags, 16384), 0, a.

40、next_run_date, a.last_enabled_time) = (select min(decode(bitand(c.flags, 16384), 0, c.next_run_date, c.last_enabled_time) from (select r.flags flags, r.next_run_date next_run_date, r.job_status job_status, r.class_oid class_oid, r.last_enabled_time last_enabled_time, r.instance_id instance_id from s

41、ys.scheduler$_job r UNION ALL select s.flags, s.next_run_date, s.job_status, s.class_oid, s.last_enabled_time, s.instance_id from sys.scheduler$_lightweight_job s UNION ALL select 0, cast(k.next_date as timestamp with time zone), 1, NULL, cast(k.next_date as timestamp with time zone), NULL from sys.

42、job$ k where (:2 = 1) and (k.field1 is null or k.field1 = 0) and k.job not in (select w.id2 from v$lock w where w.type = 'JQ') c where bitand(c.job_status, 3) = 1 and (bitand(c.flags, 134217728 + 268435456) = 0) or (bitand(c.job_status, 1024) <> 0) and bitand(c.flags, 4096) = 0 and c.i

43、nstance_id is NULL and (c.class_oid is null or (c.class_oid is not null and c.class_oid in (select d.obj# from sys.scheduler$_class d where d.affinity is null) Action Investigate the SQL statement with SQL_ID "1rswbxwhbpmr7" for possible performance improvements. Related Object SQL stateme

44、nt with SQL_ID 1rswbxwhbpmr7 and PLAN_HASH 2506064221. select decode(bitand(a.flags, 16384), 0, a.next_run_date, a.last_enabled_time), a.obj#, decode(bitand(a.flags, 16384), 0, 0, 1), a.sch_job from (select p.obj# obj#, p.flags flags, p.next_run_date next_run_date, p.job_status job_status, p.class_o

45、id class_oid, p.last_enabled_time last_enabled_time, p.instance_id instance_id, 1 sch_job from sys.scheduler$_job p UNION ALL select q.obj#, q.flags, q.next_run_date, q.job_status, q.class_oid, q.last_enabled_time, q.instance_id, 1 from sys.scheduler$_lightweight_job q UNION ALL select j.job, 0, cas

46、t(j.next_date as timestamp with time zone), 1, NULL, cast(j.next_date as timestamp with time zone), NULL, 0 from sys.job$ j where (:1 = 1) and (j.field1 is null or j.field1 = 0) and j.job not in (select v.id2 from v$lock v where v.type = 'JQ') a where bitand(a.job_status, 3) = 1 and (bitand(

47、a.flags, 134217728 + 268435456) = 0) or (bitand(a.job_status, 1024) <> 0) and bitand(a.flags, 4096) = 0 and a.instance_id is NULL and (a.class_oid is null or (a.class_oid is not null and a.class_oid in (select b.obj# from sys.scheduler$_class b where b.affinity is null) and decode(bitand(a.fla

48、gs, 16384), 0, a.next_run_date, a.last_enabled_time) = (select min(decode(bitand(c.flags, 16384), 0, c.next_run_date, c.last_enabled_time) from (select r.flags flags, r.next_run_date next_run_date, r.job_status job_status, r.class_oid class_oid, r.last_enabled_time last_enabled_time, r.instance_id i

49、nstance_id from sys.scheduler$_job r UNION ALL select s.flags, s.next_run_date, s.job_status, s.class_oid, s.last_enabled_time, s.instance_id from sys.scheduler$_lightweight_job s UNION ALL select 0, cast(k.next_date as timestamp with time zone), 1, NULL, cast(k.next_date as timestamp with time zone

50、), NULL from sys.job$ k where (:2 = 1) and (k.field1 is null or k.field1 = 0) and k.job not in (select w.id2 from v$lock w where w.type = 'JQ') c where bitand(c.job_status, 3) = 1 and (bitand(c.flags, 134217728 + 268435456) = 0) or (bitand(c.job_status, 1024) <> 0) and bitand(c.flags,

51、4096) = 0 and c.instance_id is NULL and (c.class_oid is null or (c.class_oid is not null and c.class_oid in (select d.obj# from sys.scheduler$_class d where d.affinity is null) Rationale SQL statement with SQL_ID "1rswbxwhbpmr7" was executed 209 times and had an average elapsed time of 0.07 seconds. Recommendation 5: SQL Tuning Estimated benefit is 0 active sessions, 3.34% of total activity. - Action Investigate the SQL statement with SQL_ID "3am9cfkvx7gq1" for possible performance im