Oracle Multicloud Architect Associate cheat sheet

Oracle multicloud is delivered through Oracle Database@Azure, Oracle Database@AWS, and Oracle Database@Google Cloud: Oracle-managed Exadata infrastructure placed inside the partner cloud region, connected by a low-latency private interconnect to OCI.

Split responsibility model: Oracle operates and patches the Exadata and Oracle Database software; the hyperscaler operates the physical datacenter, host network, and its native services; the customer owns data, schemas, IAM policy design, and application tier.

Oracle Database@Azure runs on OCI-managed Exadata hardware physically located in Azure regions; billing and the Azure portal surface the service, but database administration uses OCI tooling and OCI identity.

Oracle Database@AWS and Oracle Database@Google Cloud are offered as Oracle-managed Exadata services co-located in the partner region, with Oracle Database services (Autonomous Database, Exadata Database Service) exposed to workloads in that cloud.

Key decision rule: choose a multicloud database placement when the application tier must stay in the hyperscaler for data gravity, latency, or committed-spend reasons while the database must remain Oracle-exclusive (RAC, Data Guard, Exadata smart scan).

Interconnect is a prerequisite, not an option: cross-cloud traffic between the application VPC/VNet and the Oracle database subnet traverses a private, provider-managed link, so public internet egress is avoided for database traffic.

Committed-spend leverage: Oracle Database@Azure consumption can count toward Microsoft Azure consumption commitment (MACC); Oracle Database@AWS and Oracle Database@Google Cloud similarly align with partner committed-spend programs, so confirm eligibility before architecture sign-off.

Licensing portability: Bring Your Own License (BYOL) and Oracle Support Rewards apply across the multicloud database offerings, but eligibility differs per partner cloud and per service; verify the specific service's licensing terms.

Multicloud anti-pattern: splitting a single RAC cluster or a single Data Guard configuration across two hyperscaler regions without a validated private path introduces split-brain and latency risk; keep cluster members co-located.

Oracle Database@Azure resource model: an Exadata infrastructure resource, a VM cluster, and Oracle Database / Autonomous Database children are created in an Azure region but are administered through OCI; the Azure resource is a delegated resource, not a native Azure VM.

Oracle Database@Azure networking: the VM cluster's client subnet and backup subnet are Azure VNets delegated to Oracle; application traffic enters through the delegated subnet, and the OCI-side interconnect is provider-managed.

Oracle Database@AWS exposes Oracle Database services (Autonomous Database, Exadata Database Service) inside an AWS region; connectivity uses a private, Oracle-managed path between the AWS VPC and the Oracle database endpoint.

Oracle Database@Google Cloud places Exadata-based Oracle Database services in a Google Cloud region; the database is reachable from Google Cloud VPC workloads through a private interconnect rather than public endpoints.

Data Guard across regions is the standard HA pattern for multicloud databases: primary in the partner region, standby in a second region (partner or OCI), with redo transport over the private interconnect and Fast-Start Failover for automated role transition.

Autonomous Database on multicloud offerings provides automated patching, scaling, and backup; Exadata Database Service provides full RAC and Data Guard control. Decision rule: choose Autonomous for operational simplicity, Exadata Database Service for control and RAC.

Backup strategy: use Oracle-managed backups plus cross-region backup copies; for Oracle Database@Azure, backups land in the delegated backup subnet and can be replicated to OCI Object Storage for a second copy.

Storage and performance: Exadata smart scan, storage indexes, and flash cache behavior are preserved in multicloud placements because the same Exadata hardware and software stack is used; do not assume hyperscaler block storage characteristics apply.

Version and feature parity: the multicloud database services track Oracle Database release levels (for example 19c and 23ai); confirm the target release is offered in the chosen partner region before designing around a feature.

Private interconnect is the default path: Oracle Database@Azure uses an Oracle-managed interconnect between the Azure delegated subnet and OCI; Oracle Database@AWS and Oracle Database@Google Cloud use provider-managed private connectivity between the partner VPC/VNet and Oracle.

