I have a typical after migration issue, we had i/o issues visible in prod after migration to 11gr2. Oracle recommended to set the parameter “_partition_large_extents to false” and after doing that we are observing lots of HW contentions and buffer busy waits in database, mostly the truncate is getting slowed down.

Please suggest.

Thank
Saurabh

You haven’t provided much information, what version of RDBMS?

Mode of the request and hold is very important to diagnose the locking performance issue.

Can you send the output of the script below when you have locking contention? If you don’t want to post here, you can send to rshamsud@orainternals.com.

col inst format A10
col module format A30
col lmode format 999
col request format 999
SELECT DECODE(request,0,’Holder: ‘,’ Waiter: ‘)||a.sid sess,
decode(request,0,to_char(a.inst_id),’ ‘||to_char(a.inst_id)) inst,
id1, id2, lmode, request, a.type, a.sid,
b.sql_hash_value hash,module,round(last_call_et/60,0) min
FROM gV$LOCK a, gv$session b
WHERE (id1, id2, a.type) IN
(SELECT id1, id2, type FROM gV$LOCK WHERE request>0)
and a.sid = b.sid
and a.inst_id = b.inst_id
ORDER BY id1, request
;

the wait process is in a update ,also there is a important table , always inserting ( millions of rows a day ) , with a CLOB column.

Is there a way to check if the problem is for this bug? looking the oracle trace.

thanks.

Sorry for missing some important parameters . Ok it is windows XP 32 bits, filesystem- ntfs, the database version is 10.1.0.2
Insert operation done through 3 simultaneous session. Yes it has clob as in your script.In fact i am using the same scripts, but even having 3 sessions running in parallel for insert opertaion still i am not able to produce the Hw-enq wait. Statistics are fine but I need to be inline with wait and produce HW-enq wait and then after increasing the segment size to 5m check how the waits are reduced with larger extent size.
Test case useed:
@enq_hw1 “uniform size 40K segment space management manual”
@enq_hw1 “uniform size 40K segment space management auto”.

So if possible please let me know how to go for it what changes to make to get the above goal? We canot reduce the extent size further as at least 5 block size(8k) is required while creating the tablespace. Other details i have provided in previous post if anyother information is required then please let me know.
Regarding filesystem_options to setall, . i set this but still didnot find any change for “direct path write” wait event on TS_LMT_AUTO_1M_01.DBF’ file .

Regards,
Zafar

Thanks for reading my blog and your kind words.

For HW enqueue test, what version of software and what tablespace management type (ASSM or non-ASSM) are you using? You might need to increase concurrency, but keep the transaction smaller, typically, few blocks. That might trigger HW enqueue contention.

If your SQL inserts are suffering from direct path write wait events, then are you using conventional insert or direct mode insert? Do you have lob columns in that table? What software version please. Better thing is to understand why writes are slower? What kind of file system? Instead of setting disk_asynch_io parameter, you need to have filesystem_options to setall, Oracle RDBMS code will use both asynchronous I/O and direct I/O if the file system supports it.

Cheers
Riyaj

It is very pleasing to see your practical approach and demonstration for various issues.
Here may be i am just deviating some from the article but it is all related to the same. I tried to do the test and the result was very satisfactory and was in accordance to your observation. As we have to face different types of client in many cases they even donot agree with these statistics i mean HW resuest .so itried to aggrevate it by using 40K extent size and inserting data through 3 different sessions in test environment so that it could comeup with the HW enqueue wait event but unfortunately it didnot show any HW wait event . Could you please provide the test scenerio in which we can also create this wait event and then we can check if the wait event has gone by increasing the extent size. I have used manual allocate enough space to avoid this wait event( using alter table modify lob… allocate extent command).
other observation is:
I am finding lots of “direct path write” on the datafile “TS_LMT_AUTO_1M_01.DBF ” contention for each session that is doing the insert .
So could you please provide some help to reduce this “direct path write” on data file.
I have disk_asynch_io = TRUE. As this wait is not on temp file i hope it has nothing to take with pga and sort area and worksize_area_policy even then if it is required i have the following setting for them:

pga_aggregate_target =200000000

workarea_size_policy =AUTO

increasing the pga didnot help as it is coming on datafile?

Your early suggestions and solutions for both the points are very much appriciated.
Regards,
Md. zafar Ahsan Oracle DBA

Correct approach here is to understand root cause by dumping the log files. This might also mean that you may have to dump the ASSM segments with dbms_Space_admin.segment_dump to see block status of various blocks. With these two trace files, you may be able to understand, why extents are allocated even when not needed.

There are many bugs in 10.2.0.3 in ASSM for extent management. You may be hitting one of that. So, you might want to consider upgrading to version 10.2.0.4 and see if this problem reproduces.

Cheers
Riyaj

Thank you in advance,
khair