Databases AWS

Oracle Database 19c EE with ASM on AWS User Guide

Last updated: 2026-10-26 | Product: Oracle Database 19c EE with ASM on Oracle Linux 8 on AWS

Overview

This guide covers launching and using the Oracle Database 19c EE with ASM on Oracle Linux 8 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg Hardened AMIs for Oracle Database 19c, 21c & 26ai Enterprise listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.

Oracle Database 19c is Oracle's Long Term Release. This version stores the database on Oracle Automatic Storage Management (ASM), run by single instance Oracle Grid Infrastructure (Oracle Restart), instead of on a filesystem. The starter database is a single non container database named ORCL, and applications connect to the ORCL service.

Bring Your Own License. No Oracle licence is included. You need your own Oracle Database Enterprise Edition licence for the instance, and a licence for every Enterprise Edition option or management pack you use.

Base release only. Oracle Database and Oracle Grid Infrastructure are installed from Oracle's 19c base release media, version 19.3.0.0.0, with no Release Update, OJVM patch or other Oracle patch applied. Release Updates are support content that Oracle provides to customers with an Oracle support contract, so you apply them yourself (see step 12). The Oracle Linux 8 packages are fully patched when the image is built.

The cloudimg image adds:

No database and no usable password in the image. The image ships the Grid Infrastructure home, the database home and the two empty ASM disk groups. On the first boot of your instance a one shot service, oracle-db-19c-firstboot.service, waits for Oracle Restart to start ASM, sets unique random passwords on the ASM SYS (SYSASM) and ASMSNMP accounts, then creates the ORCL database on +DATA and +RECO with Oracle's Database Configuration Assistant (dbca), so every instance has its own database and its own passwords. With no listener running it then sets unique random passwords on SYS and SYSTEM and re-keys every other password account, such as DBSNMP, with a random value and leaves it locked and expired. Only then does it enable and start the listener on 127.0.0.1, prove that each new password works and that the historic and default passwords are refused, and check that no plaintext password reached the audit trail or the trace files. The passwords go to /root/oracle-db-credentials.txt, a file only root can read, followed by the ready marker /var/lib/cloudimg/oracle-db-19c-firstboot.done.
Fail closed. The image ships the Oracle Restart listener resource disabled, and only a successful first boot enables it. If any first boot step fails, the database and the listener are stopped and /root/oracle-db-FIRSTBOOT-FAILED.txt explains why.
Listener on localhost. The listener on port 1521 is bound to 127.0.0.1, and the listing's default security group opens SSH (port 22) only. You connect through an SSH tunnel; opening 1521 is a deliberate step that first requires network encryption (step 9).
No instance metadata for Oracle. Oracle Restart, the ASM instance, the database, the listener and every session they spawn, and the dbca run at first boot, are blocked from the EC2 instance metadata service, so a database feature that fetches a URL (for example UTL_HTTP, once a DBA grants it network access) cannot read the instance role's credentials (step 13).
Key only SSH. SSH accepts your EC2 key pair only: password and keyboard interactive logins, root logins and X11 forwarding are switched off in /etc/ssh/sshd_config.d/00-cloudimg.conf, which sshd reads first (step 3 shows how to check the effective settings).
Storage on separate EBS volumes. The Grid Infrastructure home, the database home and the Oracle inventory live on a 50 GiB volume mounted at /u01; the datafiles, control files, online redo logs and the server parameter file are on the ASM disk group +DATA (a raw 40 GiB volume), and the fast recovery area is on +RECO (a raw 20 GiB volume). Both disk groups use external redundancy: EBS already replicates every volume within its Availability Zone, so ASM adds striping, online storage management and the same tooling as an on premises ASM estate rather than another mirror.

This is a headless image. Oracle Database has no web interface here; you administer it over SSH with sqlplus, asmcmd and srvctl, and connect graphical tools such as Oracle SQL Developer through an SSH tunnel.

Default user: ec2-user · Architecture: x86_64 · Recommended instance type: m5.large

