Upgradation from 11..5.10 to CU2 is taking more than 30 hours

Question

Hi All ,
WE 're upgrading our application from 11.5.10 to 11.5.10.2 by applying 3460000 patch . Our OS version is AIX 5.3 .
But our patch is running from last 30 hours and is still running . We've checked the patch log & Worker log and from that we've found that it's running succesfully . But 30 hours is a very long time and we can't arrange such downtime on PROD . And still the patch is not completed .
I want to know that if anyone here ( reading this post ) has applied this patch earlier , then how much time it 'll take to complete ??? Is this time OK . And also , is this patch depends upon the DATABASE size . As here our database size is 3 TB . Is it also creating a problem , if yes then whats the workaround for this .
Earlier revert or workaround on this would be highly appreciated . you can revert me on my id also , my id is [email protected]
regds
Rahul Gupta

Answer 1

Rahul,
30 hours does seem like a long time. How many parallel workers are you using? On a 12 CPU box, you should specify workers=36 or workers=48 unless you start swapping heavily with that many java processes during the database portion. Also, how many other instances are running on this box? Does the box seem overloaded?
After the upgrade completes, go into Oracle Applications Manager and look at the timing details for 3460000, or look at the csv timing report in $APPL_TOP/admin/<sid>/out and look for problems with the longest running tasks.
You may want to run bde_rebuild.sql on your biggest schemas to look for fragmented indexes and ensure you have done gather schema stats before the upgrade along with a gather dictionary stats as shown below:
Collecting Statistics with Oracle Apps 11i
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=368252.1
bde_rebuild.sql - Validates and rebuilds indexes occupying more space than needed
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=182699.1
!date
execute dbms_stats.unlock_schema_stats('SYS');
execute dbms_stats.unlock_schema_stats('SYSTEM');
exec dbms_stats.gather_schema_stats('SYSTEM',options=>'GATHER', estimate_percent => 100, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE); exec dbms_stats.gather_schema_stats('SYS',options=>'GATHER', estimate_percent => 100, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE); exec dbms_stats.gather_fixed_objects_stats();
commit;
exec dbms_stats.DELETE_TABLE_STATS('SYS','X$KCCRSR');
exec dbms_stats.LOCK_TABLE_STATS('SYS','X$KCCRSR');
commit;
Rman Backup is Very Slow selecting from V$RMAN_STATUS
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=375386.1
Poor performance when accessing V$RMAN_BACKUP_JOB_DETAILS
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=420200.1
Troubleshooting Oracle Applications Performance Issues
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=169935.1