View Exhibit1 to examine the description of the CUSTOMERS table. The CUSTOMERS table has been updated heavily today. In a frequently used SQL statement, you notice that estimated rows and the actual…

Prof. SaraApr 13, 2026

The correct answer is D, gathering fresh statistics on the CUSTOMERS table using DBMS_STATS. The root cause here is stale statistics. The table has been heavily modified today, which means the optimizer's internal picture of row counts and data distribution no longer matches reality, and that mismatch is exactly what produces a wide gap between estimated and actual rows. Running DBMS_STATS.GATHER_TABLE_STATS will refresh NDV, histograms, and row counts so the optimizer can produce accurate cardinality estimates and pick a sensible plan. Option A is a distractor because STATISTICS_LEVEL set to ALL enables collection of additional execution metrics like row-source stats, but it does nothing to fix outdated object-level statistics already on the table. Option B is wrong because OPTIMIZER_USE_PENDING_STATISTICS governs whether the optimizer reads pending versus published stats, and setting it to FALSE just keeps the optimizer on the published set, which is the very stale set causing the problem in the first place. Option C, extended statistics, addresses correlated columns or expressions, and nothing in the scenario points to a column-group correlation issue. The COUNTRY_ID index hint in the exhibit and the straightforward cardinality mismatch both scream stale stats, so go straight to DBMS_STATS and gather.

Ola B.Apr 18, 2026

The stale stats issue here is a classic one, and after a heavy update day you absolutely want to run DBMS_STATS.GATHER_TABLE_STATS on CUSTOMERS to get the optimizer working with fresh row counts and column distributions. Did you try spinning up a test schema and running the gather before and after a bulk DML operation so you can actually see the execution plan shift in real time, or are you relying purely on the theory here?

Toby R.Apr 9, 2026

I actually leaned toward A at first since STATISTICS_LEVEL ALL enables row source statistics which can help the optimizer, but then I remembered that the real problem here is stale stats on a heavily updated table, so collecting fresh statistics with DBMS_STATS is the direct fix. Setting STATISTICS_LEVEL to ALL just gives you more diagnostic info, it does not actually refresh the underlying table and column stats that the optimizer is reading from.

Lena V.Mar 26, 2026

D is the move here, though the answer choice appears to be cut off and presumably ends with something like "DBMS_STATS.GATHER_TABLE_STATS" - if your exam copy is truncated, context makes it obvious anyway. The table took heavy DML today so stats are stale, which explains the cardinality mismatch between estimated and actual rows, and fresh stats give the optimizer accurate counts to work with. Option A is the classic trap since STATISTICS_LEVEL ALL enables row source execution stats for monitoring but does nothing to fix the underlying stale statistics problem.