No future for DB2

[Madison Pruet]

Re: No future for DB2


"Noons" <wizofoz2k@yaho o.com.au> wrote in message
news:42f11672$0 $11922$5a62ac22 @per-qv1-newsreader-01.iinet.net.au ...[color=blue]
> Madison Pruet apparently said,on my timestamp of 4/08/2005 1:00 AM:
>[color=green][color=darkred]
> >>
> >>If you have SUCH A BIG problem with cross-posting, HOW COME
> >>it's only now you're piping about it? Hmmmm?[/color]
> >
> >
> > Because you stated "that is not possible with ANY replication in any
> > database version." in comp.databases. informix, which is simply not[/color][/color]
true.[color=blue]
>
> That is absolute BULLSHIT. I asked: why did you not complain
> about x-posting before! Nothing to do with replication.
> Not even remotely related. If you want to take the
> "holier than thou" approach, at least be minimally consistent.
> And shove it.
>[color=green]
> >
> > In fact, from what I understand, Oracle streams supports this[/color][/color]
functionality[color=blue][color=green]
> > as well.[/color]
>
> Really? Exactly WHICH functionality is "this" again?
> And you READ manuals now?
>
>[color=green]
> > Well - so far I haven't had to resorted to insults, obscene statements,
> > zingers, or any other form of putdown. I've simply been stating facts.[/color]
>
> I couldn't care less what you "resort" to.
>[color=green]
> > Some of your comments, however, well - they really belong in the
> > locker-room.[/color]
>
> Good. Go see if I'm there.
>
>
> --
> Nuno Souto
> in sunny Sydney, Australia
> wizofoz2k@yahoo .com.au.nospam[/color]

[Noons]

Re: No future for DB2

Peter Nolan apparently said,on my timestamp of 4/08/2005 1:59 AM:

[color=blue]
>
> I am sure IBM Global Services are just as happy to look after an Oracle
> database as a DB2 database as an abacus if they can earn their hourly
> fee for doing so... (LOL)!![/color]

and place heaps of their hordes on the job.
27 dbas in a single project, I counted last time.
As if ANY of them was a dba...

--
Cheers
Nuno Souto
in sunny Sydney, Australia
wizofoz2k@yahoo .com.au.nospam

[Noons]

Re: No future for DB2

Madison Pruet apparently said,on my timestamp of 4/08/2005 5:11 AM:[color=blue]
>
> Noons - based on the misinformation that you've been giving out about Oracle
> DB, I'd suggest you reading it a bit as well. I admit that I don't know
> Oracle that well. That's why I asked the question in the first place. On
> the other hand, it appears that you have been giving out misinformation
> while pretending to be the Oracle expert.[/color]

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?



--
Cheers
Nuno Souto
in sunny Sydney, Australia
wizofoz2k@yahoo .com.au.nospam

[Madison Pruet]

Re: No future for DB2


"Noons" <wizofoz2k@yaho o.com.au> wrote in message
news:42f11672$0 $11922$5a62ac22 @per-qv1-newsreader-01.iinet.net.au ...[color=blue]
> Madison Pruet apparently said,on my timestamp of 4/08/2005 1:00 AM:
>[color=green][color=darkred]
> >>
> >>If you have SUCH A BIG problem with cross-posting, HOW COME
> >>it's only now you're piping about it? Hmmmm?[/color]
> >
> >
> > Because you stated "that is not possible with ANY replication in any
> > database version." in comp.databases. informix, which is simply not[/color][/color]
true.[color=blue]
>
> That is absolute BULLSHIT. I asked: why did you not complain
> about x-posting before! Nothing to do with replication.
> Not even remotely related.[/color]

Noons - you posted misinformation in comp.database.i bm_db2,
comp.databases. informix, and comp.databases. oracle.server. You stated in
those news groups ... well we all know know what you stated. Since you
passed misinformation in those news groups, then it only stands to reason
that the correction also belongs in those news groups.

By the way - since it appears that you have rather limited knowledge about
replication solutions, Sybase replication works by replication the
procedural calls made on the source. Therefor, Sybase replication is
totally in line with what I was talking about.

[Noons]

Re: No future for DB2

