Oracle課程設計B樹

1、學 號： 課 程 設 計題 目B*樹索引學 院計算機科學與信息工程學院專 業(yè)金融信息化服務外包班 級學生姓名指導教師2015年12月27日重慶工商大學課程設計成績評定表學院：計信學院 班級： 學生姓名： 學號：項目分值優(yōu)秀(100>x90)良好(90>x80)中等(80>x70)及格(70>x60)不及格(x<60)評分參考標準參考標準參考標準參考標準參考標準學習態(tài)度15學習態(tài)度認真，科學作風嚴謹，嚴格保證設計時間并按任務書中規(guī)定的進度開展各項工作學習態(tài)度比較認真，科學作風良好，能按期圓滿完成任務書規(guī)定的任務學習態(tài)度尚好，遵守組織紀律，基本保證設計時間，按期完成各

2、項工作學習態(tài)度尚可，能遵守組織紀律，能按期完成任務學習馬虎，紀律渙散，工作作風不嚴謹,不能保證設計時間和進度技術水平與實際能力25設計合理、理論分析與計算正確，實驗數(shù)據(jù)準確，有很強的實際動手能力、經濟分析能力和計算機應用能力，文獻查閱能力強、引用合理、調查調研非常合理、可信設計合理、理論分析與計算正確，實驗數(shù)據(jù)比較準確，有較強的實際動手能力、經濟分析能力和計算機應用能力，文獻引用、調查調研比較合理、可信設計合理，理論分析與計算基本正確，實驗數(shù)據(jù)比較準確，有一定的實際動手能力，主要文獻引用、調查調研比較可信設計基本合理，理論分析與計算無大錯，實驗數(shù)據(jù)無大錯設計不合理，理論分析與計算有原則錯誤，實

3、驗數(shù)據(jù)不可靠，實際動手能力差，文獻引用、調查調研有較大的問題創(chuàng)新10有重大改進或獨特見解，有一定實用價值有較大改進或新穎的見解，實用性尚可有一定改進或新的見解有一定見解觀念陳舊論文(計算書、圖紙)撰寫質量50結構嚴謹，邏輯性強，層次清晰，語言準確，文字流暢，完全符合規(guī)范化要求，書寫工整或用計算機打印成文；圖紙非常工整、清晰結構合理，符合邏輯，文章層次分明，語言準確，文字流暢，符合規(guī)范化要求，書寫工整或用計算機打印成文；圖紙工整、清晰結構合理，層次較為分明，文理通順，基本達到規(guī)范化要求，書寫比較工整；圖紙比較工整、清晰結構基本合理，邏輯基本清楚，文字尚通順，勉強達到規(guī)范化要求；圖紙比較工整內容空

4、泛，結構混亂，文字表達不清，錯別字較多，達不到規(guī)范化要求；圖紙不工整或不清晰指導教師評定成績：指導教師簽名： 年 月 日第 17 頁 共 17 頁課程設計任務書學生姓名： 專業(yè)班級： 指導教師： 工作單位： 題 目: B*樹索引已知技術參數(shù)和設計要求：a) 時間要求為14周18周。b) 開發(fā)工具不限（oracle/sqlplus）。c) 開發(fā)平臺不限（Linux）。d) 集成開發(fā)環(huán)境不限。e) 所用數(shù)據(jù)庫不限（Oracle 10g）。f) 說明文檔要求符合學校課程設計文檔規(guī)范。要求完成的主要任務: （包括課程設計工作量及其技術要求，以及說明書撰寫等具體要求）B*樹索引。(1) 什么是B*樹(2

5、) B*索引的組織結構(3) 索引鍵壓縮(作用及結構)(4) 反向鍵索引(作用及結構)(5) 降序索引(作用及結構)時間安排：1、研究分析什么是B*樹，和同學討論聯(lián)系實際，歷時2天。2、研究分析B*索引的組織結構，歷時2天。3、研究分析索引鍵壓縮，反向鍵索引，降序索引，歷時4天。4、編寫相關文檔，歷時2天。5、Oracle大型數(shù)據(jù)庫課程設計文檔的最后檢查與修訂，歷時1天指導教師簽名： 年 月 日目錄1.什么是B*樹52.B*索引的組織結構63.索引鍵壓縮(作用及結構)74.反向鍵索引(作用及結構)8（1）.反向索引應用場合9（2）.使用反向索引的優(yōu)點.9（3）.使用反向索引的缺點.9（4）.通

