Re: Extracting Redo Log Info/LogMiner/Shareplex

The actual ROWID doesn't need to change -- when a row expands from, say 200 bytes to 1000 bytes, it may be migrated to a new block (a pointer is kept in the old block pointing to the new location, enabling lookups of the record using the original ROWID, which is just a physical address to the original location of the row). The problem is that LogMiner returns the new location, not the old one -- and we can't use that in a query to look up data (unless there is a hidden function I don't know about).

I agree that not having a primary key is a design issue, and this usually isn't a problem -- except that once in awhile, it is! I've got customers who can't be convinced to change the app, so I need to find workarounds concerning these types of issues.

My recollection of Data Guard 9i is that there are a number of options as you point out. One of the options that I seem to recall, however, was that SQL statements were being reassembled and executed to the backup database. Part of the reason for this was to facilitate different disk/datafile configurations on primary and backup, different db versions, etc. Applying redo information (using the other methods) relies on the datafile config matching up exactly, I think -- the physical layout of the data must be the same on primary and backup in that case. I believe there are other reasons for using statement reassembly as well. That being the case, ROWIDs would be different between primary and backup, and without a primary key I'm not sure how updates could happen. Anyway, if you know where I can dig up more detailed documentation on this, I would love to know, I haven't had much luck.

Finally, what you're saying makes sense as to why the entire redo log must be scanned in order to get the last few records. SCN does not imply any physical location within the redo log, it needs to be hunted down. It would be ideal, I guess, if the block address of each record in the log returned by LogMiner could in turn be used as a starting position in the log.

Eric Received on Fri Sep 28 2001 - 10:59:28 CDT