Madison Pruet apparently said,on my timestamp of 4/08/2005 5:15 AM:
[color=blue]
> "Noons" <wizofoz2k@yaho o.com.au> wrote in message
> news:42f11672$0 $11922$5a62ac22 @per-qv1-newsreader-01.iinet.net.au ...
>[color=green]
>>Madison Pruet apparently said,on my timestamp of 4/08/2005 1:00 AM:
>>
>>[color=darkred]
>>>>If you have SUCH A BIG problem with cross-posting, HOW COME
>>>>it's only now you're piping about it? Hmmmm?
>>>
>>>
>>>Because you stated "that is not possible with ANY replication in any
>>>database version." in comp.databases. informix, which is simply not[/color][/color]
>
> true.
>[color=green]
>>That is absolute BULLSHIT. I asked: why did you not complain
>>about x-posting before! Nothing to do with replication.
>>Not even remotely related. If you want to take the
>>"holier than thou" approach, at least be minimally consistent.
>>And shove it.
>>
>>[color=darkred]
>>>In fact, from what I understand, Oracle streams supports this[/color][/color]
>
> functionality
>[color=green][color=darkred]
>>>as well.[/color]
>>
>>Really? Exactly WHICH functionality is "this" again?
>>And you READ manuals now?
>>
>>
>>[color=darkred]
>>>Well - so far I haven't had to resorted to insults, obscene statements,
>>>zingers, or any other form of putdown. I've simply been stating facts.[/color]
>>
>>I couldn't care less what you "resort" to.
>>
>>[color=darkred]
>>>Some of your comments, however, well - they really belong in the
>>>locker-room.[/color]
>>
>>Good. Go see if I'm there.
>>[/color][/color]

Can you post something of substance instead of cut and pasting
the original? Or is "cut and paste" your specialty?

--
Cheers
Nuno Souto
in sunny Sydney, Australia
wizofoz2k@yahoo .com.au.nospam

[Noons]

Re: No future for DB2

Frank van Bortel apparently said,on my timestamp of 4/08/2005 5:18 AM:
[color=blue]
>
> Thanks for clarifying that, Montpellier it was.
>
> Well, Montpellier <-> Nice is 275 km.
> Both on the Cote d'Azur. Close enough for me.[/color]

This is Europe you're talking about Frank,
there are entire countries in there smaller
than that! :)


--
Cheers
Nuno Souto
in sunny Sydney, Australia
wizofoz2k@yahoo .com.au.nospam

[Madison Pruet]

Re: No future for DB2


"Noons" <wizofoz2k@yaho o.com.au> wrote in message
news:42f118a8$0 $11917$5a62ac22 @per-qv1-newsreader-01.iinet.net.au ...[color=blue]
> 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?[/color]

Going back to your original mis-statement....
[color=blue]
> [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[/color]
row?[color=blue]
> (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.[/color]

Well - it just isn't true.

[Madison Pruet]

Re: No future for DB2

Noons wrote[color=blue][color=green][color=darkred]
> >>[/color][/color]
>
> Can you post something of substance instead of cut and pasting
> the original? Or is "cut and paste" your specialty?[/color]

No Noons,

Speaking the truth is and being factual is.
[color=blue]
>
> --
> Cheers
> Nuno Souto
> in sunny Sydney, Australia
> wizofoz2k@yahoo .com.au.nospam[/color]

[Madison Pruet]

Re: No future for DB2

"Noons" <wizofoz2k@yaho o.com.au> wrote in message
news:42f117f3$0 $11917$5a62ac22 @per-qv1-newsreader-01.iinet.net.au ...[color=blue]
> Peter Nolan apparently said,on my timestamp of 4/08/2005 1:59 AM:
>
>[color=green]
> >
> > I am sure IBM Global Services are just as happy to look after an Oracle
> > database as a DB2 database as an abacus if they can earn their hourly
> > fee for doing so... (LOL)!![/color]
>
> and place heaps of their hordes on the job.
> 27 dbas in a single project, I counted last time.
> As if ANY of them was a dba...
>[/color]

Noons --- I'd be very careful about talking of the number of DBA's required
to run a database system if I were you. I can quote some fairly impressive
system/dba ratios which are in place for the IBM Informix server.

[Noons]

Re: No future for DB2

Madison Pruet apparently said,on my timestamp of 4/08/2005 5:27 AM:
[color=blue]
> Going back to your original mis-statement....[/color]

Going back to your ORIGINAL statement
[color=blue]
>
>[color=green]
>>[MP]
>>1) replicate all of the trigger activity performed on the original table[/color][/color]

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".
[color=blue][color=green]
>>2) distinguish between updates on a row and inserts/deletes on the same[/color]
> row?
>[color=green]
>> (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.[/color]
> Well - it just isn't true.[/color]

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]