6、過一個實驗簡單演示一下反向索引的創(chuàng)建及修改145.降序索引（作用及結構）146.總結157.參考資料151.什么是B*樹B*樹是B+樹的變體，在B+樹的非根和非葉子結點再增加指向兄弟的指針；B*樹定義了非葉子結點關鍵字個數(shù)至少為(2/3)*M，即塊的最低使用率為2/3（代替B+樹的1/2）。B+樹的分裂：當一個結點滿時，分配一個新的結點，并將原結點中1/2的數(shù)據(jù)復制到新結點，最后在父結點中增加新結點的指針；B+樹的分裂只影響原結點和父結點，而不會影響兄弟結點，所以它不需要指向兄弟的指針。B*樹的分裂：當一個結點滿時，如果它的下一個兄弟結點未滿，那么將一部 分數(shù)據(jù)移到兄弟結點中，再在原結點插入關

7、鍵字，最后修改父結點中兄弟結點的關鍵字（因為兄弟結點的關鍵字范圍改變了）。如果兄弟也滿了，則在原結點與兄弟結點之間增加新結點，并各復制1/3的數(shù)據(jù)到新結點，最后在父結點增加新結點的指針，所以，B*樹分配新結點的概率比B+樹要低，空間使用率更高。 B*樹索引就是我們說的“傳統(tǒng)”索引，這是數(shù)據(jù)庫中最常用的一類索引結構。其實現(xiàn)與二叉查找樹類似，目標是減少oracle查找數(shù)據(jù)的時間。如果在一個數(shù)字列上有一個索引，那么理論上結構應該是這樣的（圖1）：圖1 具體B*結構示意圖  這個樹最底層是葉子節(jié)點，包含索引鍵以及一個rowid（指向索引行）。葉子節(jié)點上面的稱為分支塊，用于在結構中實

8、現(xiàn)導航。例如：想在索引中找到值42，從樹頂開始查找進入左分支，查找這個塊，發(fā)現(xiàn)需要找的數(shù)據(jù)在“42.50”的葉子節(jié)點中。另外，葉子節(jié)點之間是雙向鏈表結構。也就是查找區(qū)間數(shù)據(jù)很容易，比如這樣的條件：where x between 20 and 300。oracle只要剛開始找到大于或等于20的記錄所在的葉子節(jié)點，接著往下掃描，找到大于或者等于300的塊。這期間可能會跨葉子節(jié)點掃描，由于葉子節(jié)點之間是雙向鏈表，故很容易實現(xiàn)跨葉子節(jié)點掃描。  B*樹有一個特點：所有的葉子節(jié)點都在同一層，也就是無論你查找哪一條數(shù)據(jù)，需要執(zhí)行的I/O數(shù)據(jù)是一樣的。一般的B*樹都是2或者3層。無論這個表有多少行

9、數(shù)據(jù)，這樣查找一條數(shù)據(jù)只需要2,3個I/O操作。2.B*索引的組織結構 一般的B*樹結構如圖 2所示。圖 2 B*結構示意圖最底層的數(shù)據(jù)塊被稱為葉子結點，葉子結點中包含了索引鍵值和其所對應的 ROWID 。其它的數(shù)據(jù)塊被稱為分支塊,可用于定位相應的葉子結點。同時葉子結點之間也存在一個雙 向鏈表，當對某個索引進行范圍掃描時,可通過葉子結點之間的雙向鏈表來進行檢索而不用通過分支結點。每個索引最少有一個葉子結點，一個葉子結點中可包含多行索引數(shù)據(jù)。B*樹索引中所有的葉子結點都應在同一層中,此層的高度也即稱為這個索引的高度，因此可以說索引是高度平衡的。B*樹索引最大的層次為24層，一個索引中最

10、多只能包含32個字段列。每個鍵的長度根據(jù)不同版本的數(shù)據(jù)塊大小的不同而不同。分支塊結點存儲的是指向其下層結點的指針，每一個索引都有一個根結點，根結點所在的數(shù)據(jù)塊在索引段中緊隨段頭信息所在的數(shù)據(jù)塊。整個索引的層次被稱為索引的高度 ，可通過數(shù)據(jù)庫中視圖 index_ stat 中的字段 height 查出，分支結點的層次被稱為 blevel，可在數(shù)據(jù)字典 dba_indexes 中的字段 blevel 查出，需對索引進行分析才可計算出索引的高度和blevel 的值，即analyze index index _ name validate structure。索引的高度是由索引的分支結點的個數(shù)決定的，

