OS/DB migration and upgrade to 7.31, how to minimise downtime

[Former Member]

Hi, we currently have a single production SAP PI that is handling most of the transactions from our non-SAP to our SAP environnement. Some of the transactions are interactive (requiring an instantaneous answer, others are async). We are now planning an OS/DB migration and afterwards an upgrade. The OS/DB will most likely take around 15 hours, the upgrade 30 hours. This downtime is by far exceeding what we are accustomed to.

In order to reduce this downtime we are looking at:

- Stopping the async requests during the downtime

- Making a copy of the existing production system and redirecting the interactive requests thru it or using a QA with the current version of PI and redirecting the interactive requests thru it

What other solutions were been used to reduce the overall downtime and what works best?

[Former Member · Accepted solution]

Hi Cyril,

In addition to what Hassen already mentioned above, there are some other options:

For the OS/DB Migration:

Run export and import in parallel (using Migration Monitor; see SAP Note 784118)

Determine the largest tables (typically n=50-200) via transaction DB02 and put them into separate packages

Distribute the R3load processes on multiple machines (using Distribution Monitor; see SAP Note 855772)

Parallelize processing of very large tables using table splitting (see SAP Note 952514)

Optimize settings of your database (SAP Note depending on your database)

Export the largest tables unsorted (see SAP Note 954268)

Create the indices for the largest tables in parallel (see SAP Note 954268; only available for Oracle databases).

For the Upgrade:

Downtime Minimized scenario (upgrade guide)

Extra hardware resources, temporary, especially after OS/DB Migration your hardware should be much better than the old environment (should be less than 30 hours).

Optimize settings for your database, check the note depending on your database.

Amount of R3trans process used during upgrade (parallel)

Amount of background processes higher

In general: Archiving prior to these activity will reduce your database size, if possible. Also delete all unnecessary tables, if possible (part of preparation of OS/DB Migration).

I hope this will help you.

Regards,

Andre

[Former Member]

Has the OS/DB migration proces been throughly optimized?

- table splitting of largest tables

- export oder

- sorted vs unsorted unload

- Adding additional servers into the migration process

What is the DB size of the system?