1. 程式人生 > >高水位線和全表掃描

高水位線和全表掃描

   高水位線好比水庫中儲水的水位線,用於描述資料庫中段的擴充套件方式。高水位線對全表掃描方式有著至關重要的影響。當使用delete 操作
表記錄時,高水位線並不會下降,隨之導致的是全表掃描的實際開銷並沒有任何減少。本文給出高水位線的描述,如何降低高水位線,以及高水
位線對全表掃描的影響。

一、何謂高水位線
    如前所述,類似於水庫中儲水的水位線。只不過在資料庫中用於描述段的擴充套件方式。
    可以將資料段或索引段等想象為一個從左到右依次排開的一系列塊。當這些塊中未填充任何資料時,高水位線位於塊的最左端(底端)
    隨著記錄的不斷增加,新塊不斷地被填充並使用,高水位線隨之向右移動。高水位線之上為未格式化的資料塊。
    刪除(delete)操作之後,高水位線之下的塊處於空閒狀態,但高水位線並不隨之下降,直到重建,截斷或收縮表段。
    全表掃描會掃描高水位線之下的所有塊,包括空閒資料塊(執行了delete操作)。
    
    低高水位線
      是在使用ASSM時的一個概念。即使用ASSM時除了高水位線之外,還包括一個低高水位線。低高水位線一定是位於高水位線之下。
      當段使用MSSM管理方式時只有一種情況即只存在一個高水位線。
      使用MMSM時,當HWM升高時,Oracle立即格式化所有塊且有效,並可以安全讀取。僅當第一次使用時完成格式化,便於安全讀取資料。
      使用ASSM時,當HWM升高時,Oracle並不會立即格式化所有塊。僅當第一次使用時完成格式化,便於安全讀取資料。
      使用低高水位線可以減少當全面掃描表段時,低高水位線與高水位線之間不安全塊的檢查數量。即低高水位線之下的塊不再檢查。
   
二、演示高水位線與全表掃描

SQL> create table t    -->建立測試表
  2  as
  3  select rownum as id,
  4  round(dbms_random.normal*1000) AS val1,
  5  dbms_random.string('p',250) AS pad
  6  from dual
  7  connect by level <=10000;

Table created.

SQL> exec dbms_stats.gather_table_stats('SCOTT','T',cascade=>true);  -->收集統計資訊

SQL> @Tab_Stat                        -->從dba_tab_statistics中獲得表物件的統計資訊,此時無empty_blocks的資訊
Enter value for input_table_name: t
Enter value for input_owner: scott

  NUM_ROWS       BLKS    EM_BLKS  AVG_SPACE  CHAIN_CNT AVG_ROW_LEN AVG_ROWS_PER_BLOCK LST_ANLY  STA
---------- ---------- ---------- ---------- ---------- ----------- ------------------ --------- ---
     10000        387          0          0          0         259                 26 03-NOV-11 NO

