AWS for SAP

Reducing downtime with Oracle XTTS method for cross-platform SAP migrations

Organizations running SAP applications with Oracle databases have many methods for migrating from one operating system to another. Customers looking to migrate their on-premises SAP applications with Oracle database to AWS, which are hosted on “big-endian” platforms have to re-platform to a “little-endian”. Since it is a heterogeneous migration, customers often choose SAP’s Classical Migration (R3load/Jload) method for this type of migration.

This may result in longer downtime, depending on the size of the source database and factors such as hardware and data transfer speed. This downtime can be reduced, often from days to hours using Oracle’s Cross Platform Transportable Tablespaces (XTTS) method with Incremental Merge . While this low downtime can also be achieved using Oracle Golden Gate, as mentioned here, this approach has significant licensing implications for using the Golden Gate software.

In this blog, we discuss how customers can use Oracle’s Cross Platform Transportable Tablespaces (XTTS) method for cross-platform SAP migrations to AWS and reduce their downtime during cutover.

Migration Overview:

XTTS stands for “Cross Platform Transportable Tablespace” where an endian conversion must happen before restoring on the target database. With this approach, there are two options:

  • Transport tablespaces using backup sets
  • Directly copy uncompressed data files

Since the migration is from on-premises to AWS, “Transport tablespaces using backup sets” is the recommended approach. This provides a typical compression ratio of 5:1. This extra step to create compressed backup sets usually reduces the data transfer time window.

Architecture diagram showing steps for migration.

Pre-migration phase:

  1. Prepare the AWS account (for example using AWS Control Tower or AWS Landing Zone) and establish connectivity to on-premises via AWS Direct Connect or S2S VPN
  2. Install the SAP application with the required Oracle DB version on the target AWS servers.
  3. Build a staging server on-premises (due to the source being big endian). This is a copy of the source system and is continuously in-sync with the source system. The staging server helps to reduce migration-related export operations on the production database. It can also reduce any business interruption of multiple test migration cycles. You can achieve this with Oracle Data Guard. This requires Data Guard license, which is typically included in Oracle databases purchased through SAP. Use the following steps:
    • Perform initial RMAN full database backup and copy the backup to a staging server to initialize the Data Guard database.
    • Keep the Data Guard database in the Log Apply state.
    • Data Guard requires NOLOGGING to be turned on in the source database, or NOLOGGING objects are not migrated and must be recreated manually after migration.
  4. Prepare a conversion script to perform an endian conversion on the target database. You may download a template from Oracle Support.
  5. XTTS does not move objects that reside in the SYSTEM or SYSAUX tablespaces of the source database. Metadata residing in the SYSTEM or SYSAUX tablespaces should be transferred using Data Pump.
  6. If user-owned Tables are residing in the SYSTEM or SYSAUX tablespaces, then move the identified objects to a user tablespace beforehand, so the objects can be transported by XTTS. Alternatively, you can move the objects separately with Data Pump or you can manually re-create the objects after performing the platform migration

Migration phase:

  • Pre-cutover activities:
  1. Perform an initial RMAN full database backup (on the staging database) to initialize the Data Guard database.
  2. Keep the Data Guard database in Log Apply state.
  3. Convert the full backup of the Data Guard database into a supported endian format.
    BACKUP
    FOR TRANSPORT
    FORMAT ‘<directory path and format for backup>’
    DATABASE;
  4. Transfer the backup to AWS using Amazon S3, Amazon EFS, or AWS DataSync.
  5. Restore on target (AWS) using the following command:
    RESTORE
    FROM PLATFORM ‘Solaris Operating System (x86-64)’
    FOREIGN DATABASE TO NEW
    FROM BACKUPSET ‘<Backup file path>’;
  6. Activate automated scripts that take regularly scheduled (depending on the changes in source system, either every 6 hours, daily or weekly) incremental backups and endian conversions of the Data Guard database, and then transfer these incremental backups to the target to keep the source and target DB continuously and automatically in-sync.
  • Cutover activities:
  1.  Make tablespaces in the Data Guard staging database READ ONLY.
  2. Take a final incremental backup.
    BACKUP
    FOR TRANSPORT
    FORMAT ‘<directory path and format for backup>’
    DATABASE;
  3. Transfer the backup to AWS using Amazon S3, Amazon EFS, or AWS DataSync.
  4. Convert the incremental backup and restore the database.
    RESTORE
    FROM PLATFORM ‘Solaris Operating System (x86-64)’
    FOREIGN DATABASE TO NEW
    FROM BACKUPSET ‘<Backup file path>’;
  5. Backup tablespace metadata and restore it on the target DB using the Data Pump export utility expdp/impdp.
  6. This completes the database related migration activities. The next steps include bringing the database up and performing SAP specific post-migration activities.

Conclusion

In this blog, we provide high-level steps on how to reduce downtime for cross platform SAP migrations by using Oracle XTTS method with Incremental Merge. The outage/downtime during cutover depends on various factors such as the size of the last incremental backup, the amount of metadata, and the network speed between your on-premise DC and AWS for data transfer.

Using the approach described, we were able to migrate our customer’s critical 16TB SAP workload from AIX/Oracle on-premises to OEL/Oracle on AWS within a 24 hour cutover window. One week prior to go-live, the target database was restored with a full backup of the source system. Leveraging a 1Gbps AWS Direct Connect, daily incremental backups were transferred to AWS. During cutover, the final incremental backup was restored in about 8 hours, which included the following steps: stopping source system, performing the final incremental backup, performing the endian conversion, transferring the data to AWS, and restoring the DB on the target database. This approach provided ample time for the business to conduct their cutover activities within the business cutover window.

As this is a complex process, involve an Oracle DBA if you are planning to use this approach for your migration. Reach out to us if you have any comments or questions – we value your feedback.