Prerequisites

An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet with a route you use for management.
A security group that allows TCP 22 (SSH) from your own networks only. Port 1521 does not need to be open.
Your own Oracle Database Enterprise Edition licence (Bring Your Own License).
The AWS CLI version 2 if you plan to launch from the command line.

Instance type: m5.large (2 vCPU, 8 GiB) is the smallest supported size: Oracle Grid Infrastructure needs 8 GiB of memory, and the starter database is sized to share it with ASM and Oracle Restart. For production choose m5.xlarge (4 vCPU, 16 GiB) or larger and raise the database memory as described in step 11.

Step 1: Launch from AWS Marketplace

Open the listing on AWS Marketplace, choose View purchase options and Subscribe. When the subscription is active choose Launch your software, then in Version pick Oracle Database 19c EE with ASM on Oracle Linux 8. Choose your Region, an instance type of m5.large or larger, your key pair and a security group that opens port 22 from your own networks only, then launch.

The AMI brings three data volumes with it: /dev/sdf (/u01), /dev/sdg (+DATA) and /dev/sdh (+RECO). Keep all three and their device names when you launch: the image finds its ASM disks by those block device mapping names. You can make the volumes larger at launch; step 10 shows how to grow a disk group afterwards.

First boot waits for ASM, creates the database, then sets and proves the per instance passwords before the listener is allowed to start. Allow about 17 minutes from launch on an m5.large; creating the database with dbca is most of that time (13 minutes measured on a 2 vCPU, 8 GiB instance), and larger instance types finish sooner.

Step 2: Launch from the AWS CLI

Replace <ami-id> with the AMI ID of this version in your Region, and the other placeholders with your own values. The command requires IMDSv2 and sets a metadata hop limit of 1:

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled,HttpPutResponseHopLimit=1 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=oracle-db-19c-ee-asm}]'

The /u01 volume and the two ASM disks are created from the image automatically. Retrieve the public address once the instance is running:

aws ec2 describe-instances --instance-ids <instance-id> --query "Reservations[].Instances[].PublicIpAddress" --output text

Step 3: Connect over SSH and Watch First Boot

Version	SSH user
Oracle Database 19c EE with ASM on Oracle Linux 8	`ec2-user`

ssh -i <your-key.pem> ec2-user@<public-ip>

SSH accepts key pair logins only. To see the effective SSH settings:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|permitemptypasswords|pubkeyauthentication|x11forwarding) '

pubkeyauthentication prints yes and the other five print no.

SSH is available before first boot has finished. The ready marker exists only after the database has been created and every password has been set and proven:

sudo test -f /var/lib/cloudimg/oracle-db-19c-firstboot.done && echo "first boot complete"

If the command prints nothing, first boot is still running; follow it with sudo journalctl -u oracle-db-19c-firstboot.service -b -f (the dbca progress lines start with [dbca], ending with 100% complete). Each first boot step is also recorded, with the seconds since boot, in a root only event log:

sudo cat /var/log/cloudimg/oracle-db-firstboot.events

On a completed first boot the steps read, in this order, start, db-create-start, db-created (with the dbca run time), rotated, listener-started 127.0.0.1:1521, verified and ready, for example:

49.38 8279a488-1270-4265-91f7-d825df1c7a07 start
171.07 8279a488-1270-4265-91f7-d825df1c7a07 db-create-start
887.77 8279a488-1270-4265-91f7-d825df1c7a07 db-created 717s
889.89 8279a488-1270-4265-91f7-d825df1c7a07 rotated
893.82 8279a488-1270-4265-91f7-d825df1c7a07 listener-started 127.0.0.1:1521
921.46 8279a488-1270-4265-91f7-d825df1c7a07 verified
925.37 8279a488-1270-4265-91f7-d825df1c7a07 ready

(measured on a 4 vCPU, 16 GiB instance).

The gap between start and db-create-start is first boot waiting for Oracle Restart to start ASM and mount both disk groups.

Step 4: Retrieve the Generated Credentials

First boot writes the passwords for this instance, with the connection details, to /root/oracle-db-credentials.txt, readable only by root:

sudo cat /root/oracle-db-credentials.txt

The file looks like this, with unique passwords on your instance:

# Oracle Database 19c Enterprise Edition with ASM - per-instance credentials (cloudimg)
# Generated Mon Oct 26 20:34:59 UTC 2026 on i-0123456789abcdef0. Root-only (0600). Unique to this instance.

SYS_PASSWORD=<your generated SYS password>
SYSTEM_PASSWORD=<your generated SYSTEM password>
ASM_PASSWORD=<your generated ASM SYS password>
ASMSNMP_PASSWORD=<your generated ASMSNMP password>

ORACLE_SID=ORCL
LISTENER=127.0.0.1:1521 (localhost only - use an SSH tunnel, or see the guide to open it deliberately with encryption)

Every other database account is locked and expired with a random password.
Connect: sudo su - oracle (the login profile sets ORACLE_HOME) ; sqlplus /nolog ; then CONNECT system@//localhost:1521/ORCL

Use SYSTEM for application and administrative connections and SYS for SYSDBA operations on the database. ASM_PASSWORD is the password of the ASM instance's SYS account (SYSASM over the network) and ASMSNMP_PASSWORD that of the ASM monitoring account; on the instance itself the grid user reaches ASM with operating system authentication and needs neither. To read one password into a shell variable without printing it:

SYSPWD=$(sudo awk -F'= *' '/^SYSTEM_PASSWORD=/{print $2}' /root/oracle-db-credentials.txt)
test -n "$SYSPWD" && echo "SYSTEM password read (${#SYSPWD} characters)"

Every other account is locked

Only SYS and SYSTEM can log in to the database. To use another account, set your own password and unlock it as SYSDBA:

ALTER USER <name> IDENTIFIED BY "<new-strong-password>" ACCOUNT UNLOCK;

If first boot fails

First boot fails closed: it stops the database and the listener, writes no credentials file and leaves a notice. Read the notice and the journal:

sudo cat /root/oracle-db-FIRSTBOOT-FAILED.txt
sudo journalctl -u oracle-db-19c-firstboot.service -b

If the event log shows db-create-start without db-created, the database creation itself failed (for example on an instance with too little memory); a partly created database is not repaired by a reboot, so terminate the instance and launch a new one on a supported instance type (m5.large or larger). If a step before or after the database creation failed, reboot once to retry; first boot runs again on every boot until it succeeds. If it fails again, contact cloudimg support with the journal output.

Run the security self-test

The self-test re-proves the security state of the instance: each password in the credentials file works and the historic and default passwords are refused, for the database and for ASM, every other account is locked, the listener is bound to 127.0.0.1 only, no listener started before the passwords were set, the database was created by this instance's own first boot, and no Oracle process can reach the instance metadata service:

sudo /usr/local/sbin/cloudimg-oracle-selftest

Each check prints a PASS line and the run ends with SELFTEST_OK. The self-test checks the instance as delivered: after you rotate a password, open port 1521 or raise the database memory, the matching checks report FAIL by design.

Step 5: Confirm Oracle Restart, ASM and the Listener

Oracle Restart (oracle-ohasd.service) starts ASM, mounts the disk groups, opens the database and starts the listener on every boot:

systemctl is-enabled oracle-ohasd.service oracle-db-19c-firstboot.service
systemctl is-active oracle-ohasd.service

Both units print enabled, and Oracle Restart prints active. The Grid Infrastructure owner grid sees every resource Oracle Restart manages:

sudo su - grid -c 'crsctl stat res -t'

ora.asm, ora.DATA.dg, ora.RECO.dg, ora.LISTENER.lsnr and ora.orcl.db are ONLINE, the database with Open. (ora.ons and ora.diskmon are OFFLINE by design: they serve clusters.) The same view through srvctl:

