[20190215]sqlplus set arraysize.txt
[20190215]sqlplus set arraysize.txt
--//看連結,我感覺有點奇怪的地方,我一直認為全表掃描,如果arraysize很大的情況下,邏輯讀不會出現很大變化.
--//而對方設定arraysize=1000,5000,還是存在很大差異,不知道我以前的理解那裡存在問題.先重複作者的測試看看.
1.環境:
SCOTT@book> @ ver1
PORT_STRING VERSION BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
2.測試:
SCOTT@book> set timing on
SCOTT@book> set autot traceonly
SCOTT@book> set arraysize 1000
SCOTT@book> select * from sh.sales;
918843 rows selected.
Elapsed: 00:00:06.03
Execution Plan
----------------------------------------------------------
Plan hash value: 1550251865
---------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
---------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 918K| 25M| 525 (2)| 00:00:07 | | |
| 1 | PARTITION RANGE ALL| | 918K| 25M| 525 (2)| 00:00:07 | 1 | 28 |
| 2 | TABLE ACCESS FULL | SALES | 918K| 25M| 525 (2)| 00:00:07 | 1 | 28 |
---------------------------------------------------------------------------------------------
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
2550 consistent gets
1619 physical reads
0 redo size
25877676 bytes sent via SQL*Net to client
10617 bytes received via SQL*Net from client
920 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
918843 rows processed
SCOTT@book> set arraysize 5000
SCOTT@book> select * from sh.sales;
918843 rows selected.
Elapsed: 00:00:05.31
Execution Plan
----------------------------------------------------------
Plan hash value: 1550251865
---------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
---------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 918K| 25M| 525 (2)| 00:00:07 | | |
| 1 | PARTITION RANGE ALL| | 918K| 25M| 525 (2)| 00:00:07 | 1 | 28 |
| 2 | TABLE ACCESS FULL | SALES | 918K| 25M| 525 (2)| 00:00:07 | 1 | 28 |
---------------------------------------------------------------------------------------------
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
1818 consistent gets
1619 physical reads
0 redo size
25743171 bytes sent via SQL*Net to client
2532 bytes received via SQL*Net from client
185 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
918843 rows processed
--//也畫一個表格:
array size elapsed consistent gets SQL*Net trips
1000 06.03 2550 920
5000 05.31 1818 185
--//存在少量差異,但是有點出乎意料,consistent gets還是存在一些不同.實際上ayyaysize越大越接近如下語句的邏輯讀.
--//執行select /*+ full(a) */ count(*) from sh.sales a;邏輯讀.
SCOTT@book> select /*+ full(a) */ count(*) from sh.sales a;
Elapsed: 00:00:00.03
Execution Plan
----------------------------------------------------------
Plan hash value: 3519235612
--------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time | Pstart| Pstop |
--------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 522 (1)| 00:00:07 | | |
| 1 | SORT AGGREGATE | | 1 | | | | |
| 2 | PARTITION RANGE ALL| | 918K| 522 (1)| 00:00:07 | 1 | 28 |
| 3 | TABLE ACCESS FULL | SALES | 918K| 522 (1)| 00:00:07 | 1 | 28 |
--------------------------------------------------------------------------------------
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
1635 consistent gets
1619 physical reads
0 redo size
528 bytes sent via SQL*Net to client
519 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
--//實際上可以這樣簡單估算兩者的差別.
918843/1000 = 918.84300000000000000000
918843/5000 = 183.76860000000000000000
918-183 = 735
--//也就是arraysize= 1000,邏輯讀比arraysize=5000多735次.驗證看看是否正確.
--//2550 - 1818 = 732,非常接近.
--//我個人的觀點設定很大沒有任何意義,畢竟oltp系統很少大量讀取資料.設定200-400之間就足夠,我的測試環境都設定200.
--//實際上對方選擇的表sh.sales非常特殊,平均記錄行長很短僅僅29位元組.而記錄相對很多達到918843條.這樣平均1塊有250條記錄.
SCOTT@book> @ tab_stat sh sales
TABLE:SALES
TABLE PARTITION/SH/SALES
CARD:918843 BLKS:1907 AVGLEN:29 SAMPLE:918843 ANALYZED:2013/08/24 12:09:49
----------------------------------------------------------------------------------------------------------------------
COL:PROD_ID TYP:NUMBER VALS: 72 DENS: 0 NULLS: 0 HIST: 72
COL:CUST_ID TYP:NUMBER VALS: 7,059 DENS: .0001 NULLS: 0 HIST: 1
COL:TIME_ID TYP:DATE VALS: 1,460 DENS: .0007 NULLS: 0 HIST: 1
COL:CHANNEL_ID TYP:NUMBER VALS: 4 DENS: .25 NULLS: 0 HIST: 1
COL:PROMO_ID TYP:NUMBER VALS: 4 DENS: .25 NULLS: 0 HIST: 1
COL:QUANTITY_SOLD TYP:NUMBER VALS: 1 DENS: 1 NULLS: 0 HIST: 1
COL:AMOUNT_SOLD TYP:NUMBER VALS: 3,586 DENS: .0003 NULLS: 0 HIST: 1
-----------------------------------------------------------------------------------------------------------------------
INAME:SALES_TIME_BIX ITYP:BITMAP LBLKS: 57 KEYS: 1,460 CLUSTR:1460
..ROWS: 1,460 ANALYZED:2013/08/24 12:09:53
....POS: 1 COL:TIME_ID
-----------------------------------------------------------------------------------------------------------------------
INAME:SALES_PROMO_BIX ITYP:BITMAP LBLKS: 30 KEYS: 4 CLUSTR:54
..ROWS: 54 ANALYZED:2013/08/24 12:09:54
....POS: 1 COL:PROMO_ID
-----------------------------------------------------------------------------------------------------------------------
INAME:SALES_CHANNEL_BIX ITYP:BITMAP LBLKS: 47 KEYS: 4 CLUSTR:92
..ROWS: 92 ANALYZED:2013/08/24 12:09:54
....POS: 1 COL:CHANNEL_ID
-----------------------------------------------------------------------------------------------------------------------
INAME:SALES_CUST_BIX ITYP:BITMAP LBLKS: 452 KEYS: 7,059 CLUSTR:35808
..ROWS: 35,808 ANALYZED:2013/08/24 12:09:52
....POS: 1 COL:CUST_ID
-----------------------------------------------------------------------------------------------------------------------
INAME:SALES_PROD_BIX ITYP:BITMAP LBLKS: 32 KEYS: 72 CLUSTR:1074
..ROWS: 1,074 ANALYZED:2013/08/24 12:09:50
....POS: 1 COL:PROD_ID
Done.
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.38
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/267265/viewspace-2636120/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- [20221203]sqlplus set trimspool 問題.txtSQL
- [20221202]sqlplus set trimout 問題.txtSQL
- [20181122]18c sqlplus set linesize.txtSQL
- 每週分享第 13 期(20190215)
- [20190215]那個更快(10g).txt
- 【SQLPLUS】sqlplus 客戶端所需的檔案列表SQL客戶端
- [20230323]sqlplus #.txtSQL
- windows sqlplus亂碼WindowsSQL
- sqlplus啟動失敗SQL
- oracle系列(一)sqlplus命令OracleSQL
- set /?
- Set
- lombok get/set 與 JavaBean get/setLombokJavaBean
- [20190524]sqlplus 與輸出&.txtSQL
- [20190530]sqlplus preliminary connection.txtSQL
- sqlplus和sqlldr工具安裝SQL
- oracle sqlplus 常用命令OracleSQL
- [20211125]sqlplus生成html格式.txtSQLHTML
- [20211108]sqlplus管道過濾.txtSQL
- [Javascript] Perform Set Operations using JavaScript Set MethodsJavaScriptORM
- Jet Set
- set -o
- set -e
- oracle sqlplus 回退鍵以及上下鍵OracleSQL
- [20211123]sqlplus @與@@的區別.txtSQL
- [20230417]sqlplus warpped word_warp.txtSQL
- Vue.set與vue.$set的使用Vue
- 訓練集(train set),驗證集(validation set)和測試集(test set)AI
- alter system set event和set events的區別
- 10g sqlplus的一個bugSQL
- [20180510]sqlplus array 和 opifch2.txtSQL
- sqlplus 中文?好和awr中文問號SQL
- sqlplus常用的幾種登入方式SQL
- [20191104]sqlplus 管道檔案 過濾.txtSQL
- sqlplus執行sql檔案報錯SQL
- [20190720]sqlplus 與輸出& 2.txtSQL
- [20211220]sqlplus簡單計算器.txtSQL
- sqlplus as sysdb登入報ora-01017SQL