日本不卡不码高清免费观看,久久国产精品久久w女人spa,黄色aa久久,三上悠亚国产精品一区二区三区

您的位置:首頁技術文章
文章詳情頁

講解Oracle表碎片的具體起因及解決的辦法

瀏覽:268日期:2023-11-27 09:21:45

表碎片的相關知識:

什么是水線(High Water Mark)?

----------------------------

所有的Oracle段(segments,在此,為了理解方便,建議把segment作為表的一個同義詞) 都有一個在段內容納數據的上限,我們把這個上限稱為'high water mark'或HWM。這個HWM是一個標記,用來說明已經有多少沒有使用的數據塊分配給這個segment。HWM通常增長的幅度為一次5個數據塊,原則上HWM只會增大,不會縮小,即使將表中的數據全部刪除,HWM還是為原值,由于這個特點,使HWM很象一個水庫的歷史最高水位,這也就是HWM的原始含義,當然不能說一個水庫沒水了,就說該水庫的歷史最高水位為0。但是如果我們在表上使用了truncate命令,則該表的HWM會被重新置為0。

HWM數據庫的操作有如下影響:

a) 全表掃描通常要讀出直到HWM標記的所有的屬于該表數據庫塊,即使該表中沒有任何數據。

b) 即使HWM以下有空閑的數據庫塊,鍵入在插入數據時使用了append關鍵字,則在插入時使用HWM以上的數據塊,此時HWM會自動增大。

如何知道一個表的HWM?

a) 首先對表進行分析:

ANALYZE TABLE; ESTIMATE/COMPUTE STATISTICS;b) SELECT blocks, empty_blocks, num_rows FROM user_tables WHERE table_name = ;

BLOCKS 列代表該表中曾經使用過得數據庫塊的數目,即水線。

EMPTY_BLOCKS 代表分配給該表,但是在水線以上的數據庫塊,即從來沒有使用的數據塊。

讓我們以一個有28672行的BIG_EMP1表為例進行說明:

1) SQL> SELECT segment_name,segment_type,blocks FROM dba_segments WHERE segment_name='BIG_EMP1'; SEGMENT_NAME SEGMENT_TYPE BLOCKS EXTENTS ----------------------------- ----------------- ---------- ------- BIG_EMP1 TABLE 1024 2 1 row selected.

2) SQL> ANALYZE TABLE big_emp1 ESTIMATE STATISTICS; Statement processed.

3) SQL> SELECT table_name,num_rows,blocks,empty_blocks FROM user_tables WHERE table_name='BIG_EMP1'; TABLE_NAME NUM_ROWS BLOCKS EMPTY_BLOCKS ------------------------------ ---------- ---------- ------------ BIG_EMP1 28672 700 323 1 row selected.

注意:BLOCKS + EMPTY_BLOCKS (700+323=1023)比DBA_SEGMENTS.BLOCKS少個數據庫塊,這是因為有一個數據庫塊被保留用作segment header。DBA_SEGMENTS.BLOCKS 表示分配給這個表的所有的數據庫塊的數目。USER_TABLES.BLOCKS表示已經使用過的數據庫塊的數目。

4) SQL> SELECT COUNT (DISTINCT DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid)|| DBMS_ROWID.ROWID_RELATIVE_FNO(rowid)) 'Used' FROM big_emp1; Used ---------- 700 1 row selected.

5) SQL> DELETE from big_emp1; 28672 rows processed.

6) SQL> commit; Statement processed.

7) SQL> ANALYZE TABLE big_emp1 ESTIMATE STATISTICS; Statement processed.

8) SQL> SELECT table_name,num_rows,blocks,empty_blocks FROM user_tables WHERE table_name='BIG_EMP1'; TABLE_NAME NUM_ROWS BLOCKS EMPTY_BLOCKS ------------------------------ ---------- ---------- ------------ BIG_EMP1 0 700 323 1 row selected.

9) SQL> SELECT COUNT (DISTINCT DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid)|| DBMS_ROWID.ROWID_RELATIVE_FNO(rowid)) 'Used' FROM big_emp1; Used ---------- 0 -- 這表名沒有任何數據庫塊容納數據,即表中無數據1 row selected.