sudo su - oracle -c 'srvctl status database -db ORCL; srvctl config database -db ORCL'
sudo su - grid -c 'srvctl status asm; srvctl status listener'

srvctl config database reports Management policy: AUTOMATIC, Start options: open and Disk Groups: DATA,RECO, so the database opens whenever both disk groups are mounted. The listener binds to the loopback address only:

sudo ss -tlnp | grep ':1521 '

You see one listening socket on 127.0.0.1:1521 owned by tnslsnr, and no other address on port 1521.

The instance keeps the fixed host name oracle-asm.cloudimg.internal, mapped to 127.0.0.1 in /etc/hosts by cloudimg-update-hosts.service on every boot: Oracle Restart's configuration is tied to the host name, and its listener agent registers the host name's address, so the mapping keeps the listener on localhost. Do not change the host name.

Step 6: Confirm the Edition and the Base Release

Connect with operating system authentication as the oracle user and query the version views:

sudo su - oracle -c 'sqlplus -S -L / as sysdba' <<'SQL'
SET PAGESIZE 50 LINESIZE 120 FEEDBACK OFF
COLUMN banner FORMAT a80
COLUMN version_full FORMAT a12
SELECT banner FROM v$version WHERE banner LIKE 'Oracle%';
SELECT instance_name, version_full, status FROM v$instance;
SELECT cdb, log_mode FROM v$database;
SELECT value FROM v$option WHERE parameter = 'Partitioning';
EXIT;
SQL

The banner reads Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production, the instance ORCL reports VERSION_FULL 19.3.0.0.0, the base release, with status OPEN, CDB is NO (ORCL is a non container database) in NOARCHIVELOG mode, and the Partitioning option reports TRUE, as on every Enterprise Edition home.

Step 7: Explore the ASM Disk Groups

As the grid user, asmcmd shows the disk groups and the disks behind them:

sudo su - grid -c 'asmcmd lsdg; asmcmd lsdsk -k'

DATA (40960 MB) and RECO (20480 MB) are MOUNTED with EXTERN redundancy and a 4 MiB allocation unit, on the disks /dev/oracleasm/DATA1 and /dev/oracleasm/RECO1. Those names are stable symlinks that a udev rule creates for the EBS volumes attached as /dev/sdg and /dev/sdh, owned by grid:asmadmin, whatever NVMe name the instance gives them on each boot:

ls -l /dev/oracleasm/
cat /etc/udev/rules.d/96-oracle-asm.rules
sudo su - grid -c 'sqlplus -S / as sysasm' <<'SQL'
SET PAGESIZE 50 LINESIZE 120 FEEDBACK OFF
SHOW PARAMETER asm_diskstring
SELECT name, state, type, total_mb, free_mb FROM v$asm_diskgroup;
SQL