/**************************************************/
/* Author: Robinson Cheng                         */ 
/* Blog:   http://blog.csdn.net/robinson_0612     */
/* MSN:    
[email protected]
*/ /* QQ: 645746311 */ /**************************************************/ SQL> analyze table t compute statistics; -->執行analyze SQL> @Tab_Stat -->此時的empty_blocks值為125 Enter value for input_table_name: t Enter value for input_owner: scott NUM_ROWS BLKS EM_BLKS AVG_SPACE CHAIN_CNT AVG_ROW_LEN AVG_ROWS_PER_BLOCK LST_ANLY STA ---------- ---------- ---------- ---------- ---------- ----------- ------------------ --------- --- 10000 387 125 920 0 262 26 03-NOV-11 NO SQL> col segment_name format a15 SQL> select segment_name,segment_type,blocks,extents from dba_segments -->查看錶段上的塊的資訊 2 where segment_name='T' and owner='SCOTT'; SEGMENT_NAME SEGMENT_TYPE BLOCKS EXTENTS -->此資料字典中記錄的塊數為512塊(包含了已使用塊與空閒塊) --------------- ------------------ ---------- ---------- T TABLE 512 19 SQL> set autotrace traceonly; -->開啟autotrace SQL> select count(*) from t; -->此時SQL語句的執行計劃為全表掃描(執行計劃中部分資訊被省略) Execution Plan ---------------------------------------------------------- Plan hash value: 2966233522 ------------------------------------------------------------------- | Id | Operation | Name | Rows | Cost (%CPU)| Time | ------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 86 (0)| 00:00:02 | | 1 | SORT AGGREGATE | | 1 | | | | 2 | TABLE ACCESS FULL| T | 10000 | 86 (0)| 00:00:02 | ------------------------------------------------------------------- Statistics ---------------------------------------------------------- 1 recursive calls 0 db block gets 375 consistent gets -->consistent gets的值為375 0 physical reads SQL> set autotrace off; SQL> delete from t where rownum<=9900; -->刪除大多數的記錄,刪除後剩餘記錄值為100 9900 rows deleted. SQL> commit; SQL> exec dbms_stats.gather_table_stats('SCOTT','T',cascade=>true); -->收集統計資訊 SQL> analyze table t compute statistics; -->收集統計資訊 SQL> @Tab_Stat -->此時物件上的統計資訊無任何變化,即高水位線沒有發生任何變化 Enter value for input_table_name: t Enter value for input_owner: scott NUM_ROWS BLKS EM_BLKS AVG_SPACE CHAIN_CNT AVG_ROW_LEN AVG_ROWS_PER_BLOCK LST_ANLY STA ---------- ---------- ---------- ---------- ---------- ----------- ------------------ --------- --- 100 387 125 7921 0 262 0 03-NOV-11 NO SQL> set autotrace traceonly SQL> select count(*) from t; -->SQL的執行計劃中預估的值準確,為100行 Execution Plan ---------------------------------------------------------- Plan hash value: 2966233522 ------------------------------------------------------------------- | Id | Operation | Name | Rows | Cost (%CPU)| Time | ------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 86 (0)| 00:00:02 | | 1 | SORT AGGREGATE | | 1 | | | | 2 | TABLE ACCESS FULL| T | 100 | 86 (0)| 00:00:02 | ------------------------------------------------------------------- Statistics ---------------------------------------------------------- 1 recursive calls 0 db block gets 375 consistent gets -->consistent gets的值仍然為375,並沒有下降 0 physical reads SQL> set autotrace off; SQL> alter table t enable row movement; -->啟用row movement SQL> alter table t shrink space cascade; --> 實施shrink space SQL> alter table t disable row movement; SQL> exec dbms_stats.gather_table_stats('SCOTT','T'); SQL> analyze table t compute statistics; SQL> @Tab_Stat -->此時物件上的統計資訊已發生變化,已使用的塊為4塊,空閒塊為4塊 Enter value for input_table_name: t Enter value for input_owner: scott NUM_ROWS BLKS EM_BLKS AVG_SPACE CHAIN_CNT AVG_ROW_LEN AVG_ROWS_PER_BLOCK LST_ANLY STA ---------- ---------- ---------- ---------- ---------- ----------- ------------------ --------- --- 100 4 4 7921 0 259 25 03-NOV-11 NO SQL> set autotrace traceonly SQL> select count(*) from t; Execution Plan ---------------------------------------------------------- Plan hash value: 2966233522 ------------------------------------------------------------------- | Id | Operation | Name | Rows | Cost (%CPU)| Time | ------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 3 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | | | | 2 | TABLE ACCESS FULL| T | 100 | 3 (0)| 00:00:01 | ------------------------------------------------------------------- Statistics ---------------------------------------------------------- 1 recursive calls 0 db block gets 6 consistent gets -->表段收縮之後,consistent gets由375下降為6 0 physical reads SQL> truncate table t; -->使用表截斷技術(turncate table) Table truncated. SQL> exec dbms_stats.gather_table_stats('SCOTT','T'); -->收集統計資訊 PL/SQL procedure successfully completed. SQL> select count(*) from t; -->此時執行計劃中的rows變為1 Execution Plan ---------------------------------------------------------- Plan hash value: 2966233522 ------------------------------------------------------------------- | Id | Operation | Name | Rows | Cost (%CPU)| Time | ------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 2 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | | | | 2 | TABLE ACCESS FULL| T | 1 | 2 (0)| 00:00:01 | ------------------------------------------------------------------- Statistics ---------------------------------------------------------- 1 recursive calls 0 db block gets 3 consistent gets -->consistent gets的值降為3 0 physical reads