10) SQL> TRUNCATE TABLE big_emp1; Statement processed.

11) SQL> ANALYZE TABLE big_emp1 ESTIMATE STATISTICS; Statement processed.

12) SQL> SELECT table_name,num_rows,blocks,empty_blocks 2> FROM user_tables 3> WHERE table_name='BIG_EMP1'; TABLE_NAME NUM_ROWS BLOCKS EMPTY_BLOCKS ------------------------------ ---------- ---------- ------------ BIG_EMP1 0 0 511 1 row selected.

13) SQL> SELECT segment_name,segment_type,blocks FROM dba_segments WHERE segment_name='BIG_EMP1'; SEGMENT_NAME SEGMENT_TYPE BLOCKS EXTENTS ----------------------------- ----------------- ---------- ------- BIG_EMP1 TABLE 512 1 1 row selected.

注意:

TRUNCATE命令回收了由delete命令產生的空閑空間,注意該表分配的空間由原先的1024塊降為512塊。

為了保留由delete命令產生的空閑空間,可以使用TRUNCATE TABLE big_emp1 REUSE STORAGE

用此命令后,該表還會是原先的1024塊。

行鏈接(Row chaining) 與行遷移(Row Migration)當一行的數據過長而不能插入一個單個數據塊中時,

可能發生兩種事情:行鏈接(row chaining)或行遷移(row migration)。

行鏈接

當第一次插入行時,由于行太長而不能容納在一個數據塊中時,就會發生行鏈接。在這種情況下,oracle會使用與該塊鏈接的一塊或多塊數據塊來容納該行的數據。行連接經常在插入比較大的行時才會發生,如包含long, long row, lob等類型的數據。在這些情況下行鏈接是不可避免的。

行遷移

當修改不是行鏈接的行時,當修改后的行長度大于修改前的行長度,并且該數據塊中的空閑空間已經比較小而不能完全容納該行的數據時,就會發生行遷移。在這種情況下,Oracle會將整行的數據遷移到一個新的數據塊上,而將該行原先的空間只放一個指針,指向該行的新的位置,并且該行原先空間的剩余空間不再被數據庫使用,這些剩余的空間我們將其稱之為空洞,這就是產生表碎片的主要原因,表碎片基本上也是不可避免的,但是我們可以將其降到一個我們可以接受的程度。注意,即使發生了行遷移,發生了行遷移的行的rowid 還是不會變化,這也是行遷移會引起數據庫I/O性能降低的原因。其實行遷移是行鏈接的一種特殊形式,但是它的起因與行為跟行鏈接有很大不同,所以一般把它從行鏈接中獨立出來,單獨進行處理。

行鏈接和行遷移引起數據庫性能下降的原因:

引起性能下降的原因主要是由于引起多余的I/O造成的。當通過索引訪問已有行遷移現象的行時,數據庫必須掃描一個以上的數據塊才能檢索到改行的數據。這主要有一下兩種表現形式:

1) 導致row migration 或row chaining INSERT 或 UPDATE語句的性能比較差,因為它們需要執行額外的處理

2) 利用索引查詢已經鏈接或遷移的行的select語句性能比較差,因為它們要執行額外的I/O

如何才能檢測到行遷移與行鏈接:

在表中被遷移或被鏈接的行可以通過帶list chained rows選項的analyze語句識別出來。這個命令收集每個被遷移或鏈接的行的信息,并將這些信息放到指定的輸出表中。為了創建這個輸出表,運行腳本UTLCHAIN.SQL。

SQL> ANALYZE TABLE scott.emp LIST CHAINED ROWS; SQL> SELECT * FROM chained_rows;

當然你也可以通過檢查v$sysstat視圖中的'table fetch continued row'來檢查被遷移或被鏈接的行。

SQL> SELECT name, value FROM v$sysstat WHERE name = 'table fetch continued row'; NAME VALUE ---------------------------------------------------------------- --------- table fetch continued row 308