The ASM discovery string is /dev/oracleasm/*. The database files live in the disk groups:

sudo su - oracle -c 'sqlplus -S -L / as sysdba' <<'SQL'
SET PAGESIZE 50 LINESIZE 120 FEEDBACK OFF
COLUMN name FORMAT a60
SELECT name FROM v$datafile;
SELECT name FROM v$controlfile;
SHOW PARAMETER db_recovery_file_dest
EXIT;
SQL

The datafiles are under +DATA/ORCL/, the control file is multiplexed on +DATA and +RECO, and the fast recovery area is +RECO with a 15 GiB quota (db_recovery_file_dest_size). Browse the files with asmcmd ls +DATA/ORCL/DATAFILE/.

Step 8: Connect with SQL*Plus

Connect to the ORCL service as SYSTEM. Switch to the oracle user, then start SQL*Plus without a password on the command line and enter it at the prompt, so it never appears in the process list or your shell history:

sudo su - oracle
sqlplus /nolog
SQL> CONNECT system@//localhost:1521/ORCL
Enter password: <SYSTEM_PASSWORD>

At the SQL> prompt you can create schemas, tables and data; new tablespaces go to +DATA automatically (db_create_file_dest):

CREATE TABLE products (
  id    NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  name  VARCHAR2(100),
  price NUMBER(10,2)
);
INSERT INTO products (name, price) VALUES ('Mechanical Keyboard', 89.00);
COMMIT;
SELECT name, price FROM products;

For SYSDBA work use sqlplus / as sysdba as the oracle user, or CONNECT sys@//localhost:1521/ORCL AS SYSDBA with the SYS password.

Step 9: Connect Remotely with SQL Developer or JDBC

Through an SSH tunnel (recommended)

The listener is bound to 127.0.0.1 and the security group opens port 22 only. On your workstation, open a tunnel that forwards local port 1521 to the listener and leave it running:

ssh -i <your-key.pem> -N -L 1521:127.0.0.1:1521 ec2-user@<public-ip>

While the tunnel is open, localhost:1521 on your workstation reaches the database:

Host:            localhost (through the SSH tunnel)
Port:            1521
Service name:    ORCL
Username:        SYSTEM
Password:        <your generated SYSTEM password>
JDBC URL:        jdbc:oracle:thin:@//localhost:1521/ORCL

In SQL Developer create a connection of type Basic with these values, then Test and Connect. For SYSDBA work connect as SYS with the SYSDBA role.

Opening port 1521 deliberately

If applications must connect directly, open the listener in three steps, and only to your own networks.

1. Require Oracle native network encryption and integrity. As the oracle user, append to the database home's $ORACLE_HOME/network/admin/sqlnet.ora:

sudo su - oracle
cat >> $ORACLE_HOME/network/admin/sqlnet.ora <<'EOF'
SQLNET.ENCRYPTION_SERVER = required
SQLNET.ENCRYPTION_TYPES_SERVER = (AES256)
SQLNET.CRYPTO_CHECKSUM_SERVER = required
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256)
EOF

Oracle documents these settings in "Configuring Oracle Database Network Encryption and Data Integrity" (https://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/configuring-network-data-encryption-and-integrity.html). To use TLS (TCPS) with an Oracle wallet instead, follow the Transport Layer Security chapters of the Oracle Database 19c Security Guide (https://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/index.html).

2. Bind the listener to all interfaces. The listener belongs to Oracle Restart and its configuration is in the Grid Infrastructure home. Change its address, then restart it as the grid user:

sudo sed -i 's/(HOST = 127.0.0.1)/(HOST = 0.0.0.0)/' /u01/app/19.0.0/grid/network/admin/listener.ora
sudo su - grid -c 'srvctl stop listener -listener LISTENER; srvctl start listener -listener LISTENER'

3. Allow TCP 1521 from your own network only. Never use 0.0.0.0/0:

aws ec2 authorize-security-group-ingress --group-id <security-group-id> --protocol tcp --port 1521 --cidr <your-network-cidr>

Clients then connect to <public-ip>:1521/ORCL (or the private IP inside the VPC) and negotiate encryption automatically; the JDBC thin driver and SQL Developer do so when the server requires it.

Step 10: The Storage Volumes

The Oracle software is on its own ext4 volume at /u01, and the two ASM disks are raw EBS volumes:

findmnt /u01
df -h /u01
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT

/u01 holds the Grid Infrastructure home /u01/app/19.0.0/grid, the database home /u01/app/oracle/product/19.0.0/dbhome_1 and the inventory /u01/app/oraInventory; the two disks with FSTYPE oracleasm are +DATA and +RECO. Never create a filesystem on an ASM disk.

Growing a disk group

To add space, grow the EBS volume in the EC2 console or with aws ec2 modify-volume, then tell ASM to use the new size, for example for +DATA:

sudo su - grid -c 'sqlplus / as sysasm'
SQL> ALTER DISKGROUP DATA RESIZE ALL;

To add a disk instead, attach a new EBS volume, extend the udev rule /etc/udev/rules.d/96-oracle-asm.rules with a line for its device name (for example sdi with the symlink oracleasm/DATA2), run sudo udevadm trigger, and add it with ALTER DISKGROUP DATA ADD DISK '/dev/oracleasm/DATA2';.

Step 11: Managing the Database

Oracle Restart owns the start and stop of every component. Manage the database with srvctl as the oracle user, and the whole stack (ASM, disk groups, listener and database) with crsctl as root:

sudo su - oracle -c 'srvctl stop database -db ORCL'
sudo su - oracle -c 'srvctl start database -db ORCL'
sudo /u01/app/19.0.0/grid/bin/crsctl stop has
sudo /u01/app/19.0.0/grid/bin/crsctl start has

A reboot stops the stack cleanly and Oracle Restart starts it again. Prefer srvctl to sqlplus startup or lsnrctl start from a shell: a database or listener that Oracle Restart starts runs inside oracle-ohasd.service and keeps both metadata walls of step 13 (one started by hand from a shell keeps the nftables wall only).

Database memory and instance size

The starter database uses automatic shared memory management with 3072 MB in total, an sga_target of about 2.3 GiB and a pga_aggregate_target of about 768 MiB, sized to share an m5.large with ASM and Oracle Restart. On m5.xlarge or larger, raise it as SYSDBA, for example:

ALTER SYSTEM SET sga_max_size=6G SCOPE=SPFILE;
ALTER SYSTEM SET sga_target=6G SCOPE=SPFILE;
ALTER SYSTEM SET pga_aggregate_target=2G SCOPE=BOTH;

Then restart the database with srvctl stop database -db ORCL and srvctl start database -db ORCL. Leave at least 3 GiB of the instance memory for the operating system, ASM and Oracle Restart.

Logs

The database alert log, the ASM alert log and the Oracle Restart alert log are in the diagnostic trees under /u01/app/oracle/diag and /u01/app/grid/diag:

sudo su - oracle -c 'find /u01/app/oracle/diag -name alert_ORCL.log'
sudo su - grid -c 'find /u01/app/grid/diag -name "alert_+ASM.log" -o -name alert.log -path "*crs*"'

Step 12: Patching Oracle Database and Grid Infrastructure

This image ships the 19.3.0.0.0 base release of both homes. cloudimg does not apply or redistribute Oracle Release Updates, OJVM patches or other Oracle patches: they are available to customers with an Oracle support contract through My Oracle Support. Plan to apply the current Release Update before production use, with your own Oracle support entitlement, to the Grid Infrastructure home first and then to the database home:

Oracle's Critical Patch Update advisories, which list the security fixes in each quarterly update: https://www.oracle.com/security-alerts/
Patching with AutoUpgrade, which automates downloading and applying Release Updates: https://docs.oracle.com/en/database/oracle/oracle-database/19/upgrd/autoupgrade-patching.html

Take EBS snapshots of all three volumes (/u01, +DATA and +RECO) before you patch, as one multi-volume snapshot set so they are consistent with each other. The Oracle Linux packages can be updated at any time with sudo dnf upgrade.

Step 13: Instance Metadata Protection

Every Oracle process is blocked from the EC2 instance metadata service (169.254.169.254). This stops a database session that can fetch URLs, for example through UTL_HTTP or UTL_TCP after a DBA grants a network access control entry, from reading the credentials of an IAM role attached to the instance. Two independent walls enforce it:

A systemd drop-in on oracle-ohasd.service sets IPAddressDeny= for the metadata addresses. Oracle Restart starts ASM, the database and the listener inside that unit, so none of them, and no session they spawn, can connect to those addresses. On Oracle Linux 8 systemd enforces this only with a cgroup2 tree, so the image boots with the kernel argument systemd.legacy_systemd_cgroup_controller=0 (the hybrid hierarchy: every cgroup v1 controller is unchanged).
An nftables rule for the oracle and grid users, loaded at boot by cloudimg-oracle-imds-egress.service, rejects the same addresses for any socket either user owns, wherever it runs: the dbca run that creates the database at first boot, a database or listener started by hand from a shell, and Oracle Restart itself. oracle-ohasd.service and the first boot service require this unit, so neither starts without it.

cat /etc/systemd/system/oracle-ohasd.service.d/cloudimg-imds-egress.conf
systemctl is-active cloudimg-oracle-imds-egress.service
sudo nft list table inet cloudimg_oracle_imds

The drop-in lists IPAddressDeny=169.254.169.254 168.63.129.16 fd00:ec2::254, the unit is active, and the table holds reject rules for the uids of oracle (54321) and grid (54322) to those addresses. The security self-test in step 4 proves both walls on your instance: it connects to 169.254.169.254 from inside the running oracle-ohasd.service and as each Oracle user from a shell, expects every attempt to be refused while a loopback connection from the same place succeeds, and checks that root can still reach the metadata service. Your own administration over SSH, the AWS CLI and the AWS Systems Manager agent are not affected.

Launch instances with IMDSv2 required and a hop limit of 1 (step 2).

Step 14: Backups

Recovery Manager (RMAN) takes consistent online backups, by default into the fast recovery area on +RECO. As the oracle user:

sudo su - oracle
rman target / <<'RMAN'
BACKUP DATABASE PLUS ARCHIVELOG;
RMAN

BACKUP ... PLUS ARCHIVELOG needs the database in ARCHIVELOG mode; the starter database runs in NOARCHIVELOG mode, so enable archiving first (its archived logs then go to +RECO; see the Oracle Database Backup and Recovery User's Guide) or take a backup with the database mounted and not open. For logical, schema level exports use Oracle Data Pump, entering the password at the prompt:

expdp system@//localhost:1521/ORCL schemas=APPUSER directory=DATA_PUMP_DIR dumpfile=appuser.dmp

+RECO holds 20 GiB, of which the recovery area may use 15 GiB; copy backups off the instance (for example to Amazon S3) and size +RECO for your retention. EBS snapshots of the three volumes are a further option: take them together as one multi-volume, crash consistent snapshot set, and shut the database down first for a clean copy.

Several instances in one RMAN recovery catalog

Oracle derives the database identifier (DBID) of the new ORCL database from its name and the second it is created, so instances launched at the same moment, for example several at once from one launch request, can be given the same DBID. A recovery catalog registers each database by its DBID, so before you register more than one of them in the same catalog, give each its own DBID with Oracle's DBNEWID utility, as the oracle user, with the database mounted and not open:

sudo su - oracle
srvctl stop database -db ORCL
srvctl start database -db ORCL -startoption mount
nid TARGET=/ LOGFILE=/tmp/nid.log
srvctl start database -db ORCL -startoption mount
sqlplus / as sysdba <<'SQL'
ALTER DATABASE OPEN RESETLOGS;
SQL
srvctl stop database -db ORCL
srvctl start database -db ORCL

nid changes the DBID of the database and leaves it shut down; opening with RESETLOGS starts a new incarnation, so take a fresh full backup afterwards. Run the instances' nid at different times: the new DBID is also derived from the time. Check the result with SELECT dbid FROM v$database;.

Support and licensing

This image is Bring Your Own License: you need your own Oracle Database Enterprise Edition licence, a licence for every option or management pack you use (for example Partitioning, Advanced Compression, Advanced Security, or the Diagnostics and Tuning Packs), and Oracle support for Release Updates. The AMI price covers cloudimg's hardening, first boot setup and support for the image.

Email: support@cloudimg.co.uk
Website: https://www.cloudimg.co.uk
Support: 24/7, with a 24 hour response SLA
Every version in this listing: Hardened AMIs for Oracle Database 19c, 21c & 26ai Enterprise

For administration, see the Oracle Database 19c documentation at https://docs.oracle.com/en/database/oracle/oracle-database/19/ and the Oracle Automatic Storage Management Administrator's Guide at https://docs.oracle.com/en/database/oracle/oracle-database/19/ostmg/.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. cloudimg is not affiliated with or endorsed by Oracle.