Re: Standby abuse
- From: "Niall Litchfield" <niall.litchfield@xxxxxxxxx>
- To: "Dominic Delmolino" <ddelmoli@xxxxxxx>
- Date: Sat, 8 Nov 2008 20:31:36 +0000
On Fri, Nov 7, 2008 at 11:05 PM, Dominic Delmolino <ddelmoli@xxxxxxx> 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
Other related posts:
