1.設(shè)置memory_target參數(shù)，并通過 v$memory_target_advice分析數(shù)據(jù)庫的最佳內(nèi)存大小。<br>
2.通過調(diào)整參數(shù)optimizer_index_cost_adj的大小，演示SQL產(chǎn)生不同執(zhí)行計劃。<br>
3.通過設(shè)置參數(shù)DB_FILE_MULTIBLOCK_READ_COUNT 不同的值，演示對SQL效率的影響（sql_trace or 10046 的輸出結(jié)果）<br>
4.示例說明數(shù)據(jù)庫中“會話”和“進程”之間的關(guān)系。<br>
5.演示通過動態(tài)視圖查看某個會話的等待事件。<br>

=============================================================================================
1.設(shè)置memory_target參數(shù)，并通過 v$memory_target_advice分析數(shù)據(jù)庫的最佳內(nèi)存大小。<br>

先查了一下相關(guān)參數(shù)值，發(fā)現(xiàn)memory_target? 沒有設(shè)置，默認值為0，
這時 sga_target 是有設(shè)置的，那么這時的設(shè)置

v$memory_target_advice 表中沒有數(shù)據(jù)，說明這時沒有使用內(nèi)存自動調(diào)整？

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>
調(diào)整內(nèi)存參數(shù)，
我把內(nèi)存參數(shù)設(shè)置成系統(tǒng)內(nèi)存的1/2,
sga 設(shè)置為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.

重啟服務(wù)器使參數(shù)生效
SQL> startup force;
ORACLE 例程已經(jīng)啟動。

Total System Global Area 6263357440 bytes
Fixed Size????????????????? 2266816 bytes
Variable Size??????????? 1912604992 bytes
Database Buffers???????? 4328521728 bytes
Redo Buffers?????????????? 19963904 bytes
數(shù)據(jù)庫裝載完畢。
數(shù)據(jù)庫已經(jīng)打開。
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>

查詢內(nèi)存優(yōu)化表，可以看出，這時ORACLE已給出了調(diào)整方案了。
同時也可以看到，這里的最大內(nèi)存 16000 即為我操作系統(tǒng)中的內(nèi)存總數(shù)。
從下面兩個表中數(shù)據(jù)可以看到，在這個數(shù)據(jù)庫中，內(nèi)存調(diào)整從2G--16G，對性能來說，
都沒有變化。內(nèi)存的調(diào)整對性能沒有什么質(zhì)的變化。


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.通過調(diào)整參數(shù) optimizer_index_cost_adj 的大小，演示SQL產(chǎn)生不同執(zhí)行計劃。<br>

參數(shù)說明：
OPTIMIZER_INDEX_COST_ADJ
這個初始化參數(shù)代表一個百分比,取值范圍在1到10000之間.
該參數(shù)表示索引掃描和全表掃描成本的比較。缺省值100表示索引掃描成本等價轉(zhuǎn)換與全表掃描成本。

這些參數(shù)對于CBO的執(zhí)行具有重大影響，其缺省值對于數(shù)據(jù)庫來說通常需要調(diào)整。
一般來說對于OPTIMIZER_INDEX_CACHING可以設(shè)置為90左右
對于大多數(shù)OLTP系統(tǒng)，OPTIMIZER_INDEX_COST_ADJ可以設(shè)置在10到50之間。對于數(shù)據(jù)倉庫和DSS系統(tǒng)，
比如設(shè)置以下值：
?? ?Optimizer_index_cost_adj=20 ，表示索引的成本和全表掃描的成本比為1:5。



2.1 建立演示數(shù)據(jù)表：

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


在默認參數(shù)情況下，可以看到，查詢所以數(shù)據(jù)及使用條件查詢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 設(shè)置參數(shù)值為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就是全部數(shù)據(jù)。但人為的告訴ORACLE走索引更低，
這里有161個唯一值讀。而全表檢索也只不夠是82個唯一值的讀。





--------------------------------------------------------------------------------------------------------------
3.通過設(shè)置參數(shù)DB_FILE_MULTIBLOCK_READ_COUNT 不同的值，演示對SQL效率的影響（sql_trace or 10046 的輸出結(jié)果）<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次可以把數(shù)據(jù)讀完。


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次可以把數(shù)據(jù)讀完。

上面為兩次在不同的 DB_FILE_MULTIBLOCK_READ_COUNT 參數(shù)值環(huán)境下，同一執(zhí)行計劃的成本。
可以看出，在一次只讀16塊時，成本上升。


