Re: No future for DB2

"Noons" <wizofoz2k@yahoo.com.au> wrote in message news:42f118a8$0$11917$5a62ac22@per-qv1-newsreader-01.iinet.net.au... > Madison Pruet apparently said,on my timestamp of 4/08/2005 5:11 AM: > > I never "pretended to be an Oracle expert", dickhead. > Once again, you're letting your imagination run rampant. > Try sticking to facts. WHICH part was the misinformation? Going back to your original mis-statement.... > [MP] >1) replicate all of the trigger activity performed on the original table > 2) distinguish between updates on a row and inserts/deletes on the same row? > (If not, then cascade deletes are not properly performed) > 3) properly handle cascading updates > >[Noons]If I understand your question correctly, that is not possible >with ANY replication in any database version. Well - it just isn't true.

Madison Pruet apparently said,on my timestamp of 4/08/2005 5:27 AM: > Going back to your original mis-statement.... Going back to your ORIGINAL statement > > >>[MP] >>1) replicate all of the trigger activity performed on the original table 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 activity". >>2) distinguish between updates on a row and inserts/deletes on the same > row? > >> (If not, then cascade deletes are not properly performed) >>3) properly handle cascading updates >> >>[Noons]If I understand your question correctly, that is not possible >>with ANY replication in any database version. > Well - it just isn't true. Well, it just is true. You just do NOT understand the full consequences of your requirement 1) above. Nor does the other "responder". And I also stated that Dataguard indeed can cope with that. Something you appear to be forgetting. -- Nuno Souto in sunny Sydney, Australia wizofoz2k@yahoo.com.au.nospam

"Noons" <wizofoz2k@yahoo.com.au> wrote in message news:42f11bd4$0$11912$5a62ac22@per-qv1-newsreader-01.iinet.net.au... > Madison Pruet apparently said,on my timestamp of 4/08/2005 5:27 AM: > > > Going back to your original mis-statement.... > > Going back to your ORIGINAL statement > > > > > > >>[MP] > >>1) replicate all of the trigger activity performed on the original table > > 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 activity". At a minimun the replication solution should be able to either prevent triggers from firing on the target if it is populated by a replication apply, with the assumption (and policing) that all of the tables associated with original transaction is replicated as part of that transaction. 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. > > >>2) distinguish between updates on a row and inserts/deletes on the same > > row? > > > >> (If not, then cascade deletes are not properly performed) > >>3) properly handle cascading updates > >> > >>[Noons]If I understand your question correctly, that is not possible > >>with ANY replication in any database version. > > Well - it just isn't true. > > Well, it just is true. You just do NOT understand the full > consequences of your requirement 1) above. Oh, I wouldn't say that. Let's see now how many replication patents and patent-pending am I currently holding? Geesh - keep forgetting. ;-) And just how many customers are employing the solutions that I provide? --- quite a few. Nor does the other > "responder". > > And I also stated that Dataguard indeed can cope with that. > Something you appear to be forgetting. 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. > > -- > Nuno Souto > in sunny Sydney, Australia > wizofoz2k@yahoo.com.au.nospam

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 > activity". > > At a minimun the replication solution should be able to either prevent > triggers from firing on the target if it is populated by a replication > apply, with the assumption (and policing) that all of the tables associated > with original transaction is replicated as part of that transaction. 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@yahoo.com.au.nospam

"Noons" <wizofoz2k@yahoo.com.au> wrote in message news:42f14d48$0$11928$5a62ac22@per-qv1-newsreader-01.iinet.net.au... > 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 > > activity". > > > > At a minimun the replication solution should be able to either prevent > > triggers from firing on the target if it is populated by a replication > > apply, with the assumption (and policing) that all of the tables associated > > with original transaction is replicated as part of that transaction. > > I was not talking about triggers on the target nor were you. It's very > clear above. Don't change the subject. > > > 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. > 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). > Fair enough --- on the IDS informix server, to do this with say 5 instances by issueing the two commands cdr define template noons --database=noons --master=node1 --all cdr realize template noons --syncdatasource=node1 node2 node3 node4 node5 This would set up an update anywhere of everything in the noons database using the five servers.

