Re: First 17 updated records disappeared from REDOLOG files …
- From: Tanel Põder <tanel.poder.003@xxxxxxx>
- To: "Jurijs Velikanovs" <j.velikanovs@xxxxxxxxx>, "ORACLE-L" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 22 Feb 2006 13:49:57 -0700
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.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
