OCI Database Services Professional cheat sheet

Autonomous Database (ADB) offers four workload types: Transaction Processing (ATP), Data Warehouse (ADW), JSON, and APEX; workload type is fixed at provisioning time.

ADB scaling: ECPU or OCPU compute can be scaled online without downtime; storage scales automatically up to 64 TB for ATP/ADW Serverless and is billed per TB-month used.

ADB Serverless auto-scaling can triple the base OCPU/ECPU count when CPU utilization exceeds thresholds; the base value remains the billing floor.

ADB Dedicated runs in an Exadata Infrastructure resource inside a customer compartment, giving isolation, custom maintenance schedules, and Autonomous Container Database (ACD) placement control.

Base Database Service (DB Systems) supports Single Instance and RAC on Virtual Machine, Bare Metal, and Exadata shapes; you choose the DB version (19c, 21c, 23ai) at launch.

Exadata Database Service on Dedicated Infrastructure uses Exadata DB servers plus storage servers; Exadata Database Service on Cloud@Customer delivers the same stack in the customer data center.

Backup options: Autonomous uses automatic backups with configurable retention plus restore to any point in the retention window; Base Database Service supports RMFS/object storage backups, ZDM, and Data Guard.

Data Guard on OCI: Maximum Performance is the default protection mode; Maximum Availability requires SYNC transport and a standby that can acknowledge redo.

Key networking rule: a DB system's private IP must be in a subnet that either has a NAT gateway or a Service Gateway for patching and backup traffic unless the subnet is public.

Database lifecycle states to know: PROVISIONING, AVAILABLE, UPDATING, BACKUP_IN_PROGRESS, STOPPED, TERMINATED; scaling and patching require AVAILABLE.

Choosing a service: ADB Serverless for variable, self-managing workloads; ADB Dedicated for isolation and custom patching; Base Database Service for full OS/DB control; Exadata for extreme performance and scale.

ADB is always encrypted with TDE (Transparent Data Encryption); customer-managed keys via OCI Vault are optional, and the wallet must be downloaded to connect with mTLS.

Connection methods for ADB: TLS/mTLS with the client credentials wallet, or TLS without a wallet when mutual TLS is disabled; IAM database passwords are separate from OCI console credentials.

Autonomous Data Guard for ADB creates a standby in a different region or availability domain; failover is a switchover/failover operation, not a manual redo apply.

Patching: ADB uses quarterly release updates and lets you set a maintenance window; Base Database Service patching is done through the console/API or DB CLI and requires a defined patch window.

Storage autoscaling on Base Database Service expands allocated storage when free space drops below a threshold; it grows but never shrinks automatically.

OCI Database Migration (DMS) supports homogeneous migrations (e.g., Oracle to Oracle) and heterogeneous ones with GoldenGate-based replication for minimal downtime cutover.

Consolidation decision rule: many small schemas with predictable load map to ADB Dedicated ACDs; per-database OS access or custom agents force Base Database Service.

High availability decision rule: single AD with backups for dev/test; Data Guard or RAC across availability domains for production; Exadata for scale-out plus smart scan.

Cost rule: ADB Serverless bills for compute when running and storage consumed; stopping an ADB instance halts compute billing but storage charges continue.

Exadata System Model comparison: X9M/X10M base systems start at quarter rack; each adds database and storage servers, with smart flash cache and storage indexes available in all models.

Autonomous Database cloning: full clone copies data; metadata clone copies schema metadata only; point-in-time clone uses a timestamp or SCN within the retention window.

Refreshable clones let you periodically refresh a clone from a source ADB; they are read-only between refreshes and useful for reporting or test environments.

ADB resource management: consumer groups (HIGH, MEDIUM, LOW, TP, TPURGENT) control parallelism and concurrency; service names map to consumer groups for workload isolation.

Base Database Service shape selection: VM shapes for general workloads, Bare Metal for high I/O and licensing flexibility, Exadata shapes for smart scan and offload.

Data Guard broker commands: DGMGRL> switchover to <standby> for planned role reversal; failover for unplanned loss; reinstate restores the old primary.

Backup retention on Base Database Service: automatic backups can be configured with retention days and a recovery window; archived redo must be retained to support point-in-time recovery.

Security rule: OCI IAM policies grant access to database resources by compartment; database-level users and roles are managed inside the database, not by IAM.

