DBASK問答集萃

引言

近期咱們對DBASK小程序進行了升級，UI交互作了重大優化調整，對註冊用戶開放知識庫全文檢索功能，引入數據和雲公衆號文章，提問時自動關聯知識庫已知問題，專欄可生成圖片分享給好友，歡迎你們經過微信搜索DBASK體驗。

問答集萃

接下來，咱們分享本期整理出的問題和診斷總結，供你們參考學習，詳細的診斷分析過程能夠經過標題連接跳轉到小程序中查看。

問題1、數據庫夯ORA-00494: enqueue [CF] held for too long
listener不能訪問，重啓lsrnctl restart 無效，最後操做系統重啓後正常，請幫忙分析下緣由。
2019.01.30 02:41接到電話，反映不能使用，erp有畫面報警；我發現db不能鏈接，lsnr 不能服務了。
查詢日誌發現：

Wed Jan 30 
01:02:02 China Standard Time 2019 
ORA-00494: enqueue [CF] held for too long (more than 900 seconds) by 'inst 1, osid 4688'
waited for 'direct path read', seq_num: 10340
for 'rdbms ipc message' count=1 wait_time=3.009785 sec
DB: direct path read 這個值超時。2019-01-30 00:50:24時，有鎖出現 ：
sql::DELETE FROM XXX WHERE XXX<=TO_CHAR(SYSDATE-30,'YYYYMMDD')||' 0000000' AND ROWNUM<1001

有大量鎖表：XXX，接着有XXXX表，用戶FTRPT/sqlplus.exe_程序，XXXXX，XXXXX,一些job等進程鎖，愈來愈多！形成連鎖反映！
詳細日誌以下：

Wed Jan 30 01:02:02 China Standard Time 2019
Errors in file d:\oracle\product\10.2.0\admin\\bdump\_mmon_4704.trc:
ORA-00494: enqueue [CF] held for too long (more than 900 seconds) by 'inst 1, osid 4688'
Wed Jan 30 01:02:02 China Standard Time 2019
System State dumped to trace file d:\oracle\product\10.2.0\admin\\bdump\_mmon_4704.trc
Killing enqueue blocker (pid=4688) on resource CF-00000000-00000000
by killing session 162.1
Killing enqueue blocker (pid=4688) on resource CF-00000000-00000000
by terminating the process
MMON: terminating instance due to error 2103
Wed Jan 30 01:12:05 China Standard Time 2019
USER: terminating instance due to error 1092
Wed Jan 30 01:12:05 China Standard Time 2019
...省略

診斷結論：表象是控制文件的enq，最終鎖定到根源是閃回區清理進程RVWR，清空閃回區問題解決。

問題2、oracle rac ORA-600 : [qerltcUserIterGet_1] ORA-08103
今天經過工具查詢表的數據忽然報錯，詳細以下：

The statement failed with status 8103: 
ORA-08103: object no longer exists for input row 1236. 
(CC_OraStatement::rejectRecord, file CC_OraStatement.cpp, line 1,842）

診斷結論：客戶環境中表空間爲bigfile，設置了maxsize 700G，當前使用率已經99%，在resize爲900G後，錯誤消失，確認爲未知BUG引發。

問題3、數據庫性能問題GC等待嚴重
早上7點左右，系統忽然出現CPU警報，後鏈接失敗，直接鏈接操做系統能夠登陸但操做特別卡頓，後現象消失，後排查，發現告警日誌其中有兩個可疑告警一個是VKTM另一個是01555，目前還不清楚具體是什麼緣由形成？
診斷結論：GC相關的等待嚴重，首先能夠經過參數禁用DRM避免頻繁的GC操做。

問題4、ORA-0600:[kdsgrp1]
open數據庫報錯ORA -0600，詳細日誌以下：

Fri Feb 15 18:44:11 2019
Restarting dead background process CJQ0
Fri Feb 15 18:44:11 2019
CJQ0 started with pid=33, OS id=3992 
Errors in file f:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_cjq0_3992.trc  (incident=210531):
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
Errors in file f:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_cjq0_3992.trc  (incident=210532):
ORA-00600: internal error code, arguments: [600], [ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
], [], [], [], [], [], [], [], [], [], []

診斷結論：索引和表不一致致使，重建該對象全部的索引便可。

問題5、如何在作SPA的時候跳過某條SQL？
問題描述：11202升級12102作SPA性能測試，在12.1的庫上執行dbmssqlpa.executeanalysis_task重演SQL時，一直卡在一個SQL上不動，麻煩問下有什麼方法能暫時跳過這條SQL繼續執行後面的任務嗎？
診斷結論：正在執行的沒辦法干預，能夠在開始以前從視圖中刪除相關SQL，或者設置超時時間。

問題6、SQL的PLAN_HASH_VALUE=0
不少時候發現SQL的PLANHASHVALUE=0，請問是什麼意思？

診斷結論：這個是正常現象，主要發生在不帶查詢的INSERT/DELETE語句、帶綁定變量的SQL僅進行了解析而沒有實際執行。

問題7、awr report SQL 執行次數爲空
如圖，爲何在AWR報告中某些 SQL的 執行次數爲空？

診斷結論：這個問題是多版本致使的，當 VERSION_COUNT 超過200時，Oracle 放棄一些指標的記錄。

問題8、 logmnr未顯示所有dml操做在測試挖掘日誌時，執行了屢次DML操做，可是挖掘後發現只有1條DML語句，請問是什麼緣由？診斷結論：若是不加附加日誌，有的操做可能挖掘不出來。