dB Choices - Oracle, DB2 or Something Else?

An Anonymous Coward asks: "I work company where I currently have to implement a new back end database architecture. It needs to be highly scalable, globally accessible, distributed, robust, fault tolerant and secure. There's a feeling amongst management that our current database, PostGres, hasn't got the grunt we need. Everyone seems to think we should go to Oracle or DB2, but I'm not yet convinced. Can anyone suggest what are the pros and cons of Oracle and DB2? Why should we go for one over the other? Is it possible to implement either of these without paying a fortune in maintenance and subscriptions? Which of these requires LESS maintenance given that we are going to be using the Linux on Intel?"

Advantages of Oracle

[stephend]

The technical advantages of Oracle over Postgress are not as significant as Larry might like to think. However, what it does have is a proven ability to perform.

I'm sure that there is no technical reason why Postgress can't handle multi-terabyte databases but I know Oracle can manage because I've seen it and because there are plenty of other customers who have too. The same goes for clustering, stored procedures, etc. If you're trying to reduce technical risk it's pragmatic to choose a solution you know will work.

Also in Oracle's favour is that it's much easier to recruit Oracle people than Postgress people. Databases are complex beasts, so it's important that you have qualified people supporting it.

I've not really used DB2, but I think that it has similar advantages over Postgres as Oracle. And finally, I am slightly biased. I don't work for Oracle but I did write the Oracle 8i on Linux Howto [zx81.org.uk].

Re:Personally, I wouldn't change

[Tet]

the more advanced features (such as parallel server, for true distributed DBs) cost millions (yes, Millions)

No they don't. We were only quoted 600 grand :-) Needless to say, we stuck with a non-OPS version of Oracle. The parallel features would be nice, but there simply isn't the business justification to spend that much money on them. As we grow, perhaps we'll need it, but for us (and for most companies, in fact), the cost is just too high to justify parallel server.

Actually, unless you have a really good reason for doing so, stick with PostgreSQL. A really good reason, BTW, means more than just a vague management feeling that it doesn't have enough grunt. Have you done accurate performance benchmarking? Have you checked that it really is Postgres that's having a problem, and not an issue with inadequate hardware? 24x7 support could count as a "good reason", should you decide you need it. Yes, I know there are companies that support PostgreSQL now, but I don't know if they do 24x7, and I'm pretty sure they wouldn't be considered sufficiently established to support a large scale implementation by the corporate world. At the end of the day, no one ever got fired for choosing Oracle, but you have to be aware of what you're letting yourself in for.

DB2 is still my favorite

[K-Man]

...after using Oracle and Sybase/SQL Server.

A few reasons (I'm not even going to try to cover all the bases):

1. SQL3: This is probably the last attempt at a standard SQL, but it still seems to have a few more brains behind it than PL/SQL or T-SQL. My apps have a strong need for recursive SQL, which is present only in SQL3.

2. ODBC: This is, or at least was, an open standard API. DB2's API is essentially ODBC, while Oracle continues to push OCI, and ODBC drivers for it are hit or miss. I'm not sure about now, but a few years ago one could write an ODBC app and link it to the DB2 CLI directly, without an ODBC driver or driver manager.

3. Price.

DB2 is cheaper

[PD]

Both databases will do what you want them to do, but DB2 is cheaper than Oracle. If management gives you a choice between the two, and if your requirements are as you specified, then DB2 is probably your best bet.

troll...

[RalfM]

If I was moderating this question as a comment in another article's thread, I would mark it down as a troll....

Congrats for having your submission accepted! :-)

Ralf

__________________________________________________ __________

The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt.

consider Sybase

[MarkMac]

Sybase is also available for Linux - it is a well-respected commercial database at a fraction of the cost of Oracle and less expensive than DB2. Adaptive Server Enterprise version 12.5 for Linux can be downloaded and tried out for 60 days:

http://www.sybase.com/ase_125eval [sybase.com]

Alas, you don't say exactly what it is you intend to do with this database nor what issues/capabilities are most important to you.

depends what kind of shop you run !

[johnjones]

oh where a linux shop they say !
(expecpt for all the users admin guys and domain servers )

mostly we see that places are a UNIX shop and its HP or SUN now under solaris I'm sorry but oracle does rock !
all the perf tests beat DB2
+ there are alot of people who know admin + tuneing so geting support is Very good