Monitoring: OCI Database Management service provides fleet metrics, AWR-style performance hub, and SQL tuning; alarms in OCI Monitoring trigger on metrics such as CPU and storage.

ADB connection strings are generated per consumer group; the high-performance endpoint uses a different service name than the low-concurrency endpoint.

Private endpoint access for ADB requires a subnet with a private endpoint and either a NAT gateway or service gateway for outbound traffic; public endpoint access can be disabled.

Base Database Service listener ports default to 1521; the DB system's SCAN for RAC uses a single SCAN name/address that clients use for connection.

Data Guard association requires matching DB versions, compatible shapes, and network reachability between primary and standby; the standby can be in another region.

Patching order for RAC/Data Guard: patch the standby first, switch over, then patch the former primary to minimize downtime.

Autonomous Database tools: Database Actions (SQL, Data Load, Data Studio), APEX for low-code apps, and Oracle Machine Learning notebooks are available from the console.

Storage rule for Base Database Service: you choose initial storage and can expand online; shrinking storage is not supported, so size with headroom.

Termination behavior: terminating a DB system deletes the database and its backups unless you choose to retain backups; terminating ADB deletes automatic backups after the retention period.

Quota and limits: database service limits are per tenancy and per region (e.g., number of DB systems, Exadata infrastructure); check Service Limits before provisioning.

ADB workload types map to built-in features: ATP includes transaction-focused defaults, ADW includes columnar and parallel defaults, JSON adds document APIs, APEX adds the APEX runtime.

Auto-scaling versus manual scaling: auto-scaling adjusts compute within a base-to-maximum range; manual scaling changes the base value and therefore the billing baseline.

ADB stop/start: stopping preserves storage and backups but suspends compute; starting resumes with the same configuration and connection strings.

Base Database Service patching uses the DB system's patch history; major version upgrades require a new DB system or a documented upgrade path, not an in-place major upgrade.

Transparent Data Encryption is mandatory for ADB and optional for Base Database Service; wallet-based master key management is available for both.

Exadata smart scan pushes column filtering and joins to storage servers; it requires direct-path reads and is bypassed by some operations such as certain index scans.

Disaster recovery rule: cross-region Data Guard requires a remote region with available capacity and a VCN peering or remote peering connection between regions.

Migration cutover: use Oracle GoldenGate or OCI DMS replication to keep the target in sync, then switch applications during a maintenance window and validate row counts.

Capacity planning for ADB: ECPU is the current compute unit; 1 OCPU equals 2 ECPU for conversion purposes when comparing older and newer shapes.

ADB concurrency limits: the number of concurrent sessions and parallel servers scale with compute; low compute sizes cap parallelism, so size up before tuning SQL.

Backup window: ADB automatic backups run during a defined window; long-running backups can overlap maintenance windows and should be scheduled around them.

Base Database Service BYOL: bring-your-own-license reduces compute cost when you have Oracle licenses; license-included shapes bundle the database license.

DB system high availability: RAC provides instance-level failover within a region; Data Guard provides site-level protection; combining both gives instance and site redundancy.

Security posture: enable private endpoints, restrict security lists/NSGs to application subnets, rotate wallets and passwords, and use OCI Vault for keys and secrets.

Troubleshooting rule: if an ADB connection fails with ORA-12547 or wallet errors, verify the wallet zip matches the instance, the connection string uses the right service name, and the client clock is accurate.

ADB maintenance: you can defer a scheduled maintenance run within the allowed window; skipping indefinitely is not supported and updates eventually apply.

Base Database Service console actions include start, stop, reboot, scale shape, scale storage, update, and terminate; each action has prerequisites such as AVAILABLE state.

Data Guard role transitions: switchover is planned and reversible; failover is unplanned and may require reinstating the old primary before re-establishing protection.

ADB Data Guard standby is read-only and can serve reporting; the primary and standby must be in the same tenancy and compatible regions.

Database Management features: fleet health, performance hub with ASH and AWR, SQL tuning advisor, and tablespace monitoring are available for Base Database Service and Exadata.

Networking for DB systems: place the DB system in a private subnet, use a NAT gateway for outbound patching, and a service gateway for object storage backup traffic.

Naming and tagging: apply defined tags for cost tracking and compartment organization; tags propagate to billing and can drive IAM policy conditions.

