Migrate to Exadata Database

1. From the AWS console, navigate to Storage Gateway.
2. Select the Create gateway button.
3. In the Set up gateway section, enter the following information.
   1. Enter a descriptive name in the Gateway name field. The name must be between 2 and 255 characters and cannot include a slash (\ or /).
   2. From the dropdown list, select the Gateway time zone. Choose the local time zone based on where you want to create your gateway.
   3. From the Gateway options section, choose the Amazon S3 File Gateway option.
   4. From the Platform options section, choose the Amazon EC2 as the host platform.
   5. Choose the Use default settings if you want to create an EC2 instance with default settings. Alternatively, you can click on Customize your settings to select the EC2 instance size and shape .
   6. From the dropdown list, select the Virtual private cloud (VPC) network.
   7. From the dropdown list, select the VPC subnet.
   8. From the Key pair dropdown list, select the existing key pair. If you do not have an existing one, select the Create new key pair link to create one.
   9. Select the Launch instance button to launch the EC2 instance with default settings. If you select the Customize your settings option, the instance will be launched in EC2 instance console.
   10. Select the Next button to proceed.
   
4. In the Connect to AWS section, enter the following information.
   1. From the Connection options section, choose the IP address option.
   2. The IP address automatically populates from the previous step where you created an EC2 instance.
   3. From the Service endpoint section, choose either the Publicly accessible option or VPC hosted option.
   4. Select the Next button to continue the creation process or select the Previous button to go back.
   
5. In the Activate gateway section, enter the following information.
   1. Review the Gateway details and Connection details, and then click on the Activate gateway button to continue the creation process or select the Previous button to go back.
   
6. In the Configure gateway section, enter the following information.
   1. From the Configure cache storage section, allocate one or more disks.
   2. From the CloudWatch log group section, choose either the Create a new log group option or the Use an existing group option. The Deactivate logging option is not recommended.
   3. From the CloudWatch alarms section, choose the Create Storage Gateway's recommended alarms option.
   4. Based on your requirements, you can add Tags by selecting the Add new tag button.
   5. Select the Configure button.
   
7. Once your gateway is created, the status will change to Running.

1. From the AWS console, navigate to Storage Gateway.
2. From the Storage resources section, select File shares.
3. Select the Create file share button, and then complete the following substeps.
   1. From the Create file share page, select the Gateway that you created previously.
   2. From the File share protocol section, choose the NFS option.
   3. From the S3 bucket dropdown list, select your existing S3 bucket. If you do not have one, you can create one by clicking the Create a new S3 bucket button.
   4. Select the Create file share button.
   

1. Use the following bash commands in the database EC2 instance and mount the Amazon S3 bucket as NFS mount points. The NFS parameters used are specific to Oracle Database and RMAN.
2. Create a directory with the required mount name. For example, the s3_mount directory was created.
3. Run the following command.

   mount -t nfs -o nolock,hard [ip-address]:/demo19c-backup /s3_mount/

You can use the NFS file share that is mounted on the database server to take backups on either using Oracle Data Pump or RMAN. For this example, RMAN is being used.

Oracle Recovery Manager provides a robust utility for backing up Oracle Databases. When storing backups in Amazon S3, ensure that the db_recovery_file_dest parameter is set to the NFS mount point established in previous steps. Additionally, to enforce a strict storage limit, define the db_recovery_file_dest_size parameter, which controls the maximum space allocated for files within the recovery destination. For more information about RMAN backup types and best practices, see RMAN basic concepts.

1. Set the parameter db_recovery_file_dest to point the NFS share mounted in the previous steps, and define the db_recovery_file_dest_size by using the following command.

   alter system set db_recovery_file_dest='' scope=both;
   alter system set db_recovery_file_dest_size='<size limit for nfs share mount point>' scope=both;

2. This is an example output after setting up the parameters db_recovery_file_dest and db_recovery_file_dest_size.

   alter system set db_recovery_file_dest='/s3_mount' scope=both;
   alter system set db_recovery_file_dest_size='1000G' scope=both;

3. Run RMAN backup on the database server using the following command:

    rman target /
   RMAN> RUN
    {
    CONFIGURE DEFAULT DEVICE TYPE TO DISK;
    CONFIGURE DEVICE TYPE DISK PARALLELISM 3;
    BACKUP DATABASE PLUS ARCHIVELOG;
    }

For Oracle Database backups utilizing parallel processing via RMAN or Data Pump, configuring multiple cached disks in Amazon S3 File Gateway significantly improves performance. Instead of relying on a single disk, distributing the workload across multiple cache disks enhances throughput by leveraging parallelism, optimizing storage efficiency and backup speed.

