---
title: Deploy Oracle Database step by step on Amazon EVS with FSx for ONTAP
source: AWS Architecture Blog
source_slug: aws
url: https://aws.amazon.com/blogs/architecture/deploy-oracle-database-step-by-step-on-amazon-evs-with-fsx-for-ontap/
published: 2026-10-02
fetched: 2026-10-03T14:38:11+00:00
ingested: true
---

* * *

This post provides step-by-step procedures to deploy Oracle Database on [Amazon Elastic VMware Service (Amazon EVS)](/evs/) with [Amazon FSx for NetApp ONTAP](/fsx/netapp-ontap/) as NFS datastore storage. You will provision storage volumes, mount NFS datastores, install Oracle, and configure SnapMirror replication for cross-region disaster recovery.

Enterprises running Oracle databases on VMware want a path to AWS that preserves their existing operational workflows with no rearchitecting and retraining. In our related post, [Architect highly available Oracle Database on Amazon EVS and FSx for ONTAP](https://repost.aws/articles/ARLXLyCCi1R_692Ww9cIiXyA), we explained how to design that environment: selecting [Amazon Elastic Compute Cloud (Amazon EC2) bare metal instances](/ec2/), 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 related post: [Architect highly available Oracle Database on Amazon EVS and FSx for ONTAP](/blogs/architecture/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

* * *

### Step 1: Deploy Oracle VM on EVS

  1. Log in to 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)](/optimization-and-licensing-assessment/) 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:

**Setting** | **Value**  
---|---  
Deployment type | Single-AZ (required for EVS)  
SSD storage capacity | Size for Oracle data + logs + 20% headroom  
Throughput capacity | 512–2,048 MB/s (size for write workload. See asymmetry note)  
IOPS | Automatic (3/GiB) or user-provisioned (up to 80,000)  
VPC | Same VPC as EVS environment  
Subnet | EVS service access subnet, same AZ as DB cluster  
Security group | Allow NFS (TCP 2049, 111, 635) from EVS management VLAN  
  
  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:

**VMDK** | **Datastore** | **Size** | **Guest Mount** | **Purpose**  
---|---|---|---|---  
Hard Disk 2 | `fsx-ora-db1-data` | 500 GiB | `/u02` | Oracle data files  
Hard Disk 3 | `fsx-ora-db1-log` | 250 GiB | `/u03` | Oracle redo + archive logs  
Hard Disk 4 | `fsx-ora-db1-bin` | 50 GiB | `/u01` | Oracle Home binaries  
  
  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:** Consider Oracle licensing requirements when planning your DR strategy. 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:

**Policy** | **Scope** | **Frequency** | **SnapMirror Update**  
---|---|---|---  
Full DB Backup | Data + Control + Archive | Every 4–6 hours | Yes  
Archive Log | Archive logs only | Every 10–15 minutes | Yes  
  
  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-premises 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-premises)

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

  1. Create RMAN backup, stage to [Amazon Simple Storage Service (Amazon S3)](/s3/) using [AWS DataSync](/datasync/) or AWS 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

SnapCenter manages full database snapshots as storage-layer operations, providing efficient backup capabilities.

### 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. 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.

* * *

## Conclusion

In this post, we walked through deploying Oracle Database on Amazon Elastic VMware Service (Amazon EVS) with Amazon FSx for NetApp ONTAP as NFS datastore storage. You provisioned the Oracle VM, created FSx for ONTAP volumes, mounted NFS datastores in vSphere, installed Oracle 19c, and configured SnapMirror for cross-region disaster recovery and SnapCenter for Oracle-aware backup. We also covered four migration paths for existing on-premises Oracle workloads and day-2 operations for backup, point-in-time recovery, and cloning.

To get started, review the [Amazon EVS User Guide](https://docs.aws.amazon.com/evs/latest/userguide/) and [Configure FSx for ONTAP as NFS Datastore for EVS](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/evs-nfs-datastore.html), then deploy your first Oracle VM on Amazon EVS. For the architecture decisions behind this deployment, see our related post, [Architect highly available Oracle Database on Amazon EVS and FSx for ONTAP](/blogs/architecture/architect-highly-available-oracle-database-on-amazon-evs-and-fsx-for-ontap/). Share your feedback and questions in the comments.

* * *

## Additional resources

* * *

## About the authors