Select your cookie preferences

We use essential cookies and similar tools that are necessary to provide our site and services. We use performance cookies to collect anonymous statistics, so we can understand how customers use our site and make improvements. Essential cookies cannot be deactivated, but you can choose “Customize” or “Decline” to decline performance cookies.

If you agree, AWS and approved third parties will also use cookies to provide useful site features, remember your preferences, and display relevant content, including relevant advertising. To accept or decline all non-essential cookies, choose “Accept” or “Decline.” To make more detailed choices, choose “Customize.”

Migrating from Linux to Linux with near-zero downtime for Amazon RDS for Db2

Focus mode
Migrating from Linux to Linux with near-zero downtime for Amazon RDS for Db2 - Amazon Relational Database Service

With this migration approach, you migrate a Linux-based Db2 database from one self-managed Db2 database (source) to Amazon RDS for Db2. This approach results in minimal to no outage or downtime for the application or users. This approach backs up your database and restores it with log replay, which helps prevent disruptions to ongoing operations and provides high availability of your database.

To achieve near-zero downtime migration, RDS for Db2 implements restore with log replay. This approach takes a backup of your self-managed Linux-based Db2 database and restores it on the RDS for Db2 server. With Amazon RDS stored procedures, you then apply subsequent transaction logs to bring the database up to date.

Limitations and recommendations for near-zero downtime migration

The following limitations and recommendations apply to using near-zero downtime migration:

  • Amazon RDS requires an online backup for near-zero downtime migration. This is because Amazon RDS keeps your database in a rollforward pending state as you upload your archived transaction logs. For more information, see Migrating your Db2 database.

  • You can't restore from an Amazon S3 bucket in an AWS Region that is different from the Region where your RDS for Db2 DB instance is located.

  • Amazon S3 limits the size of files uploaded to an S3 bucket to 5 TB. If your database backup file exceeds 5 TB, then split the backup file into smaller files.

  • Amazon RDS doesn't support non-fenced external routines, incremental restores, or Delta restores.

  • You can't restore from an encrypted source database, but you can restore to an encrypted Amazon RDS DB instance.

When you restore your database, Amazon RDS copies your backup and then extracts it on your RDS for Db2 DB instance. We recommend that you provision storage space for your RDS for Db2 DB instance that is equal to or greater than the sum of the backup size plus the original database's size on disk.

The maximum size of the restored database is the maximum database size that is supported minus the size of the backup. For example, if the maximum database size that is supported is 64 TiB and the size of the backup is 30 TiB, then the maximum size of the restored database is 34 TiB.

64 TiB - 30 TiB = 34 TiB

Backing up your database to Amazon S3

To back up your database on Amazon S3, you need the following AWS components:

  • An Amazon S3 bucket to store your backup files: Upload any backup files that you want to migrate to Amazon RDS. Amazon RDS requires an online backup for near-zero downtime migration. If you already have an S3 bucket, you can use that bucket. If you don't have an S3 bucket, see Creating a bucket in the Amazon S3 User Guide.

    Note

    If your database is large and would take a long time to transfer to an S3 bucket, you can order an AWS Snow Family device and ask AWS to perform the backup. After you copy your files to the device and return it to the Snow Family team, the team transfers your backed-up images to your S3 bucket. For more information, see the AWS Snow Family documentation.

  • An IAM role to access the S3 bucket: If you already have an AWS Identity and Access Management (IAM) role, you can use that role. If you don't have a role, see Step 2: Create an IAM role and attach your IAM policy.

  • An IAM policy with trust relationships and permissions attached to your IAM role: For more information, see Step 1: Create an IAM policy.

  • The IAM role added to your RDS for Db2 DB instance: For more information, see Step 3: Add your IAM role to your RDS for Db2 DB instance.

Creating a default automatic storage group

Your source database must have a default automatic storage group. If your database doesn't have a default automatic storage group, you must create one.

To create a default automatic storage group
  1. Connect to your source database. In the following example, replace source_database with the name of your database.

    db2 connect to source_database
  2. Create an automatic storage group and set it as the default. In the following example, replace storage_path with the absolute path to where the storage group is located.

    db2 "create stogroup IBMSTOGROUP ON storage_path set as default"
  3. Terminate backend processes.

    db2 terminate

Migrating your Db2 database

After you back up your database on Amazon S3 and create an automatic storage group, you are ready to migrate your Db2 database to your RDS for Db2 DB instance.

To perform a near-zero downtime migration
  1. Perform an online backup of your source database. For more information, see BACKUP DATABASE command in the IBM Db2 documentation.

  2. Copy the backup of your database to an Amazon S3 bucket. For information about using Amazon S3, see the Amazon Simple Storage Service User Guide.

  3. Connect to the rdsadmin server with the master_username and master_password for your RDS for Db2 DB instance.

    db2 connect to rdsadmin user master_username using master_password
  4. (Optional) To make sure your database is configured with the optimal settings for the restore operation, you can call rdsadmin.show_configuration to check the values for RESTORE_DATABASE_PARALLELISM and RESTORE_DATABASE_NUM_BUFFERS. Call rdsadmin.set_configuration to change these values, as needed. Explicitly setting these values can improve the performance when restoring databases with large volumes of data.

  5. Restore the backup on the RDS for Db2 server by calling rdsadmin.restore_database. Set backup_type to ONLINE. For more information, see rdsadmin.restore_database.

  6. Copy your archive logs from your source server to your S3 bucket. For more information, see Archive logging in the IBM Db2 documentation.

  7. Apply archive logs as many times as needed by calling rdsadmin.rollforward_database. Set complete_rollforward to FALSE to keep the database in a ROLL-FORWARD PENDING state. For more information, see rdsadmin.rollforward_database.

  8. After you apply all of the archive logs, bring the database online by calling rdsadmin.complete_rollforward. For more information, see rdsadmin.complete_rollforward.

  9. Switch application connections to the RDS for Db2 server by either updating your application endpoints for the database or by updating the DNS endpoints to redirect traffic to the RDS for Db2 server. You can also use the Db2 automatic client reroute feature on your self-managed Db2 database with the RDS for Db2 database endpoint. For more information, see Automatic client reroute description and setup in the IBM Db2 documentation.

  10. (Optional) Shut down your source database.

PrivacySite termsCookie preferences
© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved.