Re: First 17 updated records disappeared from REDOLOG files …

> I've noted that redo file generated in that case is bit bigger then
> with _in_memory_undo=false
> true => 6656 KB
> false => 7168 KB
> supplemental logging => 10752 KB
> This is seems understandable.

How did you test the redo generation? I saw some strange things happening, that with the same test case occasionally way more or less of redo was generated (which means that my test case wasn't adequate enough).

> I wonder if just because of a LogMiner bug Oracle pushing people to
> use Supplemental Logging to utilize LogMiner or there are additional
> reasons for that?

At least for Streams & Logical Standby it makes sense to log primary key values, as the rowid's on target databases are different.

> One indirect indication that it is LogMiner bug is the fact that
> Oracle FlashBack feature working normally even with
> _in_memory_undo=true. Other session can access and read undo
> information in a shared pool area.

Well, logminer reads redo, flashback only undo. I think logminer just can't handle the private redo record format. There have been other similar issues when using log_parallelism > 1 in 9.2.

> Is IMU feature means that now Oracle introduce two types of undo
> pointers in datablock headers. One type is regular one pointing to the
> rollback header other type points to IMU area?

I think the pointers are still the same, it's just somewhere deeper in KT layer that when we see locking transaction being an IMU one, we go and do an IMU CR rollback (creating a CR copy using undo from IMU buffer). It can seen from statistic "IMU CR rollbacks" and "In memory undo" latch gets.

Tanel.

--
http://www.freelists.org/webpage/oracle-l