Azure side: the delegated subnet must be sized for the VM cluster's client and backup NICs; NSG rules must allow the application subnet to reach the database listener port (typically 1521) and must allow Oracle management traffic.

AWS side: use VPC security groups and route tables to steer traffic to the Oracle database endpoint; do not open database ports to 0.0.0.0/0, and prefer private subnets with NAT only for egress to Oracle management endpoints.

Google Cloud side: VPC firewall rules and Private Service Connect or the Oracle-provided private interconnect carry database traffic; confirm that the chosen region pair supports the interconnect before committing.

Latency budget: cross-cloud interconnect adds latency versus in-cloud traffic; for Data Guard, size the redo transport (SYNC vs ASYNC) against measured round-trip latency, and use ASYNC with a bounded lag for cross-region standby.

DNS: use private DNS zones so application tiers resolve the database endpoint to the private interconnect address; public DNS resolution to a database listener is a misconfiguration.

CIDR planning: application VPC/VNet, database client subnet, backup subnet, and OCI VCN ranges must not overlap; overlapping CIDRs block interconnect routing and require re-addressing.

Egress cost rule: database traffic that stays on the private interconnect avoids hyperscaler internet egress charges; traffic that leaves the partner cloud to OCI over the public internet incurs egress and is a design defect.

Troubleshooting order: confirm the delegated/private subnet association, then the NSG or security group and firewall rules, then route tables, then DNS resolution, then the database listener and wallet/TLS configuration.

Two identity planes exist: the hyperscaler identity (Microsoft Entra ID, AWS IAM Identity Center, Google Cloud Identity) governs the partner cloud resources, while OCI IAM governs the Oracle database resources; federation between them is the design goal.

Oracle Database@Azure supports Microsoft Entra ID federation into OCI IAM so that Azure users can be mapped to OCI groups and policies; map groups to least-privilege OCI policies rather than granting tenancy administrator.

Database-level security is separate from cloud IAM: Oracle Database users, roles, and privileges (or centrally managed users in Autonomous Database) control SQL access; cloud IAM does not grant schema privileges.

Data protection: enable Transparent Data Encryption (TDE) with a customer-managed key in OCI Vault, and confirm key residency and rotation policy against the partner cloud's compliance requirements.

Network security baseline: private subnets only, no public IP on database nodes, NSG/security group allowlists scoped to application subnets, and TLS with mutual authentication (Oracle wallets) for client connections.

Audit and governance: enable Oracle Database auditing plus the partner cloud's activity logs; centralize both in a SIEM so that a database privilege change and a cloud IAM change are correlated in one timeline.

Compliance residency: the database data physically resides in the partner cloud region where the Exadata is placed; confirm that backups, key vaults, and log archives are pinned to approved regions to avoid residency violations.

Segregation of duties: separate the roles that manage OCI IAM policy, the roles that manage database schemas, and the roles that approve production changes; a single principal with all three is a governance finding.

Secrets management: store database credentials and wallet files in the partner cloud's secret manager or OCI Vault, rotate on a schedule, and never embed credentials in application code or Terraform state.

Migration paths: physical migration via Data Guard or GoldenGate for minimal downtime; logical migration via Data Pump export/import for schema-level moves; RMAN cross-platform backup/restore for full database moves with compatible endianness.

Zero-downtime cutover pattern: establish a Data Guard standby or GoldenGate replication target in the multicloud database, let it catch up, then perform a planned switchover during a maintenance window and repoint the application via DNS.

GoldenGate is the choice when the source is non-Oracle, when bidirectional or filtered replication is required, or when the cutover must be reversible; Data Guard is the choice for Oracle-to-Oracle full-database HA and DR.

Data Pump over the private interconnect is preferred to exporting to local disk and shipping files; use network_link or a database directory on shared storage to avoid staging large dump files in the partner cloud.

