Advantage of DB2 over Oracle?
Ryan Gaffuri
Could I have some details? Im not looking for a debate. Just find it useful
to compare and contract.
BTW, what operating systems can DB2 run on?
lsu...@mb.sympatico.ca
wrote:
I'm not familiar enough with Oracle to make a meaningful comparison
but I can give you a list of the OS envirnoments that are supported
AIX, AS/400 (built in), z/OS (390 mainframes) Unix, Solaris, Linux,
OS/2, Windows (and others ...)
--
Lorne Sunley
The King Bee
1. lower upfront licensing costs
2. easier upgrades and migrations (more stable api)
3. lower total cost of ownership (mostly driven by ratio of dba's to
applications)
4. better price performance
5. a better thought out product (developer APIs and administration is more
intuitive - see 3)
6. superior business intelligence (datamart/datawarehouse) platform
Having said that Oracle is an excellent product and my second choice if I
can't have db2
"Ryan Gaffuri" <rkg...@erols.com> wrote in message
news:a6e01u$md2$1...@bob.news.rcn.net...
Serge Rielau
http://www-3.ibm.com/software/data/pubs/pdfs/bloor.pdf
Cheers
Serge
--
Serge Rielau
DB2 UDB SQL Compiler Development
IBM Software Lab, Canada
Dana Rothrock
riding it or eating it.
DB2 is looking more like Oracle everyday, so there will be plenty of work for
performance engineers in the future.
DB2 was an OLTP database. IMS still runs rings around it.
The problem is that Oracle runs on servers that can be dedicated to Oracle
applications. When applications begin to bog down, then you start to replicate
databases, buy more servers, build network infrastructure, etc., etc.
DB2 is designed from the IBM model of "One Corporate Database". It is not
going to perform well with replication, BLOBs, 256-byte column names, etc.
Foreign Keys (ie., "relational") are enough to degrade OLTP to tears.
Just throw processor and DASD at it (and money), or design systems to process
data, instead of pretty color pictures.
ramakrishna kolluru
1. DB2 is cheaper than Oracle
2. If you want to do a lot of development using sql then Oracle is
your choice.
3. If partitioning of data is a criteria especially in Data Warehouse
choose Oracle (it supports hash,range,list,composite) . DB2 support
only hash paritionning. and you need to have DB2 EEE verion of
software.
Jeremy Rickard
> 1. DB2 is cheaper than Oracle
> 2. If you want to do a lot of development using sql then Oracle is
> your choice.
> 3. If partitioning of data is a criteria especially in Data Warehouse
> choose Oracle (it supports hash,range,list,composite) . DB2 support
> only hash paritionning. and you need to have DB2 EEE verion of
> software.
On the other hand, the (currently) much more advanced DB2 UDB
optimiser appears to have a genuine lead on the competition with
complex ad-hoc queries (TPC-H). This may be quite pertinent for data
warehousing. Whereas the OLTP performance seems more much of a
muchness.
Jeremy Rickard
Larry Edelstein
fact, this is one of DB2's strengths (DB2 UDB EEE). Especially for large warehouses, I would say that DB2 UDB EEE has
proven scalability and is the db of choice.
Larry Edelstein
robert
from personal experience (and extrapolating to similar organizations), DB2
is the choice for os/390 shops with decades old COBOL/VSAM code.
these folks don't know any better; take VSAM file defs, load them
into DB2, and tell the customers that the system has been "converted"
to a relational database.
if you're starting from scratch, and don't have to support such
COBOL code, stay away from DB2. on the mainframe, it's just a sluggish
layer over VSAM; each table has at least two o/s files; the
tools are abysmal.
toodles,
robert
Obnoxio The Clown
Don't hold back now -- tell us how you _really_ feel!
The King Bee
warehousing. I'm guessing you don't have any real world experience.
"ramakrishna kolluru" <rkol...@yahoo.com> wrote in message
news:372ebe2.02031...@posting.google.com...
Obnoxio The Clown
<doug_...@hotmail.com> wrote:
>sorry dude. you blew your credibility suggesting Oracle beats db2 for data
>warehousing. I'm guessing you don't have any real world experience.
He didn't say that. He said that Oracle had better partitioning
options, and he's right. I suspect this is one of the first things
that the Informix XPS developers will be putting into EEE.
blair kenneth adamache
does. Imagine how successful these companies would be if they didn't have to deal with that
"sluggish" layer over VSAM. Then again, maybe they're the world's largest companies because
they do know that they're doing.
blair kenneth adamache
than companies that have competed with two separate products (i.e. Oracle 8 and Oracle OPS, Informix IDS and XPS).
New clustering strategies to give more choices than hash for all DB2 products (Workgroup and Enterprise) are in
the final testing stages. And, you can easily partition by range with DB2 using UNIONs:
http://www7b.boulder.ibm.com/dmdd/library/techarticle/0202zuzarte/0202zuzarte.pdf
Obnoxio The Clown
<adam...@stopspamca.ibm.com> wrote:
>Pretty amazing that the Fortune 100 all run DB2 on OS/390, and that 80% of the Fortune 500
>does. Imagine how successful these companies would be if they didn't have to deal with that
>"sluggish" layer over VSAM. Then again, maybe they're the world's largest companies because
>they do know that they're doing.
I've seen several large companies, and none of them struck me as
successful because they know what they are doing. In some cases it was
blind luck, in others it was monopoly or oligopoly, others grew by
acquisition of totally unrelated companies.
I'm not disputing your technical argument, only your business case.
:-)
Mark Townsend
adam...@stopspamca.ibm.com wrote on 3/18/02 11:56 AM:
> two separate products (i.e. Oracle 8 and Oracle OPS )
Care to elaborate on the code differences between the two ?
Serge Rielau
I think in order to acquire companies you need money..
And to keep that system working you must be able to keep those acquired technologies in good
shape to make more money (to buy more companies).
I highly doubt that blind luck helps you beyond a few years of success, just liek playing the
lottery is no pension plan.
You could "blame" DB2's success on luck (namely Oracle p.o-ing it's partners).
Oracle's success could be called luck (namely IBM didn't believe in Unix, and Informix and Sybase
screwed up).
Microsoft got lucky because IBM picked DOS instead of CPM, screwed up OS/2 marketing and Sybase
was foolish enough to sell the source of their DBMS.
But at the end of the day it's always one company that executes something better than another.
Oracle saw where IBM goofed. IBM saw where Oracle goofed (or not - time will show) and so it goes
on and on.
The real revelation (to me) is that technology is frightingly underrepresented in this picture.
DOS wasn't better than CPM, Windows wasn't better than OS/2. Oracle wasn't better than Informix.
But it wasn't about luck.
Obnoxio The Clown
wrote:
>I think in order to acquire companies you need money..
This is a charming display of naivete. Just look at what Ardent did
with Informix -- they used Informix's money to leverage themselves
into a much more financially substantial position. But even legitimate
mergers and acquisitions are rarely done out of the company's coffers.
Special shares are issued, bonds, deals, yada-yada.
>And to keep that system working you must be able to keep those acquired technologies in good
>shape to make more money (to buy more companies).
I wasn't just referring to technology companies. I was more thinking
of companies like GE.
>I highly doubt that blind luck helps you beyond a few years of success, just liek playing the
>lottery is no pension plan.
I don't think it's fair to play on _just_ luck as a factor. Often,
it's a combination of these and other factors.
>You could "blame" DB2's success on luck (namely Oracle p.o-ing it's partners).
>Oracle's success could be called luck (namely IBM didn't believe in Unix, and Informix and Sybase
>screwed up).
>Microsoft got lucky because IBM picked DOS instead of CPM, screwed up OS/2 marketing and Sybase
>was foolish enough to sell the source of their DBMS.
>
>But at the end of the day it's always one company that executes something better than another.
>Oracle saw where IBM goofed. IBM saw where Oracle goofed (or not - time will show) and so it goes
>on and on.
You're not saying Microsoft executed
>The real revelation (to me) is that technology is frightingly underrepresented in this picture.
>DOS wasn't better than CPM, Windows wasn't better than OS/2. Oracle wasn't better than Informix.
>But it wasn't about luck.
Technology wasn't underrepresented. It's irrelevant. :-)
Serge Rielau
>
> This is a charming display of naivete. Just look at what Ardent did
> with Informix -- they used Informix's money to leverage themselves
> into a much more financially substantial position. But even legitimate
> mergers and acquisitions are rarely done out of the company's coffers.
> Special shares are issued, bonds, deals, yada-yada.
I'm young, forgive me :-)
> >But at the end of the day it's always one company that executes something better than another.
> >Oracle saw where IBM goofed. IBM saw where Oracle goofed (or not - time will show) and so it goes
> >on and on.
>
> You're not saying Microsoft executed
To use the home-computing environment folks are used to, to break into the SMB market is brilliant if
you ask me.
I wonder if there was ever a game written for OS/2 ....
History repeats itself with Access and SQL Server.
When your home business grows up you're not buying Oracle or DB2.
Your neighbour is a SQL Server "expert" and he buys the SQL Server magazine at the kiosk around the
corner, just like the ones we bought for the C64.
> >The real revelation (to me) is that technology is frightingly underrepresented in this picture.
> >DOS wasn't better than CPM, Windows wasn't better than OS/2. Oracle wasn't better than Informix.
> >But it wasn't about luck.
>
> Technology wasn't underrepresented. It's irrelevant. :-)
I didn't hear that la la la .....*firmly covering my ears*
Obnoxio The Clown
wrote:
>> >I think in order to acquire companies you need money..
>>
>> This is a charming display of naivete. Just look at what Ardent did
>> with Informix -- they used Informix's money to leverage themselves
>> into a much more financially substantial position. But even legitimate
>> mergers and acquisitions are rarely done out of the company's coffers.
>> Special shares are issued, bonds, deals, yada-yada.
>
>I'm young, forgive me :-)
>
>> >But at the end of the day it's always one company that executes something better than another.
>> >Oracle saw where IBM goofed. IBM saw where Oracle goofed (or not - time will show) and so it goes
>> >on and on.
>>
>> You're not saying Microsoft executed
>
>To use the home-computing environment folks are used to, to break into the SMB market is brilliant if
>you ask me.
It was the bane of my life when talking to Informix -- they just
wouldn't listen to anybody telling them that the low-end volume market
wasn't important. When Linux came around, they had a wonderful chance
to leap on the bandwagon and do something special, but as usual, they
sat on their hands. I still wonder if there isn't a compelling case
for something like Standard Engine in the low-end Linux market.
>I wonder if there was ever a game written for OS/2 ....
>History repeats itself with Access and SQL Server.
>When your home business grows up you're not buying Oracle or DB2.
>Your neighbour is a SQL Server "expert" and he buys the SQL Server magazine at the kiosk around the
>corner, just like the ones we bought for the C64.
Sorry, I didn't actually disagree with you, I thought I'd erased the
start of a witticism that wasn't. :-)
>> >The real revelation (to me) is that technology is frightingly underrepresented in this picture.
>> >DOS wasn't better than CPM, Windows wasn't better than OS/2. Oracle wasn't better than Informix.
>> >But it wasn't about luck.
>>
>> Technology wasn't underrepresented. It's irrelevant. :-)
>
>I didn't hear that la la la .....*firmly covering my ears*
Well, I think you proved yourself that technology is irrelevant -- how
come Microsoft is so successful? Because of their innovation and
quality control? Oracle?
Most people hear the message, they don't investigate for themselves.
Remember when no-one got fired for buying IBM? Anybody care to compare
the Amiga or the Acorn BBC with the original PC from that era?
The average person, especially at the low end buys safety in numbers
(think market leader) at a reasonable price. At the top end CIOs have
their opinions formed by ads and articles in Forbes.
People buy the perception. The reality is irrelevant and the
technology doubly so. I say that from bitter personal experience.
blair kenneth adamache
time you're in Toronto, and you can show me where the code is identical and
something else is responsible for the restriction:
- Oracle 8i has rollback segments. With OPS you need to worry about both
public (shared) and private (per node) rollback segments.
- in DB2 multi-node, each node looks like a single node DB2. Is this true for
Oracle OPS versus 8i?
- with 8i you have redo logs; with OPS you have redo logs and that are broken
down into threads. A "private thread" is a redo log created using the ALTER
DATABASE ADD LOGFILE command with the THREAD clause so syntax of log file
creation differs in OPS
- with OPS and even RAC in 9i, you have to have Free List Groups (free list
maps that each node maintains); with 8i (nonOPS) you have only one free list
that keeps track of free space in tables but that does not share well among
nodes. (Quote from an Oracle manual: "When Oracle allocates new extents to a
table, Oracle adds their blocks to the master free list. This can eventually
result in contention for free space among multiple instances on Oracle
Parallel Server because the free space contained in newly allocated extents
cannot be reallocated to any group of free lists. You can have more control
over free space if you specifically allocate
extents to instances; in this way you minimize free space contention. In
Oracle Parallel Server, always use free list groups and free lists.")
Tim V.
news:3C9361DD...@us.ibm.com:
> In addition, it is by no means a fargone conclusion that one should
> use Oracle for partitioning in Warehousing. In fact, this is one of
> DB2's strengths (DB2 UDB EEE). Especially for large warehouses, I
> would say that DB2 UDB EEE has proven scalability and is the db of
> choice.
When comparing the MPP style, Oracle introduces overhead with the
lock manager. DB2 bypasses a lock manager by shipping the data to
correct node for processing. Of course, there is a bit of overhead
in that as well. The final verdict is if you want Oracle MPP, the
best way to get performance is to mimic what DB2 already does...
ship the data to the node where the data is stored to prevent
"pinging".
Tim.
Tim V.
I like the way Oracle makes the V$ tables available. Of course, DB2
provides an API into their monitoring. Overall, DB2 has better
monitoring, but to get the most out of it, you may have to do a bit
of programming.
Tim.
Mark Townsend
adam...@stopspamca.ibm.com wrote on 3/19/02 1:39 PM:
> My comparison is of Oracle 8i and OPS (pre-9i). Let's go for a beer the next
> time you're in Toronto, and you can show me where the code is identical and
> something else is responsible for the restriction:
Sure - in fact I know a nice bar in Toronto with New Zealand beer and lamb
chops. I'll even buy the first (and last) round.
> - Oracle 8i has rollback segments. With OPS you need to worry about both
> public (shared) and private (per node) rollback segments.
True.
> - in DB2 multi-node, each node looks like a single node DB2. Is this true for
> Oracle OPS versus 8i?
I guess Yes - in that you can connect to a specific node, or let the
'database' manage connections to specific nodes based on workload. Is this
what you mean ?
> - with 8i you have redo logs; with OPS you have redo logs and that are broken
> down into threads. A "private thread" is a redo log created using the ALTER
> DATABASE ADD LOGFILE command with the THREAD clause so syntax of log file
> creation differs in OPS
True.
> - with OPS and even RAC in 9i, you have to have Free List Groups (free list
> maps that each node maintains); with 8i (nonOPS) you have only one free list
> that keeps track of free space in tables but that does not share well among
> nodes. (Quote from an Oracle manual: "When Oracle allocates new extents to a
> table, Oracle adds their blocks to the master free list. This can eventually
> result in contention for free space among multiple instances on Oracle
> Parallel Server because the free space contained in newly allocated extents
> cannot be reallocated to any group of free lists. You can have more control
> over free space if you specifically allocate
> extents to instances; in this way you minimize free space contention. In
> Oracle Parallel Server, always use free list groups and free lists.")
AFAIK, you can have multiple free lists for both single and multinode
Oracle. On large SMP environments, free list contention can also become a
problem, so they are useful there as well.
I still concur that there is no evidence of seperate code lines - and in
fact there isn't. Having seperate code lines would be a major PITA for
development - there is no upside and just heaps of downside. The last thing
anybody needs is another mainline to merge.
Obnoxio The Clown
wrote:
>> >I think in order to acquire companies you need money..
>>
>> This is a charming display of naivete. Just look at what Ardent did
>> with Informix -- they used Informix's money to leverage themselves
>> into a much more financially substantial position. But even legitimate
>> mergers and acquisitions are rarely done out of the company's coffers.
>> Special shares are issued, bonds, deals, yada-yada.
>
>I'm young, forgive me :-)
>
>> >But at the end of the day it's always one company that executes something better than another.
>> >Oracle saw where IBM goofed. IBM saw where Oracle goofed (or not - time will show) and so it goes
>> >on and on.
>>
>> You're not saying Microsoft executed
>
>To use the home-computing environment folks are used to, to break into the SMB market is brilliant if
>you ask me.
http://www.theregister.co.uk/content/4/24489.html
Especially the last paragraph.
blair kenneth adamache
Mark Townsend wrote:
> > Mark Townsend wrote:
>
> Sure - in fact I know a nice bar in Toronto with New Zealand beer and lamb
> chops. I'll even buy the first (and last) round.
> ...
> I still concur that there is no evidence of seperate code lines - and in
> fact there isn't. Having seperate code lines would be a major PITA for
> development - there is no upside and just heaps of downside. The last thing
> anybody needs is another mainline to merge.
>
I guess I would ask:
1. how much of the mainline code from 8i is IF DEF'd out for OPS/RAC
2. if it is one codebase, do you compile once or twice to produce the multi-node
and single node products
dr_dba
You are "brutually correct" here....
Reality has got nothing to do with some of decisions
that are taken at the BigCo's....and that even includes the BigBlue!
The bottom line is (going back to Dana's point) what is that
needs to be done (and later you may bang your head against the wall
for putting forth the right techie solution and seeing it turn
down for the ....let's call them the 'Executive Descisions'...oh
wait...I got another one...let's call them the 'Team Descision').
You can't go drag racing with the family van....but then you can't
fit a family of four in a real sporty either (gee I wonder if Ford/GM
are working on a car which would resemble what the Marketing Folks at
both Oracle and IBM would want us to believe w.r.t their product(s)).
I find that even with all the hype and shake hand announcemnts....DB2
still has a big problem in the market place with 3rd party solutions
and support.
"Yes we support DB2, but we really recommend Oracle" is what I hear
all the time and if you ask Why? "Well off course it works better,
we first develop on Oracle and then port it to DB2, Oracle is the market
leader, better Java support....etc. etc."
(I am not saying the above is true or not...."only truly what I hear").
Preception issues? Marketing issues? Technical issues?
Take your pick...
obn...@hotmail.com (Obnoxio The Clown) wrote in message >
Obnoxio The Clown
>You can't go drag racing with the family van....but then you can't
>fit a family of four in a real sporty either (gee I wonder if Ford/GM
>are working on a car which would resemble what the Marketing Folks at
>both Oracle and IBM would want us to believe w.r.t their product(s)).
I hate to disagree with someone who has just agreed with me, but have
you taken a BMW M5 (or even an M3) for a drive lately? Fits a family
of four, yet performs as well as Oracle does on a slide projector. :-)
Aniruddha Govande
Yes, Oracle is FAR FAR better than DB2. I am an Oracle guy, but right
now working on DB2 and facing so many many.... problems. The DB is not
at all stable and crashes very frequently. DB2 is not even at the
position, to compare against Oracle.
blair kenneth adamache
over to DB2. Many smaller fish will follow.
DB2 had JDBC and Java stored procedures in 10/1996, before Oracle I believe.
DB2 had SQLJ in 9/1998, again before Oracle if I recall correctly. DB2 and
Oracle do have a different approach to Java: Oracle has their own JVM. DB2
uses the JVM supplied by the OS vendor (i.e. Microsoft on Windows, IBM on
AIX, Sun on Solaris, etc.). The issue here is whether you think the best
company to build a JVM is the database supplier or the Operating System
provider. Each approach has its advantages.
Larry Menard
First of all, by your own admission, you are an "Oracle guy". If a "DB2
guy" were to start using Oracle for the first time, don't you think he too
would have problems getting up to speed?
Secondly, there are thousands of people out there not experiencing all
the problems that you are. What does that tell you?
Thirdly, if you expect to be taken seriously, put some proof in your
allegations... details regarding these 'crashes'. Perhaps they aren't DB2
problems?
Do you by any chance also go by the name "Robert" in this newsgroup?
--
Larry Menard
IBM Workstation Database (DB2) Performance Team
Defender of Geese and of All Things Natural
"Aniruddha Govande" <g_ani...@hotmail.com> wrote in message
news:b07ce517.02032...@posting.google.com...
robert
> Do you by any chance also go by the name "Robert" in this newsgroup?
>
uh, no; he doesn't, but i do. and DB2 remains the last refuge of VSAM
neanderthals.
it lacks a purpose built data manager, still relying on the file
system. what i find amusing is that ibm's database folks are
still in love with os files (out of expediency, of course);
while their language folks deride files and trumpet "repository".
what's further amusing is that the unix/(ms)dos file system
is about the dumbest structure for a database; os/360's CKD
structure is much more sensible. that's why unix DB's typically
run on raw partitions. db2 can't really be any smarter than
VSAM. a purpose built data manager, which dumps the file/table
physical representation altogether, will always have the higher
potential for both speed and functionality; just as assembler
"can" always be faster than <your high level language of choice>,
getting a data manager closer to the metal improves its potential.
ibm says (i can't find the citation), that COBOL can't directly
access a db2 table as native VSAM. my suspicion (being a
suspicious sort of guy), is that this is merely a magic number
issue, not a case of real structural differences in the way
db2 does VSAM versus the rest of the world.
if, and until, ibm releases some numbers, i remain convinced that
it's claims of wide acceptance are bolstered by those VSAM cavemen
who are too scared to do anything else but "choose ibm". after all,
no one ever got fired for choosing ibm.
for those who are serious about performance: TPF. for those who
insist on os/360 but can't hack TPF: db2. for those who insist
on unix and performance and will tolerate a 4gl: Progress. for
those who want performance, don't care about os/360 or unix: PICK.
toodles,
robert
Philip Nelson
On Sat, 23 Mar 2002 03:26:31 +0000, robert wrote:
> it lacks a purpose built data manager, still relying on the file
system.
Well on Unix you can use raw devices and have for a good few releases.
Even without raw devices, a DMS tablespace uses its own internal
structure and the file system is basically told to leave well alone.
> db2 can't really be any smarter than VSAM.
But VSAM linear datasets are hardly your standard KSDS accessed by
standard VSAM calls. It's just a file that DB2 has the power to layout
as it sees fit.
And what would ssssDBM1 be other than a purpose built data manager,
responsible for getting the data to and from the buffer pools, hiper
pools and disks in the most efficient way as possible and doing as much
of the complex SQL processing as early in the game as it can.
> ibm says (i can't find the citation), that COBOL can't directly access
> a db2 table as native VSAM. my suspicion (being a suspicious sort of
> guy), is that this is merely a magic number issue, not a case of real
> structural differences in the way db2 does VSAM versus the rest of the
> world.
>
I think the truth would be that you probably could if you tried. But why
would you want to ? The interal structure is likely to change between
releases and you'd have to recode your program. I'd rather let IBM do
the rewriting for me. Besides it's one of Codd's commandments that you
shouldn't be able to access an RDBMS other than through the (SQL)
interface.
Phil
Knut Stolze
> Which planet do you live on ? Or maybe how long ago in the past ?
>
>
>
> On Sat, 23 Mar 2002 03:26:31 +0000, robert wrote:
>
>> it lacks a purpose built data manager, still relying on the file
> system.
>
> Well on Unix you can use raw devices and have for a good few releases.
> Even without raw devices, a DMS tablespace uses its own internal
> structure and the file system is basically told to leave well alone.
And with file systems, you get the OSs caching for free. For certain data,
this might beat raw devices (LOBs come to mind).
> Besides it's one of Codd's commandments that you
> shouldn't be able to access an RDBMS other than through the (SQL)
> interface.
That's the only thing that makes sense. It's the same in any
object-oriented language.
--
Knut Stolze
DB2 Spatial Extender
IBM Silicon Valley Lab
Robert Dean
are prone to fits of unsupported allegations against DB2's quality.
blair kenneth adamache
but data and indexes can also be created on raw devices.
Robert Dean
Chuck Renaud
news:372ebe2.02031...@posting.google.com...
> 3. If partitioning of data is a criteria especially in Data Warehouse
> choose Oracle (it supports hash,range,list,composite) . DB2 support
> only hash paritionning. and you need to have DB2 EEE verion of
> software.
Keep in mind that, with the Informix acquisition, IBM also picks up the XPS
fragmentation/partitioning options.
-- Chuck
Kirk Bradley
know where you got that information. Oracle on the
mainframe also knows nothing about VSAM. What both
systems know is that the way they allocate space is
with the IDCAMS program and specifying LDS as the type.
After that we both just have a zillion 4K blocks and
everything inside is owned by us. VSAM knows nothing!