11、而索引分支結點的個數(shù)又是由索引鍵值的長度和索引葉子結點的個數(shù)決定的。Oracle 數(shù)據(jù)庫中的最小邏輯單元是數(shù)據(jù)庫數(shù)據(jù)塊，其大小由數(shù)據(jù)庫初始化參數(shù) DB_BLOCK_SIZE 所決定。所有的索引數(shù)據(jù)和表數(shù)據(jù)都是以數(shù)據(jù)塊為單位存放的，同時每個索引數(shù)據(jù)塊會存放相應的頭信息。3.索引鍵壓縮(作用及結構)信息檢索系統(tǒng)中的兩個主要數(shù)據(jù)結構:詞典及倒排索引。下面將介紹對這兩個數(shù)據(jù)結構的各種壓縮技術,這些技術對于構建高效的 IR 系統(tǒng)非常關鍵。進行壓縮的一個優(yōu)點顯而易見:它能夠節(jié)省磁盤空間。要達到 14 的壓縮比是非常容易的,也就是說可以降低 75%的索引存儲開銷。索引壓縮還有兩個隱含的優(yōu)點。第一是能增加高速

12、緩存(caching)技術的利用率。在搜索系統(tǒng)中,詞典中某些條目及其索引往往比其他條目及其索引的使用更頻繁。例如：如果將一個頻繁使用的查詢詞項t的倒排記錄表放到高速緩存中,那么對僅由t構成的查詢進行應答所需要的計算完全可以在內存中完成。如果采用壓縮技術,那么高速緩存中就可以放更多的信息。當查詢詞項t的信息放在高速緩存時,處理查詢t便不再需要進行磁盤操作,而只需將其倒排記錄表在內存中解壓縮即可。因此,我們能充分減少IR系統(tǒng)的應答時間。由于內存比磁盤更貴,所以,相對于磁盤空間的減少,采用高速緩存技術帶來的速度提升是采用壓縮技術的更主要的原因。 第二個隱含的優(yōu)點是,壓縮能夠加快數(shù)據(jù)從磁盤到

13、內存的傳輸速度。高效的解壓縮算法在現(xiàn)代硬件上運行相當快,這樣將壓縮的數(shù)據(jù)塊傳輸?shù)絻却娌⒔鈮核枰目倳r間往往會比將未壓縮的數(shù)據(jù)塊傳輸?shù)絻却嬉?。舉例來說,即使會增加在內存進行解壓縮的開銷,我們也可以 通過加載一個小很多的壓縮倒排記錄表來減少 I/O 時間。因此,在大部分情況下,使用壓縮倒排記錄表的檢索系統(tǒng)會比沒用壓縮的系統(tǒng)的運行速度要快。 如果壓縮的主要目的是為了節(jié)省磁盤空間,那么壓縮算法的速度就不用特別考慮。但是, 如果要提高高速緩存利用率和磁盤到內存的傳輸率,則解壓縮的速度必須要快。 【將詞典看成單一字符串的壓縮方法】采用定長方法來存儲詞項存在著明顯的空間浪費。一種解決

14、上述缺陷的方法是,將所有的詞項存成一個長字符串，并給每個詞項增加一個定位指針,它在指向下一詞項的指針同時也標識著 當前詞項的結束。（就是目前構架中的var_data）實際上,按照詞典順序排序的連續(xù)詞項之間往往具有公共前綴。因此,可以采用一種稱為前端編碼(front coding)的技術。 公共前綴被識別出來之后,后續(xù)的詞項中便可以使用一個特殊的字符來表示這段前綴。假如一個表中，需要三列才能確認一行。那么我們在這個表示建立索引需要建立在這三列上。那么索引塊的結構有可能是這樣的：                

15、0; 圖3索引塊的結構   我們會發(fā)現(xiàn)，第一列和第二列有很多值是重復的。其實這個時候可以進行壓縮，對于重復的值，只保存一份。比如：Sql代碼 ： （1）<span style="font-size: x-small;">drop index t_idx;  （2）create index t_idx on  （3）t(owner,object_type,object_name)  （4）compress&

