Sounds like you need a better DBA...

I've done DBA work on DB2 (I'm certified here), Sybase, and SQL Server. I've installed Oracle and done some application work, but I can't say I'm an Oracle DBA.

The principles about indexes, clustering, record locking, etc. are all very similar in these systems.

The differences lie in things like how the SQL optimizer works on each system. DB2 is the best, SQL Server is the worst.

But, a good DBA can work with even the worst product by looking at the Query Plan (SET SHOWPLAN) and finding out if the right indexes are being used. Sometimes, the developer or DBA has to play a few tricks to get the SQL to perform.

SQL Server has problems because it is not architected well.

Finally, if your database is primarily read only, you might be better off with a good old-fashioned ISAM-type database (like FoxPro). These databases perform much better than relational databases when you're talking about static read-only type data, because they don't carry the overhead of transaction logging.

I did a very cool thing this morning.

One of my developers was experiencing a database hangup when running two apparently unrelated programs simultaneously. The whole system would just freeze up.

This time I managed to start a trace prior to the freeze up and captured that locks, SQL statements, and UOWs (units of work). It turned out that this guy was using statements like ALTER TABLE in the constructor of his Java code, after he had set autocommit to false (meaning you have to explicitly commit transactions in the database, instead of commiting every statement automagically).

The ALTER TABLE was locking the SYSTABLES (system catalog) table, preventing any further database action from occuring, until the first connection finally committed a transaction.

I love the trace and audit features of DB2, because they really help me solve problems like this one.

After I confronted him with the trace, he said "Well I THOUGHT I wasn't doing anything!" And he promptly fixed his constructors to commit the transactions right after doing them, and now everyone is happy.

My problem with databases like POSTGRES, is that you don't have those kinds of trace tools to get you out of problems, when your users get you into them. Yes, you have the source code. And yes, you could eventually write a tool to figure out what is going on, but I would rather have it right there ready to use.

DB2 "GET MONITOR SWITCHES"
DB2 "UPDATE MONITOR SWITCHES USING BUFFERPOOL ON LOCK ON STATEMENT ON TABLE ON UOW ON"
DB2 "GET SNAPSHOT FOR DB ON xxxx ALL"
DB2 "UPDATE MONITOR SWITCHES USING xxx OFF"

look at your output.

If you have a good DBA and a good NT Administrator, they will do fine with either one.

Microsoft has better GUI tools, better integration between database and Word/Excel/Project/Access/etc. But you would expect that.

DB2 on NT, Linux, or Unix optimizes better, runs more reliably, runs faster, and scales better ( with the right personnel). But it requires more DBA attention, isn't self-maintaining, and there are "features" that SQL Server has, that DB2 doesn't, like adding a new column into the middle of the existing table. You can add a column in the middle in DB2, by exporting the data, dropping the table, recreating the table, and reimporting the table. But SQL Server appears to do it automagically.

So, if you're light on DBA skills, need "idiot-workable" integration, then SQL Server is the DB for you.

BTW, the costs are about the same per server, (and most people don't realize that), so the decision really does come down to what you want to do, how fast, how scalable, and the skill level of your personnel.

We run both in our shop, DB2 UDB for Unix and MS SQL Server.

My Thoughts

I haven't worked with anything AS/400, so I really can't comment, except maybe to say that I think the AS/400 is IBM's version of the HP 3000 series, which just got canned.

With all that's going on in the Unix server space, IBM really needs to get an AS/400-like VM running on AIX/pSeries, then put the AS/400 out of its misery, like HP did with their 3000 series.

The only reason that I can imagine that IBM still sells AS/400 is because people still buy them (and software, and support contracts into eternity...)
Heck, a few years back, I went into a blinds factory that was still running an IBM Series 36. When I explained that they could replace the system with an IBM Pentium that would be much faster, they said they were "happy" with their System 36.

Maybe that's why Microsoft has finally decided to sell software subscriptions. So companies will finally give up on old DOS machines, and there won't be some goob running Windows NT 3.51 in 2020 (but there will be).

Glen