《單卡12.8TB閃存卡到底怎么用?》要點:
本文介紹了單卡12.8TB閃存卡到底怎么用?,希望對您有用。如果有疑問,可以聯(lián)系我們。
作者介紹
蔣健,云趣網(wǎng)絡(luò)科技聯(lián)合創(chuàng)始人,11gOCM,多年Oracle設(shè)計、管理及實施經(jīng)驗,精通數(shù)據(jù)庫優(yōu)化,OracleCBO及并行原理,曾為多個行業(yè)的客戶的Oracle系統(tǒng)實施小型機到X86跨平臺遷移和數(shù)據(jù)庫優(yōu)化服務(wù).云趣鷹眼監(jiān)控核心設(shè)計和開發(fā)者,資深PythonWeb開發(fā)者.
通常,DBA確定通過Oracle的頂級活動會話圖確定TopSQL,有了SQL的執(zhí)行會話信息和SQL文本,可以和開發(fā)人員確定TopSQL來自哪些應(yīng)用模塊的.有時候,OracleDBA需要自己確認SQL的來源,本文將演示如何使用Oracle提供豐富的跟蹤功能,來確認遞歸SQL的調(diào)用者來源.
通過頂級會話頁面,DBA發(fā)現(xiàn)一個異常的TopSQL,SQLID為c7452agj0s0t6,消耗了9%的數(shù)據(jù)庫時間.
通過 SQL 詳情頁面,可以確定 SQL c7452agj0s0t6 的用戶名和模塊,但是沒有確定 SQL c7452agj0s0t6 是哪個客戶機器造成的.
從 SQL 的文本中,這是一個針對系統(tǒng)視圖 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 的活動會話信息,可以確定執(zhí)行該 SQL 的進程為后臺 PZ 進程,這些會話的 QC(query coordinator)不為空,也就是這是針對視圖 V$ACTIVE_SESSION_HISTORY 的并行查詢造成的.因為執(zhí)行時間很短,并且執(zhí)行此 SQL 的會話為短連接,無法查詢到 QC 會話的來源.
為了確定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 文件的產(chǎn)生目錄:
對最新生成的 PRDDB_oraxxx.trc 執(zhí)行 grep c7452agj0s0t6,找到跟蹤文件如下,可以確定該的客戶端為 testapp.通過 dep=2,知道 SQL c7452agj0s0t6 為深度二級的遞歸 SQL,并不是用戶直接提交的 SQL.我們依然不知道這個遞歸 SQL 具體由什么 SQL 調(diào)用的.
*** 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:(python@testapp (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′
關(guān)閉 SQL ID 跟蹤的命令如下:
alter system set events ‘sql_trace [sql language=”:c7452agj0s0t6″][/sql] off’;
為了確認什么SQL調(diào)用了c7452agj0s0t6,我們需要在會話級別打開10046跟蹤,因為執(zhí)行SQLc7452agj0s0t6的會話是短連接,我們創(chuàng)建一個針對用戶APPUSER的logon觸發(fā)器,下次這個用戶登錄時會啟動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分析工具,網(wǎng)址為:http://oracledba.ru/orasrp/
orasrp PRDDB1_ora_10452.trc PRDDB1_ora_10452.html
orasrp相對于 Oracle 自帶的 tkprof,功能更加強大,其中一大優(yōu)勢是會生成會話的遞歸調(diào)用樹.遞歸調(diào)用樹(Session Call Graph)部分如下圖,SQL hash value=3792438054 為 SQL c7452agj0s0t6,深度為2,頂級的 SQL hash value = 2036392974.
頂級 SQL 文本如下,原來 SQL c7452agj0s0t6 是由 dbms_sqltune.report_sql_monitor 這個生成 SQL Monitor 報告的函數(shù)遞歸調(diào)用的.確定是前幾天新部署的監(jiān)控 job,在后臺定時抓取和保存新生成的 SQL monitor 報告,但是執(zhí)行過于頻繁.解決的方法為降低后臺 job 的執(zhí)行頻率,對每次抓取 SQL monitor 的執(zhí)行時間提高限制.
select dbms_sqltune.report_sql_monitor(type=>:1, sql_id=>:2, sql_exec_id=>:3, report_level=>’ALL’) monitor_report from dual;
確定問題來源之后,刪除 logon 觸發(fā)器,避免過多的跟蹤文件產(chǎn)生:
drop trigger sys.set_trace;
本文演示了如果在Oracle中分別使用SQLID和會話級別的10046跟蹤,以確定遞歸SQL的調(diào)用源頭來自PL/SQL函數(shù)dbms_sqltune.report_sql_monitor.現(xiàn)實工作中,使用類似的方法,可以對PL/SQL代碼性能,Oracle解析時間過長等疑難雜癥進行分析.對于DBA來說,使用orasrp對10046跟蹤文件生成的遞歸調(diào)用樹,也是研究應(yīng)用負載特征的一個好手段.
文章出處:DBAplus社群(訂閱號ID:dbaplus)
轉(zhuǎn)載請注明本頁網(wǎng)址:
http://www.fzlkiss.com/jiaocheng/4382.html