Primary checks on performance issues during upgrades using Oracle Databases

A lot of factors can affect the performance of an upgrade, like the table contents, DB size, tp and R3trans versions and so on.

The first check is to make sure that the latest versions of tp and R3trans are in use.

There are some phases like PARCONV_UPG, XPRAS_UPG and SHADOW_IMPORT that are phases of high database usage.

These phases perform different actions on the DB so it is important to rule out slow DB accesses to the DB initially.

On the other side, the reason could also be that many very big tables were handled, and therefore the tunning should be more focused on the applications analysis, archiving and other DB-realted tasks.

Make sure to check the following SAP notes, which deal with Oracle peformance:

• 354080 – Note collection for Oracle performance problems
• 618868 – FAQ: Oracle Performance
• 771929 – FAQ: Index fragmentation
• 588668 – FAQ: Database statistics
• 1171650 – Automated Oracle DB parameter check

   Regarding SAP software performance, these are the notes that can be checked in order to pinpoint and solve most of such issues:

• 1127194 – R3trans import with parallel processes;
• 1223360 – Composite SAP Note: Performance optimization during import;
• 983548 – Long runtimes during SAP Upgrade using Oracle 10;
• 744343 – Tips for importing Support Packages with minimized downtime;
• 558197 – upgrade hangs in PARCONV_UPG, XPRAS_UPG, SHADOW_IMPORT_UPG2
• 589124 – Performance improvements when Support Package imported;
• 132536 – Improved semaphore mechanism in tp;
• 1616401 – Understanding the R3trans parallel import mechanism

Some other points to consider related to upgrade peformance issues:

1. If the location of the datafiles (upgrade directory) is a local directory or a mounted remote directory. For a remote directory the connection speed to it is important;
2. Even if the upgrade directory is local, network layer is used and thus network configuration is important. A typical difference between production and test systems can be that production is often high availability and thus can use e.g. virtual hostnames or other methods. Maybe the network setup is then different to non-production systems;
3. Also hardware issues, e.g. if the database or the upgrade directory are on fast disks and if caches are used are important;
4. If the database is on the host where SAPup and R3trans run or on a different host might influence the speed but even a local database access uses network layer and thus network configuration for the database host is also an issue.

If you have any other doubt make sure to check the SCN community of Software Logistics (http://scn.sap.com/community/it-management/alm/software-logistics/).