單卡12.8TB快閃記憶體卡到底怎麼用？
作者介紹
蔣健，雲趣網路科技聯合創始人，11gOCM，多年Oracle設計、管理及實施經驗，精通資料庫優化，OracleCBO及並行原理，曾為多個行業的客戶的Oracle系統實施小型機到X86跨平臺遷移和資料庫優化服務。雲趣鷹眼監控核心設計和開發者，資深PythonWeb開發者。
一、概述
通常，DBA確定通過Oracle的頂級活動會話圖確定TopSQL，有了SQL的執行會話資訊和SQL文字，可以和開發人員確定TopSQL來自哪些應用模組的。有時候，OracleDBA需要自己確認SQL的來源，本文將演示如何使用Oracle提供豐富的跟蹤功能，來確認遞迴SQL的呼叫者來源。
二、問題描述
通過頂級會話頁面，DBA發現一個異常的TopSQL，SQLID為c7452agj0s0t6，消耗了9%的資料庫時間。
通過 SQL 詳情頁面，可以確定 SQL c7452agj0s0t6 的使用者名稱和模組，但是沒有確定 SQL c7452agj0s0t6 是哪個客戶機器造成的。
從 SQL 的文字中，這是一個針對系統檢視 V$ACTIVE_SESSION_HISTORY 的查詢。
SELECT GROUP_TYPE, BUCKET_START, BUCKET_END, TM_GROUP_TYPE, TM_BUCKET_START,
TM_BUCKET_END, SUM(TM_CPU_FIRST_BUCKET_VALUE) TM_CPU_FIRST_BUCKET_VALUE,
SUM(TM_CPU_MIDDLE_BUCKETS_VALUE) TM_CPU_MIDDLE_BUCKETS_VALUE,
… 省略大量 SQL 文字
FROM TABLE(SYS.GV$(CURSOR(
… 省略大量 SQL 文字
SELECT ASH0.*
FROM V$ACTIVE_SESSION_HISTORY ASH0
… 省略大量 SQL 文字
通過 SQL 的活動會話資訊，可以確定執行該 SQL 的程序為後臺 PZ 程序，這些會話的 QC（query coordinator）不為空，也就是這是針對檢視 V$ACTIVE_SESSION_HISTORY 的並行查詢造成的。因為執行時間很短，並且執行此 SQL 的會話為短連線，無法查詢到 QC 會話的來源。
三、SQLID級別的跟蹤分析
為了確定SQLc7452agj0s0t6的來源，我們使用Oracle11g中的新功能，對單個SQLID開啟10046事件跟蹤，命令如下：
alter system set events ‘sql_trace [sql language=”:c7452agj0s0t6″][/sql] wait=true,bind=true,plan_stat=all_executions,level=12’;
通過以下查詢確定 trace 檔案的產生目錄：
對最新生成的 PRDDB_oraxxx.trc 執行 grep c7452agj0s0t6，找到跟蹤檔案如下，可以確定該的客戶端為 testapp。通過 dep=2，知道 SQL c7452agj0s0t6 為深度二級的遞迴 SQL，並不是使用者直接提交的 SQL。我們依然不知道這個遞迴 SQL 具體由什麼 SQL 呼叫的。
*** 2016-10-14 09:34:13.921
*** SESSION ID:(329.41269) 2016-10-14 09:34:13.921
*** CLIENT ID:() 2016-10-14 09:34:13.921
*** SERVICE NAME:(PRDDB) 2016-10-14 09:34:13.921
*** MODULE NAME:([email protected] (TNS V1-V3)) 2016-10-14 09:34:13.921
*** ACTION NAME:() 2016-10-14 09:34:13.921
… 省略大量文字
=====================
PARSING IN CURSOR #139987897061528 len=11079 dep=2 uid=87 oct=3 lid=87 tim=1476408854404253 hv=3792438054 ad=’21b01ba960′ sqlid=’c7452agj0s0t6′
關閉 SQL ID 跟蹤的命令如下：
alter system set events ‘sql_trace [sql language=”:c7452agj0s0t6″][/sql] off’;
四、會話級別的跟蹤分析
為了確認什麼SQL呼叫了c7452agj0s0t6，我們需要在會話級別開啟10046跟蹤，因為執行SQLc7452agj0s0t6的會話是短連線，我們建立一個針對使用者APPUSER的logon觸發器，下次這個使用者登入時會啟動10046跟蹤。
create or replace trigger sys.set_trace
after logon on database
when (user in (‘APPUSER’)）
declare
begin
execute immediate ‘alter session set statistics_level=all’;
execute immediate ‘alter session set max_dump_file_size=unlimited’;
execute immediate ‘alter session set events ”10046 trace name context forever, level 12”’;
end set_trace;
/
接著，在跟蹤檔案目錄中找到最新生成的跟蹤檔案 PRDDB1_ora_10452.trc 包含 SQL ID c7452agj0s0t6。接著我們使用 orasrp 這個工具分析10046跟蹤檔案. orasrp 為 Oracle Session Resource Profiler，出自一位俄羅斯 DBA 的強大的10046分析工具，網址為：http://oracledba.ru/orasrp/
orasrp PRDDB1_ora_10452.trc PRDDB1_ora_10452.html
orasrp相對於 Oracle 自帶的 tkprof，功能更加強大，其中一大優勢是會生成會話的遞迴呼叫樹。遞迴呼叫樹(Session Call Graph)部分如下圖，SQL hash value=3792438054 為 SQL c7452agj0s0t6，深度為2，頂級的 SQL hash value = 2036392974。
頂級 SQL 文字如下，原來 SQL c7452agj0s0t6 是由 dbms_sqltune.report_sql_monitor 這個生成 SQL Monitor 報告的函式遞迴呼叫的。確定是前幾天新部署的監控 job，在後臺定時抓取和儲存新生成的 SQL monitor 報告，但是執行過於頻繁。解決的方法為降低後臺 job 的執行頻率，對每次抓取 SQL monitor 的執行時間提高限制。
select dbms_sqltune.report_sql_monitor(type=>:1, sql_id=>:2, sql_exec_id=>:3, report_level=>’ALL’) monitor_report from dual;
確定問題來源之後，刪除 logon 觸發器，避免過多的跟蹤檔案產生：
drop trigger sys.set_trace;
五、總結
本文演示瞭如果在Oracle中分別使用SQLID和會話級別的10046跟蹤，以確定遞迴SQL的呼叫源頭來自PL/SQL函式dbms_sqltune.report_sql_monitor。現實工作中，使用類似的方法，可以對PL/SQL程式碼效能，Oracle解析時間過長等疑難雜症進行分析。對於DBA來說，使用orasrp對10046跟蹤檔案生成的遞迴呼叫樹，也是研究應用負載特徵的一個好手段。
文章出處：DBAplus社群（訂閱號ID：dbaplus）