Sorry for the repost, but got zero replies to this post when first sent a
couple of weeks ago, and would really appreciate and advice or pointers
....

Hi all,

First of all - IANADBA. I'm just a developer / project manager.

Oracle 10.2.0.3 RAC cluster on Intel Linux, ASM on a SAN.

We have a series of instances on our RAC cluster, some of which support
largish 3rd party applications and some "developed in-house" including an
embrionic MIS DW.

Several of these need to exchange data, and currently this is being
achieved using a mix of bulk overnight partial copies and (near real-time,
some delay acceptable) table triggers.

I am keen to investigate the option of shifting to a consolidated approach
using Oracle Change Data Capture (aka Streams).

At some stage in the future we are also unfortunately likely to need to
add a MSSQL database (via Heterogenous Replication?) to this mix.

I've read (and absorbed a fraction of) the Oracle Streams Replication
Administrator's Guide, and think that the configuration option that will
best suit our needs is "Asynchronous AutoLog archive" mode.

Can any Streams-savvy people provide any general advice as to whether I'm
heading down the right or wrong path?

TIA

Geoff M

Geoff Muldoon wrote:
One stop further, materialized views - possibly with refresh on commit.
Only then (two stops further, one stop extra would be
Advanced Replication) comes Streams. There's quite a lot of
overhead in Streams, so make sure you stress test (when going
with Streams) in a production-like setup.

Frank

Geoff Muldoon wrote:
One stop further, materialized views - possibly with refresh on commit.
Only then (two stops further, one stop extra would be
Advanced Replication) comes Streams. There's quite a lot of
overhead in Streams, so make sure you stress test (when going
with Streams) in a production-like setup.

Frank

Geoff Muldoon wrote:
One stop further, materialized views - possibly with refresh on commit.
Only then (two stops further, one stop extra would be
Advanced Replication) comes Streams. There's quite a lot of
overhead in Streams, so make sure you stress test (when going
with Streams) in a production-like setup.

Frank

Geoff Muldoon wrote:
One stop further, materialized views - possibly with refresh on commit.
Only then (two stops further, one stop extra would be
Advanced Replication) comes Streams. There's quite a lot of
overhead in Streams, so make sure you stress test (when going
with Streams) in a production-like setup.

Frank

Frank van Bortel says...
As stated, it's one of the main methodologies we currently use. There are
particular issues here (to do amongst other thing with application vendor
support, grrr) with that approach, which is one of the reasons we are
looking at Streams.

An option, but likely to face the same obstacles here as the triggers
approach.

We are particularly looking at Asynchronous Change Data Capture because it
"can be configured to have minimal performance impact on the source
database", so I presume you refer to overheads at the staging database and
overall server resource levels, rather than within the source databases.
Maybe overheads of the subscriber databases too?

Thanks for your thoughts, appreciated.

Geoff M

Frank van Bortel says...
As stated, it's one of the main methodologies we currently use. There are
particular issues here (to do amongst other thing with application vendor
support, grrr) with that approach, which is one of the reasons we are
looking at Streams.

An option, but likely to face the same obstacles here as the triggers
approach.

We are particularly looking at Asynchronous Change Data Capture because it
"can be configured to have minimal performance impact on the source
database", so I presume you refer to overheads at the staging database and
overall server resource levels, rather than within the source databases.
Maybe overheads of the subscriber databases too?

Thanks for your thoughts, appreciated.

Geoff M

Frank van Bortel says...
As stated, it's one of the main methodologies we currently use. There are
particular issues here (to do amongst other thing with application vendor
support, grrr) with that approach, which is one of the reasons we are
looking at Streams.

An option, but likely to face the same obstacles here as the triggers
approach.

We are particularly looking at Asynchronous Change Data Capture because it
"can be configured to have minimal performance impact on the source
database", so I presume you refer to overheads at the staging database and
overall server resource levels, rather than within the source databases.
Maybe overheads of the subscriber databases too?

Thanks for your thoughts, appreciated.

Geoff M

Frank van Bortel says...
As stated, it's one of the main methodologies we currently use. There are
particular issues here (to do amongst other thing with application vendor
support, grrr) with that approach, which is one of the reasons we are
looking at Streams.

An option, but likely to face the same obstacles here as the triggers
approach.

We are particularly looking at Asynchronous Change Data Capture because it
"can be configured to have minimal performance impact on the source
database", so I presume you refer to overheads at the staging database and
overall server resource levels, rather than within the source databases.
Maybe overheads of the subscriber databases too?

Thanks for your thoughts, appreciated.

Geoff M

Geoff Muldoon wrote:

No - source. Hopefully, things have improved with 10G; 9.2.0.4 was
simply a disaster.
Oh - and do not forget about maintenance on Streams; if something
goes wrong, you're probably screwed. try to test and break things,
and see if you can get them repaired. And document that thoroughly!
FvB