Re: No future for DB2

Madison Pruet apparently said,on my timestamp of 4/08/2005 5:23 AM:[color=blue]
>
> By the way - since it appears that you have rather limited knowledge about
> replication solutions, Sybase replication works by replication the
> procedural calls made on the source. Therefor, Sybase replication is
> totally in line with what I was talking about.[/color]


Yes, yes. Sure...
Does the expression "couldn't care less" register?

--
Nuno Souto
in sunny Sydney, Australia
wizofoz2k@yahoo .com.au.nospam

[Noons]

Re: No future for DB2

Madison Pruet apparently said,on my timestamp of 4/08/2005 5:28 AM:
[color=blue]
> Noons wrote
>[color=green]
>>Can you post something of substance instead of cut and pasting
>>the original? Or is "cut and paste" your specialty?[/color]
>
>
> No Noons,
>
> Speaking the truth is and being factual is.[/color]

Well, reply to the post where your understanding is questioned.
Instead of faning out. A common technique of losers.

--
Cheers
Nuno Souto
in sunny Sydney, Australia
wizofoz2k@yahoo .com.au.nospam

[Noons]

Re: No future for DB2

Madison Pruet apparently said,on my timestamp of 4/08/2005 5:32 AM:[color=blue][color=green]
>>[color=darkred]
>>>I am sure IBM Global Services are just as happy to look after an Oracle
>>>database as a DB2 database as an abacus if they can earn their hourly
>>>fee for doing so... (LOL)!![/color]
>>
>>and place heaps of their hordes on the job.
>>27 dbas in a single project, I counted last time.
>>As if ANY of them was a dba...
>>[/color]
>
>
> Noons --- I'd be very careful about talking of the number of DBA's required
> to run a database system if I were you. I can quote some fairly impressive
> system/dba ratios which are in place for the IBM Informix server.[/color]

Me too. I can even tell you in which project IBMGSA
placed the 27 dbas.

--
Cheers
Nuno Souto
in sunny Sydney, Australia
wizofoz2k@yahoo .com.au.nospam

[Madison Pruet]

Re: No future for DB2


"Noons" <wizofoz2k@yaho o.com.au> wrote in message
news:42f11bd4$0 $11912$5a62ac22 @per-qv1-newsreader-01.iinet.net.au ...[color=blue]
> Madison Pruet apparently said,on my timestamp of 4/08/2005 5:27 AM:
>[color=green]
> > Going back to your original mis-statement....[/color]
>
> Going back to your ORIGINAL statement
>[color=green]
> >
> >[color=darkred]
> >>[MP]
> >>1) replicate all of the trigger activity performed on the original table[/color][/color]
>
> 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[/color]
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.
[color=blue]
>[color=green][color=darkred]
> >>2) distinguish between updates on a row and inserts/deletes on the same[/color]
> > row?
> >[color=darkred]
> >> (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.[/color]
> > Well - it just isn't true.[/color]
>
> Well, it just is true. You just do NOT understand the full
> consequences of your requirement 1) above.[/color]

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[color=blue]
> "responder" .[/color]

[color=blue]
>
> And I also stated that Dataguard indeed can cope with that.
> Something you appear to be forgetting.[/color]

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.

[color=blue]
>
> --
> Nuno Souto
> in sunny Sydney, Australia
> wizofoz2k@yahoo .com.au.nospam[/color]

[Noons]

Re: No future for DB2

Madison Pruet apparently said,on my timestamp of 4/08/2005 6:07 AM:
[color=blue][color=green]
>>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[/color]
> 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.[/color]

I was not talking about triggers on the target nor were you. It's very
clear above. Don't change the subject.
[color=blue]
> 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.[/color]

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.
[color=blue]
> Oh, I wouldn't say that. Let's see now how many replication patents and
> patent-pending am I currently holding? Geesh - keep forgetting. ;-)[/color]

Dear me, I can see why Informix replication is so widespread...
[color=blue]
> And
> just how many customers are employing the solutions that I provide? ---
> quite a few.[/color]

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.
[color=blue]
> 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.[/color]

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