16、#160;&2;</span>    compress&2表示壓縮兩列，這樣能節(jié)省空間，但是會增加尋找的難度。也就是說，如果現(xiàn)在已經占用了大量的cpu時間，那么創(chuàng)建索引以壓縮 的方式，會使情況更糟糕。如果目前只是I/O操作比較多，那么壓縮索引能加快處理速度，因為壓縮之后的索引空間更少，那么塊緩沖區(qū)應該能存放更多的索引塊，塊的命中率會提高。4.反向鍵索引(作用及結構)我們知道Oracle會自動為表的主鍵列建立索引，這個默認的索引是普通的B-Tree索引。對于主鍵值是按順序(遞增或遞減)加入的情況，默認的B-Tree索引并不理想。

17、這是因為如果索引列的值具有嚴格順序時，隨著數(shù)據(jù)行的插入，索引樹的層級增長很快。搜索索引發(fā)生的I/O讀寫次數(shù)和索引樹的層級數(shù)成正比，也就是說，一棵具有5個層級的B -Tree索引，在最終讀取到索引數(shù)據(jù)時最多可能發(fā)生多達5次I/O操作。因而，減少索引的層級數(shù)是索引性能調整的一個重要方法。如果索引列的數(shù)據(jù)以嚴格的有序的方式插入，那么B-Tree索引樹將變成一棵不對稱的"歪樹"，如圖 4所示：圖4不對稱的“歪樹“而如果索引列的數(shù)據(jù)以隨機值的方式插入，我們將得到一棵趨向對稱的索引樹，如圖 5所示：圖5對稱的索引樹比較圖4和圖5，在圖4中搜索到A塊需要進行5次I/O操作，而圖 5僅需要

18、3次I/O操作。 既然索引列數(shù)據(jù)從序列中獲取，其有序性無法規(guī)避，但在建立索引時，Oracle允許對索引列的值進行反向，即預先對列值進行比特位的反向，如 1000,10001,10011,10111,1100經過反向后的值將是0001,1001,1101,0011。顯然經過位反向處理的有序數(shù)據(jù)變得比較隨機了，這樣所得到的索引樹就比較對稱，從而提高表的查詢性能。 但反向鍵索引也有它局限性：如果在WHERE語句中，需要對索引列的值進行范圍性的搜索，如BETWEEN、<、>等，其反向鍵索引無法使用，此時，Oracle將執(zhí)行全表掃描；只有對反向鍵索引列進行 <>和 = 的比較操作

19、時，其反向鍵索引才會得到使用。（1）.反向索引應用場合1）發(fā)現(xiàn)索引葉塊成為熱點塊時使用 通常，使用數(shù)據(jù)時（常見于批量插入操作）都比較集中在一個連續(xù)的數(shù)據(jù)范圍內，那么在使用正常的索引時就很容易發(fā)生索引葉子塊過熱的現(xiàn)象，嚴重時將會導致系統(tǒng)性能下降。2）在RAC環(huán)境中使用 當RAC環(huán)境中幾個節(jié)點訪問數(shù)據(jù)的特點是集中和密集，索引熱點塊發(fā)生的幾率就會很高。如果系統(tǒng)對范圍檢索要求不是很高的情況下可以考慮使用反向索引技術來提高系統(tǒng)的性能。因此該技術多見于RAC環(huán)境，它可以顯著的降低索引塊的爭用。（2）.使用反向索引的優(yōu)點 最大的優(yōu)點莫過于降低索引葉子塊的爭用，減少熱點塊，提高系統(tǒng)性能。（3）.使用反向索引的

20、缺點 由于反向索引結構自身的特點，如果系統(tǒng)中經常使用范圍掃描進行讀取數(shù)據(jù)的話（例如在where子句中使用“between and”語句或比較運算符“>”“<”等），那么反向索引將不適用，因為此時會出現(xiàn)大量的全表掃描的現(xiàn)象，反而會降低系統(tǒng)的性能。有時候可以通過改寫sql語句來避免使用范圍掃描，例如where id between 12345 and 12347，可以改寫為where id in(12345,12346,12347)，CBO會把這樣的sql查詢轉換為where id=12345 or id=12346 or id=12347,這對反向索引也是有效的。（4）.通過一個小實

21、驗簡單演示一下反向索引的創(chuàng)建及修改1. SQL> select count(*) from t1; 2.   COUNT(*)  3. -  4.          0  5. SQL> select count(*) from t2;  6.   COUNT(*)  

22、;7. -  8.          0  9. SQL> select count(*) from t3;  10.   COUNT(*)  11. -  12.    2000000  13. SQL> select INDEX_NAME,INDEX_TYPE,T

23、ABLE_NAME from user_indexes;  14. INDEX_NAME                     INDEX_TYPE                

