Oracle 1Z0-078 common mistakes
Oracle 1Z0-078 · Understand the traps and how to avoid them.
Treating the multitenant CDB/PDB distinction as cosmetic - running administrative commands such as STARTUP, SHUTDOWN, or ALTER SYSTEM without first reasoning about which container is current, or assuming an ALTER SYSTEM SET applies instance-wide when it was issued inside a PDB.
Candidates learn single-instance administration first and carry those reflexes into 19c; the container concept is new to them, so they forget that many parameters and views are scoped to the current container and that a PDB has no instance of its own.
What to do instead
Before answering any multitenant question, explicitly identify the current container and the scope of the change. Drill the rule that ALTER SYSTEM SET inside a PDB is local unless CONTAINER=ALL is specified, and that instance-level operations require the root. Practice reading V$CONTAINERS, CDB_ views, and CON_NAME to confirm context.
Designing a backup strategy that ignores the difference between ARCHIVELOG and NOARCHIVELOG mode, then assuming RMAN can perform point-in-time recovery or online backups in a database that was never switched.
Backup and recovery questions present a recovery scenario and candidates jump to the RMAN syntax without checking whether the prerequisites (archivelog mode, a consistent backup, control file autobackup) actually hold.
What to do instead
For every recovery scenario, first state the mode and what backups exist, then choose the technique. Memorize that online backups and media recovery require ARCHIVELOG, that NOARCHIVELOG recovery is limited to restoring the last consistent backup, and that switching modes requires a mount-stage ALTER DATABASE.
Confusing RMAN backup types and incremental levels - treating a level 0 incremental as equivalent to a full backup, or expecting a differential incremental to include everything since the last level 0 rather than since the last incremental of any level.
The terminology overlaps with everyday usage of 'full' and 'incremental', and the cumulative-versus-differential distinction is easy to invert under time pressure.
What to do instead
Write out the definitions before evaluating options: a level 0 backup is the base for subsequent incrementals and is never skipped in a recovery chain; a differential backs up blocks changed since the most recent incremental at any level; a cumulative backs up blocks changed since the most recent level 0. Practice mapping each to its recovery implications.
Assuming a tablespace can shrink or that space is reclaimed automatically after a large delete, when the segment still holds high-water-mark blocks and the datafile cannot be resized below them.
Candidates conflate row deletion with space release and forget that Oracle does not return space to the OS unless segments are moved, shrunk, or rebuilt, and that autoextend only grows files.
What to do instead
Learn the reclaim toolkit explicitly: SHRINK SPACE (with CASCADE for dependent objects), segment move/rebuild, TRUNCATE for full release, and ALTER DATABASE DATAFILE ... RESIZE only down to the high-water mark. Check DBA_FREE_SPACE, DBA_SEGMENTS, and DBA_DATA_FILES to confirm actual reclaimable space before choosing an option.
Misreading automatic undo management - setting UNDO_TABLESPACE inside a PDB, expecting UNDO_RETENTION to guarantee retention without a retention guarantee, or confusing undo retention with the undo tablespace size.
Undo is taught superficially, so candidates miss that undo is instance-wide in a CDB (one undo tablespace per instance, shared across PDBs) and that retention is best-effort unless RETENTION GUARANTEE is set.
What to do instead
Anchor on the facts: undo tablespace is a CDB-level, instance-level resource; UNDO_RETENTION is advisory unless the tablespace is created with RETENTION GUARANTEE; ORA-01555 relates to snapshot too old, not to tablespace fullness. Verify with V$UNDOSTAT and DBA_TABLESPACES before answering.
Choosing an automatic diagnostic source incorrectly - looking in the alert log for information that lives in the trace files, or expecting AWR reports to exist when the Diagnostics and Tuning Pack is not licensed or STATISTICS_LEVEL is BASIC.
The diagnostic infrastructure has many layers (alert log, trace files, ADR, AWR, ASH, Statspack) and candidates do not map each symptom to its correct repository or licensing prerequisite.
What to do instead
Build a symptom-to-source table: alert log for instance-wide events; trace files under ADR_HOME/trace for detailed errors; AWR for performance baselines (requires Tuning Pack and STATISTICS_LEVEL=TYPICAL or ALL); ASH for short-lived sampling. Check licensing and STATISTICS_LEVEL before selecting an AWR-based answer.
Treating a SQL plan change as a tuning problem to be solved by rewriting the query, when the actual cause is a stale or missing optimizer statistic, or a plan regression that SQL Plan Management baselines would have prevented.
Candidates over-index on query text and hints, and under-index on statistics, histograms, and plan stability features that the exam explicitly tests.
What to do instead
Diagnose in order: confirm statistics freshness (DBMS_STATS, DBA_TAB_STATISTICS), check for plan changes via DBA_HIST_SQL_PLAN, and only then consider SQL profiles, baselines, or hints. Know that SQL Plan Management captures and evolves baselines to prevent regressions, and that DBMS_STATS is the first tool, not the last.
Assuming Data Pump and RMAN are interchangeable, or expecting Data Pump to back up the whole database including control files, redo, and archived logs, or expecting RMAN to move a single table between schemas.
Both are 'backup-ish' utilities with export/import-style verbs, and the exam deliberately tests the boundary between logical and physical movement.
What to do instead
Fix the boundary in memory: Data Pump is logical (schemas, tables, tablespaces as logical units) and does not produce recoverable backups of the physical database; RMAN is physical and handles full/partial recovery. For cross-platform or cross-version movement, know Transportable Tablespaces and the role of the Data Pump metadata export.
Answering security questions by granting privileges directly to users, or forgetting that a role's privileges are not active inside a definer's-rights PL/SQL unit and that PUBLIC grants create a wide exposure.
Candidates memorize GRANT syntax but not the privilege-activation model, so they miss why a procedure fails with insufficient privileges even though the user has the role, or why revoking from PUBLIC matters.
What to do instead
Internalize the model: roles are disabled inside definer's-rights units (use invoker's rights or direct grants), privileges flow through roles at the session level, and PUBLIC grants apply to every user. For auditing, know that unified auditing captures policy-driven events and that FGA handles column-level access.
Ignoring the redo and archive log destination configuration when diagnosing a hang or a failed backup - assuming a performance problem when the real cause is a full fast recovery area or an archiver stuck waiting on a destination.
Candidates separate performance tuning from backup configuration and do not connect a stalled ARCH process or ORA-00257 to space management of the FRA.
What to do instead
When a scenario shows a hang or backup failure, check DB_RECOVERY_FILE_DEST and its size, V$RECOVERY_FILE_DEST, and V$ARCHIVE_DEST_STATUS before tuning anything. Know that a full FRA blocks archiving and therefore all DML, and that DB_RECOVERY_FILE_DEST_SIZE is the lever, not a hidden parameter.