All the backup files are uploaded into Amazon S3 in the background as the Storage Gateway writes the files to the shares. Transport Layer Security encryption protects the data while in transit and Content-MD5 headers are used for data integrity.

Depending on the backup file size and network bandwidth between your Amazon S3 File Gateway and AWS, the backup file can take time to transfer from the local cache of Amazon S3 File Gateway to Amazon S3 bucket. You can use CloudWatch metrics to monitor the traffic.

1. Follow the steps from above to create a Amazon S3 File Gateway in the AWS VPC which is peered to the Exadata Database using ODB peering.
2. When you create the file share make sure you are using the same Amazon S3 bucket that you have used for the RMAN backups.

1. Enter the following bash commands in the database EC2 instance and mount the Amazon S3 bucket as NFS mount points. The NFS parameters used are specific to Oracle Database and RMAN.
2. Create a directory with the required mount name in this case we created the s3_mount/target directory.

   mount -t nfs -o nolock,hard [ip-address]:/demo19c-backup /s3_mount/target

3. After the NFS is mounted, the RMAN backup will be available on target Exadata Database since they are both using the same Amazon S3 bucket.

Using RMAN restore, databases can be restored on the same server or different server. RMAN backups can be used for disaster recovery scenarios across different regions in AWS as well.

1. Use the following command to complete the restore on Exadata Database:

   rman target /
   RMAN> CATALOG START WITH '/s3_mount/target' NOPROMPT;
   RMAN> run { 
   CONFIGURE DEFAULT DEVICE TYPE TO DISK;
   CONFIGURE DEVICE TYPE DISK PARALLELISM 3;
   RESTORE DATABASE;
   RECOVER DATABASE;
   alter database open;
   }

1. Run the validation steps to ensure the RMAN restore completed successfully.

   Table 1-2 Validation Commands

   Check Area	Command	Expected Result
   RMAN Log	-	No errors, restore complete
   DB Status	select status from v$instance;	OPEN
   Datafiles	select * from v$datafile;	All ONLINE
   Tablespaces	select * from dba_tablespaces;	All ONLINE
   Alert Log	Tail the alert log	Opened successfully
   Application Data	select count(*) from known tables	Returns rows

1. From the AWS console, navigate to Elastic File System.
2. Select the Create file system button.
3. In the Create file system section, enter the following information.
   1. The Name field is optional. If you want, you can enter a descriptive name for your file system. The name must include letters, numbers, and +-=._:/ symbols and it can up to 256 characters.
   2. From the Virtual Private Cloud (VPC) section, choose the VPC where you want EC2 instances to connect to your file system.
   3. From the Recommended settings section, review the settings. If you want to change the default settings, click on the Customize button and make required changes.
   4. Select the Create file system button to create a file system.
   
4. Configure mount targets within the same VPC as your Oracle Database.
5. Select the previously created file system, and then select the Attach button which provides you the sample commands to attach the EFS to the database server.
   1. From the Attach page, select the Mount via IP option.
   2. From the dropdown list, select the Availability zone.
   3. Copy the commands located under the Using the NFS client section.
   

1. Create a directory on the database server.

   [oracle@vm-q9rk11 backup]$ mkdir -p /home/oracle/backup/efs_backup

2. Use the following command to mount EFS on an EC2 instance running Oracle:


   [root@vm-q9rk11 ~]# sudo mount -t nfs4 -o nfsvers=4.1, rsize=1048576, wsize=1048576, hard,
         timeo=600, retrans=2,noresvport \ >10.0.0.4:
       /home/oracle/backup/efs_backup

3. Verify that RMAN backups are stored on EFS.

   df -k

   
4. You can use Oracle Data Pump export / import or RMAN, or any other backup and restore method to migrate where EFS can be used as a staging area for the files. In this example, the RMAN option is used as the migration tool.
   1. RMAN Backups: Use EFS as a backup staging area before transferring data to Exadata Database.

A key advantage of using Amazon Elastic File System for Oracle Recovery Manager backups is its ability to provide a shared, highly available storage layer between the on-premises Oracle environment and the Exadata system. This eliminates the need for complex data movement processes.

1. Configure RMAN to store backups on EFS.

   CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
         '/home/oracle/backup/efs_backup/rman_backup_%U';

2. Run RMAN backup for container database ORCLPDB1.
3. Verify RMAN backups are stored on EFS.


[opc@vm-q9rk11 ~]$ sudo mount -t nfs4 -o nfsvers=4.1, rsize=1048576, wsize=1048576, hard,
      timeo-600, retrans=2,noresvport \
    >10.0.0.4://home/oracle/backup/efs_backup

