Business Challenge Faced

Downtime for the Migration

Aliter Consulting were approached during the summer of 2016 to provide SAP OS/DB Migration Consultancy Services to help Capita Asset Services migrate their production SAP ECC system from ageing on-premise hardware to the Microsoft Azure public cloud.

The main challenge faced by the project team was the time taken to perform the migration – exporting the data out of their current production SAP ECC system and importing this data into the new Azure-based environment.

When Aliter Consulting were initially engaged, the end to end run time for the migration was circa 48 hours which was too tight for the downtime window agreed with the business including an allowance for contingency if problems occurred.

One of the problems restricting the SAP export was with the current hardware and the limited possibility to increase the CPU capacity of the server hosting the production SAP ECC system.

Another problem restricting the SAP export was the fact that the system was essentially running only SAP FI and the bulk of the data was contained in a small number of large tables.

Solution Found

An analysis of the CPU usage on the server hosting the production SAP ECC system during the export confirmed the thoughts that there was insufficient CPU in order to run sufficient R3LOAD processes in parallel. Additional CPU could only be added by “stealing” it from other servers sharing the hardware. This was recommended and was implemented.

An analysis of the statistics from the first iterative migration (export/import) was performed and it was determined that the export runtime could be reduced by using some or all of the following export tuning techniques:

  • Package Splitting
  • Table Splitting
  • Unload order of large tables
  • Number of parallel R3load processes
  • Unsorted unload
  • Oracle database settings

The import runtime could be reduced using some or all of the following import tuning techniques:

  • Early database creation
  • Load order of large tables
  • Number of parallel R3load processes
  • Oracle database settings

To reduce the time taken to export the production SAP ECC database the following main actions were taken:

  • Use table splitting techniques on the largest tables – table RFBLG alone was taking over 12 hours to export
  • Increase the number of parallel R3LOAD processes
  • Use package ordering to export the largest tables first

To reduce the time taken to import the production SAP ECC database the following main actions were taken:

  • Start the target database creation early – this was taking up to 5 hours
  • Increase the size of the Oracle PGA – this would help the index generation greatly
  • Increase the size of PSAPTEMP – this would also help the index generation if the PGA became exhausted
  • Increase the number of parallel R3LOAD processes – this would allow for more parallelism

With these tuning techniques implemented, the export time was reduced to under 8 hours and the import time was reduced to under 6 hours.

Benefits Gained

The tuning techniques and hence the massive reduction in the runtime of the actual SAP OS/DB migration proved to be very crucial for the live cutover to Azure.

Network challenges not previously envisaged meant that the data transfer of the export files from the on-premise hardware to the Azure platform would take over 20 hours. By fine tuning the export/import process, we were able to still fit the entire process into the agreed business downtime window with a small contingency.