Autonomous Database ingestion: use DBMS_CLOUD for object storage loads, Data Pump for schema imports, and GoldenGate or Data Transforms for continuous feeds; confirm the object storage bucket is reachable over the private path.

Schema and character set prechecks: verify NLS settings, time zone file version, and endianness before migration; a platform mismatch forces a logical migration rather than a physical one.

Post-migration validation: row counts, object invalidations, sequence values, scheduler jobs, and database links must be re-verified; compile invalid objects and re-gather statistics before opening traffic.

Integration patterns: applications in the partner cloud call the database over the private interconnect; cross-cloud service calls (queues, functions, object storage) should use private endpoints rather than public service endpoints.

Rollback plan: retain the source database in read-only or standby mode for a defined window after cutover, and document the reverse replication procedure before the migration begins.

Observability is split: database metrics (AWR, Automatic Workload Repository), alert logs, and Data Guard status live in OCI tooling (OCI Database Management, OCI Monitoring); infrastructure metrics live in the partner cloud monitor.

Unified alerting requires forwarding OCI alarms and partner cloud alerts into one incident channel; a database alert that only appears in OCI is invisible to a partner-cloud-only on-call rotation.

Key database signals: tablespace usage, session count versus process limit, redo generation rate, Data Guard apply lag, and top wait events; alert on apply lag and tablespace headroom before they become outages.

Cost drivers: Exadata infrastructure shape (fixed capacity), database edition and licensing model (BYOL vs License Included), interconnect data transfer, backup storage, and cross-region replication.

Cost rule: Exadata infrastructure is billed for provisioned capacity, not utilization; right-size the VM cluster and infrastructure shape at design time, because downsizing later requires a rebuild.

Committed-spend: Oracle Database@Azure spend can count toward Azure MACC; confirm which SKUs are eligible and reconcile the Oracle invoice against the partner cloud's commitment report monthly.

Data transfer cost: replication for Data Guard and backups crossing regions incur transfer charges; compress redo transport (Advanced Compression) and choose the nearest compliant region pair to reduce volume and latency.

Patch orchestration: Oracle patches the Exadata and database software, but the customer must schedule application-compatible maintenance windows and validate after patching; the partner cloud does not patch Oracle Database.

Capacity and performance review cadence: monthly review of AWR baselines, storage growth, and license consumption; quarterly review of committed-spend attainment and standby-region readiness.

HA layers: RAC provides instance-level HA within a region; Data Guard provides region-level DR; backups provide point-in-time recovery. A resilient design states the RTO and RPO each layer satisfies.

RAC on multicloud Exadata requires all cluster nodes in the same VM cluster and region; stretching RAC across clouds or distant regions is not a supported HA pattern.

Data Guard broker with Fast-Start Failover gives automated role transition; set protection mode deliberately: MaxPerformance (ASYNC, near-zero data loss risk), MaxAvailability (SYNC, zero data loss, latency-sensitive), MaxProtection (zero data loss, halts primary if standby is unreachable).

Cross-cloud DR pattern: primary database in the partner cloud region, standby in a second partner-cloud region or in OCI; redo transport over the private interconnect, with the observer placed in a third failure domain.

Failure domain analysis: enumerate region failure, availability zone failure, interconnect failure, and identity-provider failure; each must have a documented response, and interconnect failure must not silently fall back to public internet.

Split-brain prevention: Fast-Start Failover observer must be reachable from both primary and standby; if the observer loses quorum, failover must not be automatic.

Application resilience: connection pools must handle failover via Fast Application Notification (FAN) and Transparent Application Failover (TAF) or the driver's equivalent; a pool that caches a stale endpoint causes a post-failover outage.

Backup and restore testing: restore a production backup into a non-production multicloud database on a schedule; an untested backup is an unverified RTO claim.

Capacity headroom for failover: the standby region must be sized to absorb production load after failover; an undersized standby converts a DR event into a capacity incident.

