Exadata X3-2 Hardware
 
Exadata Database Machine X2-8
 
Oracle Exadata Hardware
 
Exadata X3-8 Hardware
 
Exadata Database Machine X2-2 Hardware
 
Exadata Database Machine V2
 

PLA-Support>Eng Systems>Exadata/ODA/SSC>Oracle Exadata>DB: Exadata_EST
 

Applies to:

Symptoms

On Physical Standby huge  trace files are generated. Apparently, the information in the files is related to function [kdstProcessSageData].This fills up whole os file partition and cause disk space issues. Content is repeated with the following information:

Sample output:
=========
kcbl_sage_block_check: rdba: 222013433 rdba_kcbh: 222013434 buf:0xf8902130
flag: 0x 5 frmt: 0xa2 data_len: 639128 bsz: 8192
kcbl_sage_block_check: rdba: 222013434 rdba_kcbh: 222013435 buf:0xf8904130
flag: 0x 5 frmt: 0xa2 data_len: 639128 bsz: 8192
kcbl_sage_block_check: rdba: 222013435 rdba_kcbh: 222013436 buf:0xf8906130
flag: 0x 5 frmt: 0xa2 data_len: 639128 bsz: 8192
kcbl_sage_block_check: rdba: 222013436 rdba_kcbh: 222013437 buf:0xf8908130
flag: 0x 5 frmt: 0xa2 data_len: 639128 bsz: 8192
kdstProcessSageData : unknown opcode - 0
kdstProcessSageData : unknown opcode - 0

Cause

The messages seen in the uploaded trace files are printed from
kcbl_sage_block_check & kdstProcessSageData, those messages are informative :
...
kdstProcessSageData : unknown opcode - 0
kcbl_sage_block_check: afn: 1054 rdba: 133053066 rdba_kcbh: 133053066 buf:0x14c64098 flag: 0x 5 frmt: 0xa2 data_len: 966808 bsz: 8192 type: 0

This would happen on Exadata when a block is coming from the cells. The messages show opcode 0, and there's no block corruption.

Tracing of some blocks with opcode = 0 was done unconditional in kcbl.c and kdst.c

From the errorstack we can see the following value for
"_kcfis_dump_corrupt_block" taken.

_kcfis_dump_corrupt_block = 0

This is with ref. to Unpublished Bug 10251666 which internally sets the parameter to
true(the bug is fixed in 11.2.0.3).

Solution

To fix this, the fix to bug 16746889 is required. 
 

References

This solution has no attachment