ADB scale-up versus scale-out: scale-up increases compute on the same instance; scale-out for read replicas is achieved with Autonomous Data Guard standbys, not sharding by default.

Sharding: Oracle Sharding is available for extreme scale-out with sharded databases; it is a separate architecture from ADB auto-scaling and requires shard topology planning.

Base Database Service backup destinations: Object Storage or a local recovery area; cross-region backup copies improve disaster recovery posture.

Restore options: restore to the latest backup, restore to a point in time, or restore to a new DB system for validation before cutover.

Patching compliance: track patch levels per DB system, schedule patches during maintenance windows, and verify the patch history after each update.

Cost control: stop non-production DB systems when idle, right-size shapes, use BYOL where licensed, and monitor storage growth to avoid autoscaling surprises.

Service comparison summary: ADB = fully managed, self-driving; Base Database Service = managed infrastructure with OS/DB control; Exadata = engineered systems for high performance and consolidation.

ADB SQL and PL/SQL: Database Actions provides a web SQL worksheet; SQL Developer and SQLcl connect with the wallet or TLS-only connection.

Data loading into ADB: use Data Pump, Database Actions Data Load, or OCI Object Storage with DBMS_CLOUD; external tables over Object Storage enable query-in-place.

Base Database Service access: SSH to the DB system node for OS-level tasks; the opc user has sudo, and the oracle user owns the database software.

Exadata Cloud@Customer requires a control plane connection to OCI for management; the data plane stays on-premises, satisfying data residency requirements.

Monitoring metrics to watch: CPU utilization, storage used versus allocated, tablespace usage, wait events, and backup success/failure status.

IAM policy example pattern: allow group DBA to manage db-systems in compartment Prod, and allow group Dev to read autonomous-databases in compartment Dev.

Change management rule: test patches and upgrades on a clone or non-production DB system before applying to production, especially for major version changes.

ADB free tier: always-free Autonomous Database offers limited ECPU and storage; suitable for learning and small apps but not production SLAs.

Base Database Service free tier: limited VM DB systems are available in always-free; check regional availability before designing around free tier.

Encryption key management: customer-managed keys in OCI Vault can be rotated; rotating a key requires the database to be available and may take time to re-encrypt.

Network security: use NSGs for fine-grained rules per DB system, security lists for subnet-level rules, and avoid opening port 1521 to the internet.

Backup validation: periodically restore a backup to a new DB system to confirm recoverability; backup success does not guarantee restore success.

Scaling limits: ADB compute has maximum values per workload and shape; Base Database Service shape changes may require a reboot depending on the change.

Documentation rule: OCI service limits and shape availability vary by region and availability domain; verify in the target region before committing to an architecture.

ADB refreshable clone: the source must be an ADB instance; refresh frequency is configurable and the clone is read-only between refreshes.

ADB clone from backup: you can create a clone from a backup within the retention window, enabling recovery from logical errors without affecting the source.

Base Database Service cloning: use backup and restore or Data Guard, or create a DB system from a backup; there is no built-in one-click clone like ADB.

Exadata consolidation: multiple pluggable databases (PDBs) can share an Exadata system; resource manager plans isolate CPU and I/O between PDBs.

Multitenant: CDB/PDB architecture is default in 19c and later; ADB Dedicated and Base Database Service support PDBs, and ADB Serverless manages the CDB for you.

Connection pooling: use Database Resident Connection Pooling (DRCP) or a client pool for high-connection workloads; ADB consumer groups influence session resource allocation.

Incident response: use OCI Audit logs, database audit policies, and Database Management alerts to detect unauthorized access or configuration drift.

ADB private endpoint: creating a private endpoint associates the ADB with a subnet; the endpoint must be in the same VCN or a peered VCN as the client.

Base Database Service subnet rule: the DB system subnet must have enough free IP addresses for the nodes and SCAN; RAC requires additional addresses.

Data Guard redo transport: ASYNC for Maximum Performance, SYNC for Maximum Availability; Maximum Protection requires SYNC and halts the primary if no standby can acknowledge.

Patch types: Release Updates (RUs) are quarterly; Release Update Revisions (RURs) are lower-risk; Monthly Recommended Patches (MRPs) bundle fixes; choose based on risk tolerance.

Database upgrade path: 19c is long-term support; 21c is innovation; 23ai is long-term support; verify client and application certification before upgrading.

