Oracle Database 10 g : 為 DBA 提供的最佳前 20 位的特性（十五）

2024-08-29 13:46:57

字體：大中小

來源：轉載

供稿：網友

Oracle Database 10 g : 為 DBA 提供的最佳前 20 位的特性（十五） 作者 Arup Nanda 來源： OTN 第 15 周
段治理 用 Oracle 數據庫 10 g 通過回收浪費的空間、聯機重組表格和評估增長的趨勢，有效地在段中進行存儲治理 近來，有人要求我評估一個與 Oracle 數據庫競爭的 RDBMS 。在供給商的演示過程中，觀眾認為 “ 最棒 ” 的特性是，對聯機重組的支持 — 該產品可以聯機重新部署數據塊，以使段的等價物更簡潔，并且不會影響當前的用戶。那時， Oracle 還沒有在 Oracle9 i 數據庫中提供這種功能。但是現在，有了 Oracle 數據庫 10 g ，就可以輕松地聯機回收浪費的空間和壓縮對象 — 正好適合于起步者。不過，在檢驗該特性之前，讓我們看一看處理這項任務的 “ 傳統的 ” 方法。 當前慣例 考慮讓我們看一個段，如一張表，其中填滿了塊，如圖 1 所示。在正常操作過程中，刪除了一些行，如圖 2 所示。現有就有了許多浪費的空間： (i) 在表的上一個末端和現有的塊之間，以及 (ii) 在塊內部，其中還有一些沒有刪除的行。

圖 1 ：分配給該表的塊。用灰色正方形表示行。 Oracle 不會釋放空間以供其他對象使用，有一條簡單的理由：由于空間是為新插入的行保留的，并且要適應現有行的增長。被占用的最高空間稱為最高使用標記 (HWM) ，如圖 2 所示。

圖 2 ：行后面的塊已經刪除了； HWM 仍保持不變。 但是，這種方法有兩個主要的問題：

當用戶發出一個全表掃描時， Oracle 始終必須從段一直掃描到 HWM ，即使它什么也沒有發現。該任務延長了全表掃描的時間。
當用直接路徑插入行時 — 例如，通過直接加載插入（用 APPEND 提示插入）或通過 SQL*Loader 直接路徑 — 數據塊直接置于 HWM 之上。它下面的空間就浪費掉了。