DB2 works well if you are a IBM customer and are useing WebSphere and have a mainframe /NT box that you might upgrade and dont have a clue about admin or real tuning

free DB's need very little work to get to run but to get to run well on high workloads they are a nightmare SUN + Oracle make a nice partners but I dont like there prices either

but I still pay

regards

john jones

Re:Database Choices

[robocord]

If you think Oracle's a big headache, you've obviously never worked in an Oracle shop with a competent DBA. I've never used those wacky, off-the-wall, CA databases (except Ingres), but I have used DB2, Sybase, Ingres, Informix, SQL-Server, MySQL, and PostgreSQL. Of all those, the only two I would currently recommend for a high performance 24x7 shop are DB2 and Oracle. For low speed work, especially when weekly down-time is allowed, all of them work just fine. I would not under any circumstances buy a CA product, though...I've had such horrible experiences with them that I'd sooner use Microsoft stuff than CA. Luckily, there are other choices in the world than those two.

Re:Oracle DBA

[robocord]

I'm glad to finally see somebody else that realizes this. I'm an experienced Oracle DBA and I've quit more than one contract because of a complete lack of work. I finally ended up starting a consulting company and working for as many as 7 companies at once, just to stay busy. Even with that many customers, I was only working about 25 hours a week. Working with a new database is a full-time job for a little while. Coming in on an old database that's never had a competent DBA and getting it up to snuff is a full-time job for quite a while. After that's over though, a few hours a week is more than enough. I've handled as many as 50 databases at a time in much less than 40 hours per week and I could handle many times more than that if I really wanted/needed to. I always tell people that if they want a DBA on staff, they should train one of their developers or admins to do double-duty. Unfortunately, few companies take my advice. Even more unfortunately, the ones who DO take my advice forget that they need to pay a qualified DBA as if he/she is a qualified DBA, rather than a Jr Sys Admin or whatever.

See Linux magazine

[Smoking]

There a nice comparison of all the major DB systems on linux (DB2, Oracle, Sybase, Informix, Mysql, Postgresql) in the dead trees Linux Magazine of last month. It may be a good starter point for you, even if it's a bit short on details. There a nice comparison chart of all the DBs in it.

Quentin

Oracle DBA

[eric2hill]

I see a lot of people suggesting that an Oracle DBA is a full time position. I don't really believe that. My company has several hundred (maybe a thousand or so) Oracle servers scattered all over the world. We have one DBA. Period. If you set the server up right the first time (sizing tables, tablespaces, indexes, etc.) with the proper growth rates for the application, Oracle is pretty much self-sufficient. I just finished writing a monitoring program that sends an e-mail if performance drops in one or more of 12 areas, and we rarely need to do much more than extend (and defrag) a tablespace. Anything like this should make your servers a fairly hands-off deal. JUST REMEMBER THAT THE $150/HR YOU SPEND FOR THE CONTRACT DBA IS WORTH IT TO GET SET UP RIGHT TO BEGIN WITH! If you screw the database up the first time, you'll be fighting it for the rest of its existence.

Neither...

[loony]

If your project is going to live for a long time,
you should never code for one particular DBMS. We
used Informix here for our project (that decision was made 5 years ago) because back then DB2 was too IBM centric and Oracle just wasn't able to handle the load... Now, Informix is almost gone, and porting our application to any other product will take us months. It has to be done, but all that money could have been saved if the app was coded to utilize a thin DB layer instead of accessing features of the DB directly.

Database changes

[oneiros27]

You have quite a few things to consider in this.

First off, what are the reasons for changing systems? Are there particular features that you're missing, is it so that you can get a support contract, is it just a buzzword issue?

If it's just that the management's going for the latest buzzword, try to get the management one on one, and tell them what a mistake they're making. [For some reason, they don't like us techies telling 'em their plans are crap in meetings]

If it's a features issue, well, you'd have to look at each product, and see which ones supports what you're looking for.

For the support contract, I don't know about DB2 licensing, but Oracle's rather strange -- although the cost model for the server goes in 2/5/infinate year blocks, the support's the same either way. You may save in the long run by buying a larger contract.

Also, platform is important. I was in a class once where someone recommended not running Oracle on NT, and using MS-SQL server, just for the fact that the limitations of an Oracle/NT combination were on the NT side, so you might as well take the cheap way out.