Backup encryption: backups are encrypted by default; customer-managed keys add a layer but require key availability during restore.

Performance troubleshooting: use AWR reports, ASH, SQL Monitor, and wait event analysis; on ADB, use Performance Hub and SQL Insights available in the console.

ADB scale storage: storage autoscaling expands automatically when usage approaches the limit; manual scaling sets a higher limit and cannot be reduced below used space.

Base Database Service storage expansion is online and does not require downtime; plan for ASM rebalance time on Exadata and RAC.

Termination protection: enable termination protection on production DB systems and ADB instances to prevent accidental deletion.

Maintenance windows: set windows outside peak hours; for ADB, the maintenance window applies to automatic updates; for Base Database Service, you schedule patching manually.

Disaster recovery testing: perform a switchover during a maintenance window to validate the standby, then switch back; document RTO and RPO achieved.

Cost allocation: use compartments per environment and defined tags per application; review billing for compute hours, storage GB-months, and backup storage.

Support: OCI support requests for database issues include the DB system OCID, ADB OCID, and relevant log excerpts; SR severity drives response targets.

ADB consumer group mapping: TPURGENT for highest priority, TP for transaction processing, HIGH/MEDIUM/LOW for reporting with decreasing parallelism.

Base Database Service RAC: SCAN listeners distribute connections across instances; services define which instances serve which workload.

Exadata storage indexes: created automatically per cell for predicate filtering; they reduce I/O for smart scan queries but are not persistent objects.

Flash cache: Exadata uses flash as a cache for both reads and writes; write-back flash cache improves write latency for eligible workloads.

Database firewall: use OCI network firewalls and database-level access control lists (ACLs) to restrict which hosts can connect.

Audit: enable unified auditing for compliance; export audit trails to Object Storage for long-term retention.

Capacity review cadence: review CPU, storage, and connection metrics monthly and adjust shapes or add standbys before hitting limits.

ADB region availability: not every region offers every workload type or shape; verify availability in the target region before designing.

Base Database Service shape families: Standard (general), High Memory (large SGA), and Exadata shapes; choose based on SGA and I/O requirements.

Data Guard fast-start failover: requires the observer process and Maximum Availability mode; it automates failover when the primary is unreachable.

Backup scheduling: define a backup window and retention; for Base Database Service, configure automatic backups and verify the recovery window.

Migration assessment: use Oracle Cloud Migration Advisor or the database migration assessment to size the target and identify incompatibilities.

Security: rotate database passwords, use IAM database passwords for ADB, and avoid storing wallets in shared locations.

Operational readiness: document runbooks for failover, restore, patching, and scaling, and rehearse them in non-production.

ADB workload type change: changing workload type is not supported in place; create a new ADB and migrate data.

Base Database Service version upgrade: major version changes require a new DB system or an upgrade path with testing; minor patches are applied in place.

Exadata scale: add database or storage servers to an Exadata infrastructure; scaling storage servers requires rebalance.

Monitoring integration: OCI Monitoring metrics can feed alarms and Notifications; Database Management adds database-specific metrics.

Compliance: use OCI Audit, unified auditing, and encryption at rest and in transit to meet regulatory requirements.

Capacity buffer: keep headroom for failover and peak load; a standby in another region must have sufficient capacity to take over.

Service selection checklist: workload type, control needs, isolation, performance, HA, DR, licensing, and cost determine the right service.

ADB connection with wallets: download the wallet, unzip, set TNS_ADMIN, and connect using the service name from tnsnames.ora.

Base Database Service connection: use the DB system's hostname or SCAN, port 1521, and the service name; SSH uses port 22.

Data Guard broker: use DGMGRL to configure, monitor, and switch over; the broker simplifies role transitions but requires a configuration.

Backup and restore: RMAN is used for Base Database Service; ADB manages backups automatically with retention settings.

Performance: use SQL Tuning Advisor, SQL Access Advisor, and Automatic Indexing (19c+) to improve query performance.

Security: use database vault, TDE, and network encryption for defense in depth.

Cost: monitor compute and storage usage, stop idle systems, and use BYOL to reduce licensing costs.

ADB maintenance scheduling: maintenance windows can be set; updates are applied during the window and cannot be skipped indefinitely.