Madison Pruet wrote: > At a minimun the replication solution should be able to either prevent > triggers from firing on the target if it is populated by a replication > apply, with the assumption (and policing) that all of the tables associated > with original transaction is replicated as part of that transaction. Yes, there is a function that should be called in an updateable MV target table trigger DBMS_MVIEW.I_AM_A_REFRESH. It returns FALSE if trigger is fired by local changes, and TRUE if trigger is fired by replication.

"Mark Malakanov" <markmal@rogers.com> wrote in message news:xLydnbH1n-Pl8GzfRVn-tQ@rogers.com... > > Madison Pruet wrote: > > At a minimun the replication solution should be able to either prevent > > triggers from firing on the target if it is populated by a replication > > apply, with the assumption (and policing) that all of the tables associated > > with original transaction is replicated as part of that transaction. > > Yes, there is a function that should be called in an updateable MV > target table trigger DBMS_MVIEW.I_AM_A_REFRESH. It returns FALSE if > trigger is fired by local changes, and TRUE if trigger is fired by > replication. >

"Mark Malakanov" <markmal@rogers.com> wrote in message news:xLydnbH1n-Pl8GzfRVn-tQ@rogers.com... > > Madison Pruet wrote: > > At a minimun the replication solution should be able to either prevent > > triggers from firing on the target if it is populated by a replication > > apply, with the assumption (and policing) that all of the tables associated > > with original transaction is replicated as part of that transaction. > > Yes, there is a function that should be called in an updateable MV > target table trigger DBMS_MVIEW.I_AM_A_REFRESH. It returns FALSE if > trigger is fired by local changes, and TRUE if trigger is fired by > replication. > That's a good feature. But is there a way to prevent the trigger from firing without having to make the trigger aware of the fact that replication exists? Otherwise, wouldn't it be difficult to use replication with third party applications?

Madison Pruet wrote: > "Mark Malakanov" <markmal@rogers.com> wrote in message > news:xLydnbH1n-Pl8GzfRVn-tQ@rogers.com... > >>Madison Pruet wrote: >> >>>At a minimun the replication solution should be able to either prevent >>>triggers from firing on the target if it is populated by a replication >>>apply, with the assumption (and policing) that all of the tables > > associated > >>>with original transaction is replicated as part of that transaction. >> >>Yes, there is a function that should be called in an updateable MV >>target table trigger DBMS_MVIEW.I_AM_A_REFRESH. It returns FALSE if >>trigger is fired by local changes, and TRUE if trigger is fired by >>replication. >> > > > That's a good feature. But is there a way to prevent the trigger from > firing without having to make the trigger aware of the fact that replication > exists? Otherwise, wouldn't it be difficult to use replication with third > party applications? > > > I'm afraid it would be difficult. Triggers should be modified. If you have third-party app that was not designed for replication, you could use Advanced Replication, that works via Streams and AQ and is practically transparent to the app. But it is lincensed separately.:( AR is very powerful thing, mainly because it allows to resolve data collisions using many standard and custom methods, and can work with a close to real time latency. So depending on the scenario, you can use Standard R with full or fast refreshes, groups, for one-direction replication. I doubt that you will run the same app on the replica. Usually it is some kind of reporting DB. If you need two(several) identical DBs with identical apps, that actively work by-directionally, you have to go with AR, and to think about collision resolutions. but... what was an initial question? :)

