| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: No future for DB2
Madison Pruet apparently said,on my timestamp of 4/08/2005 6:07 AM:
>>So, what happens if a trigger in that table changes ANOTHER >>table that is not being replicated? Do the OTHER table's >>changes get replicated as well? Note: you asked for "ALL trigger
I was not talking about triggers on the target nor were you. It's very clear above. Don't change the subject.
> Or the replication solution can allow the firing of triggers on the target
> node.
>
> Or the trigger can be specified to be always executed if the replication
> apply is executing.
>
> Or the trigger can be specified not to fire if the apply is executing.
>
> Or the replication solution can detect the differences between the
> source/target, and only fire the triggers that are unique on the target.
>
> Or all of the updates associated with the trigger would not be replicated,
> allowing the triggers on the targets to do their stuff.
>
> Or the replication system can detect the differencs in the impact of the
> trigger firing on the target and rereplicate the extra rows which were
> created by triggeractivity on the target back to the source.
>
> Or the individual triggers can be 'replication enabled' and informational
> logging containing the trigger pseudo code can be created for the trigger
> activity - to be replicated and executed on the target system.
>
> Or the create trigger statement can be changed to contain a clause to
> prevent it from being fired as a result of replication.
>
> Or the replication solution can dynamically triggers which can cause a
> problem with replication and dynamically correct the issue by either
> creating a similar trigger on the target, and/or changing the repplication
> attributes so that the result of the trigger would be propogated.
>
> All kinds of ways to deal with this problem.
Fantastic. I couldn't care less about the "or" bits to "deal with this problem". First of all, you didn't even understand the problem. You continue to talk in terms of triggers in the target when they are inconsequential to my question and the verbatim text of your point 1). Read again: "1) replicate all of the trigger activity performed on the original table". That's : *ALL* OF THE TRIGGER ACTIVITY PERFORMED ON THE *ORIGINAL TABLE*. That is a much more complex requirement. I want to know how YOU address it with specific NATIVE Informix replication (or any other product's for that matter). Not "solution" decisions.
Because all your "or"s are nothing more nothing else than design and implementation decisions, not specific product features that you can toggle on or off. If you write it separately as a solution, then you can do ANYTHING with ANY product. Heck, you might even write it in Assembler, for all I care! That is not the theme of this argument: don't want to know how many specific add-ons you have implemented over the years. Not interested.
> Oh, I wouldn't say that. Let's see now how many replication patents and
> patent-pending am I currently holding? Geesh - keep forgetting. ;-)
Dear me, I can see why Informix replication is so widespread...
> And
> just how many customers are employing the solutions that I provide? ---
> quite a few.
I don't think you want to get into a "number of customers" war. Mostly because in the Oracle world replication is NOT a "solution" by itself. We tend to see it as a trivial part of a larger whole. Simple feature to use or not as the case may be. Doesn't need a specific "solution" or a "cast of thousands" to implement. Configure it, enable, done. That easy. No need to patent anything.
> OK - now for the other whammy. How much does Dataguard cost? In the IBM
> Informix database, all of this is part of the base server. No extra charge.
Don't change the subject to the usual TCO crap. If you reword your first request and limit it to changes between MAIN master table and any cascading tables ALSO replicated, you can do all your requests with basic Oracle replication as well. AND snapshot replication. It's a trivial, basic replication setup.
No need for streams as the other respondent (promptly accepted as an "expert" mostly because he said what you wanted to hear) mentioned. Conveniently bypassing the fact streams are only available in EE. Which of course you can use, if you pay for.
You ONLY need Dataguard if you want to do the much more complex requirement of your original 1) request. And it is NOT a separate product. Just a name for a feature. Once again, you assumed too much. Spent too long already at IBM with the "multiple add-on (at a price) features", have we?
-- Nuno Souto in sunny Sydney, Australia wizofoz2k_at_yahoo.com.au.nospamReceived on Wed Aug 03 2005 - 18:03:35 CDT
 |
 |