NCM-DB common mistakes
NCM-DB · Understand the traps and how to avoid them.
Treating every schema as a single flat namespace and assuming two objects with the same name in different schemas conflict, so the candidate picks 'rename required' answers instead of resolving objects via schema-qualified names and the search path.
Candidates coming from single-database engines assume one global object namespace; they forget that in a multi-schema model the schema is part of an object's identity and that unqualified references resolve through a configurable search path in a defined order.
What to do instead
Before answering, restate the object identity rule: an object is schema plus name; unqualified lookup walks the search path in order and the first match wins. Practice writing fully qualified names and predicting which object an unqualified reference hits when the same table name exists in two schemas.
Confusing logical design artifacts with physical storage: the candidate says a tablespace 'contains' tables, or that dropping a schema drops its data files, and picks answers that mix logical containers with on-disk files.
The words tablespace, schema, database, and data file are used loosely in everyday speech, and candidates memorize definitions without building a mental map of which layer owns which object and what a DROP at one layer does to the others.
What to do instead
Draw the four-layer map once and reuse it: instance (memory plus processes) > database (catalog plus files) > tablespace (logical grouping of segments) > segment/extent/block. For each DDL statement, ask which layer it changes and whether storage is reclaimed. Drill DROP TABLE vs DROP TABLESPACE vs DROP SCHEMA consequences explicitly.
Assuming a query that returns correct rows is therefore efficient, and choosing the plan with the lowest cost number without checking whether the optimizer's cardinality estimates match reality or whether the chosen access path actually reduces rows early.
Candidates read execution plans as pass/fail artifacts rather than as estimates. They also forget that cost is a relative internal number tied to statistics and system settings, not a portable measure, and that stale or missing statistics invalidate the whole comparison.
What to do instead
For every plan question, verify three things in order: are statistics current for the joined tables, does estimated rows approximate actual rows, and is the most selective predicate applied at the earliest access path. Learn to spot a full scan that is correct (small table, high selectivity threshold) versus one that is wrong (large table, selective predicate).
Answering backup and recovery questions by naming a backup type (full, incremental, log) without stating the recovery point objective it satisfies, or claiming a backup is usable without testing restore of the relevant logs or archive chain.
Candidates memorize backup mode names but never connect them to what data loss window they permit. They also assume a successful backup job equals a recoverable backup, ignoring missing archive logs, broken incremental chains, or backups taken in a mode that is inconsistent for the workload.
What to do instead
For each scenario, derive the allowed data-loss window first, then select the minimum backup strategy that meets it, then state the exact restore sequence including which logs or incrementals must be applied. Always finish with 'and the restore is verified by an actual test restore', because an untested backup is a hypothesis.
Diagnosing a performance problem by changing initialization parameters first, such as raising memory or increasing parallelism, instead of identifying the top wait event or bottleneck and confirming it with evidence.
Parameter changes feel like decisive action and are easy to describe in an exam answer. Candidates skip the observation step because wait-event analysis requires knowing which view or metric to query and how to interpret cumulative versus interval values.
What to do instead
Adopt a fixed triage order for every tuning question: establish the symptom and time window, identify the dominant wait or top consumer, confirm with a second independent source, then change one thing. Reject any answer that tunes a parameter before naming the bottleneck it addresses.
Granting privileges at the object level when the requirement is role-based or least-privilege, or granting a role WITH ADMIN OPTION by default, so the candidate picks the broadest grant that makes the statement succeed.
Candidates optimize for 'does the user can do the task' and forget the second half of the requirement, which is usually 'and nothing more' plus revocability. They also conflate granting a role to a user with the role's own privileges and with the ability to re-grant it.
What to do instead
For each privilege question, write the exact object and the exact verb needed, grant only that, and separately decide whether delegation (WITH ADMIN OPTION or WITH GRANT OPTION) is explicitly required. Remember that revoking a role from a user differs from revoking a privilege from a role, and trace the effect on dependent objects.
Assuming a configuration change takes effect immediately for all sessions, so the candidate answers that altering a parameter fixes existing connections, when the change is scoped to new sessions or requires a restart or a scope qualifier.
The exam distinguishes instance-level, session-level, and persistent configuration, and candidates collapse these into 'change the parameter and it is fixed'. They also miss that some parameters are static and cannot be changed while the instance is running.
What to do instead
Classify every parameter question on two axes: dynamic versus static, and memory-only versus persisted to the configuration store. State explicitly whether existing sessions inherit the change, and if not, name the action (reconnect, restart, or set at session level) needed to observe it.
Treating NULL as a value equal to zero or to an empty string, then predicting that NOT IN, equality comparisons, and aggregate functions behave as they would with ordinary values, leading to wrong row counts and wrong join results.
Three-valued logic is counterintuitive, and NOT IN with a NULL in the subquery silently returns no rows. Candidates also expect COUNT(column) and AVG(column) to include NULLs because they think of the column, not the non-null rows.
What to do instead
For any predicate involving NULL, evaluate it as unknown, not false, and check the NOT IN subquery for NULLs before trusting the result. Memorize that COUNT(*) counts rows while COUNT(col) counts non-null values, and that AVG ignores NULLs, changing the denominator. Write the truth table out during practice.
Confusing instance startup and shutdown phases with database availability, so the candidate says the database is open as soon as the instance is started, or assumes a crashed instance leaves the data files unrecoverable.
Startup is a sequence of named stages (instance started, mounted, open) and candidates memorize the stage names without learning what is accessible at each one. They also fear crash recovery because they do not know that redo and undo make an abrupt termination recoverable.
What to do instead
Learn the stages by what you can query at each one: no data dictionary access before mount, no user data before open. Then learn that instance crash recovery replays redo and rolls back uncommitted transactions automatically on the next open, so the correct answer to 'instance crashed' is usually 'restart and let recovery run', not 'restore from backup'.
Auditing and monitoring questions answered by naming a feature rather than stating what event is captured, where it is written, and who can read it, so the candidate selects a monitoring view when the requirement is a durable audit trail or vice versa.
Performance views and audit trails both look like 'logging' to a candidate, but they differ in retention, mutability, and access control. Candidates also forget that auditing has a cost and that privileged users must not be able to erase their own trail.
What to do instead
For each requirement, ask three questions: is the record needed after restart (durable), must it be tamper-resistant (separate destination, restricted read), and what exactly must be recorded (statement, object, privilege, or login). Match those to the specific audit configuration and destination, and verify who holds read and purge rights on that destination.