Oracle multicloud is delivered through Oracle Database@Azure, Oracle Database@AWS, and Oracle Database@Google Cloud: Oracle-managed Exadata infrastructure placed inside the partner cloud region, connected by a low-latency private interconnect to OCI.

Split responsibility model: Oracle operates and patches the Exadata and Oracle Database software; the hyperscaler operates the physical datacenter, host network, and its native services; the customer owns data, schemas, IAM policy design, and application tier.

Oracle Database@Azure runs on OCI-managed Exadata hardware physically located in Azure regions; billing and the Azure portal surface the service, but database administration uses OCI tooling and OCI identity.

Oracle Database@AWS and Oracle Database@Google Cloud are offered as Oracle-managed Exadata services co-located in the partner region, with Oracle Database services (Autonomous Database, Exadata Database Service) exposed to workloads in that cloud.

Key decision rule: choose a multicloud database placement when the application tier must stay in the hyperscaler for data gravity, latency, or committed-spend reasons while the database must remain Oracle-exclusive (RAC, Data Guard, Exadata smart scan).

Interconnect is a prerequisite, not an option: cross-cloud traffic between the application VPC/VNet and the Oracle database subnet traverses a private, provider-managed link, so public internet egress is avoided for database traffic.

Committed-spend leverage: Oracle Database@Azure consumption can count toward Microsoft Azure consumption commitment (MACC); Oracle Database@AWS and Oracle Database@Google Cloud similarly align with partner committed-spend programs, so confirm eligibility before architecture sign-off.

Licensing portability: Bring Your Own License (BYOL) and Oracle Support Rewards apply across the multicloud database offerings, but eligibility differs per partner cloud and per service; verify the specific service's licensing terms.

Multicloud anti-pattern: splitting a single RAC cluster or a single Data Guard configuration across two hyperscaler regions without a validated private path introduces split-brain and latency risk; keep cluster members co-located.

Oracle Database@Azure resource model: an Exadata infrastructure resource, a VM cluster, and Oracle Database / Autonomous Database children are created in an Azure region but are administered through OCI; the Azure resource is a delegated resource, not a native Azure VM.

Oracle Database@Azure networking: the VM cluster's client subnet and backup subnet are Azure VNets delegated to Oracle; application traffic enters through the delegated subnet, and the OCI-side interconnect is provider-managed.

Oracle Database@AWS exposes Oracle Database services (Autonomous Database, Exadata Database Service) inside an AWS region; connectivity uses a private, Oracle-managed path between the AWS VPC and the Oracle database endpoint.

Oracle Database@Google Cloud places Exadata-based Oracle Database services in a Google Cloud region; the database is reachable from Google Cloud VPC workloads through a private interconnect rather than public endpoints.

Data Guard across regions is the standard HA pattern for multicloud databases: primary in the partner region, standby in a second region (partner or OCI), with redo transport over the private interconnect and Fast-Start Failover for automated role transition.

Autonomous Database on multicloud offerings provides automated patching, scaling, and backup; Exadata Database Service provides full RAC and Data Guard control. Decision rule: choose Autonomous for operational simplicity, Exadata Database Service for control and RAC.

Backup strategy: use Oracle-managed backups plus cross-region backup copies; for Oracle Database@Azure, backups land in the delegated backup subnet and can be replicated to OCI Object Storage for a second copy.

Storage and performance: Exadata smart scan, storage indexes, and flash cache behavior are preserved in multicloud placements because the same Exadata hardware and software stack is used; do not assume hyperscaler block storage characteristics apply.

Version and feature parity: the multicloud database services track Oracle Database release levels (for example 19c and 23ai); confirm the target release is offered in the chosen partner region before designing around a feature.

Private interconnect is the default path: Oracle Database@Azure uses an Oracle-managed interconnect between the Azure delegated subnet and OCI; Oracle Database@AWS and Oracle Database@Google Cloud use provider-managed private connectivity between the partner VPC/VNet and Oracle.

