1Z0-908 common mistakes
1Z0-908 · Understand the traps and how to avoid them.
Assuming that setting the initialization parameter SGA_TARGET automatically sizes every subcomponent, including the large pool and the Java pool, and being unable to say which pools are auto-tuned when it is set.
Candidates memorize that ASMM 'automatically manages memory' and never learn that SGA_TARGET auto-tunes only the buffer cache, shared pool, large pool, Java pool, and streams pool, while log buffer, keep/recycle caches, and fixed SGA are excluded and large pool sizing is partly driven by automatic memory requests rather than pure auto-tuning.
What to do instead
Build a two-column table of auto-tuned versus manually sized components under ASMM and under AMM, and for each component note the parameter that governs it. Practice explaining what happens to the large pool when SGA_TARGET is set but LARGE_POOL_SIZE is also explicitly set, and when MEMORY_TARGET replaces SGA_TARGET.
Treating a database created with DBCA as automatically using Oracle Managed Files, and then being surprised that a datafile path must be supplied or that OMF-related parameters are unset.
DBCA in silent or interactive mode may or may not set DB_CREATE_FILE_DEST depending on the options chosen, and candidates conflate 'DBCA created the database' with 'the database is OMF-enabled'. They also forget that OMF requires DB_CREATE_FILE_DEST, DB_CREATE_ONLINE_LOG_DEST_n, or DB_RECOVERY_FILE_DEST to be set before file creation statements omit a filename.
What to do instead
Memorize the three parameters that enable OMF and what each controls, then rehearse the symptom: a CREATE TABLESPACE without a DATAFILE clause fails with ORA-02199 when no OMF destination is configured. Check V$PARAMETER for these parameters when diagnosing file-creation errors.
Planning an out-of-place patch with the wrong opatch or datapatch expectations, for example assuming datapatch must be run in the same ORACLE_HOME as opatch apply or that it can be run while the database is open in any state.
Candidates learn the command names but not the ordering and environment rules: opatch apply runs against a closed or patched home, datapatch runs against the target home with the database in a state that allows it, and the SQL patch registry must be queried afterward. They also forget that datapatch must be run for every pluggable database's container context.
What to do instead
Write the patch sequence as a numbered checklist including environment variables, opatch lsinventory before and after, datapatch -verbose, and a query of DBA_REGISTRY_SQLPATCH to confirm success. Practice identifying a failed datapatch from its output rather than assuming success from opatch's exit code.
Confusing the roles of the read-only and read-write Oracle homes in a read-only home deployment, or assuming a patch can be applied directly to a read-only home.
The read-only home concept is newer and candidates map it onto older 'one home per version' thinking. They do not recall that the read-only home is shared and protected while the read-write home carries configuration and that patching is performed in the read-write home, with the read-only home remaining unchanged.
What to do instead
Draw the two-home layout with which files live where, then state the rule for each operation (patch, configure, add a database). Confirm understanding by explaining why a read-only home can be shared across many databases while a read-write home cannot.
Answering a space-management question with DBA_FREE_SPACE alone when the real issue is undo retention, temporary segment growth, or space pressure inside a locally managed tablespace with autoextend disabled.
Candidates default to 'free space' queries and never build the habit of checking segment growth, autoextend settings, and the difference between allocated and used space. They also mix up DBA_TABLESPACE_USAGE_METRICS, which reports used and allocated space in blocks, with DBA_FREE_SPACE, which reports extents.
What to do instead
Memorize which view answers which question: DBA_TABLESPACE_USAGE_METRICS for used versus allocated space, DBA_FREE_SPACE for free extents, DBA_SEGMENTS for the largest consumers, DBA_DATA_FILES for autoextend and max size. Practice a scenario where a tablespace reports free space but an insert still fails, and identify the cause.
Granting a role such as DBA or RESOURCE to solve a privilege problem, instead of granting the specific system or object privilege, and then failing questions about least privilege or about why a procedure fails with insufficient privileges.
Candidates associate 'needs more access' with 'grant a role' and do not internalize that roles are disabled inside definer's rights PL/SQL and that object privileges must be granted directly on the object. They also forget the difference between a system privilege and an object privilege in the answer choices.
What to do instead
Practice classifying each requirement as system privilege, object privilege, or role, and state whether the grant must be direct because of definer's rights. Rehearse the rule that roles granted to a user are not active within definer's rights procedures, which is why direct grants are required.
Planning a recovery strategy that relies on a backup taken in NOARCHIVELOG mode for point-in-time recovery, or assuming RMAN can recover changes made after the last backup without archived redo.
Candidates separate 'backup' and 'recovery' into unrelated topics and do not connect the database log mode to what recovery is possible. They also forget that a consistent whole-database backup in NOARCHIVELOG mode can only be restored to the point of the backup.
What to do instead
Build a matrix of log mode, backup type, and achievable recovery target (complete restore, point-in-time, tablespace point-in-time). For each cell, state whether archived redo is required. Test the matrix against a scenario where a datafile is lost and the database is in NOARCHIVELOG mode.
Reading an AWR or Statspack report and quoting the top wait event as the cause, without checking the elapsed time, the number of waits, and whether the wait is idle or foreground-related.
Candidates memorize wait event names and treat the top entry as a diagnosis. They do not check DB time versus elapsed time, ignore the difference between idle waits such as SQL*Net message from client and real contention, and do not compare the wait profile against the workload's SQL.
What to do instead
Practice a fixed reading order: DB time and elapsed time, top foreground events with average wait, top SQL by elapsed time and by executions, then instance efficiency percentages with the caveat that they are only hints. For each top wait, write the follow-up query you would run in V$SESSION or V$SQL to confirm the cause.
Assuming that a long-running transaction holds no undo after commit, or that undo retention guarantees that a query will never receive ORA-01555.
Candidates learn that commit frees undo and overgeneralize. Undo becomes inactive rather than immediately reusable, and undo retention is a target that can be overridden by space pressure, by the undo tablespace being too small, or by the retention guarantee not being enabled.
What to do instead
State the difference between active, unexpired, and expired undo, and explain what UNDO_RETENTION and RETENTION GUARANTEE each do and do not guarantee. Map ORA-01555 to its common causes: small undo tablespace, uncommitted long transactions in other sessions, and delayed block cleanout.
Connecting to a pluggable database with a service name that resolves to the root container, or assuming a common user can be created in a PDB without the appropriate common prefix and container clause.
Candidates learn multitenant vocabulary but not the mechanics: the CDB$ROOT service versus the PDB service, the requirement to be in the correct container, and the rule that common users are created in the root with the C## prefix and local users in a PDB. They also forget that a common user's privileges apply across containers but its objects are container-specific.
What to do instead
Practice the container-switching commands (ALTER SESSION SET CONTAINER, and the equivalent in SQL*Plus) and write the exact CREATE USER statement for a local user in a PDB and for a common user in the root. For each, state which container the statement must run in and why.
Assuming that a listener configuration change takes effect for existing connections, or that a tnsnames.ora change is seen by a process that has already resolved the alias.
Candidates treat configuration files as live and do not distinguish between the listener's static configuration, its dynamically registered services, and the client-side name resolution cache. They also forget that LREG registers services dynamically and that a listener restart or reload is needed for some changes.
What to do instead
Memorize the chain: client reads tnsnames.ora, resolves host and port, connects to the listener, listener routes to a service registered by LREG or statically in the listener. For each change, state whether a listener reload, a restart, or a new client process is required. Practice with lsnrctl status and services output.
Scheduling a job with DBMS_SCHEDULER and assuming it runs as the invoking user with the invoking user's privileges, or forgetting that a program or job needs an explicit credential for external execution.
Candidates conflate DBMS_SCHEDULER with older DBMS_JOB behavior and do not learn that a job runs as its OWNER, that a job can be created with a different owner, and that external jobs require a credential. They also forget that job arguments are passed as name-value pairs and that a disabled job never runs regardless of its schedule.
What to do instead
Write the components of a scheduler job (job, program, schedule, credential, job class) and state the default for each. For a scenario where a job exists but never executes, list the checks in order: enabled state, schedule, job class and resource consumer group, owner and privileges, and the alert log or DBA_SCHEDULER_JOB_RUN_DETAILS.