TL;DR
This blog outlines how an 80+ TB Oracle database was migrated from on-premises Exadata to AWS EC2 using RMAN and Oracle Data Guard, while managing the operational challenges introduced by Hybrid Columnar Compression (HCC). It covers the migration approach, HCC limitations on non-Exadata storage, post-migration decompression strategies, and the long-term operational considerations of running Oracle workloads on AWS.
Table of Contents
Why organisations are migrating Oracle Exadata workloads to AWS
Many organisations are moving away from Oracle Exadata to support broader cloud, cost optimisation, and modernisation strategies. Key drivers include reducing infrastructure and licensing costs, improving operational flexibility, enabling cloud-native integration, and adopting scalable consumption-based platforms such as AWS.
While Exadata provides strong performance and Oracle-specific optimisations such as HCC, many organisations are prioritising agility, resilience, and vendor flexibility over proprietary infrastructure.
Moving to AWS EC2 introduces operational trade-offs, but provides improved scalability, disaster recovery, and long-term cost efficiency.
This blog outlines how HCC-compressed data was successfully migrated from Exadata to a self-hosted Oracle database on AWS EC2, including approaches used to address these operational limitations.
The challenge with HCC on Non-Exadata storage
While HCC-compressed data can remain accessible after migration to AWS EC2 using ASM, EBS, or Amazon FSx for NetApp ONTAP, important limitations exist when performing DML operations, partition maintenance, table movement, and Active Data Guard activities because AWS storage does not provide native Exadata functionality.
As a result, operations on HCC-compressed objects can trigger errors such as:
ORA-64307: Hybrid Columnar Compression is only supported in tablespaces residing on Exadata, ZFSSA, or AXIOM storage.
These challenges become more significant in large enterprise databases where HCC is widely used for historical partitions and archive data.
Key migration planning considerations
Successful migration planning therefore requires careful assessment of:
- HCC-compressed tables, partitions, and subpartitions
- Storage growth after decompression or recompression
- Performance impact and maintenance considerations
- Active Data Guard
- Backup, recovery, and long-term operational supportability
A common approach is to retain compression for older historical data while moving active transactional data to standard Oracle compression formats better suited for cloud environments.
Real-World Migration Scenario
Recently, we completed the migration of an 80+ TB Oracle database from Exadata to a self-managed AWS EC2 platform. The primary complexity involved managing Exadata-specific HCC dependencies in a non-Exadata environment.
This article covers the real-world challenges and solutions around:
- RMAN-based migration from Exadata to AWS EC2
- HCC limitations on non-Exadata storage
- Active Data Guard restrictions
- Post-migration decompression strategies
- Oracle version-specific considerations
- Long-term operational supportability on AWS
Source and target architecture
Source Environment
| Target Environment
|
Migration options from Exadata to AWS EC2
There are several approaches available.
Method | Best For | Downtime | HCC Handling |
RMAN Backup/Restore | Large databases | Medium | Preserves HCC |
Oracle Data Pump | Logical migrations | Medium/High | Removes HCC |
AWS DMS | Continuous replication | Low | Converts data logically |
Data Guard | DR migrations | Low | HCC limitations apply |
Why RMAN was selected for migration
For large Oracle databases, RMAN is often the preferred migration method because it enables fast physical database movement while preserving the existing database structure and minimising downtime. This approach is especially effective for multi-terabyte environments where export/import methods can become complex and time-consuming.
However, when migrating Exadata databases that use Hybrid Columnar Compression (HCC), RMAN transfers the compressed HCC segments exactly as they exist on the source system. As a result, HCC objects remain compressed after migration to AWS EC2, and the same non-Exadata limitations around Active Data Guard, DML operations, and object maintenance still apply. Any required decompression must therefore be performed manually after migration.
Storage constraints on the source Exadata environment
In our case, the source Exadata environment had limited free storage, while much of the 80 TB database relied on HCC compression. Decompressing data before migration would have significantly increased storage usage and exceeded available capacity.
To address this, we used an RMAN-based migration approach that moved the database in its existing compressed state without altering source data structures. After the database was restored on AWS EC2, decompression and reorganisation activities were performed directly on the target environment, where cloud storage could be expanded incrementally to support phased maintenance and optimisation activities.
Storage growth after HCC decompression
While in EXADATA QUERY HIGH compression typically delivers up to a 10:1 reduction, The HCC decompression process took approximately 24 hours to complete. The largest HCC-compressed segment with QUERY HIGH compression was 12 TB on Exadata storage and expanded to nearly 70 TB after decompression on AWS EC2.
As part of the migration, several indexes were rebuilt and partitions reorganised to align with the AWS operating model, which temporarily increased storage consumption and contributed to the final cloud database footprint growing to approximately 140 TB after all decompression and optimisation activities.
The following steps outline the process to create a Data Guard environment in AWS and perform a failover to AWS with minimal downtime.
Creating an Oracle physical standby database from Exadata to AWS EC2 using RMAN and Data Guard
To migrate the large Oracle Exadata database to a self-managed AWS EC2 environment with minimal downtime, we used an RMAN-based physical standby approach combined with Oracle Data Guard Broker (DGMGRL). This approach allowed the database to be migrated in its existing HCC-compressed format without requiring decompression on the source Exadata platform.
The following sections outline the high-level implementation steps used during migration.
1. Prepare the primary database on Exadata
Before taking the RMAN backup, the source Exadata database must be validated and configured for Data Guard operations.
Enable Force Logging
ALTER DATABASE FORCE LOGGING;
Verify Database Role
SELECT NAME, DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;
Enable ARCHIVELOG Mode (If Not Already Enabled)
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
2. Create RMAN backup on Exadata
An RMAN full database backup was taken from the Exadata primary database while preserving the HCC-compressed segments.
RMAN Full Backup
rman target /
RUN {
BACKUP AS COMPRESSED BACKUPSET DATABASE FORMAT ‘/backup/full_%U.bkp’;
BACKUP CURRENT CONTROLFILE FORMAT ‘/backup/control_%U.bkp’;
SQL ‘ALTER SYSTEM ARCHIVE LOG CURRENT’;
BACKUP ARCHIVELOG ALL FORMAT ‘/backup/arch_%U.bkp’;
}
3. Transfer backup to AWS EC2
The RMAN backup pieces were securely transferred from the Exadata environment to AWS using AWS DataSync.
Transfer Method
- AWS DataSync
- NFS transfer
This ensured the backup files were available locally on the AWS EC2 database server for restore operations.
4. Prepare the AWS EC2 standby environment
The Oracle standby environment was prepared on AWS EC2 before restoring the database.
Create Oracle Password File
orapwd file=$ORACLE_HOME/dbs/orapwAWSDB password=Oracle123 entries=10
Start Database in NOMOUNT State
STARTUP NOMOUNT;
5. Restore the standby control file on AWS EC2
Once the environment was prepared, the standby controlfile was restored from the RMAN backup.
Connect RMAN
rman target /
Restore Standby Controlfile
RESTORE STANDBY CONTROLFILE
FROM ‘/backup/control_xxxxx.bkp’;
Mount the Standby Database
ALTER DATABASE MOUNT;
6. Restore and recover the database on AWS EC2
The database files were restored and recovered using RMAN.
Catalog Backup Files
CATALOG START WITH ‘/backup/’;
Restore and Recover Database
RUN {
RESTORE DATABASE;
RECOVER DATABASE;
}
At this stage, AWS EC2 was operating as a physical standby database.
7. Configure standby redo logs
Standby redo logs were added to support real-time redo apply.
Verify Existing Redo Log Size
SELECT GROUP#, BYTES/1024/1024 MB FROM V$LOG;
Add Standby Redo Logs
ALTER DATABASE ADD STANDBY LOGFILE GROUP 11 SIZE 4096M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 12 SIZE 4096M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 13 SIZE 4096M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 14 SIZE 4096M;
8. Configure Oracle Data Guard broker (DGMGRL)
After the standby database was restored successfully, Oracle Data Guard Broker (DGMGRL) was configured to simplify Data Guard management, monitoring, switchover, and failover operations.
9. Enable Data Guard broker on both databases
On Exadata Primary
ALTER SYSTEM SET DG_BROKER_START=TRUE SCOPE=BOTH;
On AWS EC2 Standby
ALTER SYSTEM SET DG_BROKER_START=TRUE SCOPE=BOTH;
10. Verify TNS connectivity
Both databases must be able to resolve each other using Oracle Net Services.
Example tnsnames.ora Configuration
EXADB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = exadata-host)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = EXADB)
)
)
AWSDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = aws-ec2-host)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = AWSDB)
)
)
Validate Connectivity
tnsping EXADB
tnsping AWSDB
11. Create Data Guard broker configuration
Connect Using DGMGRL
dgmgrl sys@EXADB
Create Broker Configuration
CREATE CONFIGURATION DGCONFIG
AS PRIMARY DATABASE IS EXADB
CONNECT IDENTIFIER IS EXADB;
12. Add AWS EC2 as physical standby
Add Standby Database
ADD DATABASE AWSDB
AS CONNECT IDENTIFIER IS AWSDB
MAINTAINED AS PHYSICAL;
Enable Configuration
ENABLE CONFIGURATION;
13. Validate Data Guard configuration
Show Configuration
SHOW CONFIGURATION;
Expected Output
Configuration – DGCONFIG
Protection Mode: MaxPerformance
Members:
EXADB – Primary database
AWSDB – Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
14. Validate database synchronisation
Check Database Status
SHOW DATABASE EXADB;
SHOW DATABASE AWSDB;
Validate Apply Lag
SHOW DATABASE AWSDB ‘ApplyLag’;
Validate Transport Lag
SHOW DATABASE AWSDB ‘TransportLag’;
15. Start managed recovery
If redo apply is not already active:
EDIT DATABASE AWSDB SET STATE=’APPLY-ON’;
16. Perform switchover to AWS EC2
After synchronisation was validated and the migration window began, the standby database on AWS EC2 was promoted to primary.
Execute Switchover
SWITCHOVER TO AWSDB;
17. Validate new primary database
Verify Configuration After Switchover
SHOW CONFIGURATION;
Expected Result
AWSDB – Primary database
EXADB – Physical standby database
18. Decommission the old Exadata database
After application validation and production signoff, the old Exadata database was removed from the Data Guard configuration.
Remove Exadata Database from Broker
REMOVE DATABASE EXADB;
Shutdown Old Exadata Database
SHUTDOWN IMMEDIATE;
Post-migration HCC decompression on AWS EC2
Following migration from Exadata to AWS EC2, organisations should assess several operational considerations beyond HCC decompression:
- Backup Strategy: Backup windows and storage consumption may increase after decompression due to larger data volumes and changes in incremental backup behaviour.
- Maintenance Activities: Operations such as table moves, partition maintenance, statistics gathering, and index rebuilds may take longer compared to Exadata-optimised environments.
- Query Performance: Some workloads may experience increased I/O and reduced query performance where HCC previously provided storage and scan efficiency benefits.
- Storage Consumption: Decompressing HCC objects can significantly increase database storage requirements on ASM, EBS, or FSx storage layers.
- Operational Ownership: Performance tuning, storage optimisation, and resilience management become more dependent on AWS infrastructure design and Oracle administration practices.
With the migration completed, the environment is now ready for post-migration decompression activities. The following SQL queries can be used to identify HCC-compressed objects and perform the required decompression to standard Oracle compression formats supported on AWS EC2.
Generating HCC conversion scripts
Move Partition Without Compression
Move Subpartition
| Generate PARTITION_NAME script using the following sql LOW’, ‘QUERY HIGH’, ‘ARCHIVE LOW’, ‘ARCHIVE HIGH’) and TABLE_NAME= ‘TABLE_NAME’ ORDER BY table_owner, table_name, SUBSTR(partition_name,2,4), partition_name;
Generate SUBPARTITION_NAME script using the following sql
select ‘ ALTER TABLE ‘ || TABLE_OWNER ||’.’|| TABLE_NAME || ‘ MOVE SUBPARTITION ‘ || SUBPARTITION_NAME || ‘ NOCOMPRESS parallel 16;’ NOCPM from dba_tab_subpartitions where compress_for IN ( ‘QUERY LOW’, ‘QUERY HIGH’, ‘ARCHIVE LOW’, ‘ARCHIVE HIGH’) and TABLE_NAME= ‘ TABLE_NAME’;
|
Rebuild Global Index Rebuild Partitioned Index
Rebuild SubPartitioned Index
| Generate list of invalid indexes using the following sql — 1. Normal indexes SELECT ‘ALTER INDEX “‘ || owner || ‘”.”‘ || index_name || ‘” REBUILD PARALLEL 32;’ AS rebuild_cmd FROM dba_indexes WHERE status NOT IN (‘VALID’,’USABLE’,’N/A’) AND partitioned = ‘NO’ AND owner = ‘owner’ UNION ALL — 2. Partitioned indexes SELECT ‘ALTER INDEX “‘ || index_owner || ‘”.”‘ || index_name || ‘” REBUILD PARTITION “‘ || partition_name || ‘” PARALLEL 32;’ AS rebuild_cmd FROM dba_ind_partitions WHERE status NOT IN (‘VALID’,’USABLE’,’N/A’) AND index_owner = ‘ owner ‘ UNION ALL — 3. Sub-partitioned indexes SELECT ‘ALTER INDEX “‘ || index_owner || ‘”.”‘ || index_name || ‘” REBUILD SUBPARTITION “‘ || subpartition_name || ‘” PARALLEL 32;’ AS rebuild_cmd FROM dba_ind_subpartitions WHERE status NOT IN (‘VALID’,’USABLE’,’N/A’) AND index_owner = ‘ owner ‘;
|
Check Compression
| SELECT owner, table_name, compression, compress_for |
Check Partition Compression
Check SubPartition Compression
| SELECT table_name, partition_name, compression
|
Key takeaways
- HCC is tightly coupled with Exadata storage
- AWS EC2 cannot fully support HCC behavior
- Active Data Guard cannot query HCC tables on third-party storage
- RMAN preserves HCC and requires post-migration decompression
- Data Pump and AWS DMS avoid HCC dependency through logical migration
- Oracle 11.2.0.1 BP4 fixed HCC MOVE decompression limitations
- ALTER TABLE MOVE NOCOMPRESS remains the standard remediation approach
Conclusion
Migrating Oracle databases from Exadata to AWS EC2 involves more than simply restoring backups into the cloud. Exadata-specific technologies such as HCC introduce operational constraints that directly impact Data Guard, standby accessibility, and post-cutover usability.
Choosing the correct migration strategy depends on:
- Database size
- Downtime tolerance
- HCC usage
- DR architecture
- Performance expectations
For large enterprise databases, RMAN combined with post-migration HCC decompression provides a reliable approach. For modernisation projects requiring logical transformation and minimal Exadata dependency, Data Pump or AWS DMS may be more appropriate.
Understanding these trade-offs is essential for a successful Exadata-to-AWS migration strategy.
Migrating Oracle Exadata workloads to AWS EC2, particularly where Hybrid Columnar Compression (HCC) and Data Guard are involved, requires a clear understanding of both the technical constraints and the operational trade-offs. If you’re planning an Oracle Exadata to AWS EC2 migration, you can explore more insights on our AWS migration approach and related cloud transformation work.
To understand how we help organisations modernise Oracle workloads, manage HCC limitations, and design scalable AWS-based database architectures, visit our site or get in touch with our team to discuss your migration strategy in detail.
Manish is a Senior Infrastructure and Cloud Migration Leader with 18+ years of experience delivering large-scale infrastructure modernisation, data centre exits, cloud transformation programs, and enterprise migrations across AWS, hybrid, and on-premises environments. Proven expertise in leading cross-functional teams across infrastructure, database, storage, networking, security, and application domains to successfully migrate mission-critical workloads from legacy platforms to AWS Cloud.
