Re: MS SQL Server vs Oracle vs DB2 (&Sybase too)

Norris wrote:

> In MSSQL, I can create a database maintainance plan in about 5 minutes using
> a wizard that includes database consistency check and daily backup schedule of
> about 50 databases.

Not that that's bad. Yes, we use it too, with varying degrees of regret. Enuf grief w/ SQL Agent (the NT service that runs your maintenance plans) to warrant writing our own tools, just like we do for Sybase & DB2.

Just wait 'til the SQL Agent screws you. Change the sa password, or do something to your exchange server. Not only will the MAPI break, the SQL Agent might get jammed. Worse, we changed the sa pwd, & it stopped doing backups. But it kept mailing us telling us "SUCCESS."

And it wouldn't work right, even when we rebuilt the maint. plans. Even when I manually wrote jobs, step by step. So back to the old pwd.

Worse, that MS SQL Agent only sends alerts to ONE e-mail address. That's it. Just one. And maint. plans only do BACKUPs or TRAN LOG dumps but not DIFFERENTIAL backups. What happened there? Did someone leave DIFF's out of the spec? Hello?

That SQL Agent breaks its MAPI interface twice a month. Sometimes the only sol'n is to cycle the server. MS could've used the xp_sendmail that's part of MS SQL 4.x up to 7. But no, sendmail's open standard, much less reliable. So SQL 7 used the Windoze Mail API. IMO, that SQL Agent is the most amaturish P-O-S I've seen.

No, wait, the DB2 6.2 GUI control center also travels faster than the speed of suck too. But at least the DB2 GUI CC isn't responsible for fouling up your backups.

> It really saves a lot of administrative effort and time and
> I can concentrate on development as a Web Developer.

I think you just, unknowingly, hit the nail on the head. MS SQL is _more_ for developers & NT admins than it is for DBAs. MS has knowingly built MS SQL to fit the small to midsize shop where the developer and/or NT admin is also wearing a DBA hat. That's 90% of the apps. MS is going for the markets that Intel can tackle successfully, w/ 32-bit & bridged PCI limitations.

MS focuses more on it's client tools & it shows. Its OLE-DB interfaces out to the rest of the world is pretty good. A lot of people like SQL Server's DTS ( I don't) & replication. But MS SQL 7 is still constrained by the limitations of Windows & MS's developer-centric approach. So MS SQL's security model favors NT Admins & developers, not security-conscious DBA's, and MS SQL's tracer / profiler require NT-based authentication. This is *bad* if your LAN admins aren't also your DBAs and your LAN uses one big domain.

OTOH, look where I sit: I'm running a state-wide data center for Texas state gov't. MS SQL is for our small apps. Sybase for our ERP PeopleSoft apps & medium-sized apps. Thank goodness I have DB2 to help me deal with this VLDB 12 gigabyte-per-week throughput on one database & a data warehousing & mart project _starting_ at a terabyte. Neither SYbase nor MS SQL could keep up with the thruput b/c of the logs: we'd either be dumping the logs all the time or truncating them. W/ DB2 you don't need to "dump" the logs. Ever.

But then there's the crappy volume mgmt of Windows. It becomes impossible to tune disk subsystems when all you have for volume names is D-Z & when RAID 5 isn't what you want for *ALL* your database devices. OTOH, AIX (IBM's Unix) has logical volume mgm't. Amazing stuff, tune down the center of each disk, etc. Makes the task of tuning the IO subsystem *possible.*

I had considered the choices on the 1st project for DB2's platform. Either 4 NT servers that'd cost $450K OR ONE (1) RS/6000 Unix (AIX) box that'll cost $450K. The NT boxen (Compaqs) would have had 1/3rd the power w/ the same amt of RAM b/c Intel is 32bit & the PCI is *bridged* which is *slow*. If we get more RAM for them, they might come out even or possibly ahead. DB2 can use *ALL* the RAM on NT 4, unlike Sybase or MS SQL, using *all* 8 or 16 Gig RAM as data storage on NT4, again unlike Sybase or MS SQL. To my knowledge, only DB2 can do this on Linux or Windows b/c of its segmented architecture & extended storage pools. All this requires extra mgm't but at least you can accomplish your objective, which is to tune the database. If you are stuck w/ MS SQL as your only option, you will hit barriers from the ground up.

So, yes. MS SQL is easy. Until you have to manage it for high volumes, at which point it's no easier, if not harder, than any other vendor's database (which is appropo, btw, since a great deal of it is still Sybase, under the hood).

/leebert Received on Sun May 28 2000 - 00:00:00 CDT