Oracle 1Z0-076 common mistakes
Oracle 1Z0-076 · Understand the traps and how to avoid them.
Treating RMAN incremental level 1 as always differential and forgetting that a cumulative level 1 backs up all blocks changed since the last level 0, not since the last level 1.
Candidates memorise 'level 1 = changes since last backup' and then mis-predict which backup a subsequent incremental will read, so they choose the wrong restore path in scenario questions about reducing recovery time.
What to do instead
Write out the three cases side by side before answering: differential level 1 = blocks changed since the most recent level 0 or level 1; cumulative level 1 = blocks changed since the most recent level 0; level 0 = all blocks. Then map the question's stated goal (shorter restore vs shorter backup) to the correct type.
Assuming a database in ARCHIVELOG mode can be opened after losing the current online redo log group, rather than recognising incomplete recovery is required.
The distinction between losing an inactive, active, or current redo group is subtle, and candidates conflate 'has archived logs' with 'no data loss possible'.
What to do instead
Learn the recovery matrix by redo group state: inactive group lost and archived = no recovery needed; current or active group lost = incomplete recovery to the last available SCN (or a fast recovery via a standby/Data Guard). Practise identifying group state from V$LOG.STATUS and ARCHIVED before selecting an answer.
Choosing 'ALTER DATABASE DATAFILE ... RESIZE' as the fix for a tablespace that cannot extend because every datafile has hit MAXSIZE, instead of adding a datafile or raising MAXSIZE/AUTOEXTEND.
Candidates see ORA-01653/ORA-01654 and jump to RESIZE, but RESIZE cannot exceed MAXSIZE and does nothing when AUTOEXTEND is off and the file is already at its limit.
What to do instead
Diagnose first with DBA_DATA_FILES (BYTES, MAXBYTES, AUTOEXTEND) and DBA_TABLESPACES. If BYTES = MAXBYTES, either raise MAXBYTES, enable AUTOEXTEND, or ADD DATAFILE. For a smallfile tablespace also check the DB_FILES limit and the OS file-size limit; for bigfile tablespace, one file only, so RESIZE is the option.
Expecting a locally managed tablespace with AUTOALLOCATE to always allocate 64K extents, rather than recognising the size depends on the segment and the 16/64/1M/8M/64M progression.
AUTOALLOCATE is described as 'system-determined', and candidates assume a single fixed size or confuse it with UNIFORM SIZE 1M.
What to do instead
Memorise the AUTOALLOCATE bitmap behaviour: small segments start at 64K, grow through 1M, 8M, and cap at 64M for large segments; the first extent of a segment in a dictionary-managed tablespace differs. Compare with UNIFORM, where every extent is identical and the size must be a multiple of the block size.
Configuring a Fast Recovery Area size based only on the datafile size, ignoring archived redo log volume and the flashback log, then being surprised by ORA-19809 or ORA-19815.
Candidates treat FRA sizing as 'database size plus a bit' and forget that archived logs, image copies, and flashback logs all consume the same space, and that the FRA also holds the controlfile and online redo autobackups.
What to do instead
Size the FRA from measured archive generation rate times retention window, plus the flashback log estimate (DB_FLASHBACK_RETENTION_TARGET and DB_FLASHBACK_LOG size views). Use V$RECOVERY_AREA_USAGE and V$FLASH_RECOVERY_AREA_USAGE to see per-file-type consumption, and set DB_RECOVERY_FILE_DEST_SIZE explicitly rather than relying on defaults.
Assuming a user with the DBA role can query any object without explicit grants, forgetting that DBA does not include SELECT ANY TABLE by default in a securely configured database.
In many test or training databases the DBA role does carry broad system privileges, so candidates generalise from that environment and miss questions testing least-privilege behaviour.
What to do instead
Distinguish role membership from system privileges: check DBA_SYS_PRIVS for the role and DBA_ROLE_PRIVS for the grantee. Remember that object privileges are separate and that SELECT ANY DICTIONARY, SELECT ANY TABLE, and SELECT_CATALOG_ROLE are distinct grants. Verify with a session-level test using SET ROLE or a fresh user.
Using 'ALTER SYSTEM KILL SESSION' and expecting the session to disappear immediately, rather than knowing it may remain in KILLED state until the client or PMON cleans it up.
Candidates confuse the mark-for-kill with actual termination, and in RAC they forget the IMMEDIATE clause is required to avoid waiting for the transaction to roll back.
What to do instead
Use ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE to force termination; otherwise the session is marked killed and the server process cleans up asynchronously. Monitor V$SESSION.STATUS and V$SESSION.EVENT. For a session holding a blocking lock, identify the blocker through V$LOCK and BLOCKING_SESSION before killing.
Believing that setting UNDO_RETENTION guarantees undo will be kept for that period, rather than understanding it is a lower-bound target subject to tablespace pressure and RETENTION GUARANTEE.
The parameter name suggests a hard guarantee, so candidates pick answers where a long-running query cannot fail with ORA-01555 after UNDO_RETENTION is raised.
What to do instead
Remember UNDO_RETENTION is a best-effort target; only ALTER TABLESPACE ... RETENTION GUARANTEE enforces it, at the cost of failing DML instead of overwriting undo. Diagnose ORA-01555 with V$UNDOSTAT (MAXQUERYLEN, SSOLDERRCNT) and tune undo tablespace size, not just the retention value.
Assuming a tablespace can be transported between platforms without checking endianness, then expecting the datafiles to be pluggable directly.
Candidates learn the transportable tablespace procedure as a fixed sequence and skip the platform compatibility check that determines whether RMAN CONVERT is required.
What to do instead
Query V$TRANSPORTABLE_PLATFORM and compare the source and target platform endianness with SELECT PLATFORM_NAME, ENDIAN_FORMAT FROM V$TRANSPORTABLE_PLATFORM. Same endianness = direct plug-in; different endianness = RMAN CONVERT TABLESPACE or CONVERT DATAFILE before transport. Always run the compatibility check with DBMS_TTS.TRANSPORT_SET_CHECK.
Configuring a standby database and assuming SYNC transport with maximum protection guarantees zero data loss even when the standby network is down, rather than knowing the primary will shut down.
Candidates mix up the three Data Guard protection modes and their failure behaviour: maximum availability degrades to maximum performance, but maximum protection halts the primary.
What to do instead
Memorise the behaviour table: Maximum Protection = SYNC, zero data loss, primary shuts down if no standby is available; Maximum Availability = SYNC, zero data loss, primary continues in maximum performance if the standby is unreachable; Maximum Performance = ASYNC, possible data loss. Confirm the configured mode with V$DATABASE.PROTECTION_MODE and the actual transport with V$ARCHIVE_DEST.