db2 vs oracle

**Larry** · Jun 27 '08, 06:41 PM

Re: db2 vs oracle

OK ... so you cross-post to comp.databases. ibm-db2 and
comp.databases. oracle with a subject line of "db2 vs. Oracle", and then
you request no flame wars? I won't hold my breath!

At the SQL level (as you put it), DB2 employs ANSI SQL ... and is the
only RDMBS vendor to employ a stored procedure language that complies
with ANSI's PSM standard.

Larry

Mike wrote:

No flame wars, please!
>
We're planning a move from a non-relational system to
a relational system. Our choices have been narrowed to
Oracle and DB2. Since we're moving from non-relational
to relational, then we're not currently using any
relational-type operators. So I expect the end result to
use simple, SQL standard commands and queries.
>
The question: At the SQL standard level is there any
appreciable difference between Oracle and DB2.
>
Example: I know that Oracle has cascading deletes. We're
not using them now so I don't expect to use them with the
new system.
>
Thanks.
>
Mike

**Buck Nuggets** · Jun 27 '08, 06:41 PM

Re: db2 vs oracle

Mike <mikee@mikee.at h.cxwrote in message news:<10ipe6fjj r7k156@corp.sup ernews.com>...

The question: At the SQL standard level is there any
appreciable difference between Oracle and DB2.

The simple answer is no: each have their own strengths & weaknesses,
but these tend to be nuances and each are otherwise very ansi sql
compliant.

The complex answer is it depends: on exactly what you want to do with
this database. I've had to make quite a few purchasing
recommendations in the past, and to be honest, sql features has never
been a deciding factor (between major commercial products). Licensing
costs, vendor strategy, vendor/product viability, solution
managability, skills availability, third-party support, performance &
scalability - these were the factors that typically influenced the
decision the most.

DB2 & Oracle are very competitive in my opinion. Oracle has more
mindshare, third-party support, and features than DB2 does. DB2 is
slightly more primitive, but also simpler and cheaper. DB2 also has
some very high-end scalability capabilities if you're in the data
warehousing world.

Coming from flat files, vsam, ims/db, or mysql these db2 & oracle
probably look about the same. But once you get much closer and start
working with them the differences loom large. ;-)

**Daniel Morgan** · Jun 27 '08, 06:41 PM

Re: db2 vs oracle

Buck Nuggets wrote:

Mike <mikee@mikee.at h.cxwrote in message news:<10ipe6fjj r7k156@corp.sup ernews.com>...
>
>

>>The question: At the SQL standard level is there any
>>appreciable difference between Oracle and DB2.

>
>
The simple answer is no: each have their own strengths & weaknesses,
but these tend to be nuances and each are otherwise very ansi sql
compliant.
>
The complex answer is it depends: on exactly what you want to do with
this database. I've had to make quite a few purchasing
recommendations in the past, and to be honest, sql features has never
been a deciding factor (between major commercial products). Licensing
costs, vendor strategy, vendor/product viability, solution
managability, skills availability, third-party support, performance &
scalability - these were the factors that typically influenced the
decision the most.
>
DB2 & Oracle are very competitive in my opinion. Oracle has more
mindshare, third-party support, and features than DB2 does. DB2 is
slightly more primitive, but also simpler and cheaper. DB2 also has
some very high-end scalability capabilities if you're in the data
warehousing world.
>
Coming from flat files, vsam, ims/db, or mysql these db2 & oracle
probably look about the same. But once you get much closer and start
working with them the differences loom large. ;-)

I too am responding from the Oracle usenet group but my comments will
be as non-inflammatory as possible.

A. Based on what you posted either product could meet your needs as the
information you provided is nearly as substantial as a vacuum.

B. What internal skills do you and your team have? You indicate no
prior knowledge of SQL. Do you think you are going to pick up either
of these products without classes and books? Have you looked for local
classes? Have you looked at the book resources available? Have you
looked for local expert resources to support and mentor your team?

C. What operating systems are you and your team familiar with? Do you
expect to be running this on Windows? Linux? some flavour of UNIX?
mainframes?

