Company thought DB2 will be better than Oracle.

[Peter]

Company thought DB2 will be better than Oracle.
The bottom line is when you do select, the system crash.

I think it may take 4-5 years for DB2 to reach Oracle standard.
Peter

[Neil Truby]

"Daniel Morgan" <da******@x.was hington.edu> wrote in message
news:1063411182 .403065@yasure. ..

Mark A wrote: Couldn't possibly be the lack of security without Tivoli or other
similar products?
Couldn't possibly be the lack of training classes?
Couldn't possibly be the lack of books?
Couldn't possibly be the fact that you need a C compiler on a production
box?
Couldn't possibly be the lack of third-party tools and applications?
Couldn't possibly be ....

You forgot to mention that lovely old IBM tradition, BINDing.

[Database Guy]

Larry Edelstein <ls*****@us.ibm .com> wrote in message news:<3F******* ********@us.ibm .com>...

Daniel, [snip] What makes you think that you need a compiler on a production box? I do not
think that is accurate.

Larry Edelstein

Daniel Morgan wrote:

Couldn't possibly be the fact that you need a C compiler on a production
box?

Larry, what makes you think you'll get anything except more stupid
arguments and big fat whopping lies from the Oracle crowd? The moment
you explode one myth they'll pretend that wasn't the point, it was
something else. C'mon, we're talking here about people who believe in
a company that writes its own "independen t reports" - a company for
the dishonest.

GET ROUTINE, PUT ROUTINE, Daniel. You really pretending you didn't
know that, and if you really didn't know something that basic then how
the hell do you figure you are qualified to discuss DB2?
DG

[Larry Edelstein]

Which many people see as an advantage by the way ...

Larry Edelstein

Neil Truby wrote:

"Daniel Morgan" <da******@x.was hington.edu> wrote in message
news:1063411182 .403065@yasure. ..

Mark A wrote:

Couldn't possibly be the lack of security without Tivoli or other
similar products?
Couldn't possibly be the lack of training classes?
Couldn't possibly be the lack of books?
Couldn't possibly be the fact that you need a C compiler on a production
box?
Couldn't possibly be the lack of third-party tools and applications?
Couldn't possibly be ....

You forgot to mention that lovely old IBM tradition, BINDing.

[Larry Edelstein]

Daniel Morgan wrote:

Comments interspersed.

Larry Edelstein wrote:

Daniel,

I don't have any problem with you expressing your opinion. But I do have to set
the record straight.

What lack of security? DB2 uses the underlying OS for authentication security
and has the same internal object security that other rdbmses have. Can you
provide more specifics on what you mean by this and how it manifests itself in
the form of any issues?
My point was not that DB2 was unsecure on mainframes and UNIX ... but
rather on Windows. Because, as demonstrated every week by a bunch of
teenagers and 20 year olds ... the O/S itself is insecure.

Plenty of DB2 training classes. Take a look at the IBM Education schedules.

Exactly. Now try to find them from third-party training facilities here
in Washington State, for example. Or from a community college or a
university? And books? Try Amazon.com for example ... 245 DB2 books and
how many relate to Windows? Then try Oracle ... 1128. Do you see the
issue? And with Oracle there is a single code base an all operating
systems so one book covers all platforms. Something not true with DB2.

I see DB2 classes on the education schedule in Seattle offered by IBM. Why the
"requiremen t" for third-party training? When your execs make a database decision,
what is the business driver/justification behind insisting on third-party training?
Personally, if I were the exec, I'd rather have it from the company that makes the
product.

As I said, why the requirement for a library-full of DB2 books, when you can get
what you need with less? The books are available. Windows, Unix, Linux ... same code
..... same book. Again you're misstating the facts: DB2 Windows, UNIX, Linux are all
exactly the same code base.

I don't understand the class/book thing being a significant decision criteria. I
don't see any issue here at all.

There are some very good DB2 books published on DB2. Do we need tons of them by
different authors each serving the same purpose?
The reference in my post was to DB2 on Windows. Don't try to make it
into something it was not intended to be.

Again ... don't need special books for DB2 on Windows. Next case.

What makes you think that you need a compiler on a production box? I do not
think that is accurate.
From my experience it is. Or do you run your databases without procedures?

You don't need a compiler on a production box to run SPs.

And as far as the third-party tools and applications, I can't believe you took a
swat at that one. There were something like > 40000 last time I checked.
Third party means from companies other than IBM. And once again my
reference was to the Windows platform only.

Same deal. > 40000 apps and increasing on Windows/UNIX/Linux.

Your points are sometimes well-taken. With all due respect, these had some
significant inaccuracies.

Larry Edelstein
Please reconsider. I am a DB2 user so I'm not slamming the product. But
it has its fair share of weaknesses just as all products do. And I just
think it is unfair to slam those that disagree with you as greedy DBAs
that only care about their jobs. Though, as I've also posted ... the
mortgage and putting the kids through college comes light-years before
product loyalty. Neither IBM, nor Oracle, nor Microsoft is writing
checks to me so I'm still responsible for the balance in the checkbook.

Daniel ... again ... please express your opinions :-). But please do some research
and know your facts. On this post, there is almost no point where you have a valid
case.


--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.wash ington.edu
(replace 'x' with a 'u' to reply)

Larry Edelstein

[Neil Truby]

> Larry Edelstein

Neil Truby wrote:

You forgot to mention that lovely old IBM tradition, BINDing.

"Larry Edelstein" <ls*****@us.ibm .com> wrote in message

news:3F******** *******@us.ibm. com...
Which many people see as an advantage by the way ...

