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

siuhungkuen_at_my-deja.com wrote:

> sybase over the past few years has been very agressive in giving you options to overcome
> some performance problems with table partitioning, parallelization, etc. ms hasnt done
> that ( not sure about 7 tho- im still learning that one). also ms 7 doesnt seem to give
> you a lot of knobs to turn from their gui ( or at least i cant find many ).
 

> feature wise sybase seems to be behind oracle. architectually
> i am not sure if they have solved the scalability issues

You are correct.

My problems w/ Sybase, in general, stem from our experience w/ 11.9.2. Parallelization has worked against us. We've had to turn it off. Named cache mgm't has problems. Right now, w/ 11.9.2 we are maxxed at about 3 Gig. RAM.

Other beefs about Sybase... Hot spots on tables w/ lots of inserts, too easy loose the segment placement and striping on tables. Outer join syntax is still proprietary. Changing locking from page to row is a better way to reorg than REORG.

Sybase 12 hopefully scales better, but by then, we'll probably be looking at simplifying our environment down to MS SQL & DB2.

> your comment about oracle reader writer blocking is right on. it is
> cool. however from a performance standpoint the tpc site consistently
> shows oracle is much slower than sybase in the tpc-c benchmarks for what its worth.

Interbase, which pioneered row-versioning in RDBMSs, suffers admitted overhead from row versioning.

> and parallel
> server is the one thing i think that makes a big difference with oracle.
> i know that oracle 7 was still mostly a rule based optimizer and were
> still trying to fix their cost based one. kinda lost track of 8 so dont
> know if oracle has an efficient optimizer yet.

db2's optimizer is cost-based & from many accounts, the best in the industry. it's so good, in fact, that it'll slow down your simple queries, so you have to detune it from using the higher heuristics.

DB2 has some legacy stuff that is vexxing, like 8-character system names in packages, stored procedures, etc. Ver. 7 will fix those.

But DB2's file-based log mgmt is the simplest & most fool-proof I've seen for managing heavy throughput in the tran. log. Our data collection project wouldn't work on Sybase or MS SQL - they'd be constantly dumping the tran. log. But with DB2, a tran. log backup is inherent to the design, requiring no "dump transaction."

/lee Received on Fri May 26 2000 - 00:00:00 CDT