"Mark Malakanov" <markmal@rogers.com> wrote in message news:Na2dnez77IBP62zfRVn-2Q@rogers.com... > Madison Pruet wrote: > > "Mark Malakanov" <markmal@rogers.com> wrote in message > > news:xLydnbH1n-Pl8GzfRVn-tQ@rogers.com... > > > >>Madison Pruet wrote: > >> > >>>At a minimun the replication solution should be able to either prevent > >>>triggers from firing on the target if it is populated by a replication > >>>apply, with the assumption (and policing) that all of the tables > > > > associated > > > >>>with original transaction is replicated as part of that transaction. > >> > >>Yes, there is a function that should be called in an updateable MV > >>target table trigger DBMS_MVIEW.I_AM_A_REFRESH. It returns FALSE if > >>trigger is fired by local changes, and TRUE if trigger is fired by > >>replication. > >> > > > > > > That's a good feature. But is there a way to prevent the trigger from > > firing without having to make the trigger aware of the fact that replication > > exists? Otherwise, wouldn't it be difficult to use replication with third > > party applications? > > > > > > > I'm afraid it would be difficult. Triggers should be modified. Mark - you are cross-posting to comp.databases.informix. Believe me, I'm fully aware of how difficult this is, and also how important it is to make replication seemless for user and third-party applications. IBM Informix Enterprise Replication supports the ability to dynamically fire or not fire the triggers based on wheither the update is performed by a user thread or by the replication apply. That means no modification of the trigger body is required to support replication, even though the tables have triggers defined. Informix Enterprise Replication also has the option to permit selective firing of the triggers. On some tables you might fire them; on others not. Since by default, triggers are not fired on the targets, we are able to fairly easily configure the system to replicate all of the tables within the database without having to modify the triggers that are supporting the application. Or I can again fairly easily define a subset of tables within the database that I want to replicate as a group. Basically replicate all of the related tables affected by the firing of the triggers and not firing any triggers on the target.

Madison Pruet apparently said,on my timestamp of 4/08/2005 9:21 AM: > > Fair enough --- on the IDS informix server, to do this with say 5 instances > by issueing the two commands > > cdr define template noons --database=noons --master=node1 --all > cdr realize template noons --syncdatasource=node1 node2 node3 node4 node5 > > This would set up an update anywhere of everything in the noons database > using the five servers. Thank you. Like I suspected, you have to relicate the entire database. It is much more efficient to do that in Oracle via dataguard. Like I said nearly 24 hours ago. Of course, you can also template the entire database and replicate the lot. Anything is possible, provided you have sufficient resources. -- Nuno Souto in sunny Sydney, Australia wizofoz2k@yahoo.com.au.nospam

"Noons" <wizofoz2k@yahoo.com.au> wrote in message news:42f1ede1$0$11939$5a62ac22@per-qv1-newsreader-01.iinet.net.au... > Madison Pruet apparently said,on my timestamp of 4/08/2005 9:21 AM: > > > > Fair enough --- on the IDS informix server, to do this with say 5 instances > > by issueing the two commands > > > > cdr define template noons --database=noons --master=node1 --all > > cdr realize template noons --syncdatasource=node1 node2 node3 node4 node5 > > > > This would set up an update anywhere of everything in the noons database > > using the five servers. > > Thank you. Like I suspected, you have to relicate the entire database. > It is much more efficient to do that in Oracle via dataguard. Like > I said nearly 24 hours ago. Of course, you can also template > the entire database and replicate the lot. Anything is possible, > provided you have sufficient resources. No Noons. You asked how I would do it, not how it had to be done. Since the IBM Informix Enterprise Replication uses less than 10% of the total resources, it is simply easier to replicate the whole DB. And since disks are so cheap now, I would have difficulty not justifying having a multi-node grid like arrangement so that the applications could be active on any of the replicated nodes. > > -- > Nuno Souto > in sunny Sydney, Australia > wizofoz2k@yahoo.com.au.nospam

"Madison Pruet" <mpruet@comcast.net> wrote > Since the IBM Informix Enterprise Replication uses less than 10% of the > total resources, it is simply easier to replicate the whole DB. And since > disks are so cheap now, I would have difficulty not justifying having a > multi-node grid like arrangement so that the applications could be active on > any of the replicated nodes. so what you are saying is that with ER on a multi node replication (all updating each other) one can develop a grid aware application which can not only provide high availability, but also load balancing. A friend of mine in USA is working on a project like this only. He says it is incredible.