enq: HW - contention 问题的处理

东非尼日利亚某运营商，这是一个06年的系统，伴随着业务的增长
服务器负载越来越高，越来越吃力， 客户提出问题已有半年，
一直没有完全解决，最近客户一直在投诉。

现象： 有几个大表的数据一直录入不完，发生数据积压。

awr 报告

Top 5 Timed Foreground Events

Event Waits Time(s) Avg wait (ms) % DB time Wait Class
enq: HW - contention 136 30,920 227353 54.17 Configuration
buffer exterminate 259,455 5,178 20 9.07 Other
buffer busy waits 4,894 4,763 973 8.34 Concurrency
log file sync 220,273 4,345 20 7.61 Commit
free buffer waits 142,053 3,071 22 5.38 Configuration

主要enq: HW - contention等待事件胶及buffer busy 等执点争用的事件

热点争用的对象
主要是系统里的大表及审计表，这里我们也用不到审计，直接关掉

Segments by Buffer Busy Waits

    % of Capture shows % of Buffer Busy Waits for each top segment compared
    with total Buffer Busy Waits for all segments captured by the Snapshot

Owner Tablespace Name Object Name Subobject Name Obj. Type Buffer Busy Waits % of Capture
REPORT_PMDB REPORT_DB C_CELL_PS   TABLE 50 53.19
REPORT_PMDB REPORT_PMDB_INDEX C_CELL_LINK_INDEX_9   INDEX 19 20.21
REPORT_PMDB REPORT_DB C_CELL_CS   TABLE 14 14.89
SYS SYSTEM AUD$   TABLE 11 11.70

为防止多个进程同时修改HWM而提供的锁称为HW锁。想要移动HWM的进程必须获得HW锁。
若在获取HW锁过程中发生争用，则等待enq: HW - contention事件。
HW锁争用大部分是大量执行insert所引发的。
众所周知，Oracle高水位线标志着该线以下的block均被Oracle格式过，
通俗一点讲就是该高水位线以下的block都被Oracle使用过。
通常在执行insert操作时，当高水位线以下block不够用时，
Oracle将会推进高水位线。更进一步讲，
当有多个进程在同时进行insert操作时，比较容易引起高水位线争用，
主要表现为enq: HW - contention

SQL> select event#,name,parameter1,parameter2,parameter3 from v$event_name where name = 'enq: HW - contention'; 

    EVENT# NAME                                     PARAMETER1           PARAMETER2           PARAMETER3 

enq: HW - contention                     name|mode            table space #    
    block  如何找到事件：'enq: HW - contention' 热点对象：

查看v$session_wait，应该会有如下等待事件：

SQL> select p1, p2, p3 from v$session_wait where event = 'enq: HW - contention'; 
  
        P1         P2         P3 
---------- ---------- ----------   5.1213661190          7  140003563 
1213661190          7  140003563 
1213661190          7  140003563 
1213661190          7  140003563 
1213661190          7  140003563 
1213661190          7  140003563 
1213661190          7  140003563 
  
7 rows selected  7 rows selected通过P3进行DBMS_UTILITY转换可以获知发生争用的文件和block：
SQL> select dbms_utility.data_block_address_block(140003563),dbms_utility.data_block_address_file(140003563) from dual; 
 
DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(140003563) DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE(140003563) 
------------------------------------------------ -----------------------------------------------   5.                                         1591531                                              33 
而通过file#和block#定位对象：                                                                                      
.SQL> select owner, segment_type, segment_name                                                                    
  from dba_extents   3.  3  where file_id = 33  
    and 1591531 between block_id and block_id + blocks - 1;

定位：几个大表数据量较大，引起高水位扩展等待及热点争用。

措施1. 修改几张大表为hash 分区表
    2. 关掉审计
   
   
插曲:

负责运维的兄弟比较保守，一开始在每个表上划分三个hash 分区
但是效果不太明显。（备注一般来说建2的次方个分区）

  于是又增加了13个分区达到16个分区，是4的n次方。但是反而更慢了。
开始怀疑方案，一再分的原来增加了分区后，全部的index 失效。
重建index ,速度提高了不少。

到此问题结束。.