Re: Extracting Redo Log Info/LogMiner/Shareplex

I know very little about Shareplex, so I can't say much about it other than my understanding is that its use is not supported by Oracle (I believe you rely on Shareplex for support). Oracle doesn't support any mechanism that I know of for mining the redo logs except the LogMiner product. That's why we brought it out.

Onto your questions. Support for reading chained and migrated rows is one of the new features of LogMiner in Oracle9i. Earlier versions could not read them. Also, you can turn on at the table or database level the ability to capture primary key information with the SQL statements in 9i. By that I mean the SQL_REDO and SQL_UNDO columns of V$LOGMNR_CONTENTS will contain statements that include "WHERE rowid='extended_rowid_format' and primary_key_column = 'value'". You can then remove the rowid= bit of the clause and apply the update to any database that uses the same PK value. To enable this, you need to store supplemental redo log information (the PK may not be in the redo logs otherwise unless it is directly impacted by the SQL statement). These supplemental redo logs obviously require more work by the database, so you may not want to turn it on database wide for performance reasons.

As for the making LogMiner more efficient, I'm not really sure what the problem is here. The START_LOGMNR procedure has been able to take STARTSCN and ENDSCN or STARTTIME and ENDTIME parameters to restrict what is read. Or am I missing something here?

--
HTH.  Additions and corrections welcome.

Pete
Author of "Oracle8i: Architecture and Administration Exam Cram"
Now got a life back again that the book is released!

"Controlling developers is like herding cats."
Kevin Loney, Oracle DBA Handbook

"Oh no, it's not.  It's much harder than that!"
Bruce Pihlamae, long-term Oracle DBA

"Eric" <bytewarrior2000_at_yahoo.com> wrote in message
news:497b38b.0109250931.2ffc1978_at_posting.google.com...


> I'd like to be able to extract information about transactions from the

> redo logs.  I've looked at LogMiner, and I know some of Quest

> Shareplex's capabilities.  I have a variety of questions remaining:

>

> If a row is migrated from one block to another (because it no longer

> fits in the original block), can LogMiner capture the original rowid?

> From some tests I've run, it appears not, and this prevents the

> capture of the original row.

>

> Can Shareplex deal with rows which don't have a primary key; putting

> it another way, can Shareplex replicate updates to a row using the

> rowid instead of the primary key?

>

> Is there a way, using the rowid which LogMiner returns, to select the

> corresponding migrated row out of the database -- "SELECT * from TABLE

> where ROWID = <logminer rowid>" won't work, since the logminer rowid

> appears to be the physical location of the row.  How does Shareplex

> deal with this issue, if the original rowid isn't available in the

> redo log -- does this involve setting up some type of extraneous

> mapping from the original row to the new row?

>

> Are there plans to enhance LogMiner to be more efficient for

> applications which need to continually process new data in the logs?

> Currently, LogMiner reads all the way through the log (very resource

> intensive), even if you only need the last 10 seconds of data.

>

> Thanks