相關推薦

水位掃描

   高水位線好比水庫中儲水的水位線,用於描述資料庫中段的擴充套件方式。高水位線對全表掃描方式有著至關重要的影響。當使用delete 操作 表記錄時,高水位線並不會下降,隨之導致的是全表掃描的實際開銷並沒有任何減少。本文給出高水位線的描述,如何降低高水位線,以及高水 位線對

很精闢的oracle水位,終於知道DELETETRUNCATE為什麼不一樣了

一、Oracle表段中的高水位線HWM在Oracle資料的儲存中,可以把儲存空間想象為一個水庫,資料想象為水庫中的水。水庫中的水的位置有一條線叫做水位線,在Oracle中,這條線被稱為高水位線(High-warter mark, HWM)。在資料庫表剛建立的時候,由於沒有任

Delete/Truncate刪除,釋放空間、降低水位、resize釋放磁碟空間相關優化

硬碟空間不足,打算刪除資料庫中的多餘資料,但刪除資料後,硬碟硬碟空間不能釋放。 【delete後用:alter table table_name move    truncate後用:alter table table_name deallocate unused 均不可

Oracle段中的水位HWM+修正ORACLE水位

Oracle表段中的高水位線HWM   在Oracle資料的儲存中,可以把儲存空間想象為一個水庫,資料想象為水庫中的水。水庫中的水的位置有一條線叫做水位線,在Oracle中,這條線被稱為高水位線(High-warter mark, HWM)。在資料庫表剛建立的時候,由於沒有任

oracle 掃描索引掃描