$ rman target=/
RUN {
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/home/oracle/backup/efs_backup/rman_backup_%U';
  ALTER PLUGGABLE DATABASE orclpdb1 CLOSE;
  RESTORE PLUGGABLE DATABASE orclpdb1;
  RECOVER PLUGGABLE DATABASE orclpdb1;
  ALTER PLUGGABLE DATABASE orclpdb1 OPEN;
}
 

1. Enable the required features as SYS.

   
   ALTER DATABASE FORCE LOGGING;
   ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(<primary_unique_name>,<standby_unique_name>)' SCOPE=BOTH;
   ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO SCOPE=BOTH;

2. Add standby redo logs (for example, for 3 online groups, add 4 standby groups).

   ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 4 ('/u01/oradata/standby_redo04.log') SIZE 100M;
   -- Repeat for additional groups.

3. Create a backup of the primary database using RMAN (include archivelogs for synchronization).

   CONNECT TARGET / BACKUP DATABASE FORMAT '/backup/db_%U' PLUS ARCHIVELOG FORMAT
         '/backup/arc_%U'; BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT
         '/backup/standby_ctl.ctl';

4. Copy the backup files, password file (orapw<sid>), and parameter file (init.ora or spfile) to the target server.

1. Install Oracle software (use the same version or a higher version for upgrade).
2. Create the necessary directories.

   mkdir -p /u01/oradata/<db_name>mkdir -p /u01/fra/<DB_UNIQUE_NAME_upper>mkdir -p /u01/app/oracle/admin/<db_name>/adump

3. Edit the copied parameter file on standby database server.
   • Set DB_UNIQUE_NAME to the standby value.
   • Set FAL_SERVER to the primary TNS name.
   • Adjust paths if needed. For example, CONTROL_FILES, DB_RECOVERY_FILE_DEST.
4. Start the standby instance in NOMOUNT mode.

   CREATE SPFILE FROM PFILE='/path/to/init.ora';STARTUP NOMOUNT;

1. Use RMAN to duplicate the database from the active database.

   CONNECT TARGET sys/<password>@primary_tns CONNECT AUXILIARY sys/<password>@standby_tns
             DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE DORECOVER
             NOFILENAMECHECK;

   Alternative: If you use backup files, duplicate the database for standby from a backup location.

   DUPLICATE DATABASE FOR STANDBY BACKUP LOCATION '/backup'
       NOFILENAMECHECK;

2. On standby, start managed recovery.

   ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

1. On primary, set remote logging.

   ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=<standby_tns> ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=<standby_unique_name>' SCOPE=BOTH;ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;ALTER SYSTEM SET FAL_SERVER='<standby_tns>' SCOPE=BOTH;

2. On standby.

   ALTER SYSTEM SET FAL_SERVER='<primary_tns>' SCOPE=BOTH;

3. (Optional) Enable Data Guard Broker for easier management.
   • Set DG_BROKER_START=TRUE on both.
   • Create configuration.

     DGMGRL> CREATE CONFIGURATION dg_config AS PRIMARY DATABASE IS <primary_unique_name> CONNECT IDENTIFIER IS <primary_tns>;

   • Add standby.

     DGMGRL> ADD DATABASE <standby_unique_name> AS CONNECT IDENTIFIER IS <standby_tns>;

   • Enable the configuration.

     DGMGRL> ENABLE CONFIGURATION;

1. On primary, force log switches.

   ALTER SYSTEM SWITCH LOGFILE;

2. On standby, check apply status.

   SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM v$managed_standby;

   Look for MRP0 applying logs.

3. Check for gaps.

   SELECT * FROM v$archive_gap;

   Should return no rows.

4. Monitor lag.

   SELECT NAME, VALUE FROM v$dataguard_stats WHERE NAME = 'apply lag';

Allow time for full sync before migration.

1. Stop applications connected to primary (minimal downtime starts here).
2. Verify no gaps and stop recovery on standby.

   ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

3. Using Broker (recommended).

   DGMGRL> SWITCHOVER TO <standby_unique_name>;

   • Manual alternative.
     • On primary:

       ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;

     • On old primary (now standby):

       STARTUP MOUNT; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

     • On new primary (old standby):

       ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL PRIMARY WITH SESSION SHUTDOWN; ALTER DATABASE OPEN;

4. Verify roles. New primary should be PRIMARY.

   SELECT DATABASE_ROLE FROM v$database;

5. Redirect applications to new primary.
6. (Optional) Decommission old primary or keep as new standby.