Enterprises running Oracle databases on VMware want a path to AWS that preserves their existing operational workflows with no rearchitecting and retraining. In our companion post, Architect highly available Oracle Database on Amazon EVS and FSx for ONTAP, we explained how to design that environment: selecting EC2 bare metal instances, sizing VMs, splitting storage between vSAN and FSx for NetApp ONTAP, and planning SnapMirror replication for cross-region DR.

This post picks up where the architecture left off. We provide step-by-step procedures to deploy the entire stack — from provisioning your first Oracle VM and creating FSx for ONTAP volumes, through mounting NFS datastores, installing Oracle 19c, and configuring SnapMirror and SnapCenter. We also cover four migration paths for moving existing on-premises Oracle workloads to EVS and day-2 operations including snapshot backup, point-in-time recovery, and database cloning.

For architecture decisions, instance type selection, storage design rationale, and high availability planning, see our companion post: Architect highly available Oracle Database on Amazon EVS and FSx for ONTAP.

Step-by-step deployment procedures

This section walks through the end-to-end deployment workflow: provisioning the Oracle VM, creating FSx for ONTAP storage volumes, mounting NFS datastores in vSphere, installing Oracle 19c, and configuring SnapMirror for cross-region DR. Complete the prerequisites first, then follow Steps 1 through 8 in order.

Prerequisites

• Amazon EVS environment deployed (VCF 5.2.2, ESXi 8.0U3g)
• Minimum 4 hosts per cluster; dedicated DB cluster recommended for Oracle
• VPC with Route Server endpoints, Transit Gateway, and Direct Connect configured
• IAM permissions for FSx for ONTAP provisioning
• VCF license entitlement (BYOL from Broadcom)

Step 1: Deploy Oracle VM on EVS

1. Log into the vSphere Client connected to your EVS vCenter.
2. Create a new Virtual Machine in the Production DB Cluster:
   • Guest OS: Red Hat Enterprise Linux 8 (64-bit) or Oracle Linux 8
   • vCPU: Size per Oracle workload (8–32 vCPU typical)
   • Memory: 32–256 GiB based on SGA/PGA requirements
   • Disk: 100 GiB on vSAN datastore (OS + Oracle Home + swap + temp tablespace)
   • Network: Attach to DB segment on the prod-trusted Tier-1 gateway
3. Power on the VM and configure the guest OS:

# Set hostname
hostnamectl set-hostname ora-db1

# Create swap on vSAN-backed disk (local NVMe, single-digit ms latency)
# The vSAN datastore is already available as the VM's primary disk
# Allocate a dedicated partition or LV for swap
lvcreate -L 16G -n swap vgos
mkswap /dev/vgos/swap
swapon /dev/vgos/swap
echo "/dev/vgos/swap swap swap defaults 0 0" >> /etc/fstab

# Install Oracle prerequisites
sudo yum install -y oracle-database-preinstall-19c python3

For HA/DR, consider replicating the entire Oracle VM rather than maintaining a separate licensed instance in the DR cluster (see DR Licensing Consideration in the architecture post).

Oracle licensing consideration: Instance type selection affects Oracle license cost, which is an important factor to take into consideration. We recommend requesting an AWS Optimization and Licensing Assessment (AWS OLA) for further guidelines.

Step 2: Provision FSx for NetApp ONTAP

1. Open the Amazon FSx console, select Create file system, then select Amazon FSx for NetApp ONTAP.
2. Select Standard create and configure:

3. Set the fsxadmin password (required for ONTAP CLI automation).
4. Create an SVM (Storage Virtual Machine) with vsadmin password.
5. Disable automatic daily backups. Use SnapCenter for Oracle-aware scheduling instead.
6. After creation, select SVM, select Endpoints, and copy the NFS DNS name.

Step 3: Create Oracle Database Volumes

Connect to the FSx for ONTAP cluster using SSH (ssh fsxadmin@management-endpoint) and create volumes:

# Oracle binary volume
vol create -volume oradb1bin -aggregate aggr1 -size 50G \
  -state online -policy default -tiering-policy none \
  -junction-path /oradb1bin

# Oracle data volume
vol create -volume oradb1data -aggregate aggr1 -size 500G \
  -state online -policy default -tiering-policy none \
  -junction-path /oradb1data

# Oracle log volume (redo + archive)
vol create -volume oradb1log -aggregate aggr1 -size 250G \
  -state online -policy default -tiering-policy none \
  -junction-path /oradb1log

Set -tiering-policy none to pin all data to SSD tier. Size the log volume for 24 hours of archive logs.

Step 4: Mount FSx for ONTAP as NFS Datastore in vSphere

1. In vSphere Client, select the DB Cluster, then select Configure > Storage > New Datastore.
2. Select NFS, then select NFS 3.
3. Enter:
   • Server: svm-id.fs-id.fsx.region.amazonaws.com
   • Folder: /oradb1data
   • Datastore name: fsx-ora-db1-data
