enq: FB - contention 等待事件造成原因以及解决办法

 Enq: FB – contention we can assume that two sessions have simultaneously tried to format the same new batch of blocks and one of them is waiting for the other to complete the format.

* This wait can also be viewed (like the “read by other session” wait) in a positive light – if the second session weren’t waiting for the first session to complete the block format it would have to do the formatting itself, which means the second end-user is actually going to get an improved response time 

* Also the number of blocks picked by a session is dependent on its process id so the second session might have picked a different set of blocks to format, which means that in the elapsed time of one format call the segment could have had more number of blocks formatted – this wouldn’t have improved the end-user’s response time, but it would mean that more time would pass before another session had to spend time formatting blocks. Basically, in a highly concurrent system, there’s not a lot you can do about enq:FB waits (unless, of course, partitioned the hot objects into different tablespace).

* This is most likely to happen if you have a tablespace using large extents and Oracle thinks you’re going to process a relatively small amount of data (e.g. small indexes on large tables) – and its the collisions between processes and wasted space.

 

1) You can find that the “FB” enqueue has the following description and wait information when you query v$lock_type, and v$event_name:

SQL> select * from v$event_name where name like 'enq: FB%';
SQL> select NAME,PARAMETER1,PARAMETER2,PARAMETER3,WAIT_CLASS_ID,DISPLAY_NAME from v$event_name where name like 'enq: FB%';

SQL> select TYPE,NAME,ID1_TAG,ID2_TAG,IS_USER,DESCRIPTION from v$lock_type where TYPE='FB';

SQL> select session_id, sql_id, event, p1, p1text, p2 "TS#", p3 "Block", wait_time, session_state, time_waited from gv$active_session_history where event like '%FB%' and sql_id = '<insert_Stmt_SQL_ID_FROM_AWR>'; ------>>>> Replace SQL_ID

 

2) If we have multiple sessions doing insert concurrently and more than one session are trying to format the block that may cause the contention.The value on P1 is name|mode , P2 tells the tablespace number, and P3 gives the dba.

SQL> select session_id,SQL_ID,EVENT,P1,P1text,P2,P3,WAIT_TIME,SESSION_STATE,TIME_WAITED from v$active_session_history where event like '%FB%';
SQL> select name from v$tablespace where ts#=P2; ----------->>> P2 value from above

SQL> SELECT dbms_utility.data_block_address_block(p3) "BLOCK", dbms_utility.data_block_address_file(p3) "FILE" from dual; ---->>> P3 Value from Above

 

-- and --


#1-- Also you can use below ::

SQL> select SID,USERNAME,SQL_ID from v$session where SQL_ID='&SQL_ID';

Enter SQL_ID's

#2-- SQL> select username, event, p1, p2 from v$session_wait where sid =&SID;

Now Enter all the SID separately / one by one for each SQL_ID from (#1).

#3-- SQL> select segment_name,segment_type from dba_extents where file_id = &file_id and &Block_id between block_id and block_id + blocks - 1;

FILE_ID=P1
BLOCK_ID=P2

 

3) Check for Below possible workarounds

* If there is any changes in Tablespace / Table level storage parameters recently
* If you have all the object and partitions in same tablespaces then move them to different tablespaces.
* Undersized storage parameters may cause the issue so please check and increase the value ( ex. PCTFREE and INITRANS etc )

SQL> alter table <TABLE> INITRANS 10 PCTFREE 40;
SQL> alter index <IND_NAME> rebuild partition <Partition_name> initrans 50 PCTFREE 40;
SQL> alter table <Schema.Table_name> modify default attributes tablespace <TS_NAME> initrans 10;
SQL> ALTER INDEX INDEX_NAME INITRANS 10 ;
* If you have large index block split then:

For segments with automatic ASSM, Oracle ignores attempts to change the PCT% setting. If you alter the PCT% setting or changed , then you must subsequently run the DBMS_REPAIR.SEGMENT_FIX_STATUS procedure to implement the new setting on blocks already allocated to the segment.

/* Below will Fix the bitmap status for all the blocks in table for that Schema */

SQL> exec dbms_repair.segment_fix_status('<Table_owner>','<Tab_Name>',dbms_repair.table_object);
-- and --

SQL> exec dbms_repair.segment_fix_status('<index_owner>','<index_name>',sys.dbms_repair.index_object);

 

SQL> exec dbms_repair.segment_fix_status('<index_owner>','<index_name>',dbms_repair.index_object);

Other possible workarounds:

* Auto allocate extent size or Pre allocate the extents to the segment having a high number of inserts.
* Make room for more extents on the Segments also check AWR and ADDM report for other possible Wait events which affects the IO of Database ( db file sequential read etc..)
* Look for any IO issue that is causing slowdown in formatting the blocks.
* Some time high IO operation like LARGE INDEX BLOCK SPLIT may require more extent allocation and may cause the enq: FB contention.
* Try to avoid multiple sessions doing the insert against one segment. Each session may try to format the block and can trigger the contention.
* It's better to put partition segments into different tablespace