Now, given that all of the above things are equal, you need to first look at maintenance issues -- how often do they recommend cold backups, hot backups, rolling the transaction logs, etc. You also need to look at how easy it's going to be to transition to the new server. [Do you have more than just tables -- views, indexes, constraints, etc, that are going to need to come over?]

Moving data of a significant size is a pain in the ass. If it's s speed issue that you have, unless something's completely built wrong on your current system, or there's some major feature that you need, you'll almost always be better fixing your current problem than moving to a new system. (eg, Oracle doesn't have an 'autonumber' field type. You'll need to set up a sequence, and then either make sure that all inserts read from the sequence, or take a (worthwhile) performance hit, and set up a trigger for inserts)

Anyway, the point I wanted to make is that your question is vague enough that either one may be the answer, or you may really want to stick with what you have. As I don't know your situation, I can't give any solid recommendations, other than to do your research, as this is something that you might have to live with for a long time.

If you need some stalling time to get all of the information you need, so you can get things done right, and not rush something through, give your management this article from C|Net:
http://news.cnet.com/news/0-1007-201-6375299-0.htm l?tag=arcv [cnet.com]

Re:Personally, I wouldn't change

[BluSkreen]

Cost of Oracle is based on how many servers you are running, how many processors on those servers, the speed of those processors,

They shitcanned the speed portion of the license formula (upu) a couple of weeks ago.

Before the reduction, a 9i license for a dual 440 sparc was about 40 grand (us) with support, now it's around US$27k.

Oracle is expensive, but you get what you pay for. If you need the power and features, it pays for itself. The most expensive part is the brain power to administer it. Usually two or three times the license cost.

Postgres and mySQL are fine for many Web sites, but if what you are doing is really mission critical, Oracle is a good way to go.

Dave

Re:Database Choices

[bobm]

can I get pointers to the fact that US customs has the largest db in the world. I would think that there are some really really big Teradata systems out there (and I'm sure NSA has a really big db but won't tell us). Last I heard Walmart was over 100Tb and there were rumors of larger systems out there. (I might be wrong here)

DBA?

[gss]

Does your company employ a DBA? If not you might want to consider that in the total cost of things. I know it helps to have one with Oracle but I'm sure it would help with DB2 as well. At least until you get eveything setup anyway.

Free Trials

[^Z]

Oracle gives free trial DB software that does not moan about it being trial version, leave alone refusing to work after evaluation period ends. Once I had trial version of Oracle7.1 to work for 3 or so years flawlessly %-)) I don't know if release 9i follows the suit, but 8i certainly does. So you can try and test it all you want; be sure to do it. It runs nice on Linux/x86, especially if you tune it right (see Red Hat Enterprise Edition for an example -- it makes Oracle fly, believe me). On Sun hardware under Solaris, it runs particularily good.

Oracle DB has great performance. But to gain it, one should spend some time reading, thinking and poking -- and things start to work *many times* faster. So, consider a DBA position for your site. Anyway, to run a large and complex distributed DB it *takes* to hire a DBA, which is expensive.

Though, very same things may apply to DB2 :-)

Re:why not MySQL

[chegosaurus]

Yeah definitely use MySQL. And you'll probably only need to run it on an old 486 becuase Linux is so much better than Windows. I installed Redhat all by myself! I am 3l337.

Doncha just love Slashdot? And trolls in general?

Try them out!

[MrBlack]

I'm pretty sure trial versions of both Oracle and DB2 are available for Linux. Why don't you download and install them both, dump in some dummy data, run a few queries etc. Both are supposed to scale up the wazoo so that shouldn't be a problem. Find out how the people who will have to administer it are about using it. Check out the tools that are available for both. Everyone's situation is going to be different (financial, ammount of data, type of data, volatility of data, in-house expertise, reporting requirements etc) so it'd be hard for an outsider to make a judgement call. The time you invest in reviewing them should easily pay for it's self.

Re:here is a very good alternative

[denshi]

Oracle is free for development; they only charge when you deploy. It's all there on technet.oracle.com.

Yes, these FrontBase guys are active on comp.database.*, and they're certainly easier to talk to than Oracle developers. For both of those I am glad. But the topic of the 'Ask Slashdot' is something more powerful than Postgres, and FrontBase really isn't even up to that yet, let alone in the range of Oracle and DB2. Stop spamming; read the article; stay on topic.

here is a very good alternative

[stefaanh]

