Oracle DB 21c Se2

Sign in to the AWS Management Console, open the EC2 service and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for Oracle Database. Select the SecureAnyCloud listing, choose Select, then choose Continue on the subscription summary.

Pick an instance type of m5.large or larger (up to 8 vCPUs for Standard Edition 2). Choose your EC2 key pair under Key pair (login). Under Network settings, select your VPC and subnet, and either create or select a security group that allows inbound port 22 from your management network only.

The default security group of this listing opens port 22 only. Port 1521 does not need to be open, because the listener is bound to 127.0.0.1. Leave the root volume at the default size or larger. The image attaches the Oracle data volume automatically.

Select Launch instance. First-boot initialization sets and then proves the per-instance passwords before the database is allowed to start. It takes several minutes after the instance state becomes Running and the status checks pass, a few minutes longer than a plain database start.

The command below launches an instance from the SecureAnyCloud Oracle Database Marketplace AMI into an existing subnet and security group. Replace the following values:

• Replace <ami-id> with the AMI ID shown on the Marketplace listing.
• Replace <key-name> with your EC2 key pair name.
• Replace <subnet-id> with your subnet ID.
• Replace <security-group-id> with a security group that opens inbound port 22 from your management network.

Port 1521 stays closed.

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 \
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":30,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=oracle-db-21c-se2-01}]'

The command prints a JSON document on success. Note the instance ID, then retrieve its public address once it is running with aws ec2 describe-instances --instance-ids <instance-id> --query "Reservations[].Instances[].PublicIpAddress" --output text.

Connect over SSH with the key pair you selected and the public IP address from step 2. The SSH login user depends on the operating system of the AMI variant you launched:

AMI variant SSH login user

Oracle Database 21c SE2 on Oracle Linux 8 ec2-user

ssh <login-user>@<public-ip>

Wait until the instance has passed both EC2 status checks before you connect. SSH can become available before first boot has finished, so confirm that first boot has completed. The ready marker exists only after every password has been set and proven:

sudo test -f /var/lib/sac/data/oracle-db-21c-firstboot.done && echo "first boot complete"

If the command prints nothing, first boot is still running. Follow its progress with sudo journalctl -u oracle-db-21c-firstboot.service -b -f. If it does not finish, see If first boot fails in step 4.

The first-boot service generates fresh SYS, SYSTEM and PDBADMIN passwords for this instance and writes them, with the connection details, to /root/oracle-db-credentials.txt. Only the root user can read the file. Display it from your SSH session:

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

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

# Oracle Database 21c Standard Edition 2 - per-instance credentials (sac)
# Generated Sun Oct 18 11:12:04 UTC 2026 on i-0123456789abcdef0. Root-only (0600). Unique to this instance. SYS_PASSWORD=<your generated SYS password> SYSTEM_PASSWORD=<your generated SYSTEM password> PDBADMIN_PASSWORD=<your generated PDBADMIN password> ORACLE_SID=ORCL PDB_SERVICE=ORCLPDB 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 ; . ~/setEnv.sh ; sqlplus /nolog ; then CONNECT system@//localhost:1521/ORCLPDB

No shared or default database passwords ship in the image. Use the generated SYSTEM password for application and administrative connections, the SYS password for SYSDBA operations, and the PDBADMIN password to administer the ORCLPDB pluggable database. ORACLE_SID=ORCL is the container root, and PDB_SERVICE=ORCLPDB is the service your applications connect to.

The file uses KEY=value lines. Images released before October 2026 wrote KEY= value, with a space after the equals sign. To read a single password into a shell variable in a way that handles both forms, run:

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, SYSTEM and PDBADMIN can log in. Every other password account in the container and the pluggable database, including DBSNMP and the sample schemas, has a random password that nobody knows and is locked and expired. To use one of these accounts, set your own password and unlock it as SYSDBA, in the container that owns the account:

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

If first boot fails

First boot fails closed. If it cannot complete every step, it stops the database and the listener on purpose, writes no credentials file, and leaves /root/oracle-db-FIRSTBOOT-FAILED.txt explaining what happened. Read the notice and the service journal, then reboot once to retry. First boot runs again on every boot until it succeeds:

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

If it fails again, contact SecureAnyCloud support with the journal output.

Run the security self-test

The image includes a self-test that re-proves the security state of the instance. It checks that each password in the credentials file works and the historic and default passwords are refused, that every other account is locked, that the listener is bound to 127.0.0.1 only, and that no listener started before the passwords were set:

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

Each check prints a PASS line and the run ends with SELFTEST_OK. Abridged sample output:

PASS: ready marker present PASS: no first-boot error notice PASS: /root/oracle-db-credentials.txt is 0600 root:root PASS: SYS@ORCL accepts its per-instance password PASS: SYSTEM@ORCL accepts its per-instance password PASS: PDBADMIN@ORCLPDB refuses a historic/default password PASS: PDBADMIN@ORCLPDB accepts its per-instance password PASS: every other password account is locked PASS: listener.ora binds 127.0.0.1 only PASS: no database socket on a non-loopback address PASS: oracle-db.service gated on the ready marker PASS: memory fits m5.large: sga_target 2304M, pga_aggregate_target 768M ... SELFTEST_OK