4. Repeat for binary (/oradb1bin) and log (/oradb1log) volumes.
5. Verify all three datastores show correct capacity in the cluster storage view.

Step 5: Create Oracle VMDKs on FSx for ONTAP Datastores

With the NFS datastores mounted at the ESXi host level (Step 4), create virtual disks for Oracle on these datastores:

1. In vSphere Client, select the Oracle VM, select Edit Settings, then select Add New Device > Hard Disk.
2. Create these VMDKs:

3. Select Thick Provision, Eager Zeroed for data and log VMDKs (best Oracle performance).

Oracle Database can be created on Oracle ASM or Filesystem (local/NFS). This installation is based on creating the Oracle database on local XFS filesystem.

Inside the Oracle VM guest OS, partition and mount the new disks:

# Identify new disks
lsblk

# Create filesystem on each disk (example: /dev/sdb for data)
mkfs.xfs /dev/sdb
mkfs.xfs /dev/sdc
mkfs.xfs /dev/sdd

# Create mount points
mkdir -p /u01 /u02 /u03

# Mount
mount /dev/sdd /u01   # Oracle Home (binaries)
mount /dev/sdb /u02   # Oracle data files
mount /dev/sdc /u03   # Oracle redo + archive logs

# Persist in /etc/fstab
cat >> /etc/fstab <<EOF
/dev/sdb /u02 xfs defaults,noatime 0 0
/dev/sdc /u03 xfs defaults,noatime 0 0
/dev/sdd /u01 xfs defaults,noatime 0 0
EOF

# Set ownership
chown -R oracle:oinstall /u01 /u02 /u03

Key insight: The Oracle VM accesses /u02 and /u03 as local XFS block devices. It has no awareness that the underlying storage is an NFS datastore backed by FSx for ONTAP. All NFS communication happens at the ESXi host level, where each host uses its own network path to FSx for ONTAP.

Step 6: Install and Configure Oracle 19c

# As oracle user
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
cd $ORACLE_HOME
./runInstaller -silent -responseFile /path/to/db_install.rsp

Create the database with data on /u02 and logs on /u03:

CREATE DATABASE orcl
  DATAFILE '/u02/oradata/orcl/system01.dbf' SIZE 1G
  LOGFILE
    GROUP 1 '/u03/oralogs/orcl/redo01.log' SIZE 512M,
    GROUP 2 '/u03/oralogs/orcl/redo02.log' SIZE 512M,
    GROUP 3 '/u03/oralogs/orcl/redo03.log' SIZE 512M;

Oracle accesses /u02 and /u03 as local XFS filesystems. Standard Oracle ASM or filesystem-based storage management applies. No NFS-specific Oracle configuration is needed because the NFS layer is abstracted by the ESXi hypervisor.

Step 7: Set Up SnapMirror for Cross-Region DR

Peer clusters (production → DR):

cluster peer create -peer-addrs <dr-cluster-intercluster-ip> \
  -username fsxadmin -initial-allowed-vserver-peers *

Peer SVMs:

vserver peer create -vserver svm-prod -peer-vserver svm-dr \
  -peer-cluster FSxDR -applications snapmirror

Create DP volumes on DR FSx for ONTAP:

vol create -volume oradb1bin -aggregate aggr1 -size 50G -state online -type DP
vol create -volume oradb1data -aggregate aggr1 -size 500G -state online -type DP
vol create -volume oradb1log -aggregate aggr1 -size 250G -state online -type DP

Create and initialize SnapMirror:

snapmirror create -source-path svm-prod:oradb1data \
  -destination-path svm-dr:oradb1data -throttle unlimited \
  -policy MirrorAllSnapshots -type DP

snapmirror create -source-path svm-prod:oradb1log \
  -destination-path svm-dr:oradb1log -throttle unlimited \
  -policy MirrorAllSnapshots -type DP

snapmirror create -source-path svm-prod:oradb1bin \
  -destination-path svm-dr:oradb1bin -throttle unlimited \
  -policy MirrorAllSnapshots -type DP

# Initialize
snapmirror initialize -destination-path svm-dr:oradb1data
snapmirror initialize -destination-path svm-dr:oradb1log
snapmirror initialize -destination-path svm-dr:oradb1bin

Important: To comply with the Oracle licensing laws, an alternative is to replicate the Oracle VM through NetApp SnapMirror from Production to DR. Keep the DR replicated volumes as data-protection (DP) volumes that are NOT mounted as NFS datastores on DR hosts until a failover event is declared to avoid Oracle double licensing. Only then break the SnapMirror, mount the NFS datastore on the DR Host, and power on the VM. Pre-mounting the SnapMirror volume as a datastore , even with no VM powered on means Oracle binaries are accessible on those hosts, which Oracle may consider an “installation” requiring licenses across the entire DR cluster. We recommend requesting an AWS Optimization and Licensing Assessment (AWS OLA) for further guidelines.