24、0; TABLE_NAME  15. - - -  16. PK_T2                          NORMAL/REV          

25、0;       T2  17. PK_T1                          NORMAL            

26、;          T1  表t1是主鍵是正常的主鍵，表t2的主鍵是反向主鍵?，F(xiàn)在我把表t3的數(shù)據(jù)分別插入到表t1和表t21. SQL> set timing on;  2. SQL> set autotrace on;  3. SQL> insert /* +append */ into t1&#

27、160;select * from t3;  4. 已創(chuàng)建2000000行。  5. 已用時間:  00: 01: 42.83  6. 執(zhí)行計劃  7. -  8. Plan hash value: 4161002650  9. -  10. | Id  | Operation   

28、60;            | Name | Rows  | Bytes | Cost (%CPU)| Time     |  11. -  12. |   0 | INSERT STATEMENT  

29、60;      |      |  2316K|   485M| 19014   (1)| 00:03:49 |  13. |   1 |  LOAD TABLE CONVENTIONAL | T1   | 

30、      |       |            |          |  14. |   2 |   TABLE ACCESS FU

31、LL      | T3   |  2316K|   485M| 19014   (1)| 00:03:49 |  15. -  16. Note  17. -  18.    - dynamic sampling used for

32、0;this statement (level=2)  19. 統(tǒng)計信息  20. -  21.       12305  recursive calls  22.      538835  db block gets  23.      20393

33、7  consistent gets  24.       83057  physical reads  25.   428323528  redo size  26.         688  bytes sent via SQL*Net

34、 to client  27.         614  bytes received via SQL*Net from client  28.           3  SQL*Net roundtrips to/from client&

35、#160; 29.           2  sorts (memory)  30.           0  sorts (disk)  31.     2000000  rows processed 

36、60;32. SQL> commit;  33. 提交完成。  34. 已用時間:  00: 00: 00.04  35. SQL> insert /* +append */ into t2 select * from t3;  36. 已創(chuàng)建2000000行。  37. 已用時間:  00: 02:

37、60;02.63  38. 執(zhí)行計劃  39. -  40. Plan hash value: 4161002650  41. -  42. | Id  | Operation                | Name | Rows

38、60; | Bytes | Cost (%CPU)| Time     |  43. -  44. |   0 | INSERT STATEMENT         |      |  2316K|  

39、; 485M| 19014   (1)| 00:03:49 |  45. |   1 |  LOAD TABLE CONVENTIONAL | T2   |       |       |    &#

40、160;       |          |  46. |   2 |   TABLE ACCESS FULL      | T3   |  2316K|   485M

41、| 19014   (1)| 00:03:49 |  47. -   48. Note  49. -  50.    - dynamic sampling used for this statement (level=2)  51. 統(tǒng)計信息  52. -  53.   

42、;     7936  recursive calls  54.     6059147  db block gets  55.      158053  consistent gets  56.       56613 

43、0;physical reads  57.   790167468  redo size  58.         689  bytes sent via SQL*Net to client  59.         614  b

44、ytes received via SQL*Net from client  60.           3  SQL*Net roundtrips to/from client  61.           2  sorts (

45、memory)  62.           0  sorts (disk)  63.     2000000  rows processed  64. SQL> commit;  65. 提交完成。  66. 已用時間:  00: 00: 0

46、0.01  可以看見：由于反向索引的數(shù)據(jù)塊比較分散了后，db block gets要稍微高一些。熱塊的爭用有所緩解，consistent gets有所下降，從203937下降到158053，減少了45884次。redo size 也變多了！再來做查詢，來看看他們的區(qū)別。1. SQL> set autotrace traceonly;  2. SQL> select OBJECT_NAME from t1 where id = 100;

47、  3. 已用時間:  00: 00: 00.06  4. 執(zhí)行計劃  5. -  6. Plan hash value: 1141790563  7. -  8. | Id  | Operation              &

48、#160;    | Name  | Rows  | Bytes | Cost (%CPU)| Time     |  9. -  10. |   0 | SELECT STATEMENT         &#

49、160;  |       |     1 |    79 |     0   (0)| 00:00:01 |  11. |   1 |  TABLE ACCESS BY INDEX

50、0;ROWID| T1    |     1 |    79 |     0   (0)| 00:00:01 |  12. |*  2 |   INDEX UNIQUE SCAN     &

51、#160;   | PK_T1 |     1 |       |     0   (0)| 00:00:01 |  13. -  14. Predicate Information (identified by operation