The self-test checks the instance as delivered. After you rotate a password, open port 1521 or raise the database memory as described in this guide, the matching checks report FAIL by design.

Oracle Database starts automatically on boot through the oracle-db.service systemd unit, which runs Oracle's dbstart to open the database and start the listener. Confirm the unit is enabled for automatic start at boot:

systemctl is-enabled oracle-db.service

The command prints enabled. A companion one-shot unit, oracle-db-21c-firstboot.service, sets the per-instance credentials on the first boot. oracle-db.service does not start until that unit has finished and written its ready marker. Confirm that it is enabled too:

systemctl is-enabled oracle-db-21c-firstboot.service

Confirm that the Oracle listener is accepting connections. It binds to the loopback address 127.0.0.1 on port 1521 only. It is therefore reachable from the instance itself and, through an SSH tunnel, from SQL Developer and JDBC clients on your workstation:

ss -tln | grep ':1521 '

You should see a listening socket on 127.0.0.1:1521, and no other address on port 1521. The screenshot below shows the full lsnrctl status output. It shows the listening endpoint on port 1521 and the ORCL container and orclpdb pluggable database services registered and ready.

The database runs as the oracle operating system user, whose login environment sets ORACLE_HOME, ORACLE_SID and the library path. Connect to the container root with operating system authentication and query the version views. The following block reports the product banner, which names the edition, along with the instance name, full version and open status:

sudo su - oracle -c 'sqlplus -S -L / as sysdba' <<'SQL' SET PAGESIZE 50 LINESIZE 120 FEEDBACK OFF SELECT banner FROM v$version WHERE banner LIKE 'Oracle%'; SELECT instance_name, version_full, status FROM v$instance; EXIT; SQL

The banner reads Oracle Database 21c Standard Edition 2 Release 21.0.0.0.0 - Production, and the instance ORCL reports version 21.3.0.0.0 with status OPEN. The screenshot below shows the client version from sqlplus -V together with this banner and instance query.

Oracle Database 21c uses the multitenant architecture. The container database ORCL holds one pluggable database, ORCLPDB, which is where your application schemas and data live. Confirm that the pluggable database is open in read-write mode:

sudo su - oracle -c 'sqlplus -S -L / as sysdba' <<'SQL' SET PAGESIZE 50 LINESIZE 120 FEEDBACK OFF COLUMN name FORMAT a12 COLUMN open_mode FORMAT a12 SELECT name, open_mode FROM v$pdbs WHERE name = 'ORCLPDB'; SELECT sysdate AS server_time FROM dual; EXIT; SQL

ORCLPDB reports READ WRITE. The pluggable database is configured with saved state, so it opens automatically whenever the container database starts. The screenshot below shows a session that switches into the ORCLPDB container, confirms that it is open read-write and reads the server time.

To run application workloads, connect to the ORCLPDB pluggable database service as the SYSTEM user with the generated password. Switch to the oracle user and source the environment first, then open SQL*Plus. Replace <SYSTEM_PASSWORD> with the value from /root/oracle-db-credentials.txt:

sudo su - oracle . ~/setEnv.sh sqlplus system/<SYSTEM_PASSWORD>@localhost:1521/ORCLPDB

Inside SQL*Plus, you can create application schemas, tables and data in the pluggable database. Run the following statements at the SQL> prompt to create a table, insert a row and read it back:

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;

Type EXIT to leave SQL*Plus.

To connect to the container root for administration instead, use operating system authentication with sqlplus / as sysdba, or connect over the network as SYS with sqlplus sys/<SYS_PASSWORD>@localhost:1521/ORCL as sysdba. To administer the pluggable database as its own administrator, connect as PDBADMIN with sqlplus pdbadmin/<PDBADMIN_PASSWORD>@localhost:1521/ORCLPDB.

The listener is bound to 127.0.0.1, and the default security group opens port 22 only, so the database is not reachable from the network. The recommended way to connect SQL Developer, a JDBC driver or any Oracle client on your workstation is an SSH tunnel. The tunnel carries the Oracle traffic inside your existing SSH connection and needs no change to the instance or the security group.

Connect through an SSH tunnel

On your workstation, open a tunnel that forwards local port 1521 to the listener on the instance, and leave it running while you work:

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. Use these connection details, with the password from the credentials file:

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

In SQL Developer, create a new connection and set the Connection Type to Basic. Enter localhost, port 1521 and the ORCLPDB service name. Supply the SYSTEM username and generated password, then select Test and Connect.

For administrative access to the container root, use the ORCL service name and connect as SYS with the SYSDBA role.

Opening port 1521 deliberately

If your applications must connect directly rather than through a tunnel, open the listener deliberately, in three steps, and only to your own network. Run these commands yourself. The SSH tunnel does not need any of them.

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