盡管行遷移與行鏈接是兩個不同的事情,但是在oracle內部,它們被當作一回事。所以當你檢測行遷移與行鏈接時,你應該仔細的分析當前你正在處理的是行遷移還是行鏈接。

解決辦法

o 在大多數情況下,行鏈接是無法克服的,特別是在一個表包含象LONGS, LOBs 等這樣的列時。當在不同的表中有大量的鏈接行,并且哪些表的行的長度不是很長時,你可以通過用更大的block size重建數據庫的方法來解決它。

例如:當前你的數據庫的數據塊的大小為4K,但是你的行的平均長度為6k,那么你可以通過用8k大小的數據塊來重建數據庫的辦法解決行鏈接現象。

o 行遷移主要是由于設置的PCTFREE參數過小,導致沒有給update操作留下足夠的空閑空間引起。為了避免行遷移,所有被修改的表應該設置合適的PCTFREE 值,以便在每個數據塊內為數據修改保留足夠的空間。可以通過增加PCTFREE值的辦法來避免行遷移,但這種解決辦法是以犧牲更多的空間為代價的,這也就是我們通常所說的以空間換效率。 而且通過增加PCTFREE值的辦法只能緩解行遷移現象,而不能完全解決行遷移,所以較好的辦法是在設置了合適的PCTFREE值的后,在發現行遷移現象比較嚴重時,對表的數據進行重組。

下面是對行遷移數據進行重組的步驟(這種方法也被成為CTAS):

-- Get the name of the table with migrated rows: ACCEPT table_name PROMPT 'Enter the name of the table with migrated rows: '

-- Clean up from last execution set echo off DROP TABLE migrated_rows; DROP TABLE chained_rows;

-- Create the CHAINED_ROWS table @.../rdbms/admin/utlchain.sql set echo on spool fix_mig -- List the chained and migrated rows ANALYZE TABLE &table_name LIST CHAINED ROWS;

-- Copy the chained/migrated rows to another table create table migrated_rows as SELECT orig.* FROM &table_name orig, chained_rows cr WHERE orig.rowid = cr.head_rowid AND cr.table_name = upper('&table_name');

-- Delete the chained/migrated rows from the original table DELETE FROM &table_name WHERE rowid IN (SELECT head_rowid FROM chained_rows);

-- Copy the chained/migrated rows back into the original table INSERT INTO &table_name SELECT * FROM migrated_rows;

spool off

當對一個表進行全表掃描時,我們實際上忽略行遷移中各個指向其它行的指針,因為我們知道,全表掃描會遍歷全表,最終會讀到發生行遷移的行的行數據,在此時才會處理這些行數據。因此,在全表掃描中,行遷移不會引發其它額外的工作。

當通過索引讀一個表的數據時,被遷移的行會引起額外的I/O操作。這是因為從所引中我們會讀到數據行的rowid,它告訴數據庫到指定文件的指定數據塊的指定slot上可以找到需要的數據,但是因為發生了行遷移,此處只存放一個指向數據的指針,而不是真正的數據,所以數據庫又需要根據該指針(類似rowid)到指定文件的指定數據塊的指定slot上去找真正的數據,重復上面的過程,知道找到真正的數據。我們可以看出,這會引入額外的I/O操作。

發現又嚴重表碎片的表的步驟:

表需要整理原因有2:

a) 有太多的migration rows

b) 表經過刪除數據后有大量的空塊, 而全表掃描時,仍需要讀這些空塊

發現需要reorganization的表,需要從表的實際使用的空間與表的hwm入手

首先分析表:

Alter table emp compute statistics.

然后可以查詢出有數據的數據塊的個數:

For ORACLE 7: SELECT COUNT(DISTINCT SUBSTR(rowid,15,4)|| SUBSTR(rowid,1,8)) 'Used' FROM schema.table;

For ORACLE 8+: SELECT COUNT (DISTINCT DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid)|| DBMS_ROWID.ROWID_RELATIVE_FNO(rowid)) 'Used' FROM schema.table; or SELECT COUNT (DISTINCT SUBSTR(rowid,1,15)) 'Used' FROM schema.table;

查詢出HWM以下的數據塊的個數(可能由于delete, 數據塊中并不包含數據):

