You are working on a decision support system (DSS). The index is available on the COUNTRY_ID column of the CUSTOMERS table. View the Exhibit and examine the parameter settings and the query…

Yusuf A.Apr 22, 2026

The answer is D, and once my senior walked me through how the optimizer thinks, it clicked right away. The Cost-Based Optimizer does not just check whether an index exists, it actually estimates how many blocks the query will touch. When it figures out that a large chunk of the table rows match the predicate, doing random single-block reads through the index ends up costing more than just scanning the whole table with multiblock reads. Option C trips people up because DB_FILE_MULTIBLOCK_READ_COUNT does play a role in making full scans cheaper, but that parameter is not the reason the optimizer chose the path, it just affects how cheap that path is. The real driver is that the optimizer ran its cost math and decided the index route would cause more I/O, not less, so it went with the full table scan. DSS workloads are especially prone to this because they tend to pull broad ranges of data rather than a few targeted rows.

Nina C.Apr 16, 2026

Honestly I kept second-guessing C because a high DB_FILE_MULTIBLOCK_READ_COUNT does make full scans cheaper and I thought that was the whole point of that parameter, but the plan itself is what it is because the optimizer looked at the selectivity and decided the index was not worth it, meaning it expected to touch most of the table blocks anyway. So D is correct, the optimizer ran its cost math and concluded a full scan was cheaper than bouncing back and forth through the index for the majority of rows.

Anjali D.Apr 5, 2026

Group says D, but what cost threshold actually tips the optimizer?

Luis F.Mar 30, 2026

Okay so I totally went with C at first because I saw DB_FILE_MULTIBLOCK_READ_COUNT set high and thought yeah that parameter is making full scans look cheap so that has to be it. But then I reread the question more carefully and realized that parameter just lowers the cost of a full scan, it does not explain WHY the optimizer chose it in the first place. The real reason is D, because when the CBO crunches the numbers and sees that the query touches a huge chunk of the table rows, like in a typical DSS workload where you are aggregating across many countries, it figures a full scan with big multiblock reads is just faster than bouncing around the index doing tons of random single-block I/O hits. Basically the selectivity on COUNTRY_ID is so low that the index becomes a liability, not a shortcut, and the optimizer is smart enough to figure that out from the stats.

Carlos M.Apr 27, 2026

The DB_FILE_MULTIBLOCK_READ_COUNT being set high makes multiblock reads so cheap that the optimizer sees a full scan as faster than random single-block index lookups, especially on a DSS workload where you're hitting a big chunk of the table anyway. That parameter directly skews the cost calculation in favor of full scans, which is exactly what we're seeing here.