Step 8: Configure SnapCenter Backup

1. Deploy SnapCenter Server (or use SnapCenter SaaS).
2. Add FSx for ONTAP storage system using the cluster management IP.
3. Install SnapCenter Plugin for Oracle on each Oracle VM.
4. Create backup policies:

5. Create resource groups, assign policies, and schedule.

Database migration from on-premises VMware to EVS

Option 1: VMware HCX Live Migration

For enterprises with existing VMware on-premises:

1. Deploy HCX Connector on-premises, HCX Cloud Manager on EVS.
2. Create site pairing and network extensions (L2 stretch).
3. Migrate Oracle VMs using HCX vMotion (zero downtime) or Bulk Migration.
4. Post-migration: storage vMotion Oracle VMDKs from vSAN to FSx for ONTAP NFS datastores for snapshot/replication capabilities.

Option 2: SnapMirror ONTAP-to-ONTAP

If on-premises Oracle already uses NetApp ONTAP storage:

1. Establish SnapMirror between on-prem ONTAP and AWS FSx for ONTAP.
2. Incrementally replicate until cutover.
3. At switchover: quiesce Oracle, flush archive logs, final SnapMirror sync, break mirror.
4. Mount FSx for ONTAP volumes on EVS Oracle VM, recover database, open for service.

Option 3: Oracle PDB Relocation (Multitenant)

For Oracle databases already in PDB/CDB multitenant model:

1. Create target CDB on EVS with FSx for ONTAP storage.
2. Use PDB hot clone to relocate PDBs from on-premises CDB to AWS CDB.
3. Minimal service interruption. Only final switchover requires brief outage.

Option 4: RMAN Backup/Restore (Non-ONTAP On-Prem)

If Oracle runs on non-ONTAP storage on-premises:

1. Create RMAN backup, stage to Amazon S3 using AWS DataSync or Direct Connect.
2. Provision Oracle VM on EVS, mount FSx for ONTAP volumes.
3. Restore from RMAN backup, apply archive logs.
4. Open database and redirect applications.

Day-2 operations

Snapshot backup

Full database snapshots complete in seconds regardless of database size. This is a storage-layer operation managed by SnapCenter.

Point-in-time recovery

In SnapCenter, select the SCN or timestamp, mount the log snapshot, restore the data snapshot, apply archive logs, and open with RESETLOGS.

Database cloning

SnapCenter FlexClone creates space-efficient database copies in minutes. Clones share unchanged blocks with the source and consume storage only for deltas. Use for dev/test, patch validation, and reporting.

HA failover procedure

1. Break SnapMirror on DR volumes.
2. Mount SnapMirror volumes as NFS datastores on DR ESXi hosts, then power on the Oracle VM.
3. Recover to last available archive log.
4. Open database; update DNS/connection strings.

Clean up

To stop incurring charges after testing this deployment, remove the following resources in this order:

1. Oracle VMs — Power off and delete Oracle database VMs from the vSphere inventory.
2. NFS datastores — Unmount FSx for ONTAP datastores from ESXi hosts in vSphere.
3. SnapMirror relationships — Delete SnapMirror relationships and DP volumes on the DR FSx for ONTAP file system.
4. FSx for ONTAP file systems — Delete both production and DR file systems from the Amazon FSx console. This action deletes all volumes and data on those file systems.
5. Amazon EVS environment — Delete the EVS environment from the Amazon EVS console. This terminates the underlying EC2 bare metal instances.
6. Networking — Remove Transit Gateway attachments, VPC Route Server configurations, and Direct Connect connections if they were created solely for this deployment.

Important: Deleting an FSx for ONTAP file system permanently removes all data. Confirm that you have backed up any data you need before proceeding.

Additional resources

• Amazon EVS User Guide
• EVS Supported VCF Versions and Instance Types
• Configure FSx for ONTAP as NFS Datastore for EVS
• FSx for NetApp ONTAP with EVS
• Amazon EVS Pricing
• Introducing Amazon EVS — AWS Blog
• NetApp Automation Toolkit for Oracle

Author Bio

Satish Bhoi is a Technical Account Manager in AWS Enterprise Support, where he helps customers design and optimize cloud solutions. With over 20 years of industry experience, he specializes in cloud architecture and is passionate about exploring generative AI applications in cloud computing. Outside of work, Satish plays league cricket, coaches young players, and enjoys traveling and adventure.

Sudhir Balasubramanian is a Data & AI Infrastructure Architect — an Oracle ACE, VMware vExpert, Nutanix NCP — a Speaker, Blogger, Author, Technologist, Evangelist, Partner & Customer Advocate. Sudhir frequently blogs on his personal website vracdba.com. Sudhir loves working with Customers & Partners to build creative solutions to solve complex problems & improve Customer experience. Outside of work, Sudhir likes to Hike, Walk, Cook and Listen to Classic Rock & Metal.

https://repost.aws/articles/ARyzO1vt7WR12rPhcDJ1uA6A