This will update the table statistics. After generating the statistics, to determine the high water mark: SELECT blocks, empty_blocks, num_rows FROM user_tables WHERE table_name = <tablename>

下面給出一個綜合的sql語句,它可以查詢出浪費空間的表(浪費超過25%),而且還計算出其它信息(使用時根據具體情況修改where子句中的blocks,owner限制條件):

SELECT OWNER, SEGMENT_NAME TABLE_NAME, SEGMENT_TYPE, GREATEST(ROUND(100 * (NVL(HWM - AVG_USED_BLOCKS,0)/GREATEST(NVL(HWM,1),1) ), 2), 0) WASTE_PER,ROUND(BYTES/1024, 2) TABLE_KB, NUM_ROWS, BLOCKS, EMPTY_BLOCKS, HWM HIGHWATER_MARK, AVG_USED_BLOCKS,CHAIN_PER, EXTENTS, MAX_EXTENTS, ALLO_EXTENT_PER,DECODE(GREATEST(MAX_FREE_SPACE - NEXT_EXTENT, 0), 0,'N','Y') CAN_EXTEND_SPACE, NEXT_EXTENT, MAX_FREE_SPACE,O_TABLESPACE_NAME TABLESPACE_NAMEFROM (SELECT A.OWNER OWNER, A.SEGMENT_NAME, A.SEGMENT_TYPE, A.BYTES,B.NUM_ROWS, A.BLOCKS BLOCKS, B.EMPTY_BLOCKS EMPTY_BLOCKS, A.BLOCKS - B.EMPTY_BLOCKS - 1 HWM,DECODE( ROUND((B.AVG_ROW_LEN * NUM_ROWS * (1 + (PCT_FREE/100)))/C.BLOCKSIZE, 0),0, 1,ROUND((B.AVG_ROW_LEN * NUM_ROWS * (1 + (PCT_FREE/100)))/C.BLOCKSIZE, 0)) + 2 AVG_USED_BLOCKS,ROUND(100 * (NVL(B.CHAIN_CNT, 0)/GREATEST(NVL(B.NUM_ROWS, 1), 1)), 2) CHAIN_PER,ROUND(100 * (A.EXTENTS/A.MAX_EXTENTS), 2) ALLO_EXTENT_PER,A.EXTENTS EXTENTS,A.MAX_EXTENTS MAX_EXTENTS, B.NEXT_EXTENT NEXT_EXTENT, B.TABLESPACE_NAME O_TABLESPACE_NAMEFROM SYS.DBA_SEGMENTS A,SYS.DBA_TABLES B,SYS.TS$ CWHERE A.OWNER =B.OWNER and SEGMENT_NAME = TABLE_NAME andSEGMENT_TYPE = 'TABLE' ANDB.TABLESPACE_NAME = C.NAMEUNION ALLSELECT A.OWNER OWNER, SEGMENT_NAME || '.' || B.PARTITION_NAME, SEGMENT_TYPE, BYTES,B.NUM_ROWS, A.BLOCKS BLOCKS, B.EMPTY_BLOCKS EMPTY_BLOCKS, A.BLOCKS - B.EMPTY_BLOCKS - 1 HWM,DECODE( ROUND((B.AVG_ROW_LEN * B.NUM_ROWS * (1 + (B.PCT_FREE/100)))/C.BLOCKSIZE, 0),0, 1,ROUND((B.AVG_ROW_LEN * B.NUM_ROWS * (1 + (B.PCT_FREE/100)))/C.BLOCKSIZE, 0)) + 2 AVG_USED_BLOCKS,ROUND(100 * (NVL(B.CHAIN_CNT,0)/GREATEST(NVL(B.NUM_ROWS, 1), 1)), 2) CHAIN_PER,ROUND(100 * (A.EXTENTS/A.MAX_EXTENTS), 2) ALLO_EXTENT_PER, A.EXTENTS EXTENTS, A.MAX_EXTENTS MAX_EXTENTS, B.NEXT_EXTENT,B.TABLESPACE_NAME O_TABLESPACE_NAMEFROM SYS.DBA_SEGMENTS A,SYS.DBA_TAB_PARTITIONS B,SYS.TS$ C,SYS.DBA_TABLES DWHERE A.OWNER = B.TABLE_OWNER and SEGMENT_NAME = B.TABLE_NAME andSEGMENT_TYPE = 'TABLE PARTITION' ANDB.TABLESPACE_NAME = C.NAME ANDD.OWNER = B.TABLE_OWNER ANDD.TABLE_NAME = B.TABLE_NAME ANDA.PARTITION_NAME = B.PARTITION_NAME),(SELECT TABLESPACE_NAME F_TABLESPACE_NAME,MAX(BYTES)MAX_FREE_SPACEFROM SYS.DBA_FREE_SPACEGROUP BY TABLESPACE_NAME)WHERE F_TABLESPACE_NAME = O_TABLESPACE_NAME ANDGREATEST(ROUND(100 * (NVL(HWM - AVG_USED_BLOCKS, 0)/GREATEST(NVL(HWM, 1), 1) ), 2), 0) > 25AND OWNER = '??' AND BLOCKS > 128ORDER BY 10 DESC, 1 ASC, 2 ASC;

