拜年+散分貼《Oracle SQL_TRACE和10046事件優化SQL例項》
一 資料庫版本
LEO1@LEO1>select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for Linux:Version 11.2.0.1.0 - Production
NLSRTL Version11.2.0.1.0 - Production
二 演示使用SQL_TRACE和10046事件對其它會話進行跟蹤，並給出trace結果
SQL_TRACE：Oracle這個功能主要是為了追蹤SQL的執行過程，分析SQL的效能，資源消耗情況。
1.檢視SQL是如何操作處理資料
2.檢視SQL在執行過程中產生了的等待事件
3.檢視SQL的執行過程資源消耗
4.檢視SQL的實際執行計劃
5.檢視SQL的遞迴語句
6.如果要探索SQL如何執行的可以詳細看看
10046：用於分析SQL執行過程中效能消耗情況，可以檢視繫結變數資訊，可以檢視等待事件資訊，它比SQL_TRACE輸入輸出更多引數。
上述工具使用場合：1.優化SQL語句
2.檢視SQL語句執行計劃
3.跟蹤SQL語句執行過程
4.把會話中SQL的資訊重定向到一個檔案裡
SET AUTO TRACE：1.輸出SQL語句估算的執行計劃（猜出來的）
2.SQL語句並沒有真正執行，只關注這條SQL的執行計劃對不對
3.只是用來估算執行計劃
實驗
使用SQL_TRACE對其它會話進行跟蹤
如果對當前會話進行跟蹤只需alter session set sql_trace=true;即可，如果對其它會話進行跟蹤還需要設定另外一些引數。
我們現在做一下，從144會話跟蹤12會話的SQL
144會話我們使用leo1使用者操作
12會話我們使用leo2使用者操作
144會話
LEO1@LEO1> selectdistinct sid from v$mystat; 可以查詢當前會話ID
SID
----------------
144
我們用會話ID和串號來唯一定位一個會話，現在我們把2個會話資訊都顯示出來了
LEO1@LEO1>select sid,serial# from v$session where sid in (144,12);
SID SERIAL#
---------------------------------
12 4472
144 979
這時我有了一個疑問，定位一個會話一般來說看sid就可以了，那麼為什麼後面還跟著個serial呢，這個serial是幹什麼用的呢，諮詢了一下Alantany 查了一下官方文件
SID NUMBER：Sessionidentifier 就是會話標識
SERIAL# NUMBER ：是用來標識唯一一個會話操作物件的，保證這個會話發出的命令可以正確的應用到對應的會話物件上。
場合 一個會話的結束和另一個會話開始都使用了同一個SID，區分這是2個不同的會話
例子
第一次leonarding登陸sid=12，操作了leo1表，退出
SID SERIAL#
---------------------------------
12 4472
第二次Alan登陸sid=12，又操作了leo2表，退出
SID SERIAL#
---------------------------- ----
12 4777
如果只是看SID我們不能分辨出是誰登入了會話操作了leo1表和leo2表，而serial可以分辨出不同會話的命令正確應用到對應的物件上，區分這是2個不同的人登入的會話。
LEO1@LEO1> droptable leo1; 清理環境
Table dropped.
LEO1@LEO1>create table leo1 as select * from dba_objects; 用leo1使用者建立leo1表
Table created.
LEO1@LEO1>select count(*) from leo1; 看看有多少條記錄
COUNT(*)
----------------
72007
LEO1@LEO1>execute dbms_stats.gather_table_stats('LEO1','LEO1',method_opt=>'for allcolumns size 254');
PL/SQL proceduresuccessfully completed.
隨便做個表分析和直方圖
LEO1@LEO1> conn/ as sysdba 切換為管理員
Connected.
SYS@LEO1> grantexecute on dbms_system to leo1; 授予執行“系統包”的使用者許可權給leo1，必須授予否則報錯
ERROR atline 1:
ORA-06550:line 1, column 7:
PLS-00201:identifier 'DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION' must be declared
ORA-06550:line 1, column 7:
PL/SQL:Statement ignored
SYS@LEO1> connleo1/leo1 我們在切換回來
LEO1@LEO1>execute sys.dbms_system.set_sql_trace_in_session(12,4472,true);
PL/SQL proceduresuccessfully completed.
啟動跟蹤會話ID=12，SERIAL=4472的SQL
宣告：這個儲存過程是SYS使用者特有的，所以在引用時必須帶schema，不帶就會報錯如下
ERROR atline 1:
ORA-06550:line 1, column 7:
PLS-00201:identifier 'SYS.DBMS_SYSTEM' must be declared
ORA-06550:line 1, column 7:
PL/SQL:Statement ignored
12會話
LEO2@LEO1> select /*+ trace_by_leo1_session*/ count(*) from leo1.leo1; leo2使用者查詢leo1表
COUNT(*)
----------------
72007 這是執行了第一條語句
/*+trace_by_leo1_session */ 用來標識這條SQL語句是leo2使用者發出的，查詢的是leo1使用者的表
select /*+trace_by_leo1_session */ count(*) from leo1.leo1 這是執行了第二條語句
select /*+trace_by_leo1_session */ object_type,count(*) from leo1.leo1 group byobject_type
這是執行了第三條語句
我們從trace檔案裡面找一找追蹤到這三條語句了嘛
144會話
LEO1@LEO1>execute sys.dbms_system.set_sql_trace_in_session(12,4472,false);
PL/SQL proceduresuccessfully completed.
關閉跟蹤會話ID=12，SERIAL=4472的SQL（exit sqlplus也可以達到同樣效果）
LEO1@LEO1>select * from v$diag_info where name like 'Default Trace File';
INST_ID NAME VALUE
----------------------------------------------------------------------------------------------------------------------------------------------
1 Default Trace File /u01/app/oracle/diag/rdbms/leo1/LEO1/trace/LEO1_ora_8420.trc
指定當前會話寫入的trace檔案，這裡面就記載了我剛才追蹤的12會話上執行的SQL資訊
如果你用的是Oracle 10g則目錄不同請注意
[oracle@leonarding1~]$ cd /u01/app/oracle/diag/rdbms/leo1/LEO1/trace/
[oracle@leonarding1trace]$ ll | grep LEO1_ora_8420.trc
顯示沒有這個檔案，退出試試
LEO1@LEO1> exit
Disconnected fromOracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With thePartitioning, OLAP, Data Mining and Real Application Testing options
還是沒有，後來我根據執行時間猜出是LEO1_ora_7455.trc這個檔案，不知道是怎麼回事
[oracle@leonarding1trace]$ vim LEO1_ora_7455.trc 我們閱讀一下原始trace檔案
=======================================================================================
PARSING IN CURSOR#4 len=59 dep=0 uid=86 ct=3 lid=86 tim=1360332670938439 hv=3157118559ad='7d950658' sqlid='42nypzay2vmkz'
select/*+ trace_by_leo1_session */ count(*) from leo1.leo1 第一條語句，有1次硬解析
END OF STMT
PARSE#4:c=5000,e=28805,p=0,cr=6,cu=0,mis=1,r=0,dep=0,og=1,plh=4191104944,tim=1360332670938434
EXEC#4:c=0,e=97,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=4191104944,tim=1360332670938668
FETCH#4:c=20997,e=21272,p=0,cr=1031,cu=0,mis=0,r=1,dep=0,og=1,plh=4191104944,tim=1360332670960096
STAT #4 id=1 cnt=1pid=0 pos=1 bj=0 p='SORT AGGREGATE (cr=1031 pr=0 pw=0 time=0 us)'
STAT #4 id=2cnt=72007 pid=1 pos=1 bj=74145 p='TABLE ACCESS FULL LEO1 (cr=1031 pr=0 pw=0 time=623242us cost=288 size=0 card=72007)'
FETCH#4:c=0,e=11,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=4191104944,tim=1360332670960834
*** 2013-02-0822:12:08.997
CLOSE#4:c=0,e=44,dep=0,type=0,tim=1360332728997966
使用的是4號遊標，PARSE #4 解析 -> EXEC #4 執行 -> FETCH #4 取操作 -> CLOSE #4 關閉遊標
=======================================================================================
PARSING IN CURSOR#2 len=59 dep=0 uid=86 ct=3 lid=86 tim=1360330870718759 hv=3157118559 ad='7d950658'sqlid='42nypzay2vmkz'
select/*+ trace_by_leo1_session */ count(*) from leo1.leo1 第二條語句，還有1次硬解析
END OF STMT
PARSE#2:c=3000,e=2516,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=4191104944,tim=1360330870718752
EXEC#2:c=0,e=62,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=4191104944,tim=1360330870719008
FETCH#2:c=19997,e=20021,p=0,cr=1031,cu=0,mis=0,r=1,dep=0,og=1,plh=4191104944,tim=1360330870739148
STAT #2 id=1 cnt=1pid=0 pos=1 bj=0 p='SORT AGGREGATE (cr=1031 pr=0 pw=0 time=0 us)'
STAT #2 id=2cnt=72007 pid=1 pos=1 bj=74145 p='TABLE ACCESS FULL LEO1 (cr=1031 pr=0 pw=0time=477183 us cost=288 size=0 card=72007)'
FETCH#2:c=0,e=6,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=4191104944,tim=1360330870739918
CLOSE#7:c=0,e=37,dep=0,type=0,tim=1360332670909360
使用的是2號遊標，PARSE #2 解析 -> EXEC #2 執行 -> FETCH #2 取操作
=======================================================================================
PARSING IN CURSOR#3 len=92 dep=0 uid=86 ct=3 lid=86 tim=1360332728999761 hv=1179742142ad='7f52a418' sqlid='afbr2j5352vxy'
select/*+ trace_by_leo1_session */ object_type,count(*) from leo1.leo1 group byobject_type
第三條語句
END OF STMT
PARSE#3:c=1000,e=1664,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=908401892,tim=1360332728999755
EXEC#3:c=0,e=102,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=908401892,tim=1360332728999981
FETCH#3:c=38994,e=38233,p=0,cr=1031,cu=0,mis=0,r=1,dep=0,og=1,plh=908401892,tim=1360332729038339
FETCH#3:c=0,e=203,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=1,plh=908401892,tim=1360332729039339
FETCH#3:c=0,e=177,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=1,plh=908401892,tim=1360332729040527
FETCH#3:c=0,e=236,p=0,cr=0,cu=0,mis=0,r=12,dep=0,og=1,plh=908401892,tim=1360332729041957
STAT #3 id=1cnt=43 pid=0 pos=1 bj=0 p='HASH GROUP BY (cr=1031 pr=0 pw=0 time=0 uscost=290 size=387 card=43)'
STAT #3 id=2cnt=72007 pid=1 pos=1 bj=74145 p='TABLE ACCESS FULL LEO1 (cr=1031 pr=0 pw=0time=497135 us cost=288 size=648063 card=72007)'
*** 2013-02-0822:12:21.604
CLOSE #3:c=0,e=34,dep=0,type=0,tim=1360332741604218
使用的是3號遊標，PARSE #3 解析 -> EXEC #3 執行 -> FETCH #3 取操作 -> CLOSE #3 關閉遊標
每次執行都使用了不同的遊標號，由此可見我們順利的跟蹤了12會話SQL
=======================================================================================
這個原始trace檔案內容比較多，不是很好看，需要花很多時間來斟酌，如果想詳細瞭解SQL整個執行過程的話可以慢慢研究一下。下面我們來看用tkprof工具彙總的精簡版report
[oracle@leonarding1trace]$ tkprof LEO1_ora_7455.trc sql_trace.txt sys=no
TKPROF: Release11.2.0.1.0 - Development on Fri Feb 8 22:50:10 2013
Copyright (c)1982, 2009, Oracle and/or its affiliates. All rights reserved.
sys=no 參數列示過濾掉sys使用者生成的遞迴語句，這樣可以精簡出比較好看的報告
[oracle@leonarding1trace]$ vim sql_trace.txt
********************************************************************************
SQL ID:42nypzay2vmkz
Plan Hash:4191104944
select/*+ trace_by_leo1_session */ count(*) from leo1.leo1
call count cpu elapsed disk query current rows
------------- -------- ---------- -------------------- ---------- ----------
Parse 2 0.00 0.02 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 4 0.04 0.04 0 2062 0 2
------------- -------- ---------- -------------------- ---------- ----------
total 8 0.04 0.07 0 2062 0 2
Misses in librarycache during parse: 2 硬解析了2次，說明把上面的2條相同SQL彙總成了一份SQL報告，每條SQL都硬解析了1次
Optimizer mode:ALL_ROWS
Parsing user id:86
Rows Row Source Operation
下面是SQL實際的執行計劃，也有可能與autotrace不同，可以很方便的進行比對研究
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=1031 pr=0 pw=0 time=0 us)
72007 TABLE ACCESS FULL LEO1 (cr=1031 pr=0 pw=0 time=477183 us cost=288 size=0card=72007)
********************************************************************************
SQL ID:afbr2j5352vxy
Plan Hash:908401892
select/*+ trace_by_leo1_session */ object_type,count(*) from leo1.leo1 group byobject_type
call count cpu elapsed disk query current rows
------------- -------- ---------- -------------------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 4 0.03 0.03 0 1031 0 43
------------- -------- ---------- -------------------- ---------- ----------
total 6 0.03 0.04 0 1031 0 43
Misses in librarycache during parse: 1 這條語句也做了1次硬解析
Optimizer mode:ALL_ROWS
Parsing user id:86
Rows Row Source Operation 這個行源操作，就是SQL實際的執行過程
------- ---------------------------------------------------
43 HASH GROUP BY (cr=1031 pr=0 pw=0 time=0 us cost=290 size=387 card=43)
72007 TABLE ACCESS FULL LEO1 (cr=1031 pr=0 pw=0 time=497135 us cost=288size=648063 card=72007)
********************************************************************************
使用10046事件對其它會話進行跟蹤
146會話我們使用leo1使用者操作
12會話我們使用leo2使用者操作
146會話
LEO1@LEO1> selectdistinct sid from v$mystat;
SID
-----------------
146
查詢一下2個會話的ID和SERIAL
LEO1@LEO1>select sid,serial# from v$session where sid in (146,12);
SID SERIAL#
---------------------------- ----
12 4777
146 1035
LEO1@LEO1> droptable leo2; 清理環境
Table dropped.
LEO1@LEO1>create table leo2 as select * from dba_objects; 建立leo2來做測試區別上一個實驗
Table created.
LEO1@LEO1>execute sys.dbms_system.set_ev(12,4777,10046,12,'LEO2');
12：要跟蹤的會話ID
4777：會話串號
10046：事件號
12：level級別
LEO2：跟蹤的使用者名稱，當前使用者可設定為空
宣告：這個儲存過程是SYS使用者特有的，所以在引用時必須帶schema，不帶就會報錯如下
ERROR atline 1:
ORA-06550:line 1, column 7:
PLS-00201:identifier 'DBMS_SYSTEM.SET_EV' must be declared
ORA-06550:line 1, column 7:
PL/SQL:Statement ignored
12會話
LEO2@LEO1>select /*+ 10046_trace_leo2_session */ count(*) from leo1.leo2;
COUNT(*)
----------
72007
/*+10046_trace_leo2_session */用來標識使用10046事件追蹤leo使用者的會話，方便在trace檔案裡找
LEO2@LEO1>select /*+ 10046_trace_leo2_session */ object_type,count(*) from leo1.leo2group by object_type;
OBJECT_TYPE COUNT(*)
-------------------------------------- ----------
EDITION 1
INDEXPARTITION 131
CONSUMERGROUP 25
SEQUENCE 223
TABLEPARTITION 128
SCHEDULE 3
QUEUE 35
RULE 1
JAVA DATA 328
PROCEDURE 160
OPERATOR 55
146會話
LEO1@LEO1>select name,value from v$diag_info where name='Default Trace File';
NAME VALUE
----------------------------------------------------------------------------------------------------------------------------------------------
Default Trace File /u01/app/oracle/diag/rdbms/leo1/LEO1/trace/LEO1_ora_16565.trc
查詢一下當前會話寫入的trace檔案，是不是還是找不到呢，嗯你猜對了
[oracle@leonarding1trace]$ ll | grep LEO1_ora_16565.trc 就像于謙唱的一無所有
LEO1@LEO1> exit leo1使用者退出
Disconnected fromOracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With thePartitioning, OLAP, Data Mining and Real Application Testing options
LEO2@LEO1> exit leo2使用者退出
Disconnected fromOracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With thePartitioning, OLAP, Data Mining and Real Application Testing options
[oracle@leonarding1trace]$ ll | grep LEO1_ora_16565.trc 腫麼還是木有呢，看來還滴猜
我這塊的trace檔案沒有生成，我查詢了臨近的所有原始檔案都沒有找到，知道原委的朋友可請教哦有加分滴！
三 演示10046 level 1,4,8,12的區別
10046事件不同級別：追蹤的資訊不同
Level 1：等同於SQL_TRACE
Level 4：在Level1的基礎上增加收集繫結變數的資訊
Level 8：在Level1的基礎上增加等待事件的資訊，這個有用，如果一條SQL語句非常非常慢，可以查一下是什麼原因導致的如此慢
Level 12：等同於Level 4+Level 8，即同時收集繫結變數資訊和等待事件資訊
彙總：級別高的概括級別低的
實驗
10046 Level 1
這個級別的trace資訊和SQL_TRACE中的內容是一致的，我們可以用一個繫結變數SQL來測試一下效果
LEO1@LEO1> setlinesize 300 調整格式
LEO1@LEO1> setpagesize 999
LEO1@LEO1>variable i number; 定義變數
LEO1@LEO1>execute :i:=100; 變數賦值
PL/SQL proceduresuccessfully completed.
LEO1@LEO1>alter session set events '10046 trace name context forever,level 1';
Oracle 下所有啟動事件的通用格式，級別為1
Session altered.
LEO1@LEO1>select * from leo2 where object_id=:i; 繫結變數，重用SQL執行計劃
OWNER OBJECT_NAME SUBOBJECT_NAME OBJECT_ID DATA_OBJECT_IDOBJECT_TYPE CREATED LAST_DDL_ TIMESTAMP STATUS T G S
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------- -------------- ---------------------------- --------- ------------------- ------- - - -
NAMESPACE EDITION_NAME
---------- ------------------------------
SYS ORA$BASE 100 EDITION 15-AUG-09 15-AUG-092009-08-15:00:16:54 VALID N N N
64
LEO1@LEO1>alter session set events '10046 trace name context off'; 關閉10046事件
Session altered.
LEO1@LEO1>select name,value from v$diag_info where name='Default Trace File';
NAME VALUE
----------------------------------------------------------------------------------------------------------------------------------------------
Default Trace File /u01/app/oracle/diag/rdbms/leo1/LEO1/trace/LEO1_ora_25998.trc
當前會話寫入的trace檔案
LEO1@LEO1> !vim/u01/app/oracle/diag/rdbms/leo1/LEO1/trace/LEO1_ora_25998.trc 我們看一下原始trace檔案
====================================================================================
PARSING IN CURSOR#2 len=37 dep=0 uid=85 ct=3 lid=85 tim=1360372361916503 hv=21593726ad='7da84c28' sqlid='4z9c6ch0nkzmy'
select *from leo2 where object_id=:i 我們看不到繫結變數值，只能看到它是一個繫結變數
END OF STMT
PARSE #2:c=2999,e=7530,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=1360372361916485
EXEC#2:c=2999,e=2920,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2258638698,tim=1360372361920321
FETCH#2:c=0,e=458,p=0,cr=5,cu=0,mis=0,r=1,dep=0,og=1,plh=2258638698,tim=1360372361928304
FETCH#2:c=20996,e=22661,p=0,cr=1027,cu=0,mis=0,r=0,dep=0,og=1,plh=2258638698,tim=1360372361953093
STAT #2 id=1 cnt=1pid=0 pos=1 bj=74150 p='TABLE ACCESS FULL LEO2 (cr=1032 pr=0 pw=0 time=0 uscost=288 size=97 card=1)'
*** 2013-02-0909:13:00.053
CLOSE #2:c=0,e=66,dep=0,type=0,tim=1360372380053747
使用的是2號遊標，PARSE #2 解析 -> EXEC #2 執行 -> FETCH #2 取操作 -> CLOSE #2關閉遊標
SQL_TRACE和10046事件內容是按時間順序列印出來的，過程如上所示
mis=1 我們進行了一次硬解析
在Level 1 下是看不到繫結變數值是多少的，只能看到有存在繫結變數
=====================================================================================
10046 Level 4
在這個級別中我們就可以看到繫結變數資訊了
LEO1@LEO1>alter session set events '10046 trace name context forever,level 4'; 我們設定級別為4
Session altered.
LEO1@LEO1>select * from leo2 where object_id=:i; 繼續繫結變數
OWNER OBJECT_NAME SUBOBJECT_NAME OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE CREATED LAST_DDL_ TIMESTAMP STATUS T G S
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------- -------------- ------------------- ------------------ ------------------- ------- - - -
NAMESPACE EDITION_NAME
----------------------------------------
SYS ORA$BASE 100 EDITION 15-AUG-09 15-AUG-092009-08-15:00:16:54 VALID N N N
64
LEO1@LEO1>alter session set events '10046 trace name context off'; 關閉10046事件
Session altered.
LEO1@LEO1>select name,value from v$diag_info where name='Default Trace File';
NAME VALUE
----------------------------------------------------------------------------------------------------------------------------------------------
Default Trace File /u01/app/oracle/diag/rdbms/leo1/LEO1/trace/LEO1_ora_25998.trc
還是同一個trace檔案
LEO1@LEO1> !vim/u01/app/oracle/diag/rdbms/leo1/LEO1/trace/LEO1_ora_25998.trc 開啟trace瞧一瞧
=======================================================================================
PARSING IN CURSOR#4 len=37 dep=0 uid=85 ct=3 lid=85 tim=1360373199428632 hv=21593726ad='7da84c28' sqlid='4z9c6ch0nkzmy'
select *from leo2 where object_id=:i
END OF STMT
PARSE#4:c=0,e=254,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2258638698,tim=1360373199428619
BINDS#4: 繫結的是4號遊標
Bind#0 0表示繫結的第一個變數 如果是1表示繫結的第二個變數，以此類推
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00pre=00
oacflg=03 fl2=1000000 frm=00 csi=00 siz=24off=0
kxsbbbfp=7f2e8344efa0 bln=22 avl=02 flg=05
value=100 這就是繫結的變數值
EXEC#4:c=2000,e=31957,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2258638698,tim=1360373199461116
FETCH#4:c=1000,e=730,p=0,cr=5,cu=0,mis=0,r=1,dep=0,og=1,plh=2258638698,tim=1360373199462378
FETCH#4:c=25996,e=26510,p=0,cr=1027,cu=0,mis=0,r=0,dep=0,og=1,plh=2258638698,tim=1360373199491356
STAT #4 id=1 cnt=1pid=0 pos=1 bj=74150 p='TABLE ACCESS FULL LEO2 (cr=1032 pr=0 pw=0 time=0 uscost=288 size=97 card=1)'
*** 2013-02-0909:26:48.104
CLOSE#4:c=0,e=66,dep=0,type=1,tim=1360373208104843
mis=0 由於剛才我們已經硬解析過了，這次直接軟解析，即SQL執行計劃重用
這次使用的是4號遊標，這個遊標號是可以重複使用的，級別4就增加了繫結變數資訊
=======================================================================================
10046 Level 8
這個級別中，可以顯示SQL語句等待事件，我們就可以知道SQL語句是在等待某些資源，還是沒有等待資源速度就是這樣了，只能提升硬體
LEO1@LEO1>alter session set events '10046 trace name context forever,level 8'; 級別為8
Session altered.
LEO1@LEO1>select count(*) from leo2 where object_id=:i group by object_name; 執行SQL
COUNT(*)
----------
1
LEO1@LEO1>alter session set events '10046 trace name context off'; 關閉10046事件
Session altered.
LEO1@LEO1>select name,value from v$diag_info where name='Default Trace File';
NAME VALUE
----------------------------------------------------------------------------------------------------------------------------------------------
Default Trace File /u01/app/oracle/diag/rdbms/leo1/LEO1/trace/LEO1_ora_25998.trc
LEO1@LEO1> !vim/u01/app/oracle/diag/rdbms/leo1/LEO1/trace/LEO1_ora_25998.trc 我們定眼觀瞧
======================================================================================
PARSING IN CURSOR#4 len=65 dep=0 uid=85 ct=3 lid=85 tim=1360373900654762 hv=3813172666ad='7dbb2f78' sqlid='fr4tufgjnhtdu'
selectcount(*) from leo2 where object_id=:i group by object_name
END OF STMT
PARSE#4:c=1999,e=1923,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=1360373900654751
EXEC#4:c=5000,e=5370,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=2474819896,tim=1360373900660419
WAIT #4:nam='SQL*Net message to client'ela= 17 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1360373900661831
FETCH #4:c=20997,e=20590,p=0,cr=1031,cu=0,mis=0,r=1,dep=0,og=1,plh=2474819896,tim=1360373900682600
WAIT #4:nam='SQL*Net message from client'ela= 1168 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1360373900684127
FETCH#4:c=1000,e=245,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2474819896,tim=1360373900684583
STAT #4 id=1 cnt=1pid=0 pos=1 bj=0 p='HASH GROUP BY (cr=1031 pr=0 pw=0 time=0 us cost=289size=30 card=1)'
STAT #4 id=2 cnt=1pid=1 pos=1 bj=74150 p='TABLE ACCESS FULL LEO2 (cr=1031 pr=0 pw=0 time=0 uscost=288 size=30 card=1)'
WAIT #4:nam='SQL*Net message to client' ela= 14 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1360373900685343
*** 2013-02-0909:38:28.482
WAIT #4:nam='SQL*Net message from client' ela= 7797435 driver id=1650815232 #bytes=1p3=0 obj#=-1 tim=1360373908482852
CLOSE#4:c=0,e=90,dep=0,type=0,tim=1360373908483370
這次還是重用4號遊標，標紅的都是標識SQL語句WAIT等待事件，這幾個等待事件都是正常的等待客戶端傳送命令的事件，說明我們的SQL語句效率都挺高的
======================================================================================
10046 Level 12
這個級別即可以顯示繫結變數，又可以顯示等待事件
LEO1@LEO1>alter session set events '10046 trace name context forever,level 12'; 現在級別可為12
Session altered.
LEO1@LEO1>select count(*) from leo2 where object_id=:i group by object_name;
COUNT(*)
----------
1
LEO1@LEO1>alter session set events '10046 trace name context off'; 關閉10046事件
Session altered.
LEO1@LEO1>select name,value from v$diag_info where name='Default Trace File';
NAME VALUE
----------------------------------------------------------------------------------------------------------------------------------------------
Default Trace File /u01/app/oracle/diag/rdbms/leo1/LEO1/trace/LEO1_ora_25998.trc
LEO1@LEO1> !vim/u01/app/oracle/diag/rdbms/leo1/LEO1/trace/LEO1_ora_25998.trc 我們再次觀瞧
==================================================================================
PARSING IN CURSOR#2 len=65 dep=0 uid=85 ct=3 lid=85 tim=1360375064416180 hv=3813172666ad='7dbb2f78' sqlid='fr4tufgjnhtdu'
select count(*)from leo2 where object_id=:i group by object_name
END OF STMT
PARSE#2:c=0,e=266,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2474819896,tim=1360375064416167
BINDS#2: 這是繫結變數的資訊
Bind#0 0表示繫結的第一個變數
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00pre=00
oacflg=03 fl2=1000000 frm=00 csi=00 siz=24off=0
kxsbbbfp=7f2e834ccec8 bln=22 avl=02 flg=05
value=100 變數值
EXEC#2:c=1000,e=639,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2474819896,tim=1360375064417345
WAIT #2:nam='SQL*Net message to client' ela= 18 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1360375064417579
FETCH#2:c=18997,e=20107,p=0,cr=1031,cu=0,mis=0,r=1,dep=0,og=1,plh=2474819896,tim=1360375064437826
WAIT #2:nam='SQL*Net message from client' ela= 846 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1360375064439398
FETCH#2:c=0,e=127,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2474819896,tim=1360375064439680
STAT #2 id=1 cnt=1pid=0 pos=1 bj=0 p='HASH GROUP BY (cr=1031 pr=0 pw=0 time=0 us cost=289size=30 card=1)'
STAT #2 id=2 cnt=1pid=1 pos=1 bj=74150 p='TABLE ACCESS FULL LEO2 (cr=1031 pr=0 pw=0 time=0 uscost=288 size=30 card=1)'
WAIT #2:nam='SQL*Net message to client' ela= 18 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1360375064440089
又有等待事件的資訊，也是我們常用的級別
*** 2013-02-0909:57:52.607
WAIT #2:nam='SQL*Net message from client' ela= 8167539 driver id=1650815232 #bytes=1p3=0 obj#=-1 tim=1360375072607728
CLOSE#2:c=0,e=129,dep=0,type=0,tim=1360375072608199
這次使用的是2號遊標，PARSE #2 馬上 EXEC #2 執行 FETCH #2 取操作 緊接著輸出執行計劃
==================================================================================
小結：到此我們完成了1~12級別的對比說明，10046事件是我們非常常用的優化SQL的監控工具，而我們最常用的是級別12，有了這些資訊我們就可以遊刃有餘的分析和改善SQL效能
四 自己構造兩條完全同樣功能的SQL，通過對SQL_TRACE產生的trace檔案的分析，比較它們的效能憂劣。
LEO1@LEO1> droptable leo4 purge; 清空環境
Table dropped.
LEO1@LEO1>create table leo4 as select * from dba_objects; 建立leo4表
Table created.
LEO1@LEO1> altersession set sql_trace=true; 啟動SQL_TRACE
Session altered.
LEO1@LEO1>select count(*) from leo4; 功能：統計全表總記錄數
COUNT(*)
---------------------
71968
LEO1@LEO1>select sum(count_id) from (select count(object_id) count_id from leo4 group byobject_type);
SUM(COUNT_ID) 功能一樣但消耗的資源不同，說明了SQL功能性和優化性同等重要
----------------------
71968
LEO1@LEO1>alter session set sql_trace=false; 關閉SQL_TRACE
Session altered.
LEO1@LEO1>select name,value from v$diag_info where name='Default Trace File';
NAME VALUE
----------------------------------------------------------------------------------------------------------------------------------------------
Default Trace File /u01/app/oracle/diag/rdbms/leo1/LEO1/trace/LEO1_ora_25998.trc
[oracle@leonarding1trace]$ tkprof LEO1_ora_25998.trc 25998_2.txt
TKPROF: Release11.2.0.1.0 - Development on Tue Feb 12 17:38:34 2013
Copyright (c)1982, 2009, Oracle and/or its affiliates. All rights reserved.
********************************************************************************
SQL ID:7hruqqqzx2zs7
Plan Hash:3210696650
selectcount(*) from leo4
call count cpu elapsed disk query current rows
------------- -------- ---------- -------------------- ---------- ----------
Parse 1 0.00 0.00 0 1 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.03 0.03 722 1030 0 1
------------- -------- ---------- -------------------- ---------- ----------
total 4 0.03 0.03 722 1031 0 1
Misses in librarycache during parse: 1
Optimizer mode:ALL_ROWS
Parsing user id:85
Rows Row Source Operation
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=1030 pr=722 pw=0 time=0 us)
71968 TABLE ACCESS FULL LEO4 (cr=1030 pr=722 pw=0 time=825511 us cost=287size=0 card=77424)
1.有1次硬解析
2.cpu time 和 elapsed time 0.03
3.行源操作只有2步就可完成
4.cr=1030 一個指標
5.由於是第一次統計，所以產生了pr=722次物理讀
***************************************************************************************
SQL ID:9zhvsut63s579
Plan Hash:2452925700
selectsum(count_id) from (select count(object_id) count_id from leo4 group byobject_type)
call count cpu elapsed disk query current rows
------------- -------- ---------- -------------------- ---------- ----------
Parse 1 0.00 0.00 0 1 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.04 0.04 0 1030 0 1
------------- -------- ---------- -------------------- ---------- ----------
total 4 0.04 0.04 0 1031 0 1
Misses in librarycache during parse: 1
Optimizer mode:ALL_ROWS
Parsing user id:85
Rows Row Source Operation
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=1030 pr=0 pw=0 time=0 us)
43 VIEW (cr=1030 pr=0 pw=0 time=588us cost=290 size=1006512 card=77424)
43 HASH GROUP BY (cr=1030 pr=0 pw=0 time=210 us cost=290 size=1858176card=77424)
71968 TABLE ACCESS FULL LEO4 (cr=1030 pr=0 pw=0 time=694104 us cost=287size=1858176 card=77424)
1.有1次硬解析
2.cpu time 和 elapsed time 0.04
3.行源操作需要處理4步才能完成，因此所用時間就會較長，效率較低
4.cr=1030 四個指標
5.由於是第二次統計，所以沒有物理讀，但所用的耗時卻多
***************************************************************************************
五 做一個較大的查詢，分析sql_trace的原始檔案，對整個trace檔案的各部分內容進行語言性描述，特別留意資料處理過程中產生的等待事件及時長，思考整個過程中最消耗時間的操作是什麼？
實驗
LEO1@LEO1> droptable leo3 purge; 清理環境
Table dropped.
LEO1@LEO1>create table leo3 as select * from dba_objects; 建立leo3表
Table created.
LEO1@LEO1>insert into leo3 select * from leo3;
72007 rowscreated.
LEO1@LEO1>insert into leo3 select * from leo3;
144014 rowscreated.
LEO1@LEO1>insert into leo3 select * from leo3;
288028 rowscreated.
LEO1@LEO1>select count(*) from leo3; 我們插入了57w條資料
COUNT(*)
----------------
576056
LEO1@LEO1> altersession set sql_trace=true; 啟動追蹤SQL功能
Session altered.
LEO1@LEO1>select count(*) from (select * from leo3 order by object_id) a,(select * fromleo3 order by object_id) b where a.object_id=b.object_id; 執行一次大查詢
COUNT(*)
-----------------
4608448
LEO1@LEO1> altersession set sql_trace=false; 關閉追蹤SQL功能
Session altered.
退出SQLPLUS同樣效果EXIT
LEO1@LEO1>select name,value from v$diag_info where name='Default Trace File';
NAME VALUE
----------------------------------------------------------------------------------------------------------------------------------------------
Default Trace File /u01/app/oracle/diag/rdbms/leo1/LEO1/trace/LEO1_ora_25998.trc
當前會話預設寫入的trace檔案
我們來看看原始trace檔案的內容
[oracle@leonarding1trace]$ vim LEO1_ora_25998.trc
=======================================================================================
PARSING IN CURSOR#4 len=549 dep=1 uid=85 ct=3 lid=85 tim=1360643355379273 hv=1384619666 ad='7f537b20'sqlid='cy3wbyd98g7nk'
SELECT/* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE NO_PARALLEL(SAMPLESUB)opt_param('parallel_execution_enabled', 'false') NO_PARALLEL_INDEX(SAMPLESUB)NO_SQL_TUNE */ NVL(SUM(C1),:"SYS_B_0"),NVL(SUM(C2),:"SYS_B_1"), COUNT(DISTINCT C3), NVL(SUM(CASE WHEN C3 ISNULL THEN :"SYS_B_2" ELSE :"SYS_B_3"END),:"SYS_B_4") FROM (SELECT /*+ NO_PARALLEL("LEO3")FULL("LEO3") NO_PARALLEL_INDEX("LEO3") */ :"SYS_B_5"AS C1, :"SYS_B_6" AS C2, "LEO3"."OBJECT_ID" AS C3FROM "LEO3" SAMPLE BLOCK (:"SYS_B_7" ,:"SYS_B_8") SEED (:"SYS_B_9") "LEO3") SAMPLESUB
END OFSTMT
PARSE#4:c=0,e=649,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=1,plh=0,tim=1360643355379266
EXEC#4:c=1999,e=1465,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=1,plh=893701161,tim=1360643355380831
FETCH#4:c=9998,e=11132,p=20,cr=85,cu=0,mis=0,r=1,dep=1,og=1,plh=893701161,tim=1360643355392015
STAT #4 id=1 cnt=1pid=0 pos=1 bj=0 p='SORT AGGREGATE (cr=85 pr=20 pw=0 time=0 us)'
STAT #4 id=2cnt=4702 pid=1 pos=1 bj=0 p='VIEW VW_DAG_0 (cr=85 pr=20 pw=0 time=125529 us cost=5 size=31356 card=603)'
STAT #4 id=3cnt=4702 pid=2 pos=1 bj=0 p='HASH GROUP BY (cr=85 pr=20 pw=0 time=25919 uscost=5 size=15075 card=603)'
STAT #4 id=4cnt=4764 pid=3 pos=1 bj=74154 p='TABLE ACCESS SAMPLE LEO3 (cr=85 pr=20 pw=0time=59412 us cost=4 size=15075 card=603)'
CLOSE#4:c=0,e=24,dep=1,type=0,tim=1360643355392298
PARSING IN CURSOR部分
說明：使用的是4號遊標，這個遊標號是可以重用的，這個遊標指向的是我們執行的SQL產生的遞迴語句（紅色部分），它是把物件屬性寫入資料字典中進行登記，好為以後的應用做語法語義校驗的
len=549 執行的SQL長度
dep=1 遞迴的SQL深度，1層遞迴
uid=85 使用者id 85代表leo1使用者
oct=3 oracle commend type 命令型別
lid=85 私有使用者id 85也代表leo1使用者
tim=1360643355379273 時間戳
hv=1384619666 have value SQL的雜湊值
ad='7f537b20' SQL address SQL的地址
STAT 部分
id=1 執行計劃的行源號，每一層都有一個號，從上往下 1 2 3 4 排列
cnt=1 當前行源號返回的行數
pid=0 行源號的父號，如果當前行源號是4 父號就是3 是1父號就是0
這也標識了執行計劃的執行順序4 -> 3 -> 2 -> 1
obj=74154 當前操作的物件id
LEO1@LEO1>select object_name from dba_objects where object_id=74154;這就是剛才我們操作的表名
OBJECT_NAME
--------------------
LEO3
op=TABLE ACCESSSAMPLE LEO3全表掃描 行源的資料處理方式（也叫操作方式）
pos=1 執行計劃中的位置
PARSE EXEC FETCH部分
c=0 消耗的CPU時間
e=649 這步操作的總用時
p=0 物理讀的次數
cr=0 一致性讀的次數（也叫資料塊數），這個一致性讀跟資料塊在記憶體中還是硬碟中是沒有關係的，它代表就需要讀這麼多次而已。如果要找的資料沒有在記憶體中就會觸發一次物理讀
cu=0 current方式讀的次數（資料塊數）
mis=1 硬解析的次數
r=1 rows處理的行數
dep=1 遞迴的SQL深度
og=1 optimizer goal優化其模式
tim=1360643355379266 時間戳
plh=893701161 plan hash value 執行計劃的雜湊值
=======================================================================================
PARSING IN CURSOR#2 len=549 dep=1 uid=85 ct=3 lid=85 tim=1360643355392971 hv=1384619666 ad='7f537b20'sqlid='cy3wbyd98g7nk'
SELECT /*OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE NO_PARALLEL(SAMPLESUB)opt_param('parallel_execution_enabled', 'false') NO_PARALLEL_INDEX(SAMPLESUB)NO_SQL_TUNE */ NVL(SUM(C1),:"SYS_B_0"),NVL(SUM(C2),:"SYS_B_1"), COUNT(DISTINCT C3), NVL(SUM(CASE WHEN C3 ISNULL THEN :"SYS_B_2" ELSE :"SYS_B_3"END),:"SYS_B_4") FROM (SELECT /*+ NO_PARALLEL("LEO3")FULL("LEO3") NO_PARALLEL_INDEX("LEO3") */ :"SYS_B_5"AS C1, :"SYS_B_6" AS C2, "LEO3"."OBJECT_ID" AS C3FROM "LEO3" SAMPLE BLOCK (:"SYS_B_7" ,:"SYS_B_8") SEED (:"SYS_B_9") "LEO3") SAMPLESUB
END OF STMT
PARSE#2:c=0,e=181,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,plh=893701161,tim=1360643355392964
EXEC#2:c=0,e=227,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,plh=893701161,tim=1360643355393267
FETCH#2:c=7999,e=8422,p=0,cr=85,cu=0,mis=0,r=1,dep=1,og=1,plh=893701161,tim=1360643355401734
STAT #2 id=1 cnt=1pid=0 pos=1 bj=0 p='SORT AGGREGATE (cr=85 pr=0 pw=0 time=0 us)'
STAT #2 id=2cnt=4702 pid=1 pos=1 bj=0 p='VIEW VW_DAG_0 (cr=85 pr=0 pw=0 time=224631 us cost=5 size=31356 card=603)'
STAT #2 id=3cnt=4702 pid=2 pos=1 bj=0 p='HASH GROUP BY (cr=85 pr=0 pw=0 time=41673 uscost=5 size=15075 card=603)'
STAT #2 id=4cnt=4764 pid=3 pos=1 bj=74154 p='TABLE ACCESS SAMPLE LEO3 (cr=85 pr=0 pw=0time=143391 us cost=4 size=15075 card=603)'
CLOSE#2:c=0,e=23,dep=1,type=0,tim=1360643355402144
=======================================================================================
PARSING IN CURSOR#9 len=134 dep=0 uid=85 ct=3 lid=85 tim=1360643355402676 hv=2179856754ad='81664b48' sqlid='b1t69vk0yvybk'
select count(*)from (select * from leo3 order by object_id) a,(select * from leo3 order byobject_id) b where a.object_id=b.object_id
END OF STMT
PARSE#9:c=24996,e=25529,p=20,cr=172,cu=0,mis=1,r=0,dep=0,og=1,plh=3063589819,tim=1360643355402670
EXEC#9:c=0,e=78,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=3063589819,tim=1360643355403027
*** 2013-02-1212:29:18.222
FETCH#9:c=2805574,e=2819059,p=2103,cr=16402,cu=0,mis=0,r=1,dep=0,og=1,plh=3063589819,tim=1360643358222227
STAT #9 id=1 cnt=1pid=0 pos=1 bj=0 p='SORT AGGREGATE (cr=16402 pr=2103 pw=0 time=0 us)'
STAT #9 id=2cnt=4608448 pid=1 pos=1 bj=0 p='HASH JOIN (cr=16402 pr=2103 pw=0 time=63222024 us cost=6498 size=83495802card=3211377)'
STAT #9 id=3cnt=576056 pid=2 pos=1 bj=74154 p='TABLE ACCESS FULL LEO3 (cr=8201 pr=1689pw=0 time=3543486 us cost=2438 size=8822853 card=678681)'
STAT #9 id=4cnt=576056 pid=2 pos=2 bj=74154 p='TABLE ACCESS FULL LEO3 (cr=8201 pr=414pw=0 time=3369685 us cost=2438 size=8822853 card=678681)'
FETCH#9:c=0,e=8,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=3063589819,tim=1360643358226922
*** 2013-02-1212:29:56.671
CLOSE#9:c=0,e=34,dep=0,type=0,tim=1360643396671376
=======================================================================================
[oracle@leonarding1trace]$ tkprof LEO1_ora_25998.trc sys=no 我們彙總一下看等待事件
output = 25998.txt
TKPROF: Release11.2.0.1.0 - Development on Tue Feb 12 14:43:31 2013
Copyright (c)1982, 2009, Oracle and/or its affiliates. All rights reserved.
********************************************************************************
SQL ID:b1t69vk0yvybk
Plan Hash:3063589819
select count(*)
from
(select * from leo3 order by object_id)a,(select * from leo3 order by
object_id) b where a.object_id=b.object_id
call count cpu elapsed disk query current rows
------------- -------- ---------- -------------------- ---------- ----------
Parse 1 0.00 0.00 0 2 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 2.80 2.81 2103 16402 0 1
------------- -------- ---------- -------------------- ---------- ----------
total 4 2.81 2.82 2103 16404 0 1
Misses in librarycache during parse: 1
Optimizer mode:ALL_ROWS
Parsing user id:85
Rows Row Source Operation
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=16402 pr=2103 pw=0 time=0 us)
4608448 HASH JOIN (cr=16402 pr=2103 pw=0 time=63222024 us cost=6498 size=83495802card=3211377)
576056 TABLE ACCESS FULL LEO3 (cr=8201 pr=1689 pw=0 time=3543486 us cost=2438size=8822853 card=678681)
576056 TABLE ACCESS FULL LEO3 (cr=8201 pr=414 pw=0 time=3369685 us cost=2438size=8822853 card=678681)
Elapsed timesinclude waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ---------------------------------------------
SQL*Net message to client 5 0.00 0.00
SQL*Net message from client 5 8.16 23.81
我們發現等待事件很少了哦，從這我們就可以看到等待事件及時長
time=63222024 顯示最消耗時間的操作HASH JOIN
小結：後面這些都可以以此類推，掌握這些含義可以幫助我們瞭解sql執行中消耗了多少資源，實際的執行過程是什麼樣子的，產生了幾層遞迴，資料如何被操作的。
SQL_TRACE 10046 優化 資源 效能 優化例項
Leonarding
2013.2.12
天津&winter
分享技術~成就夢想
Blog：www.leonarding.com
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26686207/viewspace-754101/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- Oracle 10046 SQL TRACEOracleSQL
- Oracle診斷案例-Sql_traceOracleSQL
- 10046事件概述事件
- Oracle效能優化-SQL優化(案例一)Oracle優化SQL
- Oracle效能優化-SQL優化(案例二)Oracle優化SQL
- Oracle效能優化-SQL優化(案例三)Oracle優化SQL
- Oracle效能優化-SQL優化(案例四)Oracle優化SQL
- Oracle SQL優化之sql tuning advisorOracleSQL優化
- sql_trace相關指令碼SQL指令碼
- 如何區分例項化網格中的每個例項
- 優化 WebView 的載入速度例項優化WebView
- 分享一個SQLite 效能優化例項SQLite優化
- C# Winform程式介面優化例項C#ORM優化
- Oracle EBS中分類賬和法人實體 的關係（有sql語句例項）OracleSQL
- Oracle某行系統SQL優化案例(三)OracleSQL優化
- Oracle某行系統SQL優化(案例五)OracleSQL優化
- Oracle某行系統SQL優化案例(二)OracleSQL優化
- Oracle 某行系統SQL優化案例(一)OracleSQL優化
- 4.1. Oracle例項Oracle
- Oracle Far Sync例項Oracle
- Oracle優化案例-關閉auto space advisor和sql tuning advisor（十九）Oracle優化SQL
- Java類初始化和例項化Java
- MySql/Oracle和SQL Server的分頁查MySqlOracleServer
- oracle資料庫與oracle例項Oracle資料庫
- Web 頁面優化專項 > Lighthouse > 效能分數優化Web優化
- Oracle SQL效能優化的40條軍規OracleSQL優化
- 使用SSMS連線和查詢 SQL Server 例項SSMSQLServer
- 從10046看Oracle分割槽裁剪Oracle
- 宜信DBA實踐|全面解析Oracle等待事件的分類、發現及優化Oracle事件優化
- ORACLE事務和例項恢復過程梳理Oracle
- oracle 例項表查詢Oracle
- Oracle 高效能SQL引擎剖析--SQL優化與調優機制詳解OracleSQL優化
- SQL優化案例-單表分頁語句的優化（八）SQL優化
- Oracle優化案例-單表分頁語句的優化（八）Oracle優化
- 二維字首和與差分、離散化技巧
- php例項化物件的例項方法PHP物件
- 單個SQL語句的10046 traceSQL
- 類的例項化順序和分析
- python中類的建立和例項化Python