Azure side: the delegated subnet must be sized for the VM cluster's client and backup NICs; NSG rules must allow the application subnet to reach the database listener port (typically 1521) and must allow Oracle management traffic.

AWS side: use VPC security groups and route tables to steer traffic to the Oracle database endpoint; do not open database ports to 0.0.0.0/0, and prefer private subnets with NAT only for egress to Oracle management endpoints.

Google Cloud side: VPC firewall rules and Private Service Connect or the Oracle-provided private interconnect carry database traffic; confirm that the chosen region pair supports the interconnect before committing.

Latency budget: cross-cloud interconnect adds latency versus in-cloud traffic; for Data Guard, size the redo transport (SYNC vs ASYNC) against measured round-trip latency, and use ASYNC with a bounded lag for cross-region standby.

DNS: use private DNS zones so application tiers resolve the database endpoint to the private interconnect address; public DNS resolution to a database listener is a misconfiguration.

CIDR planning: application VPC/VNet, database client subnet, backup subnet, and OCI VCN ranges must not overlap; overlapping CIDRs block interconnect routing and require re-addressing.

Egress cost rule: database traffic that stays on the private interconnect avoids hyperscaler internet egress charges; traffic that leaves the partner cloud to OCI over the public internet incurs egress and is a design defect.

Troubleshooting order: confirm the delegated/private subnet association, then the NSG or security group and firewall rules, then route tables, then DNS resolution, then the database listener and wallet/TLS configuration.

Two identity planes exist: the hyperscaler identity (Microsoft Entra ID, AWS IAM Identity Center, Google Cloud Identity) governs the partner cloud resources, while OCI IAM governs the Oracle database resources; federation between them is the design goal.

Oracle Database@Azure supports Microsoft Entra ID federation into OCI IAM so that Azure users can be mapped to OCI groups and policies; map groups to least-privilege OCI policies rather than granting tenancy administrator.

Database-level security is separate from cloud IAM: Oracle Database users, roles, and privileges (or centrally managed users in Autonomous Database) control SQL access; cloud IAM does not grant schema privileges.

Data protection: enable Transparent Data Encryption (TDE) with a customer-managed key in OCI Vault, and confirm key residency and rotation policy against the partner cloud's compliance requirements.

Network security baseline: private subnets only, no public IP on database nodes, NSG/security group allowlists scoped to application subnets, and TLS with mutual authentication (Oracle wallets) for client connections.

Audit and governance: enable Oracle Database auditing plus the partner cloud's activity logs; centralize both in a SIEM so that a database privilege change and a cloud IAM change are correlated in one timeline.

Compliance residency: the database data physically resides in the partner cloud region where the Exadata is placed; confirm that backups, key vaults, and log archives are pinned to approved regions to avoid residency violations.

Segregation of duties: separate the roles that manage OCI IAM policy, the roles that manage database schemas, and the roles that approve production changes; a single principal with all three is a governance finding.

Secrets management: store database credentials and wallet files in the partner cloud's secret manager or OCI Vault, rotate on a schedule, and never embed credentials in application code or Terraform state.

Migration paths: physical migration via Data Guard or GoldenGate for minimal downtime; logical migration via Data Pump export/import for schema-level moves; RMAN cross-platform backup/restore for full database moves with compatible endianness.

Zero-downtime cutover pattern: establish a Data Guard standby or GoldenGate replication target in the multicloud database, let it catch up, then perform a planned switchover during a maintenance window and repoint the application via DNS.

GoldenGate is the choice when the source is non-Oracle, when bidirectional or filtered replication is required, or when the cutover must be reversible; Data Guard is the choice for Oracle-to-Oracle full-database HA and DR.

Data Pump over the private interconnect is preferred to exporting to local disk and shipping files; use network_link or a database directory on shared storage to avoid staging large dump files in the partner cloud.