在 Oracle9 i 及其以前的版本中，可以通過刪除表，然后重建表并重新加載數據往返收空間；或通過使用 ALTER TABLE MOVE 命令把表移動到一個不同的表空間中往返收空間。這兩種處理方式都必須脫機進行。另外，可以使用聯機表重組特性，但是這需要至少雙倍的現有表空間。在 10 g 中，該任務已經變得微不足道了；假如您的表空間中支持自動段空間治理 (ASSM), 您現在可以縮小段、表和索引，以回收空閑塊并把它們提供給數據庫以作他用，讓我們看看其中的緣由。 10 g 中的段治理方式 設想有一個表 BOOKINGS ，它保存有經由 Web 站點的聯機登記。當一個登記確認后，就會把它存儲在一個存檔表 BOOKINGS_HIST 中，并從 BOOKINGS 表中刪除該行。登記和確認之間的時間間隔依據客戶有很大的不同，由于無法從刪除的行獲得足夠的空間，因此許多行就插入到了表的 HWM 之上。現在您需要回收浪費的空間。首先，準確地查明在可回收的段中浪費了多少空間。由于它是在支持 ASSM 的表空間中，您將不得不使用 DBMS_SPACE 包的 SPACE_USAGE 過程，如下所示： declare l_fs1_bytes number; l_fs2_bytes number; l_fs3_bytes number;
l_fs4_bytes number; l_fs1_blocks number; l_fs2_blocks number; l_fs3_blocks number; l_fs4_blocks number; l_full_bytes number; l_full_blocks number; l_unformatted_bytes number; l_unformatted_blocks number; begin dbms_space.space_usage( segment_owner => user, segment_name => 'BOOKINGS', segment_type => 'TABLE', fs1_bytes => l_fs1_bytes, fs1_blocks => l_fs1_blocks, fs2_bytes => l_fs2_bytes, fs2_blocks => l_fs2_blocks, fs3_bytes => l_fs3_bytes, fs3_blocks => l_fs3_blocks, fs4_bytes => l_fs4_bytes, fs4_blocks => l_fs4_blocks, full_bytes => l_full_bytes, full_blocks => l_full_blocks, unformatted_blocks => l_unformatted_blocks, unformatted_bytes => l_unformatted_bytes ); dbms_output.put_line(' FS1 Blocks = 'l_fs1_blocks' Bytes = 'l_fs1_bytes); dbms_output.put_line(' FS2 Blocks = 'l_fs2_blocks' Bytes = 'l_fs1_bytes); dbms_output.put_line(' FS3 Blocks = 'l_fs3_blocks' Bytes = 'l_fs1_bytes); dbms_output.put_line(' FS4 Blocks = 'l_fs4_blocks' Bytes = 'l_fs1_bytes); dbms_output.put_line('Full Blocks = 'l_full_blocks' Bytes = l_full_bytes); end; / 輸出結果如下： FS1 Blocks = 0 Bytes = 0 FS2 Blocks = 0 Bytes = 0 FS3 Blocks = 0 Bytes = 0 FS4 Blocks = 4148 Bytes = 0 Full Blocks = 2 Bytes = 16384 這個輸出結果顯示有 4,148 個塊，具有 75-100% 的空閑空間 (FS4) ；沒有其他空閑塊可用。這里僅有兩個得到完全使用的塊。 4,148 個塊都可以回收。接下來，您必須確保該表支持行移動。假如不支持，您可以使用如下命令來支持它： alter table bookings enable row movement; 或通過 Administration 頁上的企業治理器 10 g 。您還要確保在該表上禁用所有基于行 id 的觸發器，這是因為行將會移動，行 id 可能會發生改變。
最后，您可以通過以下命令重組該表中現有的行： alter table bookings shrink space compact; 該命令將會在塊內重新分配行，如圖 3 所示，這就在 HWM 之下產生了更多的空閑塊 — 但是 HWM 自身不會進行分配。

圖 3 ：重組行后的表中的塊。在執行該操作后，讓我們看一看空間利用率所發生的改變。使用在第一步展示的 PL/SQL 塊，可以看到塊現在是如何組織的： FS1 Blocks = 0 Bytes = 0 FS2 Blocks = 0 Bytes = 0 FS3 Blocks = 1 Bytes = 0 FS4 Blocks = 0 Bytes = 0 Full Blocks = 2 Bytes = 16384 注重這里的重要改變： FS4 塊（具有 75-100% 的空閑空間）的數量現在從 4,148 降為 0 。我們還看到 FS3 塊（具有 50-75% 的空閑空間）的數量從 0 增加到 1 。但是，由于 HWM 沒有被重置，總的空間利用率仍然是相同的。我們可以用如下命令檢查使用的空間： SQL> select blocks from user_segments where segment_name = 'BOOKINGS'; BLOCKS --------- 4224 由該表占用的塊的數量 (4,224) 仍然是相同的，這是因為并沒有把 HWM 從其原始位置移開?？梢园?HWM 移動到一個較低的位置，并用如下命令回收空間： alter table bookings shrink space; 注重子句 COMPACT 沒有出現。該操作將把未用的塊返回給數據庫并重置 HWM ?？梢酝ㄟ^檢查分配給表的空間來對其進行測試： SQL> select blocks from user_segments where segment_name = 'BOOKINGS'; BLOCKS ---------- 8 塊的數量從 4,224 降為 8 ；該表內所有未用的空間都返回給表空間，以讓其他段使用，如圖 4 所示。

圖 4 ：在收縮后，把空閑塊返回給數據庫。這個收縮操作完全是在聯機狀態下發生的，并且不會對用戶產生影響。也可以用一條語句來壓縮表的索引： alter table bookings shrink space cascade; 聯機 shrink 命令是一個用于回收浪費的空間和重置 HWM 的強大的特性。我把后者（重置 HWM ）看作該命令最有用的結果，因為它改進了全表掃描的性能。 找到收縮合適選擇 在執行聯機收縮前，用戶可能想通過確定能夠進行最完全壓縮的段，以找出最大的回報。只需簡單地使用 dbms_space 包中的內置函數 verify_shrink_candidate 。假如段可以收縮到 1,300,000 字節，則可以使用下面的 PL/SQL 代碼進行測試： begin if (dbms_space.verify_shrink_candidate ('ARUP','BOOKINGS','TABLE',1300000) then :x := 'T'; else :x := 'F'; end if; end;
/ PL/SQL 過程成功完成。 SQL> PRint x X -------------------------------- T 假如目標收縮使用了一個較小的數，如 3,000 ： begin if (dbms_space.verify_shrink_candidate ('ARUP','BOOKINGS','TABLE',30000) then :x := 'T'; else :x := 'F'; end if; end; 變量 x 的值被設置成 'F' ，意味著表無法收縮到 3,000 字節。 推測一下來自索引空間的需要 現在假定您將著手在一個表上，或者也許是一組表上創建一個索引的任務。除了普通的結構元素，如列和單值性外，您將不得不考慮的最重要的事情是索引的預期大小 — 必須確保表空間有足夠的空間來存放新索引。在 Oracle 數據庫 9 i 及其以前的版本中，許多 DBA 使用了大量的工具（從電子數據表到獨立程序）來估計將來索引的大小。在 10 g 中，通過使用 DBMS_SPACE 包，使這項任務變得極其微不足道。讓我們看一看它的作用方式。我們要求在 BOOKINGS 表的 booking_id 和 cust_name 列上創建一個索引。這個提議的索引需要多少空間呢？您所需要做的全部工作就是執行下面的 PL/SQL 腳本。 declare l_used_bytes number; l_alloc_bytes number; begin dbms_space.create_index_cost ( ddl => 'create index in_bookings_hist_01 on bookings_hist ' '(booking_id, cust_name) tablespace users', used_bytes => l_used_bytes, alloc_bytes => l_alloc_bytes ); dbms_output.put_line ('Used Bytes = 'l_used_bytes); dbms_output.put_line ('Allocated Bytes = 'l_alloc_bytes); end; / The output is: Used Bytes = 7501128 Allocated Bytes = 12582912 假定您想使用一些參數，而這些將參數潛在地增加了索引的大小，例如，指定 INITRANS 參數為 10 。 declare l_used_bytes number; l_alloc_bytes number; begin dbms_space.create_index_cost ( ddl => 'create index in_bookings_hist_01 on bookings_hist ' '(booking_id, cust_name) tablespace users initrans 10',
used_bytes => l_used_bytes, alloc_bytes => l_alloc_bytes ); dbms_output.put_line ('Used Bytes = 'l_used_bytes); dbms_output.put_line ('Allocated Bytes = 'l_alloc_bytes); end; / 輸出結果如下： Used Bytes = 7501128 Allocated Bytes = 13631488 注重通過指定一個更高的 INITRANS ，而導致的分配字節的增加。使用這種方法可以輕易地確定索引對存儲空間的影響。但是，您應該意識到兩個重要的警告。第一，該過程只適用于打開了 SEGMENT SPACE MANAGEMENT AUTO 的表空間。第二，包是依據表上的統計來計算索引的估計大小。因此，對表執行相對新的統計是非常重要的。但請注重：假如沒有對表的統計，不會導致使用包時出錯，但會產生一個錯誤的結果。 估計表的大小 假定有一個名為 BOOKINGS_HIST 的表，它共有 30,000 行，各行長度較為平均，并且 PCTFREE 參數值為 20 。假如想把參數 PCT_FREE 增至 30, 表格的大小將增加多少？由于 30 是將 20 增長了 10% ，表格大小將會按 10% 的比例增長嗎？這個問題不要問自己，而要問 DBMS_SPACE 包內的 CREATE_TABLE_COST 過程。下面是您能夠估計大小的方法： declare l_used_bytes number; l_alloc_bytes number; begin dbms_space.create_table_cost ( tablespace_name => 'USERS', avg_row_size => 30, row_count => 30000, pct_free => 20, used_bytes => l_used_bytes, alloc_bytes => l_alloc_bytes ); dbms_output.put_line('Used:'l_used_bytes); dbms_output.put_line('Allocated:'l_alloc_bytes); end; / 輸出結果如下： Used: 1261568 Allocated: 2097152 要把表的 PCT_FREE 參數從 20 更改為 30 ，可以通過指定 pct_free => 30 我們得到了輸出結果： Used: 1441792 Allocated: 2097152 注重：使用的空間已從 1,261,568 增加到 1,441,792 ，這是由于 PCT_FREE 參數在用戶數據的數據塊中保留了較少的空間。增量大約有 14% ，而不是所預期的 10% 。使用這個包可以輕易地計算出參數（如 PCT_FREE ）對表大小的影響，或把該表移動到一個不同的表空間中的影響。 猜測段的增長 這是一個假日的周末， Acme 酒店期待有如同潮涌般的人群要求入住。作為一名 DBA ，您正設法了解這種需求，以使您能夠確保有足夠的空間可供使用。如何猜測表的空間利用率呢？只需詢問 10 g ；您就會驚詫于它能夠多么準確和聰明地為您作出猜測。只需簡單地發出查詢 : select * from table(dbms_space.OBJECT_GROWTH_TREND
('ARUP','BOOKINGS','TABLE')); 函數 dbms_space.object_growth_trend() 將以 PipELINE d 格式返回記錄，這種格式可以通過 TABLE() 強制轉換將其顯示出來。輸出如下： TIMEPOINT SPACE_USAGE SPACE_ALLOC QUALITY ------------------------------ ----------- ----------- ------------ 05-MAR-04 08.51.24 .421081 PM 8586959 39124992 INTERPOLATED 06-MAR-04 08.51.24 .421081 PM 8586959 39124992 INTERPOLATED 07-MAR-04 08.51.24 .421081 PM 8586959 39124992 INTERPOLATED 08-MAR-04 08.51.24 .421081 PM 126190859 1033483971 INTERPOLATED 09-MAR-04 08.51.24 .421081 PM 4517094 4587520 GOOD 10-MAR-04 08.51.24 .421081 PM 127469413 1044292813 PROJECTED 11-MAR-04 08.51.24 .421081 PM 128108689 1049697234 PROJECTED 12-MAR-04 08.51.24 .421081 PM 128747966 1055101654 PROJECTED 13-MAR-04 08.51.24 .421081 PM 129387243 1060506075 PROJECTED 14-MAR-04 08.51.24 .421081 PM 130026520 1065910496 PROJECTED 輸出結果多次清楚顯示了 BOOKINGS 表的大小，就像在 TIMEPOINT 列、 TIMESTAMP 數據類型中所顯示的那樣。 SPACE_ALLOC 列顯示了分配給該表的字節，而 SPACE_USAGE 列顯示了已使用了多少字節。該信息是由自動負載存儲或 AWR （參閱本系列中的第 6 周）天天進行收集的。在上面的輸出中，數據是在 2004 年 3 月 9 日收集好的，就像 QUALITY 列的值－ "GOOD" 所指示的那樣。那一天的空間分配和使用數字都是準確無誤的。但是，以后的日子，該列的值將是 PROJECTED ，這表示空間計算是由 AWR 功能依據收集的數據進行猜測的 — 不是直接從段進行收集。注重 3 月 9 日以前的該列中的值 — 全都是 INTERPOLATED 。換句話說，該值沒有真正收集或猜測的值，只是簡單地依據適用于任何可用數據的使用圖案添加進去的。最有可能的是當時沒有數據，因此不得不添加該值。結論有了段級操作，現在就能對段內空間如何使用進行細粒度的控制，可用往返收表內的空閑空間、聯機重組表中的行以使之更壓縮，以及更多操作。這些功能幫助 DBA 從諸如表重組之類的日常任務中解脫出來。聯機段收縮特性在估計內部碎片和降低段的最高使用標記方面非凡有用，能顯著地減少全表掃描的成本。么獲取關于 SHRINK 操作的更多信息，請參閱 Oracle 數據庫 SQL 參考 中的這部分的內容?？梢栽?PL/SQL 包和類型參考 的第 88 章中了解到有關 DBMS_SPACE 包的更多信息。為了對 Oracle 數據庫 10 g 中的所有新的空間治理特性作一個全面的回顧，可以閱讀技術白皮書 自我治理的數據庫：積極的空間和模式對象治理 。最后，在線提供了一個 Oracle 數據庫 10 g 空間治理的演示

上一篇：Oracle Database 10 g : 為 DBA 提供的最佳前 20 位的特性（十四）

下一篇：Oracle Database 10 g : 為 DBA 提供的最佳前 20 位的特性（十二）