Just because I'm extremely happy not to have chosen Oracle or Sybase or Informix: You should definitly try out FrontBase [frontbase.com] everything you've asked for - and more - much more:

A free SIX months developers licence with all options active. An active dev-community. A no-nonsense support - even if you only have a free developers license.

Scalable license scheme, SQL92 compliant, row level privs...
Mac OS X
Mac OS X Server
RedHat 6.x
SuSE 6.x (Intel and Power PC)
YellowDog Linux
Debian Linux
Stormix
Mandrake Linux
FreeBSD
Solaris
HP-UX
Windows NT
go and read the specs!

Those guys react as if they were your collegues!

Re:why not MySQL

[jesseraf]

I don't mean to dis MySQL (I use it for many things myself), but the area which NASA changed from Oracle to MySQL was essientially a Mailing List. (not the most Database intensive thing).

http://www.mysql.com/news/article-51.html

check for yourself.

there is objective information

[Hector8011]

If you want some database performance numbers, check out the http://www.tpc.org. It may take you some time to understand the differences between the benchmarks but its the only place where you're going to get objective information about the current databases out there.

Personally, I wouldn't change

[ClubPetey]

Rather than weighing the pros and cons of the databases, you should look into the reasons that management wants to convert. Do they want distributable database because they need it? Or becuase it's a cool buzzword? Unless you really need the features and there's no way around it, I would stick with Postgres. At a previous job we used Oracle, and it was expensive, VERY VERY expensive. RIDICULOUSLY expensive. Not only that, but some of the more advanced features (such as parallel server, for true distributed DBs) cost millions (yes, Millions) and can only be implemented (let alone managed) by about three people on the planet.

If you're a company like American Express or Citibank then perhaps Oracle is the way to go. Otherwise, stick with Postgres, if only for the cost reasons. Cost of Oracle is based on how many servers you are running, how many processors on those servers, the speed of those processors, what your business is, and probably the relative IQ of your full-time Oracle DBA. (You do have a licensed Oracle DBA don't you?) On the average, you are looking at $150,000+ per year for software licenses, more if you need 24/7/4 support.

I can't speak for DB2, but I definitely recommend against Oracle. I would seriously spend a lot of time trying to convince management that they don't need the fancy buzzword, and that for anything else, Postgres is fine.

--
He had come like a thief in the night,

Depends on what you're using and doing...

[bdmm]

You're choice of DBMS depends primarily on these items:

1. Price
2. Platform
3. Support
4. Your Industry

Taking each one briefly, Oracle ain't cheap and DB2 isn't either, but it's cheaper than Oracle.

Platform - Since you're on the Lintel platform either should work well.

Support - Both DBs are well supported, most of my experience is with Oracle - once you get past first-level support Oracle actually does a very good job.

Industry - I work in the clinical trials industry (humans only) and 90% of the all members use Oracle for one thing or another, therfore we use Oracle.

Also, take the advice I've seen here and hire a DBA to perform setup of your instance. It will save you many problems later. If you will be running a distributed DB consider a full-time DBA.

It doesn't sound like you are considering anything else, that's good. MySQL lacks many of the features of any enterprise-level DBMS packages, it doesn't even have row indexing.

I've worked for IBM running M$ SQL Server, Oracle 8i and dabbled briefly in DB2 for benchmarking. Overall I would trust my data to Oracle before any other DB out there - period. With Oracles recent price drop (30%) Oracle 9i falls more in line with the others. It's also much easier to find Oracle experience than any other.

Re:DB2 is cheaper

[smchris]

I'm no expert but I have 4 of the 5 Oracle dba core classes and I remember in one of them the instructor was quite chipper about discussing a feature and then saying "db2--same but different" to orient people with db2 backgrounds (and dismissing SQLServer at the same time). Remind your management of the cardinal maxim that _the_ most important speed factor is well-written SQL. Then you can start talking about hardware needs and db tuning for shared pool code reuse and such. And maybe security is an underlying concern?

Another Database solution: InterSystems Cache

[Gabriev]

Just to add another voice to the fray. :) You should talk to a sales engineer for Cache (http://www.intersys.com). It is all you say, performs about 80% (yes, eighty) better than Oracle in most circumstances, is massively scalable, and is so reliable that it's the leading database used in the healthcare industry. It's also very inexpensive compared to what you would be laying out for Oracle. Just a thought.