【效能優化】 之效能檢視及效能引數
阿新 • • 發佈：2019-02-11
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/
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
[
查詢當前會話：
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 是存在的
[
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.有程序，沒會話
[[email protected] ~]$ sqlplus tang/[email protected]
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的程序呢，可以看到，是有的
[[email protected] ~]# 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
[[email protected] ~]#
還可以再建立連線。檢視剛看到的程序，是否就是開啟的SQLPUS視窗的程序
SQL> connect
Enter user-name: tang
Enter password:
Connected.
SQL>
從下面的兩次對比可以看出。
[[email protected] ~]# 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
[[email protected] ~]# 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
[[email protected] ~]#
SQL> /
USERNAME SPID
--------------------
SYS 10787
TANG 12308
SQL>
4.3.無程序，無會話：
4.3.1在一個視窗登入
[[email protected] ~]$ 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 視窗檢視程序：
[[email protected] ~]$ 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
[[email protected] ~]$
可以看到，使用ORACLE 的程序只有一個 10787 ，就是使用SYS登入 查詢會話的視窗，
而第一個視窗登入的，卻沒有會話記錄，也沒有程序資訊。
4.4 單連線，單程序，多會話
4.4.1 登入ORACLE,開啟跟蹤
[[email protected] ~]$ sqlplus tang/[email protected]
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 查詢程序
[[email protected] ~]$ 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/
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
[
查詢當前會話：
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 是存在的
[
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.有程序，沒會話
[[email protected] ~]$ sqlplus tang/[email protected]
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的程序呢，可以看到，是有的
[[email protected] ~]# 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
[[email protected] ~]#
還可以再建立連線。檢視剛看到的程序，是否就是開啟的SQLPUS視窗的程序
SQL> connect
Enter user-name: tang
Enter password:
Connected.
SQL>
從下面的兩次對比可以看出。
[[email protected] ~]# 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
[[email protected] ~]# 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
[[email protected] ~]#
SQL> /
USERNAME SPID
--------------------
SYS 10787
TANG 12308
SQL>
4.3.無程序，無會話：
4.3.1在一個視窗登入
[[email protected] ~]$ 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 視窗檢視程序：
[[email protected] ~]$ 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
[[email protected] ~]$
可以看到，使用ORACLE 的程序只有一個 10787 ，就是使用SYS登入 查詢會話的視窗，
而第一個視窗登入的，卻沒有會話記錄，也沒有程序資訊。
4.4 單連線，單程序，多會話
4.4.1 登入ORACLE,開啟跟蹤
[[email protected] ~]$ sqlplus tang/[email protected]
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 查詢程序
[[email protected] ~]$ 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
相關推薦
【效能優化】 之效能檢視及效能引數
1.設定memory_target引數，並通過 v$memory_target_advice分析資料庫的最佳記憶體大小。<br> 2.通過調整引數optimizer_index_cost_adj的大小，演示SQL產生不同執行計劃。<br> 3.通過設
【效能優化】 之 並行執行
1.給出一個2表關聯的並行查詢執行計劃，並畫出並行資料流圖。<br> 2.就自己本機的硬體情況，通過SQL示例，來找到最優的並行度。<br> 3.針對PARALLEL_DEGREE_POLICY的三個值，分別演示它們的效果。<br> 4.
【oracle效能優化】- 使用AWR定位oracle效能瓶頸
1 AWR簡介 AWR（全稱Automatic Workload Repository）是Oracle 10g版本推出的新特性，隨資料庫一起被安裝的效能收集和分析工具。AWR可以收集場景執行期間的各方面效能資料，還可以從統計資料中分析出度量資料，通過分析報告，可以瞭解整個系統的執行情況，因而，o
【redis常用的鍵值操作及效能優化】
服務端 啟動redis服務 { // -a:指定密碼 -h:指定主機 -p:指定埠 } //讓redis 服務中斷崩潰 //儲存和關閉 //後臺備份 //設定登入密碼 //redis-benchmark :效能測試 &
【朝花夕拾】Android效能優化篇之（四）Apk打包
APK，即Android Package，是將android程式和資源整合在一起，形成的一個.apk檔案。相信所有的Android程式設計師是在IDE的幫助下，完成打包輕而易舉，但對打包流程真正清楚的可能並不多。本章的內容比較簡單，也是非常基礎的內容，但是對理解android應用的結構卻有很大
【朝花夕拾】Android效能優化篇之（一）序言及JVM篇
序言 筆者從事Anroid開發有些年頭了，深知掌握Anroid效能優化方面的知識的必要性，這是一個程式設計師必須修煉的內功。在面試中，它是面試官的摯愛，在工作中，它是程式碼質量的攔路虎，其重要性可見一斑。在團隊中，效能優化的工作又往往由經驗豐富的老師傅來完成，可見要做好效能優化，絕不是一件容易的事情。
146.Python修煉之路【151-前端-前端自動化及其優化-前端效能優化】2018.08.06
前端效能優化 從使用者訪問資源到資源完整的展現在使用者面前的過程中，通過技術手段和優化策略，縮短每個步驟的處理時間從而提升整個資源的訪問和呈現速度。網站的效能直接會影響到使用者的數量，所有前端效能優化很重要。 前端效能優化分為如下幾個方面： 一、程式碼部署： 1、程式碼的壓縮與合併
【朝花夕拾】Android效能優化篇之（五）Android虛擬機器簡介
前言 Android虛擬機器的使用，使得android應用和Linux核心分離，這樣做使得android系統更穩定可靠，比如程式中即使包含惡意程式碼，也不會直接影響系統檔案；也提高了跨平臺相容性。在Android4.4以前的系統中，Android系統均採用Dalvik作為執行andorid程式的
【朝花夕拾】Android效能優化篇之（五）Android虛擬機器
前言 Android虛擬機器的使用，使得android應用和Linux核心分離，這樣做使得android系統更穩定可靠，比如程式中即使包含惡意程式碼，也不會直接影響系統檔案；也提高了跨平臺相容性。在Android4.4以前的系統中，Android系統均採用Da
【朝花夕拾】效能優化篇之（八）AIDL與Android跨程序通訊
一、Linux程序間通訊 1、程序隔離 在作業系統中，程序與程序間的記憶體和資料都是不共享的。兩個程序就好像大海中相互獨立的兩個島嶼，各自生活在互相平行的兩個世界中，互不干擾，各
【docker】效能優化-redis之【主從複製】全量複製和部分複製
概念： 全量複製：用於初次複製或其它無法進行部分複製的情況，將主節點中的所有資料都發送給從節點，是一個非常重型的操作，當資料量較大時，會對主從節點和網路造成很大的開銷 部分複製：用於處理在主從複製中因網路閃斷等原因造成的資料丟失場景，當從節點再次連上主節點後，如果條件允許，主節點會補發丟
【docker】效能優化-redis之【主從複製】，第一次準備
主從複製說明 面臨問題 在實際的場景當中單一節點的redis容易面臨風險。 比如： 1、機器故障。我們部署到一臺 Redis 伺服器，當發生機器故障時，需要遷移到另外一臺伺服器並且要保證資料是同步的。而資料是最重要的，如果你不在乎，基本上也就不會使用 Redis 了。
【效能優化】檢視tomcat 併發連線數
檢視tomcat併發連線數有兩個方式：方式1：通過tomcat自帶的管理控制檯檢視：啟動tomcat後，在瀏覽器輸入：http://11.8.130.129:8080/manager/statustomcat7以後需要賬號登入，配置賬號需要進入tomcat目錄下的conf路徑
【效能優化】如何實現：c/c++整個專案工程使用一個全域性變數
如果工程中存在malloc/free等頻繁動態分配和釋放記憶體的情況，一般優化思路是： 方法1：加記憶體池 方法2：使用全域性buf 方法1的優點：眾所周知，不詳細說了。 方法2使用場合：整個工程執行過程中，動態分配的記憶體大小有規律性且有最大個數。可以在工程起始
【效能優化】取模運算：x%n，當n是偶數時，可以用x&(n-1)替代
#include <assert.h> void modulo_operation_opt() { int m = 100000; int n = 100000; double a
【Android效能優化】儘可能用RelativeLayout來代替多層巢狀的LinearLayout
儘量用RelativeLayout來代替多層巢狀的LinearLayout 在Android UI開發中，有時會遇到較複雜的佈局設計，比如如下： --------------------------------------- 標題 作者
【效能優化】quicklink：實現原理與給前端的啟發
近來，GoogleChromeLabs 推出了 quicklink，用以實現連結資源的預載入（prefetch）。本文在介紹其實現思路的基礎上，會進一步探討在預載入方面前端工程師還可以做什麼。 1. quicklink 是什麼的？ quicklink 是一個通過預載入資源來提升後續方案速度的輕量級工具庫。
【高效能MySQL】第六章查詢效能優化 查詢優化器侷限
剛才誤關了瀏覽器，啊~~~ 6.5MySQL查詢優化器侷限性 6.5.1關聯子查詢 where子查詢實現的非常糟糕，最糟一類where包含in 優化： exists等效改寫： 或使用group_concat（）在in中構造由逗號分隔的列表：【源】
【three.js-效能優化】three.js效能優化
轉載：three.js效能優化 three.js是JavaScript編寫的WebGL第三方庫。提供了非常多的3D顯示功能。在使用的時候，雖然three.js 做了優化，但是在使用不恰當的程式碼，也會產生效能損耗。幀率越低，給人感覺就越卡。這是我在開發中自己百度總結的，有不對的
【T-SQL效能優化】01.TempDB的使用和效能問題
以前總是追求新東西，發現基礎才是最重要的，今年主要的目標是精通SQL查詢和SQL效能優化。 本系列【T-SQL基礎】主要是針對T-SQL基礎的總結。 一、TempDB是什麼? 1.TempDB是一個系統資料庫。從SQL Server2000開始就一直存在。 2.只有Simple恢復模式