Please expand ..?

[Larry Edelstein]

Binding is done to support a feature called Static/Embedded SQL. Static
SQL is suitable for situations where the SQL is somewhat predictable.
You develop the SQL as part of the application code and "embed" it into
the application so to speak. Then, you precompile, compile, link edit,
and BIND the SQL into what is called a package (which essentially is a
Load module). The package is an executable ... and when invoked, no
compilation or bind is necessary ... therefore, the performance tends to
be significantly better than dynamic SQL.

Larry Edelstein

Neil Truby wrote:

Larry Edelstein

Neil Truby wrote:

You forgot to mention that lovely old IBM tradition, BINDing.

"Larry Edelstein" <ls*****@us.ibm .com> wrote in message

news:3F******** *******@us.ibm. com...

Which many people see as an advantage by the way ...

Please expand ..?

[Daniel Morgan]

Daniel ... again ... please express your opinions :-). But please do
some research

and know your facts. On this post, there is almost no point where you have a valid
case.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.was hington.edu
(replace 'x' with a 'u' to reply)

Larry Edelstein

Then please corrrect me. My recollection from a few years ago when I was
doing some DB2 work was that the code base for Windows was different
from that for AIX was different from that for AS/400 was different from
that for VM was different from that for MVS was different from that for
Z-series requiring recompilation with a C compiler on the production
box. And that the C compiler was not included with the database but was
an extra expense.

I'd appreciate a clarification if this is no longer true or my memory is
faulty.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[Noons]

db******@hotmai l.com (Database Guy) wrote in message news:<7f******* *************** ****@posting.go ogle.com>...

Larry, what makes you think you'll get anything except more stupid
arguments and big fat whopping lies from the Oracle crowd?
Oh, just like the "lie" about the multiple code bases?
Which the DB2 "experts" two years ago REFUSED to accept
and has now been openly recognized as the truth?
The moment
you explode one myth they'll pretend that wasn't the point, it was
something else.
Heard that one before many times from the DB2 mob myself.

C'mon, we're talking here about people who believe in
a company that writes its own "independen t reports" - a company for
the dishonest.
and IBM doesn't do that? GMAB, if Oracle is a company for the
dishonest, then IBM is a company for the bigots.

GET ROUTINE, PUT ROUTINE, Daniel. You really pretending you didn't
know that, and if you really didn't know something that basic then how
the hell do you figure you are qualified to discuss DB2?

The problem with some DB2 idiots is they think age of a product
equates to qualification of any incompetent user to argue about it.
Preferably with insulting arguments. Did you really read Daniel's reply?

Nuno Souto
wi*******@yahoo .com.au.nospam

PS: veiled threats do nothing for me. Neither does
open hostility, innuendo posted on newsgroups under
fake ids and all sorts of other DISHONEST techniques.

[Jim Kennedy]

DB2 doesn't do dynamic SQL; it turns dynamic SQL into static SQL and runs
that. If you issue dynamic SQL (and do not commit) then anyone who is
trying to bind after you is hung until you commit. Why? Because the
dynamic sql is bound and a plan is generated, a row is added to the plan
table (thus blocking others from adding to the plan table, until you
commit). Since the concurrency model in db2 is not very concurrent people
issueing dynamic sql lock out those trying to bind their plans in. It
really pisses the developers on the system off. I was at ATT (American
Transtech) years ago with DB2 running on a mainframe and this was a major
problem. So we had to take the application and remove any transactions and
just do everything in an autocommit type of mode.(issue select...;
commit;...etc.)

Binding is a nice and powerfule thing, but the way IBM has implimented it it
really makes DB2 an autocommit only type of database. Ugly real ugly.
Jim

"Larry Edelstein" <ls*****@us.ibm .com> wrote in message
news:3F******** *******@us.ibm. com...

Binding is done to support a feature called Static/Embedded SQL. Static
SQL is suitable for situations where the SQL is somewhat predictable.
You develop the SQL as part of the application code and "embed" it into
the application so to speak. Then, you precompile, compile, link edit,
and BIND the SQL into what is called a package (which essentially is a
Load module). The package is an executable ... and when invoked, no
compilation or bind is necessary ... therefore, the performance tends to
be significantly better than dynamic SQL.

Larry Edelstein

Neil Truby wrote:

Larry Edelstein

Neil Truby wrote:

> You forgot to mention that lovely old IBM tradition, BINDing.
"Larry Edelstein" <ls*****@us.ibm .com> wrote in message

news:3F******** *******@us.ibm. com...

Which many people see as an advantage by the way ...

Please expand ..?

[Mark A]

>Then please corrrect me. My recollection from a few years

ago when I was doing some DB2 work was that the code
base for Windows was different from that for AIX was different
from that for AS/400 was different from that for VM was different
from that for MVS was different from that for Z-series requiring
recompilatio n with a C compiler on the production box. And that
the C compiler was not included with the database but was an extra expense. I'd appreciate a clarification if this is no longer true or my memory is

faulty.

You did not address the questions to me, but I will answer them.

The DB2 code base for Windows, Linux and Unix is 90% the same.

The MVS, VM , and AS/400 products are all different, which is not really a
factor since either Oracle doesn't have a product on these platforms, or the
if they do, the Oracle product is universally known to stink on these
platforms.

If you write stored procedures in C, you will need a compiler, but not sure
if it needs to be on the production machine. But if you say so, I would
concede that point. Stored procedures may also be written in SQL, which is
the preferred method. With regards to the total cost of ownership, I think
that you will find DB2 cheaper or the same as Oracle even with the compiler
expense.