【性能优化】 之性能视图及性能参数
生活随笔
收集整理的這篇文章主要介紹了
【性能优化】 之性能视图及性能参数
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
1.設置memory_target參數，并通過 v$memory_target_advice分析數據庫的最佳內存大小。<br>
2.通過調整參數optimizer_index_cost_adj的大小，演示SQL產生不同執行計劃。<br>
3.通過設置參數DB_FILE_MULTIBLOCK_READ_COUNT 不同的值，演示對SQL效率的影響（sql_trace or 10046 的輸出結果）<br>
4.示例說明數據庫中“會話”和“進程”之間的關系。<br>
5.演示通過動態視圖查看某個會話的等待事件。<br>
=============================================================================================
1.設置memory_target參數，并通過 v$memory_target_advice分析數據庫的最佳內存大小。<br>
先查了一下相關參數值，發現memory_target? 沒有設置，默認值為0，
這時 sga_target 是有設置的，那么這時的設置
v$memory_target_advice 表中沒有數據，說明這時沒有使用內存自動調整？
SQL> show parameter memory;
NAME???????????????????????????????? TYPE????????????????? VALUE
------------------------------------ -------------------- ----------------
hi_shared_memory_address???????????? integer????????????? 0
memory_max_target??????????????????? big integer????????? 0
memory_target??????????????????????? big integer????????? 0
shared_memory_address??????????????? integer????????????? 0
SQL> show parameter memory;
NAME???????????????????????????????? TYPE???????????????? VALUE
------------------------------------ ----------------???? ----------------
hi_shared_memory_address???????????? integer????????????? 0
memory_max_target??????????????????? big integer????????? 0
memory_target??????????????????????? big integer????????? 0
shared_memory_address??????????????? integer????????????? 0
SQL> show parameter sga;
NAME???????????????????????????????? TYPE???????????????? VALUE
------------------------------------ ------------------?? ----------------
lock_sga???????????????????????????? boolean????????????? FALSE
pre_page_sga???????????????????????? boolean????????????? FALSE
sga_max_size???????????????????????? big integer????????? 4912M
sga_target?????????????????????????? big integer????????? 4912M
SQL> select * from v$memory_target_advice;
no rows selected
SQL>
調整內存參數，
我把內存參數設置成系統內存的1/2,
sga 設置為memory_target 的65%
alter system set memory_max_target=10000M scope=spfile;
alter system set memory_target=8000M scope=spfile;
alter system set sga_max_size=6000M scope=spfile;
alter system set sga_target=5200M scope=spfile;
SQL> alter system set memory_max_target=10000M scope=spfile;
System altered.
SQL> alter system set memory_target=8000M scope=spfile;
System altered.
SQL> alter system set sga_max_size=6000M scope=spfile;
System altered.
SQL> alter system set sga_target=5200M scope=spfile;
System altered.
重啟服務器使參數生效
SQL> startup force;
ORACLE 例程已經啟動。
Total System Global Area 6263357440 bytes
Fixed Size????????????????? 2266816 bytes
Variable Size??????????? 1912604992 bytes
Database Buffers???????? 4328521728 bytes
Redo Buffers?????????????? 19963904 bytes
數據庫裝載完畢。
數據庫已經打開。
SQL>
SQL> set linesize 400;
SQL> show parameter sga;
NAME???????????????????????????????? TYPE???????????????????????????? VALUE
------------------------------------ -------------------------------- ----------
lock_sga???????????????????????????? boolean????????????????????????? FALSE
pre_page_sga???????????????????????? boolean????????????????????????? FALSE
sga_max_size???????????????????????? big integer????????????????????? 6000M
sga_target?????????????????????????? big integer????????????????????? 5200M
SQL> show parameter memory;
NAME???????????????????????????????? TYPE???????????????????????????? VALUE
------------------------------------ -------------------------------- ----------
hi_shared_memory_address???????????? integer????????????????????????? 0
memory_max_target??????????????????? big integer????????????????????? 10000M
memory_target??????????????????????? big integer????????????????????? 8000M
shared_memory_address??????????????? integer????????????????????????? 0
SQL>
查詢內存優化表，可以看出，這時ORACLE已給出了調整方案了。
同時也可以看到，這里的最大內存 16000 即為我操作系統中的內存總數。
從下面兩個表中數據可以看到，在這個數據庫中，內存調整從2G--16G，對性能來說，
都沒有變化。內存的調整對性能沒有什么質的變化。
SQL> set pagesize 800;
SQL> select * from v$memory_target_advice;
MEMORY_SIZE MEMORY_SIZE_FACTOR ESTD_DB_TIME ESTD_DB_TIME_FACTOR??? VERSION
----------- ------------------ ------------ ------------------- ----------
?????? 2000??????????????? .25?????????? 34?????????????????? 1????????? 0
?????? 4000???????????????? .5?????????? 34?????????????????? 1????????? 0
?????? 5000?????????????? .625?????????? 34?????????????????? 1????????? 0
?????? 6000??????????????? .75?????????? 34?????????????????? 1????????? 0
?????? 7000?????????????? .875?????????? 34?????????????????? 1????????? 0
?????? 8000????????????????? 1?????????? 34?????????????????? 1????????? 0
?????? 9000????????????? 1.125?????????? 34?????????????????? 1????????? 0
????? 10000?????????????? 1.25?????????? 34?????????????????? 1????????? 0
????? 11000????????????? 1.375?????????? 34?????????????????? 1????????? 0
????? 12000??????????????? 1.5?????????? 34?????????????????? 1????????? 0
????? 13000????????????? 1.625?????????? 34?????????????????? 1????????? 0
????? 14000?????????????? 1.75?????????? 34?????????????????? 1????????? 0
????? 15000????????????? 1.875?????????? 34?????????????????? 1????????? 0
????? 16000????????????????? 2?????????? 34?????????????????? 1????????? 0
14 rows selected.
SQL> select * from v$sga_target_advice;
? SGA_SIZE SGA_SIZE_FACTOR ESTD_DB_TIME ESTD_DB_TIME_FACTOR ESTD_PHYSICAL_READS
---------- --------------- ------------ ------------------- -------------------
????? 1300???????????? .25?????????? 39?????????????????? 1?????????????? 35898
????? 1950??????????? .375?????????? 39?????????????????? 1?????????????? 35898
????? 2600????????????? .5?????????? 39?????????????????? 1?????????????? 35898
????? 3250??????????? .625?????????? 39?????????????????? 1?????????????? 35898
????? 3900???????????? .75?????????? 39?????????????????? 1?????????????? 35898
????? 4550??????????? .875?????????? 39?????????????????? 1?????????????? 35898
????? 5200?????????????? 1?????????? 39?????????????????? 1?????????????? 35898
????? 5850?????????? 1.125?????????? 39?????????????????? 1?????????????? 35898
????? 6500??????????? 1.25?????????? 39?????????????????? 1?????????????? 35898
????? 7150?????????? 1.375?????????? 39?????????????????? 1?????????????? 35898
????? 7800???????????? 1.5?????????? 39?????????????????? 1?????????????? 35898
????? 8450?????????? 1.625?????????? 39?????????????????? 1?????????????? 35898
????? 9100??????????? 1.75?????????? 39?????????????????? 1?????????????? 35898
????? 9750?????????? 1.875?????????? 39?????????????????? 1?????????????? 35898
???? 10400?????????????? 2?????????? 39?????????????????? 1?????????????? 35898
15 rows selected.
----------------------------------------------------------------------------------------
2.通過調整參數 optimizer_index_cost_adj 的大小，演示SQL產生不同執行計劃。<br>
參數說明：
OPTIMIZER_INDEX_COST_ADJ
這個初始化參數代表一個百分比,取值范圍在1到10000之間.
該參數表示索引掃描和全表掃描成本的比較。缺省值100表示索引掃描成本等價轉換與全表掃描成本。
這些參數對于CBO的執行具有重大影響，其缺省值對于數據庫來說通常需要調整。
一般來說對于OPTIMIZER_INDEX_CACHING可以設置為90左右
對于大多數OLTP系統，OPTIMIZER_INDEX_COST_ADJ可以設置在10到50之間。對于數據倉庫和DSS系統，
比如設置以下值：
?? ?Optimizer_index_cost_adj=20 ，表示索引的成本和全表掃描的成本比為1:5。
2.1 建立演示數據表：
SQL> CREATE TABLE T12 AS SELECT * FROM DBA_OBJECTS where object_id<=1000;
SQL> CREATE INDEX IDX_T12_OWNER ON T12(OWNER);
Index created
SQL>
BEGIN
dbms_stats.gather_table_stats(user,'T12',CASCADE=>TRUE,ESTIMATE_PERCENT=> NULL,
?METHOD_OPT=>'for all columns size 254');
END;
SQL> SET LINESIZE 500;
SQL> SET PAGESIZE 800;
C:\Users\Administrator>sqlplus tang/sa@orcl
SQL*Plus: Release 11.2.0.1.0 Production on Thu Dec 26 15:38:29 2013
Copyright (c) 1982, 2010, Oracle.? All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
在默認參數情況下，可以看到，查詢所以數據及使用條件查詢object_id<1200，走的都是全表檢索。
這是正確的。
SQL> SET AUTOTRACE TRACEONLY
SQL> select * from t13;
998 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 17950186
--------------------------------------------------------------------------
| Id? | Operation???????? | Name | Rows? | Bytes | Cost (%CPU)| Time???? |
--------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT? |????? |?? 998 | 85828 |???? 6?? (0)| 00:00:01 |
|?? 1 |? TABLE ACCESS FULL| T13? |?? 998 | 85828 |???? 6?? (0)| 00:00:01 |
--------------------------------------------------------------------------
Statistics
----------------------------------------------------------
????????? 0? recursive calls
????????? 0? db block gets
???????? 81? consistent gets
????????? 0? physical reads
????????? 0? redo size
???? 105204? bytes sent via SQL*Net to client
?????? 1250? bytes received via SQL*Net from client
???????? 68? SQL*Net roundtrips to/from client
????????? 0? sorts (memory)
????????? 0? sorts (disk)
??????? 998? rows processed
SQL> select * from t13 where object_id<1200;
998 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 17950186
--------------------------------------------------------------------------
| Id? | Operation???????? | Name | Rows? | Bytes | Cost (%CPU)| Time???? |
--------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT? |????? |?? 998 | 85828 |???? 6?? (0)| 00:00:01 |
|*? 1 |? TABLE ACCESS FULL| T13? |?? 998 | 85828 |???? 6?? (0)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
?? 1 - filter("OBJECT_ID"<1200)
Statistics
----------------------------------------------------------
????????? 0? recursive calls
????????? 0? db block gets
??????? 161? consistent gets
????????? 0? physical reads
????????? 0? redo size
???? 105204? bytes sent via SQL*Net to client
?????? 1250? bytes received via SQL*Net from client
???????? 68? SQL*Net roundtrips to/from client
????????? 0? sorts (memory)
????????? 0? sorts (disk)
??????? 998? rows processed
2.2 設置參數值為10 ，這時ORACLE 會認為走索引的成本 更低。
SQL> alter? session set optimizer_index_cost_adj=10;
Session altered.
SQL> select * from t13;
998 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 17950186
--------------------------------------------------------------------------
| Id? | Operation???????? | Name | Rows? | Bytes | Cost (%CPU)| Time???? |
--------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT? |????? |?? 998 | 85828 |???? 6?? (0)| 00:00:01 |
|?? 1 |? TABLE ACCESS FULL| T13? |?? 998 | 85828 |???? 6?? (0)| 00:00:01 |
--------------------------------------------------------------------------
Statistics
----------------------------------------------------------
????????? 0? recursive calls
????????? 0? db block gets
???????? 82? consistent gets
????????? 0? physical reads
????????? 0? redo size
???? 105204? bytes sent via SQL*Net to client
?????? 1250? bytes received via SQL*Net from client
???????? 68? SQL*Net roundtrips to/from client
????????? 0? sorts (memory)
????????? 0? sorts (disk)
??????? 998? rows processed
SQL> set linesize 400;
SQL> select * from t13 where object_id<1200;
998 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 541349760
------------------------------------------------------------------------------------------
| Id? | Operation?????????????????? | Name?????? | Rows? | Bytes | Cost (%CPU)| Time???? |
------------------------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT??????????? |??????????? |?? 998 | 85828 |???? 3?? (0)| 00:00:01 |
|?? 1 |? TABLE ACCESS BY INDEX ROWID| T13??????? |?? 998 | 85828 |???? 3?? (0)| 00:00:01 |
|*? 2 |?? INDEX RANGE SCAN????????? | IDX_T13_ID |?? 998 |?????? |???? 1?? (0)| 00:00:01 |
------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
?? 2 - access("OBJECT_ID"<1200)
Statistics
----------------------------------------------------------
????????? 0? recursive calls
????????? 0? db block gets
??????? 161? consistent gets
????????? 0? physical reads
????????? 0? redo size
???? 105204? bytes sent via SQL*Net to client
?????? 1250? bytes received via SQL*Net from client
???????? 68? SQL*Net roundtrips to/from client
????????? 0? sorts (memory)
????????? 0? sorts (disk)
??????? 998? rows processed
SQL>
從最后的查詢可以看到，這時ORACLE走索引了。其實OBJECT_ID<1200就是全部數據。但人為的告訴ORACLE走索引更低，
這里有161個唯一值讀。而全表檢索也只不夠是82個唯一值的讀。
--------------------------------------------------------------------------------------------------------------
3.通過設置參數DB_FILE_MULTIBLOCK_READ_COUNT 不同的值，演示對SQL效率的影響（sql_trace or 10046 的輸出結果）<br>
SQL> drop table t13;
Table dropped.
SQL> create table t13 as select * from dba_objects;
Table created.
SQL> show parameter DB_FILE_MULTIBLOCK_READ_COUNT
NAME?????????????????????????? TYPE?????????? VALUE
------------------------------ -------?? ??? ?--------
db_file_multiblock_read_count? integer??????? 128
SQL> SET AUTOTRACE TRACEONLY;
SQL> select count(*) from t13;
Execution Plan
----------------------------------------------------------
Plan hash value: 2598196162
-------------------------------------------------------------------
| Id? | Operation????????? | Name | Rows? | Cost (%CPU)| Time???? |
-------------------------------------------------------------------
|?? 0 | SELECT STATEMENT?? |????? |???? 1 |?? 196?? (1)| 00:00:03 |
|?? 1 |? SORT AGGREGATE??? |????? |???? 1 |??????????? |????????? |
|?? 2 |?? TABLE ACCESS FULL| T13? | 82867 |?? 196?? (1)| 00:00:03 |
-------------------------------------------------------------------
Note
-----
?? - dynamic sampling used for this statement (level=2)
Statistics
----------------------------------------------------------
????????? 0? recursive calls
????????? 0? db block gets
?????? 1095? consistent gets?? ??? ?
????????? 0? physical reads
????????? 0? redo size
??????? 528? bytes sent via SQL*Net to client
??????? 524? bytes received via SQL*Net from client
????????? 2? SQL*Net roundtrips to/from client
????????? 0? sorts (memory)
????????? 0? sorts (disk)
????????? 1? rows processed
#1092/128=8.53125,約要讀8.5次可以把數據讀完。
SQL> alter system set DB_FILE_MULTIBLOCK_READ_COUNT=16;
System altered.
SQL> select count(*) from t13;
Execution Plan
----------------------------------------------------------
Plan hash value: 2598196162
-------------------------------------------------------------------
| Id? | Operation????????? | Name | Rows? | Cost (%CPU)| Time???? |
-------------------------------------------------------------------
|?? 0 | SELECT STATEMENT?? |????? |???? 1 |?? 247?? (1)| 00:00:03 |
|?? 1 |? SORT AGGREGATE??? |????? |???? 1 |??????????? |????????? |
|?? 2 |?? TABLE ACCESS FULL| T13? | 82867 |?? 247?? (1)| 00:00:03 |
-------------------------------------------------------------------
Note
-----
?? - dynamic sampling used for this statement (level=2)
Statistics
----------------------------------------------------------
????????? 0? recursive calls
????????? 0? db block gets
?????? 1095? consistent gets
????????? 0? physical reads
????????? 0? redo size
??????? 528? bytes sent via SQL*Net to client
??????? 524? bytes received via SQL*Net from client
????????? 2? SQL*Net roundtrips to/from client
????????? 0? sorts (memory)
????????? 0? sorts (disk)
????????? 1? rows processed
SQL>
#1092/16=68.25,約要讀68次可以把數據讀完。
上面為兩次在不同的 DB_FILE_MULTIBLOCK_READ_COUNT 參數值環境下，同一執行計劃的成本。
可以看出，在一次只讀16塊時，成本上升。
再打開10046事件跟蹤，查看在不同參數環境下，查詢到底發生了什么變化。
SQL> show parameter DB_FILE_MULTIBLOCK_READ_COUNT
NAME?????????????????????????? TYPE?????????? VALUE
------------------------------ -------?? ??? ?--------
db_file_multiblock_read_count? integer??????? 128
SQL> alter session set events '10046 trace name context forever,level 12';
Session altered.
SQL> alter system flush shared_pool;
System altered.
SQL> alter system flush shared_pool;
System altered.
SQL> alter system flush shared_pool;
System altered.
SQL> select count(*) from t13;
? COUNT(*)
----------
?????? 998
SQL> alter system set DB_FILE_MULTIBLOCK_READ_COUNT=16;
System altered.
SQL> select count(*) from t13;
? COUNT(*)
----------
?????? 998
SQL> alter session set events '10046 trace name context off';
Session altered.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
C:\Users\Administrator>
trace file content:
-------------------------------------------------------
=====================
PARSING IN CURSOR #438005240 len=24 dep=0 uid=84 oct=3 lid=84 tim=10125283859956 hv=988653825 ad='2f0ddbf70' sqlid='6aqutrwxfva81'
select count(*) from t13
END OF STMT
PARSE #438005240:c=0,e=9297,p=0,cr=103,cu=4,mis=1,r=0,dep=0,og=1,plh=2598196162,tim=10125283859955
EXEC #438005240:c=0,e=25,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2598196162,tim=10125283860031
WAIT #438005240: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=10125283860085
FETCH #438005240:c=15600,e=12634,p=0,cr=1095,cu=0,mis=0,r=1,dep=0,og=1,plh=2598196162,tim=10125283872748
STAT #438005240 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=1095 pr=0 pw=0 time=12629 us)'
STAT #438005240 id=2 cnt=76475 pid=1 pos=1 obj=99240 op='TABLE ACCESS FULL T13 (cr=1095 pr=0 pw=0 time=80082 us cost=196 size=0 card=82867)'
WAIT #438005240: nam='SQL*Net message from client' ela= 605 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=10125283873478
FETCH #438005240:c=0,e=2,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=2598196162,tim=10125283873523
WAIT #438005240: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=10125283873551
*** 2013-12-26 16:06:06.746
WAIT #438005240: nam='SQL*Net message from client' ela= 6166840 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=10125290040409
CLOSE #438005240:c=0,e=12,dep=0,type=0,tim=10125290040702
我們來重點查看? FETCH部分
c=15600???????????????? 消耗的CPU時間
e=12634?????????????? 這步操作的總用時
p=0???????????????? 物理讀的次數
cr=1095??????????????? 一致性讀的次數（也叫數據塊數），這個一致性讀跟數據塊在內存中還是硬盤中是沒有關系的，它代表就需要讀這么多次而已。如果要找的數據沒有在內存中就會觸發一次物理讀
cu=0?????????????? current方式讀的次數（數據塊數）
mis=0????????????? 硬解析的次數
r=1??????????????? rows處理的行數
dep=1????????????? 遞歸的SQL深度
og=1?????????????? optimizer goal優化其模式
tim=10125283872748? 時間戳
plh=2598196162????? plan hash value? 執行計劃的哈希值
=====================
PARSING IN CURSOR #436681312 len=49 dep=0 uid=84 oct=49 lid=84 tim=10125290040764 hv=2944834790 ad='0' sqlid='6yq881yrsd776'
alter system set DB_FILE_MULTIBLOCK_READ_COUNT=16
END OF STMT
PARSE #436681312:c=0,e=13,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=0,tim=10125290040763
WAIT #436681312: nam='reliable message' ela= 80 channel context=12688921096 channel handle=12537097552 broadcast message=12689296352 obj#=-1 tim=10125290041221
WAIT #436681312: nam='Disk file operations I/O' ela= 220 FileOperation=2 fileno=0 filetype=13 obj#=-1 tim=10125290041485
WAIT #436681312: nam='Parameter File I/O' ela= 157 blkno=1 #blks=1 read/write=1 obj#=-1 tim=10125290041667
WAIT #436681312: nam='Parameter File I/O' ela= 85 blkno=2 #blks=3 read/write=1 obj#=-1 tim=10125290041850
WAIT #436681312: nam='Parameter File I/O' ela= 89 blkno=5 #blks=3 read/write=2 obj#=-1 tim=10125290044211
WAIT #436681312: nam='Parameter File I/O' ela= 85 blkno=1 #blks=1 read/write=2 obj#=-1 tim=10125290044332
WAIT #436681312: nam='Parameter File I/O' ela= 108 blkno=5 #blks=3 read/write=1 obj#=-1 tim=10125290044468
WAIT #436681312: nam='Parameter File I/O' ela= 57 blkno=2 #blks=3 read/write=2 obj#=-1 tim=10125290044557
WAIT #436681312: nam='Parameter File I/O' ela= 53 blkno=1 #blks=1 read/write=2 obj#=-1 tim=10125290044639
WAIT #436681312: nam='Parameter File I/O' ela= 53 blkno=5 #blks=3 read/write=2 obj#=-1 tim=10125290044719
WAIT #436681312: nam='Disk file operations I/O' ela= 441 FileOperation=5 fileno=0 filetype=13 obj#=-1 tim=10125290045185
=====================
.............
=====================
PARSING IN CURSOR #438005240 len=24 dep=0 uid=84 oct=3 lid=84 tim=10125294712617 hv=988653825 ad='2f0ddbf70' sqlid='6aqutrwxfva81'
select count(*) from t13
END OF STMT
PARSE #438005240:c=0,e=4128,p=0,cr=73,cu=0,mis=1,r=0,dep=0,og=1,plh=2598196162,tim=10125294712616
EXEC #438005240:c=0,e=25,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2598196162,tim=10125294712692
WAIT #438005240: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=10125294712743
FETCH #438005240:c=15600,e=12991,p=0,cr=1095,cu=0,mis=0,r=1,dep=0,og=1,plh=2598196162,tim=10125294725760
STAT #438005240 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=1095 pr=0 pw=0 time=12985 us)'
STAT #438005240 id=2 cnt=76475 pid=1 pos=1 obj=99240 op='TABLE ACCESS FULL T13 (cr=1095 pr=0 pw=0 time=83408 us cost=247 size=0 card=82867)'
WAIT #438005240: nam='SQL*Net message from client' ela= 426 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=10125294726301
FETCH #438005240:c=0,e=3,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=2598196162,tim=10125294726343
WAIT #438005240: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=10125294726371
*** 2013-12-26 16:06:16.309
WAIT #438005240: nam='SQL*Net message from client' ela= 4876078 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=10125299602467
CLOSE #438005240:c=0,e=9,dep=0,type=0,tim=10125299602722
我們來看參數值為16時的? FETCH部分
c=15600???????????????? 消耗的CPU時間
e=12991 （上一次12634 可以看出增加了）????????????? 這步操作的總用時
p=0???????????????? 物理讀的次數
cr=1095??????????????? 一致性讀的次數（也叫數據塊數），這個一致性讀跟數據塊在內存中還是硬盤中是沒有關系的，它代表就需要讀這么多次而已。如果要找的數據沒有在內存中就會觸發一次物理讀
cu=0?????????????? current方式讀的次數（數據塊數）
mis=0????????????? 硬解析的次數
r=1??????????????? rows處理的行數
dep=1????????????? 遞歸的SQL深度
og=1?????????????? optimizer goal優化其模式
tim=10125294725760 （上一次 10125283872748）? 時間戳
plh=2598196162????? plan hash value? 執行計劃的哈希值
=====================
PARSING IN CURSOR #438005240 len=55 dep=0 uid=84 oct=42 lid=84 tim=10125299602877 hv=2217940283 ad='0' sqlid='06nvwn223659v'
alter session set events '10046 trace name context off'
END OF STMT
PARSE #438005240:c=0,e=112,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=0,tim=10125299602876
EXEC #438005240:c=0,e=503,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=0,tim=10125299603428
------------------------------------------------------------------
4.示例說明數據庫中“會話”和“進程”之間的關系。<br>
先梳理一下名稱
連接：從客戶端到ORACLE實例的一條鏈路，
會話：指與數據庫的一個連接就是一個會話，會話是實例中存在的一個邏輯實體。
這就是你的會話狀態（session state），ORACLE實例已分配了對應的內存空間。
進程：指操作系統層面，與數據庫開啟了一個連接。
4.1.一個進程對應一個會話：
?? ?登錄ORACLE
?? ?[oracle@ract1 ~]$ sqlplus tang/sa@orcl
?? ?查詢當前會話：
?? ?SQL> select SS.USERNAME,SPID from v$process pr,v$session ss where pr.addr=ss.paddr and ss.USERNAME IN ('SYS','TANG');
?? ?USERNAME?? ??? ??? ?SPID
?? ?------------------------------------------------------------------------
?? ?SYS?? ??? ??? ??? ??? ?10787
?? ?TANG?? ??? ??? ??? ?11621
?? ?在操作系統中查看會話的進程 按進程號看到11621 是存在的
?? ?[root@ract1 ~]# ps -ef|grep 11621
?? ?oracle?? 11621???? 1? 0 11:41 ???????? 00:00:00 oracletdb1 (LOCAL=NO)
?? ?root???? 12049 11659? 0 11:50 pts/3??? 00:00:00 grep 11621
4.2.有進程，沒會話
?? ?[oracle@ract1 ~]$ sqlplus tang/sa@orcl
?? ?SQL> disconnect;
?? ?Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
?? ?With the Partitioning, Real Application Clusters, Automatic Storage Management and Data Mining options
?? ?SQL>
?? ?在另一個SYS 登錄的窗口查詢：
?? ?SQL> /
?? ?USERNAME? SPID
?? ?-------------------------
?? ?SYS?? ??? ??? ?10787
?? ?SQL>
?? ?看到這時在ORACLE下，沒有會話信息了。
?? ?但在同一臺服務器中，再查詢是否還有打開ORACLE的進程呢，可以看到，是有的
?? ?[root@ract1 ~]# ps -ef|grep oracletdb1
?? ?oracle?? 10787 10615? 0 11:27 ???????? 00:00:04 oracletdb1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
?? ?oracle?? 12184???? 1? 0 11:54 ???????? 00:00:00 oracletdb1 (LOCAL=NO)
?? ?root???? 12271 11659? 0 11:56 pts/3??? 00:00:00 grep oracletdb1
?? ?[root@ract1 ~]#
?? ?還可以再建立連接。查看剛看到的進程，是否就是打開的SQLPUS窗口的進程
?? ?SQL> connect
?? ?Enter user-name: tang
?? ?Enter password:
?? ?Connected.
?? ?SQL>
?? ?從下面的兩次對比可以看出。
?? ?[root@ract1 ~]# ps -ef|grep oracletdb1
?? ?oracle?? 10787 10615? 0 11:27 ???????? 00:00:04 oracletdb1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
?? ?oracle?? 12184???? 1? 0 11:54 ???????? 00:00:00 oracletdb1 (LOCAL=NO)
?? ?root???? 12271 11659? 0 11:56 pts/3??? 00:00:00 grep oracletdb1
?? ?[root@ract1 ~]# ps -ef|grep oracletdb1
?? ?oracle?? 10787 10615? 0 11:27 ???????? 00:00:04 oracletdb1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
?? ?oracle?? 12308 12182? 5 11:57 ???????? 00:00:00 oracletdb1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
?? ?root???? 12312 11659? 0 11:57 pts/3??? 00:00:00 grep oracletdb1
?? ?[root@ract1 ~]#
?? ?SQL> /
?? ?USERNAME?? ?SPID
?? ?--------------------
?? ?SYS?? ??? ??? ?10787
?? ?TANG?? ??? ?12308
?? ?SQL>
4.3.無進程，無會話：
?? ?4.3.1在一個窗口登錄
?? ?[oracle@ract1 ~]$ sqlplus /nolog
?? ?SQL*Plus: Release 11.2.0.1.0 Production on Fri Dec 27 14:35:43 2013
?? ?Copyright (c) 1982, 2009, Oracle.? All rights reserved.
?? ?SQL>
?? ?4.3.2在另一個窗口查詢
?? ?SQL> select SS.USERNAME,SPID from v$process pr,v$session ss where pr.addr=ss.paddr and ss.USERNAME IN ('SYS','TANG');
?? ?USERNAME?? ??? ?SPID
?? ?-----------?? -------
?? ?SYS?? ??? ??? ??? ?10787
?? ?4.3.3在另一個SHELL 窗口查看進程：
?? ?[oracle@ract1 ~]$ ps -ef|grep oracletdb
?? ?oracle?? 10787 10615? 0 11:27 ???????? 00:00:04 oracletdb1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
?? ?oracle?? 19187 18653? 0 14:36 pts/3??? 00:00:00 grep oracletdb
?? ?[oracle@ract1 ~]$
?? ?可以看到，使用ORACLE 的進程只有一個 10787 ，就是使用SYS登錄 查詢會話的窗口，
?? ?而第一個窗口登錄的，卻沒有會話記錄，也沒有進程信息。
4.4 單連接，單進程，多會話
?? ?4.4.1 登錄ORACLE,打開跟蹤
?? ?[oracle@ract1 ~]$ sqlplus tang/sa@tdb1
?? ?SQL*Plus: Release 11.2.0.1.0 Production on Fri Dec 27 14:43:05 2013
?? ?Copyright (c) 1982, 2009, Oracle.? All rights reserved.
?? ?Connected to:
?? ?Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
?? ?With the Partitioning, Real Application Clusters, Automatic Storage Management and Data Mining options
?? ?SQL> set autotrace on
?? ?SQL> set linesize 200;
?? ?4.4.2 另外一窗口查詢
?? ?SQL> select SS.USERNAME,SPID,SS.SERIAL# from v$process pr,v$session ss where pr.addr=ss.paddr and ss.USERNAME IN ('SYS','TANG');
?? ?USERNAME?? ?SPID?? ??? SERIAL#
?? ?--------------------------------
?? ?SYS?? ??? ??? ?10787?? ??? ? 5
?? ?TANG?? ??? ?19522?? ??? ?20
?? ?TANG?? ??? ?19522?????? 100
?? ?SQL>
?? ?4.4.3 查詢進程
?? ??? ?[oracle@ract1 ~]$ ps -ef|grep oracletdb
?? ??? ?oracle?? 10787 10615? 0 11:27 ???????? 00:00:04 oracletdb1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
?? ??? ?oracle?? 19522???? 1? 0 14:43 ???????? 00:00:00 oracletdb1 (LOCAL=NO)
?? ??? ?oracle?? 19689 18653? 0 14:47 pts/3??? 00:00:00 grep oracletdb
?? ?看到進程數還是兩個，但在進程 19522 ，中。會話卻有了2個
?? ?當啟用set autotrace功能后，通常會創建一個新的會話用于監控當前的操作并返回統計信息，并記錄到跟蹤日志中。
??? session：指定了一個實例中允許的會話數，即能同時登錄到數據庫的并發用戶數。
??? process: 指定了一個實例在操作系統級別能同時運行的進程數，包括后臺進程與服務器進程。
??? 由上面的分析可知，一個后臺進程可能同時對應對個會話，因此通常sessions的值是大于processes的值
??? 通常的設置公式
??????? sessions = 1.1 * processes + 5? ?
------------------------------------------------------------------
5.演示通過動態視圖查看某個會話的等待事件。<br>
?? ?
?? ?幾個相關的性能視圖：
?? ?v$session?? ?會話當前的各種狀態和屬性；
?? ?v$session_wait 會話當前的等待事件詳細信息；
?? ?v$session_event 會話的所有等待事件的詳細信息;
?? ?
?? ?v$session_wait_history 會話的等待事件的歷史信息
?? ?v$sesstat 會話資源的統計信息
?? ?
#查詢當前SESSION_ID
SQL> select distinct sid from v$mystat;
?????? SID
----------
??????? 42
#建立一個測試環境數據
SQL> drop table t13 purge;
Table dropped.
SQL> create table t13 as select * from dba_objects;
Table created.
SQL> create table t13_name as select object_name from dba_objects;
Table created.
SQL> alter system flush buffer_cache;
System altered.
SQL> /
System altered.
SQL> /
System altered.
SQL> set autot trace expl;
SQL> set linesize 400;
SQL> set pagesize 800;
SQL>
#為了能查看到等待事件，我用了 兩個表的兩字段關聯。可以看出是進行了全表檢索
SQL> select t.* from t13 t inner join t13_name n on t.object_name=n.object_name;
Execution Plan
----------------------------------------------------------
Plan hash value: 3251948810
---------------------------------------------------------------------------------------
| Id? | Operation????????? | Name???? | Rows? | Bytes |TempSpc| Cost (%CPU)| Time???? |
---------------------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT?? |????????? |?? 414K|?? 107M|?????? |? 1467?? (1)| 00:00:18 |
|*? 1 |? HASH JOIN???????? |????????? |?? 414K|?? 107M|? 5840K|? 1467?? (1)| 00:00:18 |
|?? 2 |?? TABLE ACCESS FULL| T13_NAME | 76610 |? 4937K|?????? |??? 74?? (2)| 00:00:01 |
|?? 3 |?? TABLE ACCESS FULL| T13????? | 82867 |??? 16M|?????? |?? 248?? (1)| 00:00:03 |
---------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
?? 1 - access("T"."OBJECT_NAME"="N"."OBJECT_NAME")
Note
-----
?? - dynamic sampling used for this statement (level=2)
SQL>
為了更好的查看等待事件，我特別進行全表查詢，并且每次都清空緩存
SQL> set autot off;
SQL> for i in 1..10000 loop
SP2-0734: unknown command beginning "for i in 1..." - rest of line ignored.
SQL> begin
? 2? for i in 1..10000 loop
? 3? execute immediate 'select t.* from t13 t inner join t13_name n on t.object_name=n.object_name';
? 4? execute immediate 'alter system flush buffer_cache';
? 5? end loop;
? 6? end;
? 7? /
在另一個窗口查看等待事件情況：
select sid,event,total_waits,total_timeouts,time_waited
from v$session_event where sid =42;
? ??? ?SID?? ?EVENT?? ?TOTAL_WAITS?? ?TOTAL_TIMEOUTS?? ?TIME_WAITED
?? ?---------------------------------------------------
1?? ?42?? ?Disk file operations I/O?? ?4?? ?0?? ?0?? ??? ?#操作系統IO? 等待
2?? ?42?? ?latch: cache buffers chains?? ?2?? ?0?? ?0?? ??? ?#LATCH 等待
3?? ?42?? ?buffer busy waits?? ?7?? ?0?? ?0?? ??? ??? ??? ?#buffer 等待
4?? ?42?? ?read by other session?? ?2?? ?0?? ?0
5?? ?42?? ?enq: RO - fast object reuse?? ?1?? ?0?? ?0
6?? ?42?? ?log file sync?? ?5?? ?0?? ?0
7?? ?42?? ?db file sequential read?? ?24665?? ?0?? ?350?? ??? ?#數據文件順序讀等待
8?? ?42?? ?db file scattered read?? ?130?? ?0?? ?15
9?? ?42?? ?direct path write?? ?2?? ?0?? ?0
10?? ?42?? ?SQL*Net message to client?? ?39?? ?0?? ?0
11?? ?42?? ?SQL*Net message from client?? ?39?? ?0?? ?228811
12?? ?42?? ?SQL*Net break/reset to client?? ?2?? ?0?? ?0
13?? ?42?? ?events in waitclass Other?? ?8240?? ?0?? ?51570
可以從此表中看到，當上面的循環查詢沒完成前，‘db file sequential read’ 數據讀等待 及等待時間，還是一直增加的。
完成后，也可以在等待厙事件表中可以同樣查詢到
select * from v$session_wait_history where sid=42;
? ??? ?SID?? ?SEQ#?? ?EVENT#?? ?EVENT?? ?P1TEXT?? ?P1?? ?P2TEXT?? ?P2?? ?P3TEXT?? ?P3?? ?WAIT_TIME?? ?WAIT_TIME_MICRO?? ?TIME_SINCE_LAST_WAIT_MICRO
?? ?-----------------------------------------------------------------------------------------------------------------------
1?? ?42?? ?1?? ?348?? ?SQL*Net message to client?? ?driver id?? ?1413697536?? ?#bytes?? ?1?? ??? ?0?? ?0?? ?3?? ?216
2?? ?42?? ?2?? ?146?? ?db file sequential read?? ?file#?? ?3?? ?block#?? ?2248?? ?blocks?? ?1?? ?0?? ?93?? ?39
3?? ?42?? ?3?? ?146?? ?db file sequential read?? ?file#?? ?3?? ?block#?? ?240?? ?blocks?? ?1?? ?0?? ?113?? ?92
4?? ?42?? ?4?? ?146?? ?db file sequential read?? ?file#?? ?1?? ?block#?? ?244652?? ?blocks?? ?1?? ?0?? ?114?? ?236
5?? ?42?? ?5?? ?440?? ?rdbms ipc reply?? ?from_process?? ?14?? ?timeout?? ?21474836?? ??? ?0?? ?5?? ?52869?? ?693
6?? ?42?? ?6?? ?146?? ?db file sequential read?? ?file#?? ?3?? ?block#?? ?2248?? ?blocks?? ?1?? ?0?? ?132?? ?38
7?? ?42?? ?7?? ?146?? ?db file sequential read?? ?file#?? ?3?? ?block#?? ?240?? ?blocks?? ?1?? ?0?? ?109?? ?92
8?? ?42?? ?8?? ?146?? ?db file sequential read?? ?file#?? ?1?? ?block#?? ?244652?? ?blocks?? ?1?? ?0?? ?140?? ?241
9?? ?42?? ?9?? ?440?? ?rdbms ipc reply?? ?from_process?? ?14?? ?timeout?? ?21474836?? ??? ?0?? ?5?? ?54544?? ?587
10?? ?42?? ?10?? ?146?? ?db file sequential read?? ?file#?? ?3?? ?block#?? ?2248?? ?blocks?? ?1?? ?0?? ?109?? ?34
2.通過調整參數optimizer_index_cost_adj的大小，演示SQL產生不同執行計劃。<br>
3.通過設置參數DB_FILE_MULTIBLOCK_READ_COUNT 不同的值，演示對SQL效率的影響（sql_trace or 10046 的輸出結果）<br>
4.示例說明數據庫中“會話”和“進程”之間的關系。<br>
5.演示通過動態視圖查看某個會話的等待事件。<br>
=============================================================================================
1.設置memory_target參數，并通過 v$memory_target_advice分析數據庫的最佳內存大小。<br>
先查了一下相關參數值，發現memory_target? 沒有設置，默認值為0，
這時 sga_target 是有設置的，那么這時的設置
v$memory_target_advice 表中沒有數據，說明這時沒有使用內存自動調整？
SQL> show parameter memory;
NAME???????????????????????????????? TYPE????????????????? VALUE
------------------------------------ -------------------- ----------------
hi_shared_memory_address???????????? integer????????????? 0
memory_max_target??????????????????? big integer????????? 0
memory_target??????????????????????? big integer????????? 0
shared_memory_address??????????????? integer????????????? 0
SQL> show parameter memory;
NAME???????????????????????????????? TYPE???????????????? VALUE
------------------------------------ ----------------???? ----------------
hi_shared_memory_address???????????? integer????????????? 0
memory_max_target??????????????????? big integer????????? 0
memory_target??????????????????????? big integer????????? 0
shared_memory_address??????????????? integer????????????? 0
SQL> show parameter sga;
NAME???????????????????????????????? TYPE???????????????? VALUE
------------------------------------ ------------------?? ----------------
lock_sga???????????????????????????? boolean????????????? FALSE
pre_page_sga???????????????????????? boolean????????????? FALSE
sga_max_size???????????????????????? big integer????????? 4912M
sga_target?????????????????????????? big integer????????? 4912M
SQL> select * from v$memory_target_advice;
no rows selected
SQL>
調整內存參數，
我把內存參數設置成系統內存的1/2,
sga 設置為memory_target 的65%
alter system set memory_max_target=10000M scope=spfile;
alter system set memory_target=8000M scope=spfile;
alter system set sga_max_size=6000M scope=spfile;
alter system set sga_target=5200M scope=spfile;
SQL> alter system set memory_max_target=10000M scope=spfile;
System altered.
SQL> alter system set memory_target=8000M scope=spfile;
System altered.
SQL> alter system set sga_max_size=6000M scope=spfile;
System altered.
SQL> alter system set sga_target=5200M scope=spfile;
System altered.
重啟服務器使參數生效
SQL> startup force;
ORACLE 例程已經啟動。
Total System Global Area 6263357440 bytes
Fixed Size????????????????? 2266816 bytes
Variable Size??????????? 1912604992 bytes
Database Buffers???????? 4328521728 bytes
Redo Buffers?????????????? 19963904 bytes
數據庫裝載完畢。
數據庫已經打開。
SQL>
SQL> set linesize 400;
SQL> show parameter sga;
NAME???????????????????????????????? TYPE???????????????????????????? VALUE
------------------------------------ -------------------------------- ----------
lock_sga???????????????????????????? boolean????????????????????????? FALSE
pre_page_sga???????????????????????? boolean????????????????????????? FALSE
sga_max_size???????????????????????? big integer????????????????????? 6000M
sga_target?????????????????????????? big integer????????????????????? 5200M
SQL> show parameter memory;
NAME???????????????????????????????? TYPE???????????????????????????? VALUE
------------------------------------ -------------------------------- ----------
hi_shared_memory_address???????????? integer????????????????????????? 0
memory_max_target??????????????????? big integer????????????????????? 10000M
memory_target??????????????????????? big integer????????????????????? 8000M
shared_memory_address??????????????? integer????????????????????????? 0
SQL>
查詢內存優化表，可以看出，這時ORACLE已給出了調整方案了。
同時也可以看到，這里的最大內存 16000 即為我操作系統中的內存總數。
從下面兩個表中數據可以看到，在這個數據庫中，內存調整從2G--16G，對性能來說，
都沒有變化。內存的調整對性能沒有什么質的變化。
SQL> set pagesize 800;
SQL> select * from v$memory_target_advice;
MEMORY_SIZE MEMORY_SIZE_FACTOR ESTD_DB_TIME ESTD_DB_TIME_FACTOR??? VERSION
----------- ------------------ ------------ ------------------- ----------
?????? 2000??????????????? .25?????????? 34?????????????????? 1????????? 0
?????? 4000???????????????? .5?????????? 34?????????????????? 1????????? 0
?????? 5000?????????????? .625?????????? 34?????????????????? 1????????? 0
?????? 6000??????????????? .75?????????? 34?????????????????? 1????????? 0
?????? 7000?????????????? .875?????????? 34?????????????????? 1????????? 0
?????? 8000????????????????? 1?????????? 34?????????????????? 1????????? 0
?????? 9000????????????? 1.125?????????? 34?????????????????? 1????????? 0
????? 10000?????????????? 1.25?????????? 34?????????????????? 1????????? 0
????? 11000????????????? 1.375?????????? 34?????????????????? 1????????? 0
????? 12000??????????????? 1.5?????????? 34?????????????????? 1????????? 0
????? 13000????????????? 1.625?????????? 34?????????????????? 1????????? 0
????? 14000?????????????? 1.75?????????? 34?????????????????? 1????????? 0
????? 15000????????????? 1.875?????????? 34?????????????????? 1????????? 0
????? 16000????????????????? 2?????????? 34?????????????????? 1????????? 0
14 rows selected.
SQL> select * from v$sga_target_advice;
? SGA_SIZE SGA_SIZE_FACTOR ESTD_DB_TIME ESTD_DB_TIME_FACTOR ESTD_PHYSICAL_READS
---------- --------------- ------------ ------------------- -------------------
????? 1300???????????? .25?????????? 39?????????????????? 1?????????????? 35898
????? 1950??????????? .375?????????? 39?????????????????? 1?????????????? 35898
????? 2600????????????? .5?????????? 39?????????????????? 1?????????????? 35898
????? 3250??????????? .625?????????? 39?????????????????? 1?????????????? 35898
????? 3900???????????? .75?????????? 39?????????????????? 1?????????????? 35898
????? 4550??????????? .875?????????? 39?????????????????? 1?????????????? 35898
????? 5200?????????????? 1?????????? 39?????????????????? 1?????????????? 35898
????? 5850?????????? 1.125?????????? 39?????????????????? 1?????????????? 35898
????? 6500??????????? 1.25?????????? 39?????????????????? 1?????????????? 35898
????? 7150?????????? 1.375?????????? 39?????????????????? 1?????????????? 35898
????? 7800???????????? 1.5?????????? 39?????????????????? 1?????????????? 35898
????? 8450?????????? 1.625?????????? 39?????????????????? 1?????????????? 35898
????? 9100??????????? 1.75?????????? 39?????????????????? 1?????????????? 35898
????? 9750?????????? 1.875?????????? 39?????????????????? 1?????????????? 35898
???? 10400?????????????? 2?????????? 39?????????????????? 1?????????????? 35898
15 rows selected.
----------------------------------------------------------------------------------------
2.通過調整參數 optimizer_index_cost_adj 的大小，演示SQL產生不同執行計劃。<br>
參數說明：
OPTIMIZER_INDEX_COST_ADJ
這個初始化參數代表一個百分比,取值范圍在1到10000之間.
該參數表示索引掃描和全表掃描成本的比較。缺省值100表示索引掃描成本等價轉換與全表掃描成本。
這些參數對于CBO的執行具有重大影響，其缺省值對于數據庫來說通常需要調整。
一般來說對于OPTIMIZER_INDEX_CACHING可以設置為90左右
對于大多數OLTP系統，OPTIMIZER_INDEX_COST_ADJ可以設置在10到50之間。對于數據倉庫和DSS系統，
比如設置以下值：
?? ?Optimizer_index_cost_adj=20 ，表示索引的成本和全表掃描的成本比為1:5。
2.1 建立演示數據表：
SQL> CREATE TABLE T12 AS SELECT * FROM DBA_OBJECTS where object_id<=1000;
SQL> CREATE INDEX IDX_T12_OWNER ON T12(OWNER);
Index created
SQL>
BEGIN
dbms_stats.gather_table_stats(user,'T12',CASCADE=>TRUE,ESTIMATE_PERCENT=> NULL,
?METHOD_OPT=>'for all columns size 254');
END;
SQL> SET LINESIZE 500;
SQL> SET PAGESIZE 800;
C:\Users\Administrator>sqlplus tang/sa@orcl
SQL*Plus: Release 11.2.0.1.0 Production on Thu Dec 26 15:38:29 2013
Copyright (c) 1982, 2010, Oracle.? All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
在默認參數情況下，可以看到，查詢所以數據及使用條件查詢object_id<1200，走的都是全表檢索。
這是正確的。
SQL> SET AUTOTRACE TRACEONLY
SQL> select * from t13;
998 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 17950186
--------------------------------------------------------------------------
| Id? | Operation???????? | Name | Rows? | Bytes | Cost (%CPU)| Time???? |
--------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT? |????? |?? 998 | 85828 |???? 6?? (0)| 00:00:01 |
|?? 1 |? TABLE ACCESS FULL| T13? |?? 998 | 85828 |???? 6?? (0)| 00:00:01 |
--------------------------------------------------------------------------
Statistics
----------------------------------------------------------
????????? 0? recursive calls
????????? 0? db block gets
???????? 81? consistent gets
????????? 0? physical reads
????????? 0? redo size
???? 105204? bytes sent via SQL*Net to client
?????? 1250? bytes received via SQL*Net from client
???????? 68? SQL*Net roundtrips to/from client
????????? 0? sorts (memory)
????????? 0? sorts (disk)
??????? 998? rows processed
SQL> select * from t13 where object_id<1200;
998 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 17950186
--------------------------------------------------------------------------
| Id? | Operation???????? | Name | Rows? | Bytes | Cost (%CPU)| Time???? |
--------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT? |????? |?? 998 | 85828 |???? 6?? (0)| 00:00:01 |
|*? 1 |? TABLE ACCESS FULL| T13? |?? 998 | 85828 |???? 6?? (0)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
?? 1 - filter("OBJECT_ID"<1200)
Statistics
----------------------------------------------------------
????????? 0? recursive calls
????????? 0? db block gets
??????? 161? consistent gets
????????? 0? physical reads
????????? 0? redo size
???? 105204? bytes sent via SQL*Net to client
?????? 1250? bytes received via SQL*Net from client
???????? 68? SQL*Net roundtrips to/from client
????????? 0? sorts (memory)
????????? 0? sorts (disk)
??????? 998? rows processed
2.2 設置參數值為10 ，這時ORACLE 會認為走索引的成本 更低。
SQL> alter? session set optimizer_index_cost_adj=10;
Session altered.
SQL> select * from t13;
998 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 17950186
--------------------------------------------------------------------------
| Id? | Operation???????? | Name | Rows? | Bytes | Cost (%CPU)| Time???? |
--------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT? |????? |?? 998 | 85828 |???? 6?? (0)| 00:00:01 |
|?? 1 |? TABLE ACCESS FULL| T13? |?? 998 | 85828 |???? 6?? (0)| 00:00:01 |
--------------------------------------------------------------------------
Statistics
----------------------------------------------------------
????????? 0? recursive calls
????????? 0? db block gets
???????? 82? consistent gets
????????? 0? physical reads
????????? 0? redo size
???? 105204? bytes sent via SQL*Net to client
?????? 1250? bytes received via SQL*Net from client
???????? 68? SQL*Net roundtrips to/from client
????????? 0? sorts (memory)
????????? 0? sorts (disk)
??????? 998? rows processed
SQL> set linesize 400;
SQL> select * from t13 where object_id<1200;
998 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 541349760
------------------------------------------------------------------------------------------
| Id? | Operation?????????????????? | Name?????? | Rows? | Bytes | Cost (%CPU)| Time???? |
------------------------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT??????????? |??????????? |?? 998 | 85828 |???? 3?? (0)| 00:00:01 |
|?? 1 |? TABLE ACCESS BY INDEX ROWID| T13??????? |?? 998 | 85828 |???? 3?? (0)| 00:00:01 |
|*? 2 |?? INDEX RANGE SCAN????????? | IDX_T13_ID |?? 998 |?????? |???? 1?? (0)| 00:00:01 |
------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
?? 2 - access("OBJECT_ID"<1200)
Statistics
----------------------------------------------------------
????????? 0? recursive calls
????????? 0? db block gets
??????? 161? consistent gets
????????? 0? physical reads
????????? 0? redo size
???? 105204? bytes sent via SQL*Net to client
?????? 1250? bytes received via SQL*Net from client
???????? 68? SQL*Net roundtrips to/from client
????????? 0? sorts (memory)
????????? 0? sorts (disk)
??????? 998? rows processed
SQL>
從最后的查詢可以看到，這時ORACLE走索引了。其實OBJECT_ID<1200就是全部數據。但人為的告訴ORACLE走索引更低，
這里有161個唯一值讀。而全表檢索也只不夠是82個唯一值的讀。
--------------------------------------------------------------------------------------------------------------
3.通過設置參數DB_FILE_MULTIBLOCK_READ_COUNT 不同的值，演示對SQL效率的影響（sql_trace or 10046 的輸出結果）<br>
SQL> drop table t13;
Table dropped.
SQL> create table t13 as select * from dba_objects;
Table created.
SQL> show parameter DB_FILE_MULTIBLOCK_READ_COUNT
NAME?????????????????????????? TYPE?????????? VALUE
------------------------------ -------?? ??? ?--------
db_file_multiblock_read_count? integer??????? 128
SQL> SET AUTOTRACE TRACEONLY;
SQL> select count(*) from t13;
Execution Plan
----------------------------------------------------------
Plan hash value: 2598196162
-------------------------------------------------------------------
| Id? | Operation????????? | Name | Rows? | Cost (%CPU)| Time???? |
-------------------------------------------------------------------
|?? 0 | SELECT STATEMENT?? |????? |???? 1 |?? 196?? (1)| 00:00:03 |
|?? 1 |? SORT AGGREGATE??? |????? |???? 1 |??????????? |????????? |
|?? 2 |?? TABLE ACCESS FULL| T13? | 82867 |?? 196?? (1)| 00:00:03 |
-------------------------------------------------------------------
Note
-----
?? - dynamic sampling used for this statement (level=2)
Statistics
----------------------------------------------------------
????????? 0? recursive calls
????????? 0? db block gets
?????? 1095? consistent gets?? ??? ?
????????? 0? physical reads
????????? 0? redo size
??????? 528? bytes sent via SQL*Net to client
??????? 524? bytes received via SQL*Net from client
????????? 2? SQL*Net roundtrips to/from client
????????? 0? sorts (memory)
????????? 0? sorts (disk)
????????? 1? rows processed
#1092/128=8.53125,約要讀8.5次可以把數據讀完。
SQL> alter system set DB_FILE_MULTIBLOCK_READ_COUNT=16;
System altered.
SQL> select count(*) from t13;
Execution Plan
----------------------------------------------------------
Plan hash value: 2598196162
-------------------------------------------------------------------
| Id? | Operation????????? | Name | Rows? | Cost (%CPU)| Time???? |
-------------------------------------------------------------------
|?? 0 | SELECT STATEMENT?? |????? |???? 1 |?? 247?? (1)| 00:00:03 |
|?? 1 |? SORT AGGREGATE??? |????? |???? 1 |??????????? |????????? |
|?? 2 |?? TABLE ACCESS FULL| T13? | 82867 |?? 247?? (1)| 00:00:03 |
-------------------------------------------------------------------
Note
-----
?? - dynamic sampling used for this statement (level=2)
Statistics
----------------------------------------------------------
????????? 0? recursive calls
????????? 0? db block gets
?????? 1095? consistent gets
????????? 0? physical reads
????????? 0? redo size
??????? 528? bytes sent via SQL*Net to client
??????? 524? bytes received via SQL*Net from client
????????? 2? SQL*Net roundtrips to/from client
????????? 0? sorts (memory)
????????? 0? sorts (disk)
????????? 1? rows processed
SQL>
#1092/16=68.25,約要讀68次可以把數據讀完。
上面為兩次在不同的 DB_FILE_MULTIBLOCK_READ_COUNT 參數值環境下，同一執行計劃的成本。
可以看出，在一次只讀16塊時，成本上升。
再打開10046事件跟蹤，查看在不同參數環境下，查詢到底發生了什么變化。
SQL> show parameter DB_FILE_MULTIBLOCK_READ_COUNT
NAME?????????????????????????? TYPE?????????? VALUE
------------------------------ -------?? ??? ?--------
db_file_multiblock_read_count? integer??????? 128
SQL> alter session set events '10046 trace name context forever,level 12';
Session altered.
SQL> alter system flush shared_pool;
System altered.
SQL> alter system flush shared_pool;
System altered.
SQL> alter system flush shared_pool;
System altered.
SQL> select count(*) from t13;
? COUNT(*)
----------
?????? 998
SQL> alter system set DB_FILE_MULTIBLOCK_READ_COUNT=16;
System altered.
SQL> select count(*) from t13;
? COUNT(*)
----------
?????? 998
SQL> alter session set events '10046 trace name context off';
Session altered.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
C:\Users\Administrator>
trace file content:
-------------------------------------------------------
=====================
PARSING IN CURSOR #438005240 len=24 dep=0 uid=84 oct=3 lid=84 tim=10125283859956 hv=988653825 ad='2f0ddbf70' sqlid='6aqutrwxfva81'
select count(*) from t13
END OF STMT
PARSE #438005240:c=0,e=9297,p=0,cr=103,cu=4,mis=1,r=0,dep=0,og=1,plh=2598196162,tim=10125283859955
EXEC #438005240:c=0,e=25,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2598196162,tim=10125283860031
WAIT #438005240: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=10125283860085
FETCH #438005240:c=15600,e=12634,p=0,cr=1095,cu=0,mis=0,r=1,dep=0,og=1,plh=2598196162,tim=10125283872748
STAT #438005240 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=1095 pr=0 pw=0 time=12629 us)'
STAT #438005240 id=2 cnt=76475 pid=1 pos=1 obj=99240 op='TABLE ACCESS FULL T13 (cr=1095 pr=0 pw=0 time=80082 us cost=196 size=0 card=82867)'
WAIT #438005240: nam='SQL*Net message from client' ela= 605 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=10125283873478
FETCH #438005240:c=0,e=2,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=2598196162,tim=10125283873523
WAIT #438005240: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=10125283873551
*** 2013-12-26 16:06:06.746
WAIT #438005240: nam='SQL*Net message from client' ela= 6166840 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=10125290040409
CLOSE #438005240:c=0,e=12,dep=0,type=0,tim=10125290040702
我們來重點查看? FETCH部分
c=15600???????????????? 消耗的CPU時間
e=12634?????????????? 這步操作的總用時
p=0???????????????? 物理讀的次數
cr=1095??????????????? 一致性讀的次數（也叫數據塊數），這個一致性讀跟數據塊在內存中還是硬盤中是沒有關系的，它代表就需要讀這么多次而已。如果要找的數據沒有在內存中就會觸發一次物理讀
cu=0?????????????? current方式讀的次數（數據塊數）
mis=0????????????? 硬解析的次數
r=1??????????????? rows處理的行數
dep=1????????????? 遞歸的SQL深度
og=1?????????????? optimizer goal優化其模式
tim=10125283872748? 時間戳
plh=2598196162????? plan hash value? 執行計劃的哈希值
=====================
PARSING IN CURSOR #436681312 len=49 dep=0 uid=84 oct=49 lid=84 tim=10125290040764 hv=2944834790 ad='0' sqlid='6yq881yrsd776'
alter system set DB_FILE_MULTIBLOCK_READ_COUNT=16
END OF STMT
PARSE #436681312:c=0,e=13,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=0,tim=10125290040763
WAIT #436681312: nam='reliable message' ela= 80 channel context=12688921096 channel handle=12537097552 broadcast message=12689296352 obj#=-1 tim=10125290041221
WAIT #436681312: nam='Disk file operations I/O' ela= 220 FileOperation=2 fileno=0 filetype=13 obj#=-1 tim=10125290041485
WAIT #436681312: nam='Parameter File I/O' ela= 157 blkno=1 #blks=1 read/write=1 obj#=-1 tim=10125290041667
WAIT #436681312: nam='Parameter File I/O' ela= 85 blkno=2 #blks=3 read/write=1 obj#=-1 tim=10125290041850
WAIT #436681312: nam='Parameter File I/O' ela= 89 blkno=5 #blks=3 read/write=2 obj#=-1 tim=10125290044211
WAIT #436681312: nam='Parameter File I/O' ela= 85 blkno=1 #blks=1 read/write=2 obj#=-1 tim=10125290044332
WAIT #436681312: nam='Parameter File I/O' ela= 108 blkno=5 #blks=3 read/write=1 obj#=-1 tim=10125290044468
WAIT #436681312: nam='Parameter File I/O' ela= 57 blkno=2 #blks=3 read/write=2 obj#=-1 tim=10125290044557
WAIT #436681312: nam='Parameter File I/O' ela= 53 blkno=1 #blks=1 read/write=2 obj#=-1 tim=10125290044639
WAIT #436681312: nam='Parameter File I/O' ela= 53 blkno=5 #blks=3 read/write=2 obj#=-1 tim=10125290044719
WAIT #436681312: nam='Disk file operations I/O' ela= 441 FileOperation=5 fileno=0 filetype=13 obj#=-1 tim=10125290045185
=====================
.............
=====================
PARSING IN CURSOR #438005240 len=24 dep=0 uid=84 oct=3 lid=84 tim=10125294712617 hv=988653825 ad='2f0ddbf70' sqlid='6aqutrwxfva81'
select count(*) from t13
END OF STMT
PARSE #438005240:c=0,e=4128,p=0,cr=73,cu=0,mis=1,r=0,dep=0,og=1,plh=2598196162,tim=10125294712616
EXEC #438005240:c=0,e=25,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2598196162,tim=10125294712692
WAIT #438005240: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=10125294712743
FETCH #438005240:c=15600,e=12991,p=0,cr=1095,cu=0,mis=0,r=1,dep=0,og=1,plh=2598196162,tim=10125294725760
STAT #438005240 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=1095 pr=0 pw=0 time=12985 us)'
STAT #438005240 id=2 cnt=76475 pid=1 pos=1 obj=99240 op='TABLE ACCESS FULL T13 (cr=1095 pr=0 pw=0 time=83408 us cost=247 size=0 card=82867)'
WAIT #438005240: nam='SQL*Net message from client' ela= 426 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=10125294726301
FETCH #438005240:c=0,e=3,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=2598196162,tim=10125294726343
WAIT #438005240: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=10125294726371
*** 2013-12-26 16:06:16.309
WAIT #438005240: nam='SQL*Net message from client' ela= 4876078 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=10125299602467
CLOSE #438005240:c=0,e=9,dep=0,type=0,tim=10125299602722
我們來看參數值為16時的? FETCH部分
c=15600???????????????? 消耗的CPU時間
e=12991 （上一次12634 可以看出增加了）????????????? 這步操作的總用時
p=0???????????????? 物理讀的次數
cr=1095??????????????? 一致性讀的次數（也叫數據塊數），這個一致性讀跟數據塊在內存中還是硬盤中是沒有關系的，它代表就需要讀這么多次而已。如果要找的數據沒有在內存中就會觸發一次物理讀
cu=0?????????????? current方式讀的次數（數據塊數）
mis=0????????????? 硬解析的次數
r=1??????????????? rows處理的行數
dep=1????????????? 遞歸的SQL深度
og=1?????????????? optimizer goal優化其模式
tim=10125294725760 （上一次 10125283872748）? 時間戳
plh=2598196162????? plan hash value? 執行計劃的哈希值
=====================
PARSING IN CURSOR #438005240 len=55 dep=0 uid=84 oct=42 lid=84 tim=10125299602877 hv=2217940283 ad='0' sqlid='06nvwn223659v'
alter session set events '10046 trace name context off'
END OF STMT
PARSE #438005240:c=0,e=112,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=0,tim=10125299602876
EXEC #438005240:c=0,e=503,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=0,tim=10125299603428
------------------------------------------------------------------
4.示例說明數據庫中“會話”和“進程”之間的關系。<br>
先梳理一下名稱
連接：從客戶端到ORACLE實例的一條鏈路，
會話：指與數據庫的一個連接就是一個會話，會話是實例中存在的一個邏輯實體。
這就是你的會話狀態（session state），ORACLE實例已分配了對應的內存空間。
進程：指操作系統層面，與數據庫開啟了一個連接。
4.1.一個進程對應一個會話：
?? ?登錄ORACLE
?? ?[oracle@ract1 ~]$ sqlplus tang/sa@orcl
?? ?查詢當前會話：
?? ?SQL> select SS.USERNAME,SPID from v$process pr,v$session ss where pr.addr=ss.paddr and ss.USERNAME IN ('SYS','TANG');
?? ?USERNAME?? ??? ??? ?SPID
?? ?------------------------------------------------------------------------
?? ?SYS?? ??? ??? ??? ??? ?10787
?? ?TANG?? ??? ??? ??? ?11621
?? ?在操作系統中查看會話的進程 按進程號看到11621 是存在的
?? ?[root@ract1 ~]# ps -ef|grep 11621
?? ?oracle?? 11621???? 1? 0 11:41 ???????? 00:00:00 oracletdb1 (LOCAL=NO)
?? ?root???? 12049 11659? 0 11:50 pts/3??? 00:00:00 grep 11621
4.2.有進程，沒會話
?? ?[oracle@ract1 ~]$ sqlplus tang/sa@orcl
?? ?SQL> disconnect;
?? ?Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
?? ?With the Partitioning, Real Application Clusters, Automatic Storage Management and Data Mining options
?? ?SQL>
?? ?在另一個SYS 登錄的窗口查詢：
?? ?SQL> /
?? ?USERNAME? SPID
?? ?-------------------------
?? ?SYS?? ??? ??? ?10787
?? ?SQL>
?? ?看到這時在ORACLE下，沒有會話信息了。
?? ?但在同一臺服務器中，再查詢是否還有打開ORACLE的進程呢，可以看到，是有的
?? ?[root@ract1 ~]# ps -ef|grep oracletdb1
?? ?oracle?? 10787 10615? 0 11:27 ???????? 00:00:04 oracletdb1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
?? ?oracle?? 12184???? 1? 0 11:54 ???????? 00:00:00 oracletdb1 (LOCAL=NO)
?? ?root???? 12271 11659? 0 11:56 pts/3??? 00:00:00 grep oracletdb1
?? ?[root@ract1 ~]#
?? ?還可以再建立連接。查看剛看到的進程，是否就是打開的SQLPUS窗口的進程
?? ?SQL> connect
?? ?Enter user-name: tang
?? ?Enter password:
?? ?Connected.
?? ?SQL>
?? ?從下面的兩次對比可以看出。
?? ?[root@ract1 ~]# ps -ef|grep oracletdb1
?? ?oracle?? 10787 10615? 0 11:27 ???????? 00:00:04 oracletdb1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
?? ?oracle?? 12184???? 1? 0 11:54 ???????? 00:00:00 oracletdb1 (LOCAL=NO)
?? ?root???? 12271 11659? 0 11:56 pts/3??? 00:00:00 grep oracletdb1
?? ?[root@ract1 ~]# ps -ef|grep oracletdb1
?? ?oracle?? 10787 10615? 0 11:27 ???????? 00:00:04 oracletdb1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
?? ?oracle?? 12308 12182? 5 11:57 ???????? 00:00:00 oracletdb1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
?? ?root???? 12312 11659? 0 11:57 pts/3??? 00:00:00 grep oracletdb1
?? ?[root@ract1 ~]#
?? ?SQL> /
?? ?USERNAME?? ?SPID
?? ?--------------------
?? ?SYS?? ??? ??? ?10787
?? ?TANG?? ??? ?12308
?? ?SQL>
4.3.無進程，無會話：
?? ?4.3.1在一個窗口登錄
?? ?[oracle@ract1 ~]$ sqlplus /nolog
?? ?SQL*Plus: Release 11.2.0.1.0 Production on Fri Dec 27 14:35:43 2013
?? ?Copyright (c) 1982, 2009, Oracle.? All rights reserved.
?? ?SQL>
?? ?4.3.2在另一個窗口查詢
?? ?SQL> select SS.USERNAME,SPID from v$process pr,v$session ss where pr.addr=ss.paddr and ss.USERNAME IN ('SYS','TANG');
?? ?USERNAME?? ??? ?SPID
?? ?-----------?? -------
?? ?SYS?? ??? ??? ??? ?10787
?? ?4.3.3在另一個SHELL 窗口查看進程：
?? ?[oracle@ract1 ~]$ ps -ef|grep oracletdb
?? ?oracle?? 10787 10615? 0 11:27 ???????? 00:00:04 oracletdb1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
?? ?oracle?? 19187 18653? 0 14:36 pts/3??? 00:00:00 grep oracletdb
?? ?[oracle@ract1 ~]$
?? ?可以看到，使用ORACLE 的進程只有一個 10787 ，就是使用SYS登錄 查詢會話的窗口，
?? ?而第一個窗口登錄的，卻沒有會話記錄，也沒有進程信息。
4.4 單連接，單進程，多會話
?? ?4.4.1 登錄ORACLE,打開跟蹤
?? ?[oracle@ract1 ~]$ sqlplus tang/sa@tdb1
?? ?SQL*Plus: Release 11.2.0.1.0 Production on Fri Dec 27 14:43:05 2013
?? ?Copyright (c) 1982, 2009, Oracle.? All rights reserved.
?? ?Connected to:
?? ?Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
?? ?With the Partitioning, Real Application Clusters, Automatic Storage Management and Data Mining options
?? ?SQL> set autotrace on
?? ?SQL> set linesize 200;
?? ?4.4.2 另外一窗口查詢
?? ?SQL> select SS.USERNAME,SPID,SS.SERIAL# from v$process pr,v$session ss where pr.addr=ss.paddr and ss.USERNAME IN ('SYS','TANG');
?? ?USERNAME?? ?SPID?? ??? SERIAL#
?? ?--------------------------------
?? ?SYS?? ??? ??? ?10787?? ??? ? 5
?? ?TANG?? ??? ?19522?? ??? ?20
?? ?TANG?? ??? ?19522?????? 100
?? ?SQL>
?? ?4.4.3 查詢進程
?? ??? ?[oracle@ract1 ~]$ ps -ef|grep oracletdb
?? ??? ?oracle?? 10787 10615? 0 11:27 ???????? 00:00:04 oracletdb1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
?? ??? ?oracle?? 19522???? 1? 0 14:43 ???????? 00:00:00 oracletdb1 (LOCAL=NO)
?? ??? ?oracle?? 19689 18653? 0 14:47 pts/3??? 00:00:00 grep oracletdb
?? ?看到進程數還是兩個，但在進程 19522 ，中。會話卻有了2個
?? ?當啟用set autotrace功能后，通常會創建一個新的會話用于監控當前的操作并返回統計信息，并記錄到跟蹤日志中。
??? session：指定了一個實例中允許的會話數，即能同時登錄到數據庫的并發用戶數。
??? process: 指定了一個實例在操作系統級別能同時運行的進程數，包括后臺進程與服務器進程。
??? 由上面的分析可知，一個后臺進程可能同時對應對個會話，因此通常sessions的值是大于processes的值
??? 通常的設置公式
??????? sessions = 1.1 * processes + 5? ?
------------------------------------------------------------------
5.演示通過動態視圖查看某個會話的等待事件。<br>
?? ?
?? ?幾個相關的性能視圖：
?? ?v$session?? ?會話當前的各種狀態和屬性；
?? ?v$session_wait 會話當前的等待事件詳細信息；
?? ?v$session_event 會話的所有等待事件的詳細信息;
?? ?
?? ?v$session_wait_history 會話的等待事件的歷史信息
?? ?v$sesstat 會話資源的統計信息
?? ?
#查詢當前SESSION_ID
SQL> select distinct sid from v$mystat;
?????? SID
----------
??????? 42
#建立一個測試環境數據
SQL> drop table t13 purge;
Table dropped.
SQL> create table t13 as select * from dba_objects;
Table created.
SQL> create table t13_name as select object_name from dba_objects;
Table created.
SQL> alter system flush buffer_cache;
System altered.
SQL> /
System altered.
SQL> /
System altered.
SQL> set autot trace expl;
SQL> set linesize 400;
SQL> set pagesize 800;
SQL>
#為了能查看到等待事件，我用了 兩個表的兩字段關聯。可以看出是進行了全表檢索
SQL> select t.* from t13 t inner join t13_name n on t.object_name=n.object_name;
Execution Plan
----------------------------------------------------------
Plan hash value: 3251948810
---------------------------------------------------------------------------------------
| Id? | Operation????????? | Name???? | Rows? | Bytes |TempSpc| Cost (%CPU)| Time???? |
---------------------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT?? |????????? |?? 414K|?? 107M|?????? |? 1467?? (1)| 00:00:18 |
|*? 1 |? HASH JOIN???????? |????????? |?? 414K|?? 107M|? 5840K|? 1467?? (1)| 00:00:18 |
|?? 2 |?? TABLE ACCESS FULL| T13_NAME | 76610 |? 4937K|?????? |??? 74?? (2)| 00:00:01 |
|?? 3 |?? TABLE ACCESS FULL| T13????? | 82867 |??? 16M|?????? |?? 248?? (1)| 00:00:03 |
---------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
?? 1 - access("T"."OBJECT_NAME"="N"."OBJECT_NAME")
Note
-----
?? - dynamic sampling used for this statement (level=2)
SQL>
為了更好的查看等待事件，我特別進行全表查詢，并且每次都清空緩存
SQL> set autot off;
SQL> for i in 1..10000 loop
SP2-0734: unknown command beginning "for i in 1..." - rest of line ignored.
SQL> begin
? 2? for i in 1..10000 loop
? 3? execute immediate 'select t.* from t13 t inner join t13_name n on t.object_name=n.object_name';
? 4? execute immediate 'alter system flush buffer_cache';
? 5? end loop;
? 6? end;
? 7? /
在另一個窗口查看等待事件情況：
select sid,event,total_waits,total_timeouts,time_waited
from v$session_event where sid =42;
? ??? ?SID?? ?EVENT?? ?TOTAL_WAITS?? ?TOTAL_TIMEOUTS?? ?TIME_WAITED
?? ?---------------------------------------------------
1?? ?42?? ?Disk file operations I/O?? ?4?? ?0?? ?0?? ??? ?#操作系統IO? 等待
2?? ?42?? ?latch: cache buffers chains?? ?2?? ?0?? ?0?? ??? ?#LATCH 等待
3?? ?42?? ?buffer busy waits?? ?7?? ?0?? ?0?? ??? ??? ??? ?#buffer 等待
4?? ?42?? ?read by other session?? ?2?? ?0?? ?0
5?? ?42?? ?enq: RO - fast object reuse?? ?1?? ?0?? ?0
6?? ?42?? ?log file sync?? ?5?? ?0?? ?0
7?? ?42?? ?db file sequential read?? ?24665?? ?0?? ?350?? ??? ?#數據文件順序讀等待
8?? ?42?? ?db file scattered read?? ?130?? ?0?? ?15
9?? ?42?? ?direct path write?? ?2?? ?0?? ?0
10?? ?42?? ?SQL*Net message to client?? ?39?? ?0?? ?0
11?? ?42?? ?SQL*Net message from client?? ?39?? ?0?? ?228811
12?? ?42?? ?SQL*Net break/reset to client?? ?2?? ?0?? ?0
13?? ?42?? ?events in waitclass Other?? ?8240?? ?0?? ?51570
可以從此表中看到，當上面的循環查詢沒完成前，‘db file sequential read’ 數據讀等待 及等待時間，還是一直增加的。
完成后，也可以在等待厙事件表中可以同樣查詢到
select * from v$session_wait_history where sid=42;
? ??? ?SID?? ?SEQ#?? ?EVENT#?? ?EVENT?? ?P1TEXT?? ?P1?? ?P2TEXT?? ?P2?? ?P3TEXT?? ?P3?? ?WAIT_TIME?? ?WAIT_TIME_MICRO?? ?TIME_SINCE_LAST_WAIT_MICRO
?? ?-----------------------------------------------------------------------------------------------------------------------
1?? ?42?? ?1?? ?348?? ?SQL*Net message to client?? ?driver id?? ?1413697536?? ?#bytes?? ?1?? ??? ?0?? ?0?? ?3?? ?216
2?? ?42?? ?2?? ?146?? ?db file sequential read?? ?file#?? ?3?? ?block#?? ?2248?? ?blocks?? ?1?? ?0?? ?93?? ?39
3?? ?42?? ?3?? ?146?? ?db file sequential read?? ?file#?? ?3?? ?block#?? ?240?? ?blocks?? ?1?? ?0?? ?113?? ?92
4?? ?42?? ?4?? ?146?? ?db file sequential read?? ?file#?? ?1?? ?block#?? ?244652?? ?blocks?? ?1?? ?0?? ?114?? ?236
5?? ?42?? ?5?? ?440?? ?rdbms ipc reply?? ?from_process?? ?14?? ?timeout?? ?21474836?? ??? ?0?? ?5?? ?52869?? ?693
6?? ?42?? ?6?? ?146?? ?db file sequential read?? ?file#?? ?3?? ?block#?? ?2248?? ?blocks?? ?1?? ?0?? ?132?? ?38
7?? ?42?? ?7?? ?146?? ?db file sequential read?? ?file#?? ?3?? ?block#?? ?240?? ?blocks?? ?1?? ?0?? ?109?? ?92
8?? ?42?? ?8?? ?146?? ?db file sequential read?? ?file#?? ?1?? ?block#?? ?244652?? ?blocks?? ?1?? ?0?? ?140?? ?241
9?? ?42?? ?9?? ?440?? ?rdbms ipc reply?? ?from_process?? ?14?? ?timeout?? ?21474836?? ??? ?0?? ?5?? ?54544?? ?587
10?? ?42?? ?10?? ?146?? ?db file sequential read?? ?file#?? ?3?? ?block#?? ?2248?? ?blocks?? ?1?? ?0?? ?109?? ?34
總結
以上是生活随笔為你收集整理的【性能优化】 之性能视图及性能参数的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【性能优化】 之 10053 事件
- 下一篇： 【性能优化】 之AWR 报告分析