Base Database Service patching: use the console or API to apply patches; the DB system must be available and backups should be taken first.

Data Guard: monitor redo apply lag and transport lag; high lag indicates network or standby performance issues.

Backup: verify backup completion and test restores; backup storage costs accrue separately from database storage.

Scaling: scale compute and storage online where supported; some shape changes require a reboot.

Security: use private endpoints, NSGs, and IAM policies to restrict access.

Operational excellence: automate patching, backups, and monitoring with OCI APIs and CLI.

ADB: fully managed, self-driving, auto-scaling, automatic backups, no OS access; best for variable workloads and rapid provisioning.

Base Database Service: managed infrastructure with OS and DB control; best for custom configurations and legacy applications.

Exadata: engineered system with smart scan, flash cache, and scale-out; best for high performance and consolidation.

Cloud@Customer: Exadata in the customer data center for data residency; managed by OCI control plane.

Data Guard: cross-region DR with switchover and failover; choose protection mode based on RPO requirements.

Backup: automatic for ADB, RMAN-based for Base Database Service; test restores regularly.

Cost: right-size, stop idle systems, use BYOL, and monitor storage growth.

ADB: workload types ATP, ADW, JSON, APEX; ECPU compute; auto-scaling; storage up to 64 TB.

Base Database Service: VM, Bare Metal, Exadata shapes; 19c, 21c, 23ai; RAC and Data Guard.

Exadata: X9M/X10M; quarter rack and larger; smart scan and flash cache.

Data Guard: Maximum Performance (ASYNC), Maximum Availability (SYNC), Maximum Protection (SYNC, halts primary).

Backup: ADB automatic; Base Database Service RMAN to Object Storage; retention and recovery window.

Networking: private subnet, NAT gateway, service gateway, NSGs.

Security: TDE, IAM, Vault, audit, private endpoints.

ADB: stop halts compute billing, storage continues; start resumes with same connection strings.

Base Database Service: termination deletes backups unless retained; enable termination protection.

Scaling: ADB auto-scaling triples base compute; Base Database Service storage expands online but does not shrink.

Patching: ADB quarterly updates; Base Database Service manual patching with backups first.

Data Guard: switchover planned, failover unplanned; reinstate old primary after failover.

Monitoring: OCI Monitoring alarms, Database Management performance hub, AWR and ASH.

Cost: BYOL, right-size, stop idle, monitor storage.

ADB clone types: full, metadata, point-in-time; refreshable clone for periodic refresh.

Base Database Service clone: backup and restore or Data Guard; no one-click clone.

Multitenant: CDB/PDB default in 19c+; ADB manages CDB; Exadata consolidates PDBs.

Resource management: consumer groups on ADB; resource manager plans on Exadata.

Connection pooling: DRCP or client pool; consumer groups affect session resources.

Incident response: OCI Audit, unified auditing, Database Management alerts.

Capacity: review CPU, storage, connections monthly; add standbys before limits.

ADB private endpoint: subnet association; same or peered VCN as client.

Base Database Service subnet: enough IPs for nodes and SCAN; RAC needs more.

Data Guard redo transport: ASYNC, SYNC, Maximum Protection halts primary.

Patch types: RU, RUR, MRP; choose based on risk.

Upgrade path: 19c LTS, 21c innovation, 23ai LTS; verify certification.

Backup encryption: default; customer-managed keys require key availability.

Performance: AWR, ASH, SQL Monitor, Performance Hub.

ADB storage autoscaling: expands automatically; manual scaling cannot reduce below used space.

Base Database Service storage expansion: online; ASM rebalance on Exadata/RAC.

Termination protection: enable on production.

Maintenance windows: set outside peak; ADB automatic updates; Base Database Service manual.

DR testing: switchover in maintenance window; document RTO/RPO.

Cost allocation: compartments per environment; defined tags per application.

Support: include OCIDs and log excerpts in SRs.

ADB consumer groups: TPURGENT, TP, HIGH, MEDIUM, LOW; priority and parallelism differ.

Base Database Service RAC: SCAN listeners; services define instance serving.

Exadata storage indexes: automatic per cell; reduce I/O for smart scan.

Flash cache: read and write caching; write-back improves write latency.

Database firewall: OCI network firewalls and database ACLs.

Audit: unified auditing; export to Object Storage.

Capacity review: monthly; adjust shapes or add standbys.