Regarding 10.2.0.3 on AIX 5.3

Question

Hi Gurus,
I am in one of our clients site and visited here to see Oracle problems which they are facing.
They have recently upgraded their oracle database release to 10.2.0.3 on AIX-5.3(64bit production)
Actually speaking they have a application server residing on Linux and database resides on AIX5.3.Through tnsnames.ora they are communicating their Application server.
They are unable to authorise the records in their Live system.Resulting all the trans boundry records unable to rollback and they are even loosing the old records as well.This is a very critical situation for us now :-(
The error log showing as below
~ -->CT FCRD.ACCT.ACTIVITY 13011040000004-200708
Error 5 during READ_ERROR to file ../bnk.data/ac/FCRD.ACCT001
Enter I to Ignore, R to Retry , Q to Quit :
* Oracle Error **: ORA-03113: end-of-file on communication channel
TRANSROLLBACK: Rollback failed
** Oracle Error **: ORA-03114: not connected to ORACLE
** Error ** WRITE: Unable to write key 200708290037156335.00 record <row
id='200708290037156335.00'><c1>20070829</c1><c2>1</c2><c3>153855</c3><c4>371 33</c4><c6>BD0010126</c6><c7>MUHAMMAD</c7><c8>AZ
.ACCOUNT,PR.FD.OPEN</c8><c9>1 I</c9><c10>12641010008042</c10><c11>Cannot write 12641010008042 to FFEX.AZ.SCHEDULES.NAU</c11><
/row>
3857 - 2.0.9 - Wed Aug 29 15:38:55 - ** Oracle Error **: ORA-03114: not connected to ORACLE
5919 - 2.0.9 - Wed Aug 29 15:39:15 - ACFCRD_ACCT001 - ** Error ** READ: Key = 13011040000004-200708. Unable to convert XML re
cord into jBASE record
The above is one of our locally generated error log file where we can see all the the actions sending to Oracle database.
we can concentrate on the below error order.
Oracle Error **: ORA-03113: end-of-file on communication channel
TRANSROLLBACK: Rollback failed
** Oracle Error **: ORA-03114: not connected to ORACLE
Just yesterday we have confirmed from them that they are missing one patch which is
Errors in file
/orafs/app/oracle/admin/pblprod/udump/pblprod_ora_303562.trc:
ORA-07445: exception encountered: core dump [] [] [] [] [] []
Thu Jul 19 08:25:41 2007
Technical details:
This problem is arised due to "hash table key was exceeding
"ub1maxval" on 64 bit platforms because of the increas
e in size of struct memebers.
ORA-07445 and ORA-03113 are inter linked ?
and also please advice us how should we tune the rollback segments in oracle if huge rollback is concern.
Thanks
Kiran Kumar.S

Answer 1

Do you have any Oracle error related to rollback segment or undo tablespace ?Actually speaking we use transaction boundry in our code is as concern.When user inputting transactions if
at any point of failure, any tables,files at the application level updated within the transaction boundry should be rolled back.This is failing only at some point of time and the records which meant to be flushed back from the shared memory was not happenning.
I just wanted to convey my problem scenario to you before giving the update.
I havent got any error messages regarding roll back in my alertlogfile except below.
(FOB) flags=2 fib=70000025cb621e8 incno=0 pending i/o cnt=0
fname=/oradata/pblprod/undotbs01.dbf
fno=2 lblksz=8192 fsiz=206400
Are you using automatic undo ?Yes we are using undo_management as AUTO
What is the value of undo_retention parameter ?
Undo rentention parameter value is 900 which is too high i think. :-(
SQL> show parameter undo_retention;
NAME TYPE
VALUE
undo_retention integer
900
Do you have long running queries ? How long ?
Do you large write queries (UPDATE/INSERT/DELETE)Yes we do have.We have long running queries from application level during batch updates.The batch update we call it as
Close of Business (COB).So in COB we do have larger appends/writes/delete/truncate is as concern.
But in this case i think we have a problem with write.A longer running query may run at the maximum of 5min without any indexes created.
As a conclusion i think the problem which is ORA-03113 happenning because we have a very big undo_retention value which is 900.The UNDO_RETENTION parameter works best if the current undo tablespace has enough space fir the active transactions. If an active transaction needs undo space and the undo tablespace does not have any free space, then the system will start reusing undo space that would have been retained. This may cause long queries to fail.
My thinking makes sense ?
If i am speaking sense then shall we clear the undo tablespace please ?