D. What are your security requirements? Are you expecting to host a
web site?

E. What are your anticipated transaction volumes in terms of number of
transactions? Number of simultaneous transactions? Transaction sizes?

F. Does what you are building require a front-end? GUI? Web?
Client-Server? What tools? What connection mechanism?

I could list a good 20 to 30 more without even beginning to exhaust
the basic criteria that are the minimum set from which your decision
should be made.

Absent these answers anything you get in a usenet group will be worth
what you paid for it.
--
Daniel A. Morgan
University of Washington
damorgan@x.wash ington.edu
(replace 'x' with 'u' to respond)

**michael newport** · Jun 27 '08, 06:41 PM

Re: db2 vs oracle

which choices did you look at ?

did you consider Ingres ?

**robert** · Jun 27 '08, 06:41 PM

Re: db2 vs oracle

Mike <mikee@mikee.at h.cxwrote in message news:<10ipe6fjj r7k156@corp.sup ernews.com>...

No flame wars, please!
>
We're planning a move from a non-relational system to
a relational system. Our choices have been narrowed to
Oracle and DB2. Since we're moving from non-relational
to relational, then we're not currently using any
relational-type operators. So I expect the end result to
use simple, SQL standard commands and queries.
>
The question: At the SQL standard level is there any
appreciable difference between Oracle and DB2.
>
Example: I know that Oracle has cascading deletes. We're
not using them now so I don't expect to use them with the
new system.
>
Thanks.
>
Mike

at the sql syntax level, there's not much difference Ov10 vs. DB2v8.

on the other hand: oracle and db2 use diametrically opposite
concurrency
mechanisms. oracle is said to require more husbanding than oracle.
on
the other hand, 390 db2 is just as needy. oracle is said to be a dog
on
the 390 (at least by blue folk). oracle is pretty much the same on
any platform. db2 is pretty much different on any platform. oracle
has
most of the mindshare on *nix (except AIX, natch), and it's largest
install segment. it doesn't exist (IIRC) on AS/400.

there are studies which show Total Cost of Ownership to be higher with
oracle. ditto db2.