sudo su - oracle . ~/setEnv.sh 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

Alternatively, configure TCPS (TLS) with an Oracle wallet instead. See "Configuring Transport Layer Security Authentication" in the Oracle Database 21c Security Guide at https://docs.oracle.com/en/database/oracle/oracle-database/21/dbseg/configuring-transport-layer-security-authentication.html.

2. Bind the listener to all interfaces. In $ORACLE_HOME/network/admin/listener.ora (/opt/oracle/product/21.0.0/dbhome_1/network/admin/listener.ora), change (HOST = 127.0.0.1) to (HOST = 0.0.0.0). Then restart the listener as the oracle user. The database and the ORCLPDB service register with the restarted listener within a minute:

sudo su - oracle . ~/setEnv.sh sed -i 's/(HOST = 127.0.0.1)/(HOST = 0.0.0.0)/' $ORACLE_HOME/network/admin/listener.ora lsnrctl stop lsnrctl start

3. Allow TCP 1521 from your own network only. Add a security group rule for your management or application CIDR. Never use 0.0.0.0/0:

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

Clients then connect to <public-ip>:1521/ORCLPDB (or the private IP from inside the VPC), or ORCL for the container root, and must also use encryption. The JDBC thin driver, and therefore SQL Developer, negotiates encryption automatically when the server requires it. Other Oracle clients do the same with their default sqlnet.ora settings.

Instances launched from earlier images

On instances launched from images released before October 2026, the listener binds 0.0.0.0 and the old default security group opened port 1521 to the internet. To bring such an instance in line with the current image, remove that security group rule. Then set the listener back to 127.0.0.1 in the same listener.ora file and restart it:

aws ec2 revoke-security-group-ingress --group-id <security-group-id> --protocol tcp --port 1521 --cidr 0.0.0.0/0
sudo su - oracle . ~/setEnv.sh sed -i 's/(HOST = 0.0.0.0)/(HOST = 127.0.0.1)/' $ORACLE_HOME/network/admin/listener.ora lsnrctl stop lsnrctl start

Check that the HOST entry in listener.ora now reads 127.0.0.1. On those images, PDBADMIN also kept its build-time password, so rotate it. As the oracle user, connect with sqlplus / as sysdba and run:

ALTER SESSION SET CONTAINER=ORCLPDB; ALTER USER PDBADMIN IDENTIFIED BY "<new-strong-password>";

Then connect through the SSH tunnel described above. If you need direct access instead, follow Opening port 1521 deliberately.

The Oracle binaries, the datafiles, the redo logs and the archive area are stored under /opt/oracle, a dedicated EBS volume separate from the operating system disk. Confirm the mount:

findmnt /opt/oracle

The output shows /opt/oracle is its own ext4 filesystem on a separate device. Check the available space at any time with:

df -h /opt/oracle

Because the database tier is on its own volume, you can take an Amazon EBS snapshot of it on its own schedule and grow it independently of the root volume.

systemd manages Oracle Database as the oracle-db.service unit, which starts the database and the listener automatically on boot, as confirmed in step 5. Check the service status:

systemctl status oracle-db.service --no-pager

Stop, start or restart the service when needed. Stopping the service runs Oracle's dbshut to close the database cleanly, and starting it runs dbstart:

sudo systemctl stop oracle-db.service
sudo systemctl start oracle-db.service
sudo systemctl restart oracle-db.service

Database memory and instance size

The starter database is sized for the recommended m5.large (8 GiB). It uses automatic shared memory management with 3072 MB in total, which gives an sga_target of about 2.3 GiB and a pga_aggregate_target of about 768 MiB, leaving room for the operating system. On m5.xlarge or a larger instance for production, raise the database memory as SYSDBA in the container root, 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 sudo systemctl restart oracle-db.service so that the new SGA size takes effect. Choose values that leave at least 2 GiB of the instance memory for the operating system.

Logs

The Oracle alert log and listener log live under /opt/oracle/diag. When you diagnose a startup or runtime problem, review the alert log first. Locate it with:

sudo su - oracle -c 'find /opt/oracle/diag -name alert_ORCL.log'

Oracle Database includes Recovery Manager (RMAN) for consistent, online backups. As the oracle user, run RMAN against the local instance to take a full backup of the container database and its pluggable databases:

sudo su - oracle . ~/setEnv.sh rman target / <<'RMAN' BACKUP DATABASE PLUS ARCHIVELOG; RMAN

For logical, schema-level exports, use Oracle Data Pump against the pluggable database:

expdp system/<SYSTEM_PASSWORD>@localhost:1521/ORCLPDB \
  schemas=APPUSER directory=DATA_PUMP_DIR dumpfile=appuser.dmp

Because /opt/oracle is a dedicated EBS volume, you can also take an EBS snapshot of the volume itself for a point-in-time copy of the entire database tier. For a crash-consistent snapshot, place the database in backup mode or shut it down cleanly first.