Re: Oracle multi-master replicaiton: index generation necessary?

In article <SVpa9.15576$g9.48494_at_newsfeeds.bigpond.com>, "Richard says...
>
>
>"Nuno Souto" <nsouto_at_optushome.com.au.nospam> wrote in message
>news:3d6a2476$3$28861$afc38c87_at_news.optusnet.com.au...
>> In article <IMoa9.15474$g9.49128_at_newsfeeds.bigpond.com>, you said (and I
>> quote):
>> > Just a little snippet from the Oracle documentation:
>> >
>> > When replicating tables with foreign key referential constraints, Oracle
>> > Corporation recommends that you always index foreign key columns and
>> > replicate these indexes, unless no updates and deletes are allowed in
>the
>> > parent table. *Indexes are not replicated automatically*.
>>
>> Hmm, interesting. I don't have that in my replication book. Which
>> version?
>
>This is from 9i doco although I believe the same applies to 8i.
>
>>
>> I think they mean cascaded. Not replicated.
>>
>> >
>> > So your comment that indexes are not replicated is not strictly speaking
>> > correct.
>>
>> I'm not sure myself. The darn thing changes from point version to point
>> version!
>
>Tell me about it !!
>
>>
>> >
>> > Also note that it's not good practice as such to have PK on replicated
>> > tables. You *must* have a PK if a table is to be replicated, else you
>get an
>> > error trying to add the table to a replicated group.
>>
>> Hang on, that doesn't make sense at all. I must have a PK if it is to be
>> replicated but it's not good practice to have PK on replicated table?
>> What am I missing here?
>
>My subtle distinction between 'best practice' where you have a choice but
>one option is better than the other vs. *must* when you have no choice and
>it will either work or not work. I don't think you can add a table to a
>master to master replicated group if it doesn't have a PK.

Gee I love it when you're wrong Richard! ;)

There is a way to tell Oracle what the PK would be if you were allowed to have one (I believe this was specifically added to support packages where you can't change the application, but I could be wrong). It's the SET_COLUMNS procedure of DBMS_REPCAT.

Pete
>
>Cheers
>
>Richard
>
>>
>>
>> --
>> Cheers
>> Nuno Souto
>> nsouto_at_optushome.com.au.nospam
>
>

HTH. Additions and corrections welcome.

Pete

SELECT standard_disclaimer, witty_remark FROM company_requirements; Received on Mon Aug 26 2002 - 11:52:12 CDT