oracle cache快取

1.使用caching table 的原因
        在通常的情況下，應用程式訪問在cache中的資料塊將按照LRU演算法來進行處理。然而對於小表的訪問，當使用全表掃描時，則該表
    中的塊會放置LRU列表最近最少使用尾部的(LRU端)，因此很快就被淘汰出局。然而使用基於成本最佳化的方法，對於小表進行查詢以及收
    集統計資訊，大多情形下走的是全表掃描，因此勢必造成一種情形，即該表後續需要再次訪問，而每次使用了全表掃描，而該物件很快
    被淘汰出局，因此需要再次讀入到buffer cache，耗用了大量的I/O。            
2.解決該問題的方法
    設計表為caching table ，即使對該表使用全表訪問時，則該表物件的塊仍然被放置在LRU列表最近最多使用的尾部(MRU段)
    不要過度的使用caching table，以免造成效能下降
    通常將caching table 存放在keep buffer pool，預設的情況下會放置在default buffer pool。
3.具有cache屬性與pin 的差異
    對於具有cache屬性的物件，並不是將該物件pin到cache裡，而是儘可能的延遲該物件駐留cache的時間
    而對於pin物件，則是將該物件常駐到記憶體
4.設計cache table 的方法
    建立表物件時，使用cache子句
    修改表物件時，使用cache子句
    使用cache 提示
    建立表物件時使用cache，如下面的例子
        create table tb_test
        (id number
         ,name varchar2(20)
         ,sex  char(1)
         ,age  number
         ,score number)
         tablespace users
         storage(initial 50k next 50k pctincrease 0)
         cache;    --指定cache子句
 
     使用alter table 修改已經存在的表
        alter table scott.emp cache;
     可以使用nocache來修改物件，使其不具備cache屬性
        alter table soctt.emp nocache
     使用hint提示符來實現cache
        select /*+ cache*/ empno,ename from scott.emp;

5.使用例子演示caching table情形
 
    scott@ORCL> create table tb1 nologging
       as select level id,rpad('*',4000,'*') data,rpad('*',2000,'*') data2
      from dual
      connect by level <= 15000;
    Table created.  

    scott@ORCL> create table tb2
cache nologging
as select level id,rpad('*',4000,'*') data,rpad('*',2000,'*') data2
from dual 
 connect by level <= 15000;
Table created.
scott@ORCL> select count(1) from tb1;
COUNT(1)
 ----------
 15000
 scott@ORCL> select count(1) from tb2;
COUNT(1)
----------
 15000
    scott@ORCL> select table_name,num_rows,cache from user_tables where table_name in ('TB1','TB2');
    TABLE_NAME        NUM_ROWS CACHE
    --------------- ---------- -----
    TB1                  15000     N
    TB2                  15000     Y
    scott@ORCL> set autotrace traceonly statistics;
    scott@ORCL> select count(1) from tb1;
    Statistics
    ----------------------------------------------------------
              5  recursive calls
              0  db block gets
          15086  consistent gets
          15000  physical reads
              0  redo size
            412  bytes sent via SQL*Net to client
            385  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              1  rows processed             
    scott@ORCL> select count(1) from tb1;
    Statistics
    ---------------------------------------------------------
              0  recursive calls
              0  db block gets
          15011  consistent gets
          15000  physical reads
              0  redo size
            412  bytes sent via SQL*Net to client
            385  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              1  rows processed     
    scott@ORCL> select count(1) from tb2;
    Statistics
    ----------------------------------------------------------
              0  recursive calls
              0  db block gets
          15011  consistent gets
            197  physical reads
              0  redo size
            412  bytes sent via SQL*Net to client
            385  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              1  rows processed

    scott@ORCL> select count(1) from tb2;
    Statistics
    ----------------------------------------------------------
              0  recursive calls
              0  db block gets
          15011  consistent gets
              0  physical reads
              0  redo size
            412  bytes sent via SQL*Net to clien
            385  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              1  rows processed       
        從上面的示例中可以看出，表tb1每次都將使用相同的物理讀，而表tb2一旦被load進buffer cache中，始終處於LRU的MRU端，儘可能的
    避免因buffer cache過小而被置換到buffer cache之外。
        注意不同的演示環境可能有所差異，本人的演示環境如下;
            scott@ORCL> show parameter sga_
            NAME                                 TYPE        VALUE
            ------------------------------------ ----------- ------------------------------
            sga_max_size                         big integer 264M
            sga_target                           big integer 264M
            scott@ORCL> select * from v$version;
            BANNER
            ----------------------------------------------------------------
            Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
            PL/SQL Release 10.2.0.1.0 - Production
            CORE    10.2.0.1.0      Production
            TNS for Linux: Version 10.2.0.1.0 - Production
            NLSRTL Version 10.2.0.1.0 - Production     
6.注意cache table與keep buffer pool的異同
    兩者的目的都是儘可能將最熱的物件置於到buffer pool，儘可能的避免aged out。
    cache table是將物件置於到default buffer cache。
    而使用buffer_pool keep子句是將物件置於到keep buffer pool。
    當buffer_pool和cache同時指定時，keep比cache有優先權。buffer_pool用來指定存貯使用緩衝池，而cache/nocache指定儲存的
    方式(LRU或MRU端)。建表時候不註明的話，nocache是預設值。

例句：alter table A storage(buffer_pool keep)
      alter table A cache