ORACLE 11g 生產中高水位線(HWM)處理

數據庫中表不斷的insert，delete，update，致使表和索引出現碎片。這會致使HWM以前有不少的空閒空間，而oracle在作全表掃描的時候會讀取HWM一下的全部塊，這樣會產生更多的IO，影響性能。

oracle提供了shrink space碎片整理的功能，對於索引要採起rebuild online的方式進行碎片整理。

高水位的管理機制

高水位的管理機制在 MSSM 和 ASSM 中不一樣，在以往的手動段空間管理中（MSSM），高水位標記 HWM，一個段分紅三部分，header block，used block(row data)，unusedblock，其中 used block 和 unused block 之間的分界線就是高水位標記 HWM，當進行全表掃描的時候，會掃描到 HWM 下的全部數據塊，即便 used block 中不少數據被刪除了，全表掃描仍是以HWM爲準。

 

在自動段管理（ASSM）中，利用位圖來代替空閒列表，當會話向表插入數據時，數據庫只格式一個單獨的位圖塊，而不是像 MSSM 中那樣，會預先格式化一組塊。在ASSM表空間中，除了一個 HWM 外，還有一個低 HWM。在 MSSM 中，HWM 推動時，全部的塊都會格式化並當即生效，這樣 Oracle 就能夠安全的讀取這些塊。可是對於 ASSM，當 HWM推動時，Oracle 並不會當即格式全部的塊，只是在第一次使用的時候纔會對這些塊進行格式化。也就是說，在第一次使用的的時候，即進行 insert 操做時，數據會插入到塊中的任意水位線，位於低水位線（LHMW）和高水位線（HHMW）之間。所以在這個區域的許多塊就不會被格式化。

背景

生產中這S_OPERATELOG, S_T_RTNRP_STATUS, S_T_SEND_REPORT三張表實際使用量不大（即truncate分區後），表空間數據文件仍是佔用很高，幾個T，現須要釋放不用的空間。

 

生產中遇到的案例

如下是生產中的三張表，且都是按天生成的分區表（不足一個月的數據，一年數據量很大）

select segment_name,round(sum(bytes / 1024 / 1024 / 1024), 2) G

  from user_segments

 where segment_name in

       ('S_OPERATELOG', 'S_T_RTNRP_STATUS', 'S_T_SEND_REPORT') group by segment_name;

  

能夠看出使用的並非很大。

 

查看錶使用的表空間

select owner, table_name, tablespace_name

  from dba_tables

 where owner = 'SMART'

   AND TABLE_NAME in

       ('S_OPERATELOG', 'S_T_RTNRP_STATUS', 'S_T_SEND_REPORT')

       UNION

 select TABLE_OWNER,TABLE_NAME,TABLESPACE_NAME

  from dba_Tab_Partitions

 where

  TABLE_OWNER='SMART'

   AND TABLE_NAME in

       ('S_OPERATELOG', 'S_T_RTNRP_STATUS', 'S_T_SEND_REPORT')     

 

查看錶空間使用狀況：

select tablespace_name,

ROUND(sum(bytes / 1024 / 1024 / 1024),2) G，ROUND(sum(maxbytes / 1024 / 1024 / 1024),2) max_G

  from dba_data_files

 where file_name like '+FDATADG%'

 GROUP BY TABLESPACE_NAME ORDER BY 2 DESC;

 

 

能夠看出幾個表空間佔用空間很大，尤爲是前三個表空間。

查看錶空間數據文件狀況：

SELECT a.tablespace_name,

       a.file_name,

       round(a.bytes/1024/1024/1024,2) AS "current_bytes(GB)",

       round(a.bytes/1024/1024/1024 - b.resize_to/1024/1024/1024,2) AS "shrink_by_bytes(GB)",

       round(b.resize_to/1024/1024/1024,2) AS "resize_to_bytes(GB)"

FROM   dba_data_files a,

       (SELECT file_id, MAX((block_id+blocks-1)*&v_block_size) AS resize_to

        FROM   dba_extents

        GROUP by file_id) b

WHERE  a.file_id = b.file_id

and a.TABLESPACE_NAME in

 (

'SMART_OPLOG01',

'SMART_NRRPSTA01',

'SMART_NRRPSTA02',

'SMART_NSNRP01',

'SMART_NSNRP02'

)

ORDER BY a.tablespace_name, a.file_name;

塊大小是16K的。16384

 

 

後三列表示當前佔用大小，可以收縮大小,最小的resize大小。

處理辦法：

1)    Shrink對應的表

注意：因爲在線上，不能進行有表鎖的操做，因此我並無採用這種辦法

alter table TABLE_NAME enable ROW MOVEMENT;--啓動行移動功能

alter table TABLE_NAME shrink space compact;  --只整理碎片 不回收空間

-- 重置高水位，此時不能有DML操做

alter table TABLE_NAME shrink space; --整理碎片並回收空間，並調整水位線。業務少時執行

alter table TABLE_NAME disable ROW MOVEMENT;--關閉行移動

 

2)    Resize 數據文件

select  ' alter database datafile '''||file_name ||''' resize 43g;' from dba_data_files where tablespace_name

   in (

   'SMART_NRRPSTA01'

   );

 

 

收縮前表空間使用以下：

 

 

收縮後表空間使用以下：

 

 

磁盤組使用以下：

 

原+FDATADG磁盤中使用達到96%,釋放了20%的空間。