分析HWM，swot分析

分析HWM，swot分析
下面結合官方文檔和實驗介紹下HWM:
以下英文摘自11gR2官方文檔:
HWM(high water mark)：The boundary between used and unused space in a segment.
ORACLE9i之後開始使用自動段空間管理即ASSM,它使用位元影像來管理段空間的使用方式，如果資料表空間ASSM,則資料表空間中的段也是ASSM.

 At table creation, the HWM is at the beginning of the segment on the left. Because no data has been inserted yet, all blocks in the segment are unformatted and never used.
當表建立時，HWM開始於段的最左邊。因為從來沒有資料插入，所有在段裡的塊沒有被格式化和使用。

Suppose that a transaction inserts rows into the segment. The database must allocate a group of blocks to hold the rows. The allocated blocks fall below the HWM. The database formats a bitmap block in this group to hold the metadata, but does not preformat the remaining blocks in the group.In Figure 12–24, the blocks below the HWM are allocated, whereas blocks above the HWM are neither allocated or formatted. As inserts occur, the database can write to any block with available space. The low high water mark (low HWM) marks the point below which all blocks are known to be formatted because they either contain data or formerly contained data.
假設一個事務將行插入到段。資料庫必須分配一個組塊的行。低於HWM分配的塊。這組資料庫格式的位元影像塊的中繼資料,但不預先格式剩下的組塊。在圖12 - 24中,下面的塊HWM分配,而塊上面HWM既不分配或格式化。插入時,資料庫可以寫任何塊可用空間。高水標低(低HWM)標誌著點下面這所有的塊都被格式化的,因為他們要麼包含資料或以前包含資料。

In Figure 12–25, the database chooses a block between the HWM and low HWM and writes to it. The database could have just as easily chosen any other block between the HWM and low HWM, or any block below the low HWM that had available space. In Figure 12–25, the blocks to either side of the newly filled block are unformatted.
在圖12-25,資料庫選擇HWM和低HWM和之間的一塊寫道。資料庫也可以輕易選擇其他塊之間HWM和低HWM,或任何塊低於低HWM可用空間。在圖12-25,塊的新填充塊無格式。



The low HWM is important in a full table scan. Because blocks below the HWM arformatted only when used, some blocks could be unformatted, as in Figure 12–25. Fthis reason, the database reads the bitmap block to obtain the location of the low HWM. The database reads all blocks up to the low HWM because they are known tbe formatted, and then carefully reads only the formatted blocks between the low HWM and the HWM.Assume that a new transaction inserts rows into the table, but the bitmap indicates that insufficient free space exists under the HWM. In Figure 12–26, the database advances the HWM to the right, allocating a new group of unformatted blocks.
HWM低是重要的在一個全表掃描。因為塊低於HWM基於“增大化現實”技術格式化只使用時,一些街區可以無格式,12-25所示。F因此,資料庫讀取位元影像塊獲得低的位置HWM。資料庫讀取所有塊的低HWM因為它們是已知的被格式化,然後仔細閱讀只有格式化塊之間的低HWM HWM。假設一個新的事務將行插入到表中,但位元影像顯示HWM空閑空間不足存在。圖12-26資料庫右邊的HWM進步,分配一個新組的非格式化塊。


When the blocks between the HWM and low HWM are full, the HWM advances to the right and the low HWM advances to the location of the old HWM. As the database inserts data over time, the HWM continues to advance to the right, with the low HWM always trailing behind it. Unless you manually rebuild, truncate, or shrink the object, the HWM never retreats.
當HWM之間的塊和低HWM充滿,HWM進步的正確的和低老HWM HWM進步的位置。作為資料庫插入資料隨著時間的推移,右邊的HWM不斷進步,HWM偏低總是落後。除非你手動重建、截斷或縮小對象,HWM從不撤退。

以上通過官方文檔理論的分析了HWM,下面我們通過實驗來分析：

[oracle@localhost ~]$ cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 5.5 (Tikanga)

SQL> select * from v$version where rownum=1;


BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production


SQL> show user;
USER 為 "HR"
SQL> desc t;
 名稱                                    是否為空白? 類型
 ----------------------------------------- -------- ----------------------------
 ID                                                 NUMBER(38)
 NAME                                               VARCHAR2(10)


SQL> select count(*) from t;


  COUNT(*)
----------
    327680

t是使用者hr裡的一張比較大的表。
我們在列id上建索引index_t:(下面有用）
SQL> create index index_t on t(id);


索引已建立。

分析一下表：
SQL> exec dbms_stats.gather_table_stats('HR','T');  oracle提供了這個分析包

PL/SQL 過程已成功完成。
當然你也可以使用之前版本提供的工具：
SQL>  analyze table t1 compute statistics;

表已分析。
刪除分析：SQL> analyze table t1 delete statistics;

表已分析。



Total Blocks 表示分配給表的總的blocks 數。Unused Blocks 表示位於高水位線以上的從未使用的資料區塊個數。
上面的參數不一一介紹，感興趣的可以研究。

通過執行計畫分析：
SQL> set autotrace traceonly;
SQL> select * from t;（執行了兩次，此為第二次結果）


已選擇327680行。

執行計畫
----------------------------------------------------------
Plan hash value: 1601196873


--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   327K|  2240K|   172   (2)| 00:00:03 |
|   1 |  TABLE ACCESS FULL| T    |   327K|  2240K|   172   (2)| 00:00:03 |
--------------------------------------------------------------------------

統計資訊
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      22418  consistent gets
          0  physical reads
          0  redo size
    6379306  bytes sent via SQL*Net to client
     240710  bytes received via SQL*Net from client
      21847  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     327680  rows processed
執行計畫
----------------------------------------------------------
Plan hash value: 1601196873

從上面可以看出，邏輯讀了22418次。

我們此時delete表t，但是不會降低HWM:



表t雖然被delete的那部分被刪除，但是被佔用的那部分內空間存仍然沒被釋放,可以通過alter table t move來釋放儲存空間：
alter table move 主要有兩方面的作用：1、用來移動table 到其他資料表空間。2、用來減少table 中的儲存片段，最佳化儲存空間和效能。
SQL> alter table t move （tablespace users） online;（此時別的會話可以正常訪問此表）
表已更改。
此時rows的rowid也會改變。
SQL> select * from t;   （執行了兩次，此為第二次結果）


已選擇131072行。




執行計畫
----------------------------------------------------------
Plan hash value: 1601196873


--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   327K|  2240K|   172   (2)| 00:00:03 |
|   1 |  TABLE ACCESS FULL| T    |   327K|  2240K|   172   (2)| 00:00:03 |
--------------------------------------------------------------------------




統計資訊
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       9274  consistent gets
          0  physical reads
          0  redo size
    4020151  bytes sent via SQL*Net to client
      96533  bytes received via SQL*Net from client
       8740  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     131072  rows processed
此時的邏輯讀已經降低為9274。
但是此時造成建立在id上的索引不可用：

此時我們可以通過重建索引來解決：
 alter index index_t rebuild (tablespace users)  online;(此時如果不加online，則不能進行delete，update，insert操作，對於大表來說，很慢）
SQL> alter index index_t rebuild online; 


索引已更改。
索引重新可以使用：