原文链接：

http://www.dbaleet.org/how_to_diagnostic_wrong_result_issue_caused_by_smart_scan/

虽然错误结果（Wrong Result）对于Oracle数据库来说并不是什么新鲜的事情，例如如果有细读过Patchset bugfix list， 就能看到其中有一个专门的主题就是列出导致错误结果的各种bug。 但是实际上因Exadata导致的错误结果的现象并不多见。由于Smart Scan本身的机制比较复杂，而且Exadata存储软件本身是个黑盒，所以在诊断的时候往往感到无从下手。以下是Smart Scan导致错误结果的诊断流程：虽然并不是很实用，但是通过它，可以隐约亏测到一些关于Smart Scan的内部机制。

以下摘 自Exadata: How to diagnose smart scan and wrong results (Doc ID 1260804.1)

STEP 1. Set cell_offload_processing = FALSE

Wrong results still occur?
Yes – a data layer issue
No – smart scan problem. Restore parameter’s default value; go to (2)

STEP 2. Set _kcfis_cell_passthru_enabled = TRUE

Wrong results still occur?
Yes – not an FPLIB problem. Restore parameter default value; go to (3)
No – most likely a FPLIB problem

STEP 3. Set _kcfis_storageidx_disabled = TRUE

Wrong results still occur?
Yes – not a storage index problem. Restore parameter default value; go to (4)
No – most likely a storage index problem

STEP 4. If RDBMS is 11.2.0.1 set _kcfis_control1=1.

    If RDBMS is 11.2.0.2 and later, set  _kcfis_kept_in_cellfc_enabled = FALSE

Wrong results still occurs?
Yes – not a flash cache problem. Restore parameter defaults; go to (5)
No – most likely a flash cache issue

STEP 5. Set _kcfis_rdbms_blockio_enabled = TRUE

Wrong results still occurs?
Yes – problem is a kcfis issue
No – problem could still be a kcfis issue. This is somewhat of a gray area.
The investigation should start with kcfis

It may be required to get the dump of corrupted blocks.

If RDBMS  is 11.2.0.2 or later:

set _kcfis_dump_corrupt_block
TRUE – Dump any corrupt block, seen in smart IO code path, to rdbms trace file for the process
FALSE – (default) – Corrupt blocks are dumped only if none of the mirrors had a good copy.

If RDBMS is  11.2.0.1:

set _kcfis_control2
0 – (default) – Corrupt blocks are dumped only if none of the mirrors had a good copy.
1 – Dump any corrupt block, seen in smart IO code path, to rdbms trace file for the process