1) 全表掃描(Full Table Scans, FTS)        為實現全表掃描,Oracle讀取表中所有的行,並檢查每一行是否滿足語句的WHERE限制條件。Oracle順序地讀取分配給表的每個資料塊,直到讀到表的最高水線處(high water mark, HWM

避免掃描的sql優化

設計 結束 edate bstr 需要 表達 大量數據 第一個 關鍵字 摘抄自:http://www.cnblogs.com/jameslif/p/6406167.html 對查詢進行優化,應盡量避免全表掃描,首先應考慮在where 及order by 涉及的列上建立索引

oracle 水位詳解

dbm 標示 man archive mark 新建 arc 有一種 art 一、什麽是水線(High Water Mark)? 所有的oracle段(segments,在此,為了理解方便,建議把segment作為表的一個同義詞) 都有一個在段內容納數據的上限,我們把這個上

水位基礎

清空 臨時 轉移表 適用於 能說 statistic stat 。。 sed 一、oracle 高水位線詳解 一、什麽是水線(High Water Mark)? 所有的oracle 段(segments,在此,為了理解方便,建議把segment 作為表

ORACLE sql調優之記錄一次trim函數引發的大掃描

oracle trim 全表掃描 sql 調優 2017年8月14日,一地市oracle相關的調度程序ETL抽取速度奇慢,sql語句每次執行平均時間要9秒左右,如果所示:該調度過程涉及的sql語句如下:select count(*) from (SELECT rtrim(

項目owner看這裏,MaxCompute掃描新功能,給你“失誤”的機會

業務需求 機會 表數據 人的 人員 做了 設置 cli ssi 摘要: MaxCompute發布了“ALIAS 命令”,提供了在不修改代碼的前提下,在MapReduce或自定義函數(UDF) 代碼中,通過某個固定的資源名讀取不同資源(數據)的需求。隨著社會數據收集手段的不斷

造成MySQL掃描的原因

記錄 添加 its 工程師 review 全表掃描 字段 count 查詢條件 全表掃描是數據庫搜尋表的每一條記錄的過程,直到所有符合給定條件的記錄返回為止。通常在數據庫中,對無索引的表進行查詢一般稱為全表掃描;然而有時候我們即便添加了索引,但當我們的SQL語句寫的不合理的

關係型資料庫掃描分片詳解

導讀:資料匯流排(DBus)專注於資料的實時採集與實時分發,可以對IT系統在業務流程中產生的資料進行匯聚,經過轉換處理後成為統一JSON的資料格式(UMS),提供給不同資料使用方訂閱和消費,充當數倉平臺、大資料分析平臺、實時報表和實時營銷等業務的資料來源。在上一篇關於DBus的文章中,我們主要介紹了在DBus

Oracle 檢查資料庫有哪些頻繁進行掃描

select a.object_name, a.sql_id, b.sql_text, max(b.executions) executions, max(b.last_active_time) last_active_time, b.first_load_time from v$sql_plan a,

oracle 水位詳解(刪除大量資料後續處理)

一、oracle 高水位線詳解 一、什麼是水線(High Water Mark)? 所有的oracle段(segments,在此,為了理解方便,建議把segment作為表的一個同義詞) 都有一個在段內容納資料的上限,我們把這個上限稱為"high water mark"或HWM。這個HWM是一個標記,

MyBatis實戰之對映器 SSM框架之批量增加示例(同步請求jsp檢視解析) mybatis的批量更新例項 造成MySQL掃描的原因 SSM框架實戰之整合EhCache

對映器是MyBatis最強大的工具,也是我們使用MyBatis時用得最多的工具,因此熟練掌握它十分必要。MyBatis是針對對映器構造的SQL構建的輕量級框架,並且通過配置生成對應的JavaBean返回給呼叫者,而這些配置主要便是對映器,在MyBatis中你可以根據情況定義動態SQL來滿足不同場景的需要,它比

一、oracle 水位詳解

一、什麼是水線(High Water Mark)? 所有的oracle段(segments,在此,為了理解方便,建議把segment作為表的一個同義詞) 都有一個在段內容納資料的上限,我們把這個上限稱為"high water mark"或HWM。這個HWM是一個標記,用來說明已經有多少沒

降低oracle水位方法總結(包括驗證結果)

1. 執行表重建指令 alter table table_name move(驗證不可行,不降低水位線,但可釋放表空間) 當你建立了一個物件如表以後,不管你有沒有插入資料,它都會佔用一些塊,ORACLE也會給它分配必要的空間.同樣,用ALTER TABLE MOVE釋放自由空間後,還是保留了一些

Mysql避免掃描的sql查詢優化

對查詢進行優化,應儘量避免全表掃描,首先應考慮在 where 及 order by 涉及的列上建立索引:  嘗試下面的技巧以避免優化器錯選了表掃描:   使用ANALYZE TABLE tbl_

scala操作Hbas -掃描

package com.blm.util import javax.ws.rs.core.Response.Status.Family import org.apache.hadoop.hbase.{CellUtil, HBaseConfiguration, TableName} im

如何對10億資料量級的mongoDB作高效的掃描

本文連結: http://quentinXXZ.iteye.com/blog/2149440 一、正常情況下,不應該有這種需求 首先,大家應該有個概念,標題中的這個問題,在大多情況下是一個偽命題,不應該被提出來。要知道,對於一般較大資料量的資料庫,全表查詢,這種操作一般情況下是不應該出現的,在做正常查