Autonomous Database ingestion: use DBMS_CLOUD for object storage loads, Data Pump for schema imports, and GoldenGate or Data Transforms for continuous feeds; confirm the object storage bucket is reachable over the private path.

Schema and character set prechecks: verify NLS settings, time zone file version, and endianness before migration; a platform mismatch forces a logical migration rather than a physical one.

Post-migration validation: row counts, object invalidations, sequence values, scheduler jobs, and database links must be re-verified; compile invalid objects and re-gather statistics before opening traffic.

Integration patterns: applications in the partner cloud call the database over the private interconnect; cross-cloud service calls (queues, functions, object storage) should use private endpoints rather than public service endpoints.

Rollback plan: retain the source database in read-only or standby mode for a defined window after cutover, and document the reverse replication procedure before the migration begins.

Observability is split: database metrics (AWR, Automatic Workload Repository), alert logs, and Data Guard status live in OCI tooling (OCI Database Management, OCI Monitoring); infrastructure metrics live in the partner cloud monitor.

Unified alerting requires forwarding OCI alarms and partner cloud alerts into one incident channel; a database alert that only appears in OCI is invisible to a partner-cloud-only on-call rotation.

Key database signals: tablespace usage, session count versus process limit, redo generation rate, Data Guard apply lag, and top wait events; alert on apply lag and tablespace headroom before they become outages.

Cost drivers: Exadata infrastructure shape (fixed capacity), database edition and licensing model (BYOL vs License Included), interconnect data transfer, backup storage, and cross-region replication.

Cost rule: Exadata infrastructure is billed for provisioned capacity, not utilization; right-size the VM cluster and infrastructure shape at design time, because downsizing later requires a rebuild.

Committed-spend: Oracle Database@Azure spend can count toward Azure MACC; confirm which SKUs are eligible and reconcile the Oracle invoice against the partner cloud's commitment report monthly.

Data transfer cost: replication for Data Guard and backups crossing regions incur transfer charges; compress redo transport (Advanced Compression) and choose the nearest compliant region pair to reduce volume and latency.

Patch orchestration: Oracle patches the Exadata and database software, but the customer must schedule application-compatible maintenance windows and validate after patching; the partner cloud does not patch Oracle Database.

Capacity and performance review cadence: monthly review of AWR baselines, storage growth, and license consumption; quarterly review of committed-spend attainment and standby-region readiness.

HA layers: RAC provides instance-level HA within a region; Data Guard provides region-level DR; backups provide point-in-time recovery. A resilient design states the RTO and RPO each layer satisfies.

RAC on multicloud Exadata requires all cluster nodes in the same VM cluster and region; stretching RAC across clouds or distant regions is not a supported HA pattern.

Data Guard broker with Fast-Start Failover gives automated role transition; set protection mode deliberately: MaxPerformance (ASYNC, near-zero data loss risk), MaxAvailability (SYNC, zero data loss, latency-sensitive), MaxProtection (zero data loss, halts primary if standby is unreachable).

Cross-cloud DR pattern: primary database in the partner cloud region, standby in a second partner-cloud region or in OCI; redo transport over the private interconnect, with the observer placed in a third failure domain.

Failure domain analysis: enumerate region failure, availability zone failure, interconnect failure, and identity-provider failure; each must have a documented response, and interconnect failure must not silently fall back to public internet.

Split-brain prevention: Fast-Start Failover observer must be reachable from both primary and standby; if the observer loses quorum, failover must not be automatic.

Application resilience: connection pools must handle failover via Fast Application Notification (FAN) and Transparent Application Failover (TAF) or the driver's equivalent; a pool that caches a stale endpoint causes a post-failover outage.

Backup and restore testing: restore a production backup into a non-production multicloud database on a schedule; an untested backup is an unverified RTO claim.

Capacity headroom for failover: the standby region must be sized to absorb production load after failover; an undersized standby converts a DR event into a capacity incident.