Performance issue possibly due to wrong parameters??

Question

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit.
We have a program that runs every two weeks to process 3million records in our Oracle 10g database. Processing normally takes about 6 hours. With no change to the program (which is a java client program), the processing time has gotten longer and longer over the last few weeks. The processor on the database server was upgraded to iTanium and during this upgrade the databases were striped to fix a read/write issue that occurred due to poor configuration (it wasn't using multiple channels for processing so everything ran super slow) when the server hardware was upgraded. Since the last upgrade to the processor, we've noticed many errors being generated on the server when our program runs (java null reference errors). these errors never occurred before the upgrade. The upgrade was in July. In August we noticed the beginning of a degradation in performance - the process went from 6 hours to 10 hours. This month, it is taking 20 hours. Next month I fear it will be 40 hours.
The program launches multiple sessions that work at once doing an update against the same table. The last time it ran it started at 6AM and by 1PM it was only 11% done. I looked at the session stats and saw the top 5 wait events:
SQL*Net message from client-->
totalwaits=11,997
timewaited=2,070,070
avgwait=172
enq: TX - row lock contention-->
totalwaits=587
timewaited 65,614
avgwait=111
timeouts=180
latch:cache buffers chains-->
totalwaits=933
timewaited=1,815
avgwait=2
db file sequential read-->
totalwaits=1,426
timewaited=1,519
avgwait=1
log file sync-->
totalwaits=1,422
totalwaited=2594
avgwait=2
It looks like all of these values are way too high and I'm wondering what parameters we could change on the database/server side that might improve performance in these areas.
I read that increasing the INITRANS VALUE TO SOMETHING GREATER THAN ONE WOULD HELP WITH THE ROW LOCK CONTENTION AND TIMEOUTS.
I also read that changing DB_CACHE_ADVICE OFF WOULD HELP WITH THE CACHE BUFFER CHAINS ISSUE.
Are these viable solutions? Changing the program is not an option right now. Any help is greatly appreciated.

Answer 1

Rakesh jayappa wrote:
Hi,
sorry i am not getting your question, i am guessing your question, you can reduce the log file sync by
COMMIT WRITE BATCH;
COMMIT WRITE IMMEDIATE;
or
The disks or I/O subsystems where the redologs are placed may be too busy.
- Reduce other I/O activity on the disks containing the redo logs, or use dedicated disks.
- Move the redo logs to faster disks or a faster I/O subsystem.
- Move the redolog files from RAID 5 devices. RAID 5 is not efficient for writes.
- Alternate redo logs on different disks to minimize the effect of the archiver on the log writer.
Kind Regards,
Rakesh JayappaMy point is that even if you eliminate it completely you have only eliminated a tiny fraction of the total wait time -- it may look like low hanging fruit, but it's a very small piece of fruit indeed.