OCI Database Services Professional common mistakes
OCI Database Services Professional · Understand the traps and how to avoid them.
Treating a standby database in Data Guard as a read-write target for application traffic, or assuming a switchover can be triggered by simply stopping the primary instance.
Candidates carry over on-premises habits where failover was often an ad hoc DBA action, and they confuse the roles of switchover (planned, role reversal, both databases remain) versus failover (unplanned, primary lost). They also forget that a physical standby stays mounted read-only until it is activated, and that Data Guard broker commands (DGMGRL) or the console are required rather than instance shutdown.
What to do instead
Memorise the decision matrix: switchover requires both databases healthy and results in reversed roles with no data loss; failover is for disaster and may lose data unless zero data loss mode is configured. Practise the exact DGMGRL syntax (VALIDATE DATABASE, SWITCHOVER TO, FAILOVER TO) and know that reinstate is needed after failover before the old primary can rejoin. Route read-only reporting to Active Data Guard only when the feature is enabled.
Choosing Autonomous Database when the workload needs OS-level access, custom init.ora parameters, or non-standard third-party agents, then being unable to explain why the deployment fails.
Autonomous Database is heavily marketed and candidates default to it as the 'modern' answer, without checking its constraints: no SSH, restricted parameter changes, fixed patching windows, and limited network options. The exam tests whether you can map workload requirements to the correct service tier rather than pick the newest product.
What to do instead
Build a quick filter: if the requirement mentions root access, custom kernel modules, specific database parameters, or third-party binaries on the host, the answer is a VM DB System or Bare Metal, not Autonomous. Reserve Autonomous for workloads that fit its automation model (OLTP, DW, APEX, JSON, graph) and where patching/scaling should be hands-off. Read the constraints section of the service docs, not just the feature list.
Confusing the roles of the DB System, the Container Database (CDB), and Pluggable Databases (PDBs) when answering questions about where a connection string, wallet, or TDE keystore lives.
OCI's console exposes both DB System-level settings and CDB/PDB-level settings, and many settings (backup policy, TDE, Data Guard) are configured at the DB System or CDB level while connection strings and schemas are per-PDB. Candidates answer at the wrong layer and pick a plausible but incorrect option.
What to do instead
Draw the hierarchy once: DB System (compute + storage + network) hosts one CDB, which hosts one or more PDBs. Attach facts to layers: TDE keystore and backup destination are configured on the DB System/CDB; service names and application schemas belong to PDBs; Data Guard associations are between DB Systems. When a question mentions 'per database', ask which layer it means before answering.
Assuming the default backup retention and automatic backups protect against every scenario, and not distinguishing between automatic backups, on-demand full backups, and archived redo needed for point-in-time recovery.
The console shows 'automatic backups enabled' and candidates stop there, missing that retention windows, cross-region copy, and long-term retention are separate settings, and that restoring to an arbitrary time requires archived redo logs to be available for that window. They also forget that deleting a DB System can delete its backups unless the retain option is used.
What to do instead
Learn the three knobs: backup retention period, cross-region backup copy, and long-term backup retention. Know that PITR is bounded by the retention window and by available archived redo, and that a backup taken with the 'retain' flag survives DB System termination. Practise describing a restore-to-timestamp scenario end to end, including which backups and redo are consumed.
Mixing up the network paths for database access: public endpoint versus private endpoint, the role of the subnet and NSGs, and when a wallet or TLS is mandatory.
OCI networking is the most common source of 'it works in the console but not from my app' problems, and candidates conflate security lists, NSGs, route tables, and service gateways. They also assume a wallet is always required, when mTLS is optional for some connection types and mandatory for others depending on the service and endpoint.
What to do instead
For each service, state the connection path explicitly: which subnet, which NSG rules on which ports (1521 for listener, 6200/6201 for TCPS where applicable), and whether the client needs a wallet. Remember that private endpoints require the client to be in the VCN or connected via VPN/FastConnect/peering. Test with a concrete example: 'application subnet 10.0.1.0/24 to DB subnet 10.0.2.0/24 on port 1521' and verify the NSG rule direction.
Ignoring the difference between scaling up (shape change) and scaling storage, and assuming both are online operations with no reboot or downtime.
Candidates assume cloud means everything is elastic and instantaneous. In reality, changing a DB System shape may require a reboot depending on the change, storage can be expanded online but not shrunk, and Autonomous Database scaling is handled differently (OCPU count, auto-scaling flag) than a VM DB System.
What to do instead
Memorise per service: which operations are online, which need a restart, and which are irreversible. For VM DB Systems, storage expansion is online and one-way; shape changes may need a reboot. For Autonomous Database, scaling OCPUs is online and auto-scaling can be toggled. When a question asks for 'no downtime', check whether the operation is actually online before choosing it.
Treating patching and version upgrades as a single concept, and not knowing which patching is automatic versus manual for each database service.
Autonomous Database patches itself on a schedule; VM DB Systems require you to apply patches or use a maintenance run; Exadata infrastructure has its own patching cycle. Candidates answer 'patches are automatic' universally or 'you patch manually' universally, and miss that the exam tests the boundary.
What to do instead
Build a table with columns: service, who patches, can you control the window, and is a reboot needed. Autonomous: Oracle patches, you can defer within limits. VM DB System: you schedule and apply, with options for rolling patching in Data Guard configurations. Know that major version upgrades are always a deliberate action, not automatic, except where the service explicitly manages it.
Assuming encryption is on by default everywhere and that TDE keys are managed the same way across services, including confusion about the relationship between the TDE master key and the OCI Vault.
TDE is default-on for many OCI database offerings, but the keystore location (local wallet versus OCI Vault) and the rotation behaviour differ. Candidates also confuse TDE with encryption at rest for block storage, and forget that losing the master key means losing the data.
What to do instead
State the chain: data files encrypted with TDE tablespace keys, protected by a TDE master key, which can live in a local keystore or in OCI Vault. Know that Vault-backed keys enable central rotation and that the key must not be deleted while the database exists. Distinguish TDE (database-level) from block volume encryption (storage-level) and from network encryption (TLS/mTLS).
Answering Data Guard and backup questions with on-premises tooling assumptions (RMAN scripts, manual log shipping) instead of OCI-managed mechanisms, or vice versa.
The exam sits between DBA fundamentals and OCI-specific managed features, and candidates oscillate: they either describe manual RMAN configuration when the console handles it, or assume the console handles everything when a specific RMAN capability is still required. They also miss that managed backup and Data Guard are separate features that can be combined.
What to do instead
Separate the concerns: backup (managed automatic backups, on-demand backups, RMAN for advanced cases) versus disaster recovery (Data Guard, cross-region backup copy, Autonomous Data Guard). Know which is used for accidental data loss versus regional outage. For each question, identify whether it is asking about recovery point objective (backup) or recovery time objective (Data Guard) before selecting an answer.
Skipping the service limits and quota dimension, then choosing an architecture that exceeds default limits (number of DB Systems, storage per shape, number of PDBs) without noting the need for a limit increase.
Candidates focus on features and forget that OCI enforces tenancy limits and quotas per compartment, and that some shapes have maximum storage or PDB counts. Exam questions about large deployments often hinge on recognising that a limit increase request or a different shape is required.
What to do instead
Before finalising any architecture answer, check three things: default service limits for the resource, whether the chosen shape supports the required storage and PDB count, and whether the design spans compartments or regions that affect quotas. Know that limit increases are requested through the console/support and are not instantaneous, so designs with hard deadlines must account for lead time.