your biggest effort, should you choose to do so (most COBOL/VSAM folk
don't), is defining a relational structure which balances the
concurrency
stuff you get free in a (R)DBMS with the existing code base, which
was/will be doing it too. you'll need to decide. if you use the DB
concurrency stuff, you should remove it from the code. if you leave
it
in the code, you'll get it from the DB anyway, and performance could
be
anywhere from a little worse to in the toilet. depends.

hire a consultant. one that has documented experience with systems on
your platform and oracle and db2 on that platform. it's your only
hope.

**Daniel Morgan** · Jun 27 '08, 06:42 PM

Re: db2 vs oracle

Comments in-line.

at the sql syntax level, there's not much difference Ov10 vs. DB2v8.
>
on the other hand: oracle and db2 use diametrically opposite
concurrency
mechanisms. oracle is said to require more husbanding than oracle.

Perhaps in the past. Certainly not with 10g.

on the other hand, 390 db2 is just as needy. oracle is said to be a dog
on the 390 (at least by blue folk). oracle is pretty much the same on
any platform. db2 is pretty much different on any platform. oracle
has
most of the mindshare on *nix (except AIX, natch), and it's largest
install segment. it doesn't exist (IIRC) on AS/400.
>
there are studies which show Total Cost of Ownership to be higher with
oracle. ditto db2.
>
your biggest effort, should you choose to do so (most COBOL/VSAM folk
don't), is defining a relational structure which balances the
concurrency
stuff you get free in a (R)DBMS with the existing code base, which
was/will be doing it too. you'll need to decide. if you use the DB
concurrency stuff, you should remove it from the code. if you leave
it
in the code, you'll get it from the DB anyway, and performance could
be
anywhere from a little worse to in the toilet. depends.
>
hire a consultant. one that has documented experience with systems on
your platform and oracle and db2 on that platform. it's your only
hope.

I absolutely agree. And make sure the consultant is equally familiar
with both. A carpenter will favour a hammer even when confronted with
a sheet metal screw.

--
Daniel A. Morgan
University of Washington
damorgan@x.wash ington.edu
(replace 'x' with 'u' to respond)

**Ollie** · Jun 27 '08, 06:42 PM

Re: db2 vs oracle

Daniel Morgan <damorgan@x.was hington.eduwrot e in message news:<109358052 4.649947@yasure >...

Comments in-line.
>

at the sql syntax level, there's not much difference Ov10 vs. DB2v8.

on the other hand: oracle and db2 use diametrically opposite
concurrency
mechanisms. oracle is said to require more husbanding than oracle.

>
Perhaps in the past. Certainly not with 10g.
>

on the other hand, 390 db2 is just as needy. oracle is said to be a dog
on the 390 (at least by blue folk). oracle is pretty much the same on
any platform. db2 is pretty much different on any platform. oracle
has
most of the mindshare on *nix (except AIX, natch), and it's largest
install segment. it doesn't exist (IIRC) on AS/400.

there are studies which show Total Cost of Ownership to be higher with
oracle. ditto db2.

your biggest effort, should you choose to do so (most COBOL/VSAM folk
don't), is defining a relational structure which balances the
concurrency
stuff you get free in a (R)DBMS with the existing code base, which
was/will be doing it too. you'll need to decide. if you use the DB
concurrency stuff, you should remove it from the code. if you leave
it
in the code, you'll get it from the DB anyway, and performance could
be
anywhere from a little worse to in the toilet. depends.

hire a consultant. one that has documented experience with systems on
your platform and oracle and db2 on that platform. it's your only
hope.

>
I absolutely agree. And make sure the consultant is equally familiar
with both. A carpenter will favour a hammer even when confronted with
a sheet metal screw.

You're using a wrong approach to determine the RDBMS that will suit
your need. The kind of application you're thinking of running should
be the first concern. Are you goning to be running OLTP, DDS or
datawarehouse application. I don't think Oracle will bet UDB, Sybase
or SQL Server when it comes to OLTP application. As far as
datawarehouse is concern, Sybase has a specific product that is design
for that specific application called Sybase IQ.

The mistake organization make when picking database platform is the
same kind I am seeing from the approach you're taken. If you running
mission critical application, then you should be concern about backup
and recovery. Oracle backup and recovery is too complicated otherwise
they won't need a 4 days training seesion on the topic. It takes a
couple of hours to teach the same function in other platform. My point
is that you have to think of what is important in the application
you're running.

**Daniel Morgan** · Jun 27 '08, 06:42 PM

Re: db2 vs oracle

You're using a wrong approach to determine the RDBMS that will suit

your need. The kind of application you're thinking of running should
be the first concern. Are you goning to be running OLTP, DDS or
datawarehouse application. I don't think Oracle will bet UDB, Sybase
or SQL Server when it comes to OLTP application. As far as
datawarehouse is concern, Sybase has a specific product that is design
for that specific application called Sybase IQ.

Not according to a lot of published benchmarks. And not according to
the owners of the biggest OLTP systems on the planet.

But then what does Sybase have to do with the OP's question? The
OP specifically stated a choice between DB2 and Oracle and most likely
either would work just fine. So comments about SQL Server and Sybase
are irrelevant.

The mistake organization make when picking database platform is the
same kind I am seeing from the approach you're taken. If you running
mission critical application, then you should be concern about backup
and recovery. Oracle backup and recovery is too complicated otherwise
they won't need a 4 days training seesion on the topic. It takes a
couple of hours to teach the same function in other platform. My point
is that you have to think of what is important in the application
you're running.

BTW: Oracle backup and recovery unless you are still working with some
Paleolithic version consists of a few mouse clicks in OEM. So your
comments indicate little but ignorance about the product.

--
Daniel A. Morgan
University of Washington
damorgan@x.wash ington.edu
(replace 'x' with 'u' to respond)

**Hans Forbrich** · Jun 27 '08, 06:42 PM

Re: db2 vs oracle

Flame wars .... here we come! <sigh>

Ollie wrote:

You're using a wrong approach to determine the RDBMS that will suit
your need. The kind of application you're thinking of running should
be the first concern. Are you goning to be running OLTP, DDS or
datawarehouse application. I don't think Oracle will bet UDB, Sybase
or SQL Server when it comes to OLTP application. As far as
datawarehouse is concern, Sybase has a specific product that is design
for that specific application called Sybase IQ.

Oracle is as good, if not better, with OLTP as the others.

Like any environment, you have to understand it properly to be able to use
it properly.

Statements like "I don't think Oracle will bet UDB, Sybase or SQL Server
...." generally are based on "I learned how to do it efficiently on 'x' but
those principals don't apply to 'y' therefore 'y' is bad."

Of course, Ollie is using a traditional 'more competitor names is relevant'
tactic, conveniently forgetting that Sybase sold their soul to Microsoft by
giving them what is now SQL Server.

>
The mistake organization make when picking database platform is the
same kind I am seeing from the approach you're taken. If you running
mission critical application, then you should be concern about backup
and recovery. Oracle backup and recovery is too complicated otherwise
they won't need a 4 days training seesion on the topic. It takes a
couple of hours to teach the same function in other platform. My point
is that you have to think of what is important in the application
you're running.

Oracle Backup and Recovery is not difficult - you do need to understand it
though. Since backups are really only relevant for recovery, the course is
designed to give a large number of scenarios in recovery that you actually
practise so that you do not need to 'practise' or look like a dodo to
mamangement when a crash actually occurs.

Besides, the course includes other items, such as Oracle Networking.

My point is that Ollie is attempting to use irrelevant information, or pure
FUD, to prove his point.

Religion in software, like ignorance, is bliss.

/Hans

**Mike** · Jun 27 '08, 06:42 PM

Re: db2 vs oracle

In article <82f47a3c.04082 70444.633be454@ posting.google. com>, Ollie wrote:

Daniel Morgan <damorgan@x.was hington.eduwrot e in message news:<109358052 4.649947@yasure >...

>Comments in-line.
>>

at the sql syntax level, there's not much difference Ov10 vs. DB2v8.
>
on the other hand: oracle and db2 use diametrically opposite
concurrency
mechanisms. oracle is said to require more husbanding than oracle.

>>
>Perhaps in the past. Certainly not with 10g.
>>

on the other hand, 390 db2 is just as needy. oracle is said to be a dog
on the 390 (at least by blue folk). oracle is pretty much the same on
any platform. db2 is pretty much different on any platform. oracle
has
most of the mindshare on *nix (except AIX, natch), and it's largest
install segment. it doesn't exist (IIRC) on AS/400.
>
there are studies which show Total Cost of Ownership to be higher with
oracle. ditto db2.
>
your biggest effort, should you choose to do so (most COBOL/VSAM folk
don't), is defining a relational structure which balances the
concurrency
stuff you get free in a (R)DBMS with the existing code base, which
was/will be doing it too. you'll need to decide. if you use the DB
concurrency stuff, you should remove it from the code. if you leave
it
in the code, you'll get it from the DB anyway, and performance could
be
anywhere from a little worse to in the toilet. depends.
>
hire a consultant. one that has documented experience with systems on
your platform and oracle and db2 on that platform. it's your only
hope.

>>
>I absolutely agree. And make sure the consultant is equally familiar
>with both. A carpenter will favour a hammer even when confronted with
>a sheet metal screw.

>
You're using a wrong approach to determine the RDBMS that will suit
your need. The kind of application you're thinking of running should
be the first concern. Are you goning to be running OLTP, DDS or
datawarehouse application. I don't think Oracle will bet UDB, Sybase
or SQL Server when it comes to OLTP application. As far as
datawarehouse is concern, Sybase has a specific product that is design
for that specific application called Sybase IQ.
>
The mistake organization make when picking database platform is the
same kind I am seeing from the approach you're taken. If you running
mission critical application, then you should be concern about backup
and recovery. Oracle backup and recovery is too complicated otherwise
they won't need a 4 days training seesion on the topic. It takes a
couple of hours to teach the same function in other platform. My point
is that you have to think of what is important in the application
you're running.

Thank you and everyone for your opinion. I have DBA'd and
developed for most databases out there (Oracle, Sybase,
Informix, Unify, Ingres, open source, etc.) except
for DB2. I know and understand their strengths and
weaknesses. I also very well understand my company's
current application and where they want to be in two years.
While most find my original question too general to answer,
and being general felt I was focusing on the wrong aspects
of my needs, I asked the question intentionally and have
received the responses I need.

Mike

**Daniel Morgan** · Jun 27 '08, 06:42 PM

Re: db2 vs oracle

Data Goob wrote:

In the book they mention that Oracle is more about applications than the
database.

And this is a surprise to you? Where have you been hiding?

Certainly the grid is
interesting, but it is not necessarily clustering, nor is it really even
applicable to a lot of business requirements. Oracle will be a big nut
to crack in an organization that has never used a relational database.

Cracking Oracle and cracking DB2 are of equivalent difficulty. But your
comments about "grid" and "clustering " in the same sentence demonstrate
a lack of understanding about what "grid" means to Oracle.

--
Daniel A. Morgan
University of Washington
damorgan@x.wash ington.edu
(replace 'x' with 'u' to respond)

**Data Goob** · Jun 27 '08, 06:42 PM

Re: db2 vs oracle

I remain jealous of you Daniel for having access to really good weed! It seems
to have the intended effect. Must be that stuff from Vancouver I heard about.

Anyway since you opened the door...

DB2 is far less difficult to understand and master than Oracle. More specifically
Oracle is the difficult database, whereas DB2 is a breeze to install and use.

Oracle is a collection of disparate pieces of bolt-on software that requires years
to "master" and lots of people to make it successful. This is why it is happy
in larger organizations and completely inappropriate in smaller ones. DB2
has a clearly defined scalability that Oracle has yet to implement. Instead
Oracle continues to opt for smoke and mirrors. 10g has yet to be proven in
the business world as even relevant, much less RAC ( bwaahahaaaa! :-) I would
say DB2 and SQL-Server are more equivalent in ease of use, but the differentiator
in DB2 is that it can scale way beyond what SQL-Server can, on low-cost hardware,
and O/S. Oracle requires a lot of money, time, and hardware, something I would
be very concerned about as a business wanting to be competitive and keep costs
down. Of course if money is no issue, go for Oracle, it will increase Larry's
wallet and decrease your own. Ford Motor by the way recently decided that using
Oracle was a good learning experience, but not suitable for their business after
what, 5 years of dicking around with it. ( See Eweek )

Daniel Morgan wrote:

Data Goob wrote:
>

>In the book they mention that Oracle is more about applications than the
>database.

>
>
And this is a surprise to you? Where have you been hiding?
>

>Certainly the grid is
>interesting, but it is not necessarily clustering, nor is it really even
>applicable to a lot of business requirements. Oracle will be a big nut
>to crack in an organization that has never used a relational database.

>
>
Cracking Oracle and cracking DB2 are of equivalent difficulty. But your
comments about "grid" and "clustering " in the same sentence demonstrate
a lack of understanding about what "grid" means to Oracle.
>

**Jim Kennedy** · Jun 27 '08, 06:42 PM

Re: db2 vs oracle

"Data Goob" <datagoob@hotma il.comwrote in message
news:7x3Yc.202$ Qy4.36@fe10.use netserver.com.. .

I remain jealous of you Daniel for having access to really good weed! It

seems

to have the intended effect. Must be that stuff from Vancouver I heard

about.

>
Anyway since you opened the door...
>
DB2 is far less difficult to understand and master than Oracle. More

specifically

Oracle is the difficult database, whereas DB2 is a breeze to install and

use.

>
Oracle is a collection of disparate pieces of bolt-on software that

requires years

to "master" and lots of people to make it successful. This is why it is

happy

in larger organizations and completely inappropriate in smaller ones. DB2
has a clearly defined scalability that Oracle has yet to implement.

Instead

Oracle continues to opt for smoke and mirrors. 10g has yet to be proven

in

the business world as even relevant, much less RAC ( bwaahahaaaa! :-) I

would

say DB2 and SQL-Server are more equivalent in ease of use, but the

differentiator

in DB2 is that it can scale way beyond what SQL-Server can, on low-cost

hardware,

and O/S. Oracle requires a lot of money, time, and hardware, something I

would

be very concerned about as a business wanting to be competitive and keep

costs

down. Of course if money is no issue, go for Oracle, it will increase

Larry's

wallet and decrease your own. Ford Motor by the way recently decided

that using

Oracle was a good learning experience, but not suitable for their business

after

what, 5 years of dicking around with it. ( See Eweek )
>
>

You know not what you write about. I worked for a company that included
Oracle as the database for an Electronic Medical Records company who's main
customers were ambulatory care centers. (Your standard Dr.'s office) The
customer did not need nor did they have a DBA or even an IS department on
staff. Someone who was desktop savy could install the whole system from the
excellent step by step documentation. (we started on Oracle 7.1 which was
current at the time) People ran it for many years without a problem and as
long as they followed the procedures in our manual (eg backup, hot or cold)
then they didn't have any problems even if they had to restore. They
usually called us for restores. We were installed at several thousand sites
all across the US. Dr. offices are very cheap and they did not willingly
hire people just to administer the system. We supported Oracle running on a
variety of platforms. (Netware, NT, HPUX, and if we had a larger QA
department could have easily supported Sun and AIX. QA, understandably,
wanted to run complete regression passes for every platform. With about 150
employees in the entire company at the time, there were just not enough
resources to reasonably do it.)

So one can set things up incorrectly and cause all sorts of headaches and
make work, but if you take a little care and set it up right you don't have
to spend time screwing around.

So you are completely wrong. Oracle has gotten easier to administer since
7.1.
Jim

Daniel Morgan wrote:
>

Data Goob wrote:

In the book they mention that Oracle is more about applications than

the

database.

And this is a surprise to you? Where have you been hiding?

Certainly the grid is
interesting, but it is not necessarily clustering, nor is it really

even

applicable to a lot of business requirements. Oracle will be a big nut
to crack in an organization that has never used a relational database.

Cracking Oracle and cracking DB2 are of equivalent difficulty. But your
comments about "grid" and "clustering " in the same sentence demonstrate
a lack of understanding about what "grid" means to Oracle.

>

**Data Goob** · Jun 27 '08, 06:42 PM

Re: db2 vs oracle

Jim,

Thanks for your comments. I disagree that I'm 'completely' wrong, but it
doesn't really matter, I'm not using Oracle. Oracle is a beast of a pig
all the way around, but you would only know that if you used something
besides Oracle. Oracle has excellent marketing, pay no attention to the
man behind the curtain.

Thanks!

Jim Kennedy wrote:

>
>
You know not what you write about. I worked for a company that included
Oracle as the database for an Electronic Medical Records company who's main
customers were ambulatory care centers. (Your standard Dr.'s office) The
customer did not need nor did they have a DBA or even an IS department on
staff. Someone who was desktop savy could install the whole system from the
excellent step by step documentation. (we started on Oracle 7.1 which was
current at the time) People ran it for many years without a problem and as
long as they followed the procedures in our manual (eg backup, hot or cold)
then they didn't have any problems even if they had to restore. They
usually called us for restores. We were installed at several thousand sites
all across the US. Dr. offices are very cheap and they did not willingly
hire people just to administer the system. We supported Oracle running on a
variety of platforms. (Netware, NT, HPUX, and if we had a larger QA
department could have easily supported Sun and AIX. QA, understandably,
wanted to run complete regression passes for every platform. With about 150
employees in the entire company at the time, there were just not enough
resources to reasonably do it.)
>
So one can set things up incorrectly and cause all sorts of headaches and
make work, but if you take a little care and set it up right you don't have
to spend time screwing around.
>
So you are completely wrong. Oracle has gotten easier to administer since
7.1.
Jim
>