DA Morgan schreef:
> Frank van Bortel wrote:
>> DA Morgan schreef:
>>> Frank van Bortel wrote:
>>>> DA Morgan schreef:
>>>>
>>>>> Materialized view (older method) and Streams (newer 9i and 10g) and
>>>>> intended for data replication.
>>>> Daniel, are you not mixing up Advanced Replication and MV's?
>>> I don't think so. A materialized view, on its own, will replicate data
>>> but it is not asynchronous and the OP indicated the connection, at
>>> times, may be down. Or at least that's my recollection and I'm sticking
>>> with it. ;-)
>>
>> Erhm... MV's are refreshed when you like them to be refreshed.
>> That's async to me
>
> If you believe in manual intervention and always manually test to see
> that the connection is up and always do a complete refresh.
>
> (apart from refresh groups, that can refresh
>> synchronously/asynchronously - internal to the group).
>
> The difference is that if the DB Link is down it doesn't automatically
> catch up ... streams does.
>

Ah - yes, that Streams does.
>
>> Same for AR - AR uses MV's, or at least; it can.
>>>>> I would suggest you ignore Materialized Views if, as you previously
>>>>> stated, the connection may be down. Streams is asynchronous and can
>>>>> play catch-up. Materialized views are a maintenance nightmare.
>>>> AR can be - MV's - nope
>>> My point. And AR is not in the same galaxy, maintenance-wise as Streams.
>>
>> Streams would be a valid choice for the OP, but I find it a
>> bigger nightmare than MV's - even with additional logging.
>
> You've got to be kidding. ;-)
>
Hmmm - no. Ever tried Streams to get sync'ed on 9.2.0.4? I gave up,
and ended in just rebuilding the whole shabang.
Bottom-line: I discarded Streams as a possible solution for this
particular project; in 9.2 it simply did not seem mature enough.
And as the OP has a mix of 9i and 10g....

> Streams is easy and there are a large number of live-demos on the web,
> such as mine at at www.psoug.org that are literally cut-and-paste jobs
> to put into use.
>
>> MV's seem out of the question, as the OP wants parts of tables
>> (this column yes, this not) only - not sure Streams can handle
>> that, nor how conflict resolution works (which does work
>> rather well with Advanced Replication)
>
> Streams can handle it with ease.
OK, if you say so - not been there.

--
Regards,
Frank van Bortel

Top-posting is one way to shut me up...

I'm reading up on Streams now. The docs say data that is changed due
to invocation of PL/SQL procedures isn't included in the LCRs. Does
anyone know if that includes data created in schema triggers? In my
app, inserting a row into a table might cause a trigger on that table
to insert a row into a different table. I would imagine that as long
as I have Streams set up to capture DML changes in both of the tables,
I should be OK...

Oh, and to answer an earlier question: when I say "component library",
I'm talking about the component-related data stored in my DB -
components being physical things (such as wires / tape / tubing) that
have part numbers.

Cheers,
Tarby