Re: Standby abuse

From: Dominic Delmolino <ddelmoli_at_cox.net>
Date: Mon, 10 Nov 2008 11:21:44 -0500
Message-ID: <d2a8d6b70811100821laeed2b8uac477984051d6b44@mail.gmail.com>


All good -- I agree, for a COTS application it probably wouldn't be a good idea to rely on Logical Standby for DR.
On the "Real Application" front -- too funny -- one of the reasons I'm looking at Logical is to potentially handle limited nologging operations (index rebuilds in particular). I know you can "force logging", but in that case you might as well fight the battle to remove the nologging operations altogether, since "force logging" is just a sneaky way to ignore the directive.

Gosh I don't like designs which allow duplicate rows -- messy and difficult to clean-up. Having done replication for years, I'm sensitive to the issue.

On Sat, Nov 8, 2008 at 3:31 PM, Niall Litchfield <niall.litchfield_at_gmail.com
> wrote:

> On Fri, Nov 7, 2008 at 11:05 PM, Dominic Delmolino <ddelmoli_at_cox.net>wrote:
>
>
>> Excellent points, Niall.
>>
>
> Thanks .
>
>
>
>> *****
>> Oracle Apps are NOT certified to run against Logical Standby per Metalink:
>>
>>
>> From Note 285267.1<https://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=285267.1&blackframe=1>Oracle E-Business Suite 11i and Database FAQ
>>
>> *1. Is Logical Standby supported with E-Business Suite 11i ?
>> *No. Logical standby is not supported with E-Business Suite 11i.The
>> interoperability notes do not cover how to upgrade a logical Oracle
>> Applications database and data
>> corruption in a logical database is covered in these notes.
>> It is recommended to use a "physical standby database" to guard against
>> potential data corruption.
>> Some datatypes utilized by Ebusiness Suite are not supported with logical
>> Standby database,
>> and NOLOGGING tables are used e-Bus in some places as well.
>>
>>
>>
> I rather thought that was the case, it seems to me that any solution that
> is not vendor supported (I misused certified earlier I think) is somewhat
> problematic to consider as a DR solution for a critical business app. I also
> didn't mention, but probably should have that logical's "new" status rather
> mitigates against it as a DR solution for me. I really want my DR to be
> bullet proof. Logical may get there, but I'm not convinced yet.
>
>
>
>> *****
>> For the lack of primary keys and unique indexes, Logical DG handles them
>> as long as their are steps taken to uniquely identify the row:
>>
>
> I rather thought that might be the case - I've been fighting a downstream
> capture streams replication for a client, which is another sql apply based
> technology - The docs for that say emphasis mine
>
>
>> Substitute Key Columns
>>
>> If possible, each table for which changes are applied by an apply process
>> should have a primary key. When a primary key is not possible, Oracle *
>> recommends* that each table have a set of columns that can be used as a
>> unique identifier for each row of the table. If the tables that you plan to
>> use in your Streams environment do not have a primary key or a set of unique
>> columns, then *consider* altering these tables accordingly.
>>
>> <snip>
>>
>> In the absence of substitute key columns, primary key constraints, and
>> unique key constraints, an apply process uses all of the columns in the
>> table as the key columns, excluding LOB, LONG, and LONG RAW columns. In
>> this case, you must create an unconditional supplemental log group
>> containing these columns at the source database. *Using substitute key
>> columns is preferable* when there is no primary key constraint for a
>> table because fewer columns are needed in the row LCR.
>>
>> Now my reading of this was that although primary/unique constraints were
> highly desirable for obvious reasons for sql apply, they weren't required -
> Oracle didn't seem to me to be using mandatory language above. In common
> with only about 85% of all applications the schemas that need replication
> don't actually either have unique constraints (and as a result have
> duplicate rows). Working through an SR with Oracle right now it seems like
> SQL apply works great if you have a well designed schema, and doesn't work
> when you, er, don't. I'd imagine much the same applies to Logical Standby -
> i.e if you have a data model that has at least a passing familiarity with
> constraints and data integrity - if not necessarily the relational model
> itself - then it will probably work fine. If it's a "Real Application"
> (sorry) it probably won't be reliable.
>
>
>
>
> --
> Niall Litchfield
> Oracle DBA
> http://www.orawin.info
>

-- 
Dominic Delmolino

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Nov 10 2008 - 10:21:44 CST

Original text of this message