On-Premises, OCI, Autonomous, Exadata, and Container-Based Learning/Deployment Models

Learning outcomes

ServiceHub can run Oracle locally, but a production architecture meeting now contains five proposals: install Oracle on company VMs, run a container, use OCI Base Database Service, choose Autonomous AI Database, or purchase an Exadata-based deployment. All can involve Oracle Database, yet they move very different responsibilities across the boundary between the team and Oracle. This lesson turns “where should we run Oracle?” into an explicit responsibility model.

1. Start with responsibility, not with product slogans

A deployment choice determines who patches the operating system, Oracle Home, and database; who provisions storage; who owns backups; who configures listeners and services; who designs high availability; and who can reach host-level diagnostics. Those responsibilities are as important as SQL compatibility. Two offerings can run similar SQL yet expose very different administrative surfaces.

2. Self-managed host or VM: maximum control means maximum obligation

On a self-managed Linux or Windows host you can inspect Oracle Home files, listener configuration, ADR diagnostics, database services, OS processes, filesystem or ASM storage, and host telemetry. That visibility is valuable for learning and some production requirements, but nothing automatically patches the database, tests restore procedures, or keeps the listener secure. A VM adds virtualization but does not turn the database into a managed service.

For the course, a native Free installation on Windows or Oracle/RHEL-compatible Linux is a valid local path. Oracle’s current Free packages include 26ai installers for Linux and Windows. Native installation is especially useful when a later lesson needs host service management or file-path observation.

3. Containers: excellent lab reproducibility, but persistence is explicit

A database container packages the Oracle software/runtime in an isolated container environment. It is useful for repeatable labs because image identity, port mappings, and volumes can be scripted. But the database still writes persistent files. If those files live only in the writable container layer and the container is removed, your durable state disappears with that layer.

# Pull the current Oracle AI Database Free image.docker pull container-registry.oracle.com/database/free:latest# Create a persistent named volume once.docker volume create oracle26ai-data# ORACLE_PWD must contain a temporary strong lab password in your shell environment.docker run -d --name oracle26ai-free \  -p 1521:1521 \  -e ORACLE_PWD="$ORACLE_PWD" \  -v oracle26ai-data:/opt/oracle/oradata \  container-registry.oracle.com/database/free:latest# Watch initialization until the database reports readiness.docker logs -f oracle26ai-free

Pin an immutable image digest for a serious reproducibility record instead of trusting a moving latest tag forever. The course uses the tag for approachable setup, then asks you to record docker image inspect output and the database VERSION_FULL.

docker image inspect container-registry.oracle.com/database/free:latest   --format '{{json .RepoDigests}}'docker inspect oracle26ai-free   --format '{{json .Mounts}}' 

4. Deliberately wrong approach: treat the container as the backup

An engineer launches Oracle without a volume, loads ServiceHub data, then “cleans up” with docker rm -f. A replacement container starts clean and the engineer reports that Oracle lost data. Oracle did exactly what the deployment instructed: durable database files were stored in an ephemeral container layer that was deleted.

The repair is not “never use containers.” The repair is to make persistence, image identity, secret handling, backup, and restore separate design objects. A persistent volume protects against container replacement; it is still not a backup because deleting/corrupting data inside the database also changes the volume.

5. OCI Base Database, Autonomous AI Database, and Exadata move different boundaries

OCI Base Database Service provides Oracle Database on OCI compute/infrastructure with service-level provisioning and lifecycle capabilities. Autonomous AI Database shifts more operational responsibility to Oracle, automating tasks such as infrastructure management and portions of database lifecycle/tuning while exposing a database service rather than a host you administer like a conventional server. Exadata is an engineered database platform; Exadata Database Service and Exadata Cloud@Customer add cloud/service control planes around that engineered infrastructure.

Do not use a cloud diagram to explain a local instance mechanism unless the mechanism is actually portable. SQL semantics, transaction behavior, schemas, and many data types transfer conceptually. Host paths, patch commands, storage internals, RAC topology, service management, and license bundles can differ substantially.

6. Connection evidence should survive deployment changes

An application should prefer a documented service/connect descriptor rather than baking host-specific instance assumptions into code. Your evidence card should capture both portable and deployment-specific state.

SELECT banner_full FROM v$version;SELECT sys_context('USERENV','DB_NAME') AS db_name,       sys_context('USERENV','CON_NAME') AS con_name,       sys_context('USERENV','SERVICE_NAME') AS service_name,       sys_context('USERENV','HOST') AS client_host,       sys_context('USERENV','IP_ADDRESS') AS client_ipFROM dual;SELECT platform_nameFROM   v$database;

These values tell you what database/session you reached. They do not tell you whether the host is an OCI VM, an Exadata compute node, or a local container with certainty. Combine database evidence with the deployment control plane or host/container evidence rather than over-interpreting one SQL query.

7. Hands-on lab: write a deployment decision record

Use your current Free lab and write a short record with: deployment type, host OS, container/native choice, image/package version, persistent data location, port exposure, PDB service, client tool, backup/export location, owner of patching, and owner of restore testing. Then add a hypothetical production row for each candidate architecture.

docker ps --filter name=oracle26ai-freedocker inspect oracle26ai-free   --format 'Image={{.Image}} Ports={{json .NetworkSettings.Ports}} Mounts={{json .Mounts}}'# Database-side confirmation after connecting to FREEPDB1:# SELECT banner_full FROM v$version;# SELECT sys_context('USERENV','SERVICE_NAME') FROM dual;

Acceptance criteria:

• The local lab has persistent storage independent of the container lifecycle, or a documented native data location.
• You have recorded the actual image digest/package and Oracle VERSION_FULL.
• No production cloud/Exadata/RAC/GoldenGate feature is required for the mandatory lab.
• Every candidate production model names who owns OS, database patching, backup, HA, monitoring, and restore verification.
• The record distinguishes a portable database concept from a service-specific operational implementation.

8. Production judgment

Choose deployment models from SLOs, regulatory/control requirements, staff capability, latency, data gravity, failure domains, licensing, and operational burden. “More control” is not automatically better; unmanaged responsibilities become risk. “More managed” is not automatically simpler either; reduced host access can change troubleshooting, migration, networking, and integration patterns.

Keep an exit and recovery path. Know how data leaves the platform, how a restore is tested, how client service names change during migration, and which features create portability constraints. The next lesson creates the local baseline carefully so all later exercises have a known connection and recovery boundary.

9. Summary and next step

Self-managed servers, containers, OCI Base Database Service, Autonomous AI Database, and Exadata-based offerings can all involve Oracle Database, but they move patching, infrastructure, host access, HA, storage, and monitoring responsibilities differently. A container makes a great lab only when persistent data and backup are explicit. Lesson 4 now provisions Oracle AI Database Free and proves the listener/service/session path instead of assuming that a successful installer means the environment is correct.

Authoritative references

• Oracle AI Database Free Quick Start — current native and container learning paths
• Oracle AI Database Free Installation Guide for Linux — native Free installation and database layout
• OCI Base Database Service documentation — OCI database service responsibilities and operations
• Autonomous AI Database documentation — managed database service concepts and operations
• Oracle Exadata Database Machine documentation — engineered-system architecture and operations
• Oracle AI Database Licensing Information — offering and option boundaries