再打開10046事件跟蹤，查看在不同參數(shù)環(huán)境下，查詢到底發(fā)生了什么變化。


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???????????????? 物理讀的次數(shù)
cr=1095??????????????? 一致性讀的次數(shù)（也叫數(shù)據(jù)塊數(shù)），這個一致性讀跟數(shù)據(jù)塊在內(nèi)存中還是硬盤中是沒有關(guān)系的，它代表就需要讀這么多次而已。如果要找的數(shù)據(jù)沒有在內(nèi)存中就會觸發(fā)一次物理讀
cu=0?????????????? current方式讀的次數(shù)（數(shù)據(jù)塊數(shù)）
mis=0????????????? 硬解析的次數(shù)
r=1??????????????? rows處理的行數(shù)
dep=1????????????? 遞歸的SQL深度
og=1?????????????? optimizer goal優(yōu)化其模式
tim=10125283872748? 時間戳
plh=2598196162????? plan hash value? 執(zhí)行計劃的哈希值





=====================
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


我們來看參數(shù)值為16時的? FETCH部分
c=15600???????????????? 消耗的CPU時間
e=12991 （上一次12634 可以看出增加了）????????????? 這步操作的總用時
p=0???????????????? 物理讀的次數(shù)
cr=1095??????????????? 一致性讀的次數(shù)（也叫數(shù)據(jù)塊數(shù)），這個一致性讀跟數(shù)據(jù)塊在內(nèi)存中還是硬盤中是沒有關(guān)系的，它代表就需要讀這么多次而已。如果要找的數(shù)據(jù)沒有在內(nèi)存中就會觸發(fā)一次物理讀
cu=0?????????????? current方式讀的次數(shù)（數(shù)據(jù)塊數(shù)）
mis=0????????????? 硬解析的次數(shù)
r=1??????????????? rows處理的行數(shù)
dep=1????????????? 遞歸的SQL深度
og=1?????????????? optimizer goal優(yōu)化其模式
tim=10125294725760 （上一次 10125283872748）? 時間戳
plh=2598196162????? plan hash value? 執(zhí)行計劃的哈希值




=====================
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.示例說明數(shù)據(jù)庫中“會話”和“進程”之間的關(guān)系。<br>

先梳理一下名稱

連接：從客戶端到ORACLE實例的一條鏈路，
會話：指與數(shù)據(jù)庫的一個連接就是一個會話，會話是實例中存在的一個邏輯實體。
這就是你的會話狀態(tài)（session state），ORACLE實例已分配了對應(yīng)的內(nèi)存空間。
進程：指操作系統(tǒng)層面，與數(shù)據(jù)庫開啟了一個連接。

4.1.一個進程對應(yīng)一個會話：

?? ?登錄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


?? ?在操作系統(tǒng)中查看會話的進程 按進程號看到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下，沒有會話信息了。

?? ?但在同一臺服務(wù)器中，再查詢是否還有打開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

?? ?看到進程數(shù)還是兩個，但在進程 19522 ，中。會話卻有了2個
?? ?當啟用set autotrace功能后，通常會創(chuàng)建一個新的會話用于監(jiān)控當前的操作并返回統(tǒng)計信息，并記錄到跟蹤日志中。



??? session：指定了一個實例中允許的會話數(shù)，即能同時登錄到數(shù)據(jù)庫的并發(fā)用戶數(shù)。
??? process: 指定了一個實例在操作系統(tǒng)級別能同時運行的進程數(shù)，包括后臺進程與服務(wù)器進程。
??? 由上面的分析可知，一個后臺進程可能同時對應(yīng)對個會話，因此通常sessions的值是大于processes的值
??? 通常的設(shè)置公式
??????? sessions = 1.1 * processes + 5? ?

------------------------------------------------------------------
5.演示通過動態(tài)視圖查看某個會話的等待事件。<br>
?? ?
?? ?幾個相關(guān)的性能視圖：
?? ?v$session?? ?會話當前的各種狀態(tài)和屬性；
?? ?v$session_wait 會話當前的等待事件詳細信息；
?? ?v$session_event 會話的所有等待事件的詳細信息;
?? ?
?? ?v$session_wait_history 會話的等待事件的歷史信息

?? ?v$sesstat 會話資源的統(tǒng)計信息

?? ?

#查詢當前SESSION_ID

SQL> select distinct sid from v$mystat;

?????? SID
----------
??????? 42

#建立一個測試環(huán)境數(shù)據(jù)
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>

#為了能查看到等待事件，我用了 兩個表的兩字段關(guān)聯(lián)。可以看出是進行了全表檢索
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?? ??? ?#操作系統(tǒng)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?? ??? ?#數(shù)據(jù)文件順序讀等待
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



可以從此表中看到，當上面的循環(huán)查詢沒完成前，‘db file sequential read’ 數(shù)據(jù)讀等待 及等待時間，還是一直增加的。
完成后，也可以在等待厙事件表中可以同樣查詢到


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

總結(jié)

以上是生活随笔為你收集整理的【性能优化】 之性能视图及性能参数的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。