52、0;id):  15. -  16.    2 - access("ID"=100)  17. 統(tǒng)計信息  18. -  19.           0  recursive calls  20.        

53、;   0  db block gets  21.           4  consistent gets  22.           3  physical reads  23.   

54、        0  redo size  24.         434  bytes sent via SQL*Net to client  25.         416  bytes 

55、;received via SQL*Net from client  26.           2  SQL*Net roundtrips to/from client  27.           0  sorts (memory)&#

56、160; 28.           0  sorts (disk)  29.           1  rows processed  30. SQL> select OBJECT_NAME from t1 where i

57、d > 100 and id < 200;  31. 已選擇99行。  32. 已用時間:  00: 00: 01.10  33. 執(zhí)行計劃  34. -  35. Plan hash value: 1249713949  36. -  37. | Id  | Operatio

58、n                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |  38. -  39. |   0

59、60;| SELECT STATEMENT            |       |    99 |  7821 |     1   (0)| 00:00:01 |  40. | 

60、  1 |  TABLE ACCESS BY INDEX ROWID| T1    |    99 |  7821 |     1   (0)| 00:00:01 |  41. |*  2 |   I

61、NDEX RANGE SCAN          | PK_T1 |    99 |       |     1   (0)| 00:00:01 |  42. -  43. Predicate

62、0;Information (identified by operation id):  44. -  45.    2 - access("ID">100 AND "ID"<200)  46. Note  47. -  48.    - dynamic sampling us

63、ed for this statement (level=2)  49. 統(tǒng)計信息  50. -  51.           9  recursive calls  52.           0  db block&

64、#160;gets  53.         140  consistent gets  54.         189  physical reads  55.        2356  redo size 

65、 56.        2656  bytes sent via SQL*Net to client  57.         482  bytes received via SQL*Net from client  58.    

66、;       8  SQL*Net roundtrips to/from client  59.           0  sorts (memory)  60.           0  

67、;sorts (disk)  61.          99  rows processed  62.   63. SQL> select OBJECT_NAME from t2 where id = 100;  64. 已用時間:  00: 00: 00.05&

68、#160; 65. 執(zhí)行計劃  66. -  67. Plan hash value: 1480579010  68. -  69. | Id  | Operation                   | Name  

69、;| Rows  | Bytes | Cost (%CPU)| Time     |  70. -  71. |   0 | SELECT STATEMENT            |     

70、60; |     1 |    79 |     0   (0)| 00:00:01 |  72. |   1 |  TABLE ACCESS BY INDEX ROWID| T2    | 

71、60;   1 |    79 |     0   (0)| 00:00:01 |  73. |*  2 |   INDEX UNIQUE SCAN         | PK_T2 | &#

72、160;   1 |       |     0   (0)| 00:00:01 |  74. -  75. Predicate Information (identified by operation id):  76. -  77.   

73、; 2 - access("ID"=100)  78. 統(tǒng)計信息  79. -  80.           1  recursive calls  81.           0  db block 

74、;gets  82.           4  consistent gets  83.           1  physical reads  84.           0&

75、#160; redo size  85.         434  bytes sent via SQL*Net to client  86.         416  bytes received via SQL*Net from cli

76、ent  87.           2  SQL*Net roundtrips to/from client  88.           0  sorts (memory)  89.       

77、    0  sorts (disk)  90.           1  rows processed  91. SQL> select OBJECT_NAME from t2 where id > 100 and id <

78、60;200;  92. 已選擇99行。  93. 已用時間:  00: 00: 04.39  94. 執(zhí)行計劃  95. -  96. Plan hash value: 1513984157  97. -  98. | Id  | Operation        &

79、#160;| Name | Rows  | Bytes | Cost (%CPU)| Time     |  99. -  100. |   0 | SELECT STATEMENT  |      |   336 | 

80、26544 |  8282   (1)| 00:01:40 |  101. |*  1 |  TABLE ACCESS FULL| T2   |   336 | 26544 |  8282   (1)| 00:01:40 |  102. -

81、  103. Predicate Information (identified by operation id):  104. -  105.    1 - filter("ID">100 AND "ID"<200)  106. Note  107. -  108.    -

82、 dynamic sampling used for this statement (level=2)  109. 統(tǒng)計信息  110. -  111.          29  recursive calls  112.          

83、; 1  db block gets  113.       60187  consistent gets  114.       30335  physical reads  115.        5144  redo size  116.        2656  bytes sent via SQL*Net to client