RE: Logical DG won't work with ROWIDs period, right?

From: Mark W. Farnham <>
Date: Mon, 10 Mar 2014 10:44:23 -0400
Message-ID: <013601cf3c6f$3b7c1de0$b27459a0$>

Are you talking about rowids that are developed in the process of running a query on the target? That should work.

Are you talking about supporting update queries of the form update <some_table> set {some column assignments} where rowid in (<some list of rowids on the source>)?
That will not work.

The process of sql apply to the target cannot work for any statement that attempts to change anything at some specific place in some specific file from the source, because that location on the target may not exist or may be for some other logical entity even if it exists.

Next question: Do you need Active Dataguard? That depends on how quickly you want to be able to query changes on the target. If something like "as of last night at midnight" is good enough and IF you have space and appropriate technology to cancel recovery, make a cold clone of the target, startup rename reset redologs of the clone, and then resume recovery on the target, then you only need regular physical recovery (one of the flavors of which is DG.)

Since changes are no longer being applied to the "frozen clone" it also allows the opportunity for aggregations and index augmentations that would be inappropriate for a continuously changing database. Whether or not this is useful in any particular case varies. Given sufficient space (which might be minimized with technology such as Delphix), it can be extremely useful to the user community to have reports and aggregations as of month and quarter ends without having to affix appropriate time as of clauses to queries.

Did I mention this is not the appropriate solution for everyone? Check. We probably do not need a laundry list of the cases where it is less good than active DG, since I hope most of them are obvious.


-----Original Message-----

From: [] On Behalf Of Rich Jesse
Sent: Monday, March 10, 2014 9:26 AM
Subject: Logical DG won't work with ROWIDs period, right?

Hey all,

Just looking for some outside confirmation: I've read in the docs that "ROWID datatypes" are not supported for a logical data guard setup in 11.2. I assume that to mean that queries and DML with ROWID in the WHERE clause will fail to copy?

I understand that logical DG is a SQL apply and that ROWIDs do not have to match, but that seems different from saying the datatype isn't supported. I take that to mean a column in a table rather than a SQL statement.

I'm thinking we're going to need Active Data Guard then, in order to get our reporting DB... [sigh]



-- Received on Mon Mar 10 2014 - 15:44:23 CET

Original text of this message