各列說明:

WASTE_PER:已分配空間中水線以下的空閑空間(即浪費空間)的百分比。

TABLE_KB:該表目前已經分配的所有空間的大小,以k為單位。

NUM_ROWS:在在表中數據的行數

BLOCKS:該表目前已經分配的數據塊的塊數,包含水線以上的部分

EMPTY_BLOCKS:已分配空間中水線以上的空閑空間

HIGHWATER_MARK:目前的水線

AVG_USED_BLOCKS:理想情況下(沒有行遷移),該表數據應該占用的數據塊的個數

CHAIN_PER:發生行遷移現象的行占總行的比率

EXTENTS:該表目前已經分配的extent數

MAX_EXTENTS:該表可以分配的最大extent的個數

ALLO_EXTENT_PER:目前已分配的extent的個數占可以分配最大extent的比率

CAN_EXTEND_SPACE:是否可以分配下一個extent

NEXT_EXTENT:下一個extent的大小

MAX_FREE_SPACE:表的已分配空間中最大的空閑空間

標簽: Oracle 數據庫
日本不卡不码高清免费观看,久久国产精品久久w女人spa,黄色aa久久,三上悠亚国产精品一区二区三区
午夜在线精品偷拍| 亚洲永久av| 视频一区欧美精品| 黑丝一区二区三区| 好看不卡的中文字幕| 欧美日韩国产综合网| 伊人久久亚洲热| 亚洲永久字幕| 丝袜美腿亚洲一区二区图片| 日韩制服丝袜av| 日韩毛片一区| 国产亚洲电影| 国产精品伦理久久久久久| 欧美成a人片免费观看久久五月天| 国产精品探花在线观看| 久久不见久久见免费视频7 | 不卡福利视频| 88xx成人免费观看视频库| 久久九九精品| 国产一区二区高清| 最新国产精品久久久| 国产精品入口久久| 国产成人精品亚洲日本在线观看| 欧美日中文字幕| 午夜亚洲一区| 国产欧美自拍一区| 国产精选在线| 蜜桃tv一区二区三区| 欧美在线综合| 91精品尤物| 成人台湾亚洲精品一区二区| 欧美日一区二区| 国产精选久久| 久久激五月天综合精品| 一级欧洲+日本+国产| 天堂√中文最新版在线| 精品三级久久| 只有精品亚洲| 国产一区导航| 亚洲自拍另类| 亚洲日本三级| 粉嫩av一区二区三区四区五区 | 久久精品国产99国产精品| 成人在线视频免费| 激情综合自拍| 国产三级一区| 欧美亚洲精品在线| 国产图片一区| 宅男在线一区| 久久一区欧美| 免费人成精品欧美精品| 国产精品宾馆| 午夜精品一区二区三区国产| 99免费精品| 日韩一区二区免费看| 欧美精品观看| 99tv成人| 日本欧美一区| 久久九九精品| 国产精品久久久久久久久免费高清| 亚洲a在线视频| 国产伦理一区| 一区在线免费| 精品网站aaa| 中文字幕中文字幕精品| 毛片在线网站| 伊人久久亚洲| 亚洲精品一级二级| 国产精品亚洲产品| 蜜桃视频在线观看一区二区| 亚洲三级欧美| 国产精品chinese| 综合国产在线| 激情综合网五月| 精品三区视频| 日韩美女精品| 日av在线不卡| 欧美日韩在线二区| 国产第一亚洲| 国产精品网站在线看| 免费日本视频一区| 亚洲精品一级| 国产日韩欧美中文在线| 午夜日本精品| 日韩电影免费网站| 久久亚洲道色| 欧美日韩亚洲一区三区| 亚洲国产日韩欧美在线| 国产一区二区三区久久| 亚洲免费福利一区| 99国产精品久久久久久久 | 午夜在线精品| 韩日一区二区三区| 日韩天堂在线| 高清久久一区| 国产欧美日韩亚洲一区二区三区| 久久福利毛片| 欧美日韩国产精品一区二区亚洲| 九九99久久精品在免费线bt| 日本国产欧美| 亚洲日韩视频| 蜜臀av在线播放一区二区三区| 黄色亚洲免费| 国产韩日影视精品| 欧美中文一区二区| 成人羞羞在线观看网站| 黄色aa久久| 色婷婷综合网| 国内精品亚洲| 欧美 日韩 国产精品免费观看| 伊人久久大香线蕉av不卡| 国产精品久久久久久久久久齐齐 | 蜜臀a∨国产成人精品| 亚洲欧美伊人| 天堂网在线观看国产精品| 成人久久一区| 综合日韩av| 日韩大片在线观看| 亚洲啊v在线| 日韩精品电影| 日韩视频网站在线观看| 免费看av不卡| 美女av在线免费看| 日韩理论片av| 丝袜美腿一区| 91精品综合| 欧美在线亚洲| 99国产精品视频免费观看一公开| 日韩视频久久| 欧美综合国产| 亚洲美女久久| 欧美影院精品| 国产一区二区三区日韩精品| 九九久久婷婷| 蜜桃视频在线网站| 亚洲www啪成人一区二区| 日本精品影院| 国产超碰精品| 99国产一区| 亚洲三级毛片| 国产精品一级| av免费不卡国产观看| 久久一区二区三区喷水| 亚洲精品一区二区在线看| 蜜桃伊人久久| 日韩高清一区| 国产精品videosex极品| 狠狠久久伊人中文字幕| 欧美日韩免费看片| 91超碰国产精品| 亚洲精品系列| 免费日韩成人| 国产成人免费精品| 精品在线99| 日韩福利视频导航| 超碰成人av| 亚洲一区国产| 国产精品伦一区二区| 97精品国产福利一区二区三区| 水蜜桃久久夜色精品一区| 日韩不卡免费高清视频| 久久亚洲欧洲| 国产精品一区二区三区www| 麻豆精品少妇| 欧洲一级精品| 亚洲视频电影在线| 欧美成人aaa| 日本亚洲欧美天堂免费| 亚洲精品极品少妇16p| 久久国产精品亚洲77777| 午夜精品影视国产一区在线麻豆| 国产精品色在线网站| 久久久久免费| 视频一区在线播放| 国产在视频一区二区三区吞精| 女人av一区| 国产日韩一区二区三免费高清| 日本不良网站在线观看| 老鸭窝亚洲一区二区三区| 国产伦理一区| 国产精品av一区二区| 欧美日韩一区二区高清| 麻豆精品少妇| 在线亚洲国产精品网站| 国产精品.xx视频.xxtv| 不卡视频在线| 麻豆成人综合网| 99热精品在线观看| 国产精品资源| 国产精品88久久久久久| 国产精品v日韩精品v欧美精品网站 | 欧美二区视频| 国产精品久久久一区二区| 久久精品国产68国产精品亚洲| 日韩精品第一| 日韩高清中文字幕一区二区| 日韩一区网站| 日韩精品永久网址| 欧美日韩国产探花| 亚洲午夜久久|