Re: Sybase vs Oracle - which is better?

I find this sort of reply VERY confusing.

It assumes that Sybase is inefficient for using a single, or few, processes and a large chunk of shared memory. On the contrary, if within that process you can do your own multi-threading and context switching more efficiently that the operating system then a single process doing all of the work is more efficient than lots of processes. As multi-threading is, as far as I am aware, ALWAYS more efficient than using mutiple processes Sybase is MORE efficient than Oracle etc. The reason for the existence of multi-threading is because it is more efficient.

Also why use a small amount of memory for storing useful data from the database when you can use most of the machine's memory for it. Oracle only uses a relatively small portion of the memory as it HAS to use the other memory for redundant data which it cannot share, this redundancy is also inefficient.

The better efficiency is why Sybase always seems to beat Oracle hands down for performance on like for like and can be MUCH better e.g Oracle need a 44 processor system to achieve 49000 TPC transactions per minute while Sybase acieve 52000+ on a 16 processor system.

I know both systems well and Oracle's architecture is definitely NOT more efficient then Sybase.

Any questions?

Chris

In article <72t1sm$nad$1_at_nnrp1.dejanews.com>,   lburns4770_at_my-dejanews.com wrote:
> One major difference between the DBMSs seems to be the way they use the
> operating system's shared memory. Sybase appears to do everything inside of
> one Unix process (the dataserver process), while Oracle and Informix spawn
> multiple Unix processes to perform tasks. For this reason, Sybase requires
> you to define a huge chunk of shared memory on the Unix platform (2/3 to 3/4
> of the total physical memory), and allocate most of it to Sybase. Oracle and
> Informix require a shared memory pool that is only 20-25% of the total
> memory.
>
> Incidently, there doesn't seem to be any useable documentation anywhere on
> what settings to use for SHMMAX, although you can hose your system really
> badly if it is set too high or too low. I don't know why Sybase doesn't
> address this issue in any of its documentation.
>
> Also, does anyone know the history of why Sybase is architected like this?
>
> Thanks!
>
> -- Larry
>
> In article <72p0am$j5n$1_at_imsp009a.netvigator.com>,
> paulkcng_at_news.netvigator.com (Ng K C Paul) wrote:
> > I can explain that sometimes Sybase holds the fastest tpc and sometimes
> > Oracle and sometimes DB2.
> >
> > Sybase vs Oracle is like Unix vs VMS , ls vs dir
> >
> > Karl Zdero (zderok_at_viaginterkom.de) wrote:
> > : The usual techie debate continues,
> > : Is Sybase better than Oracle or is Oracle better than Sybase?
> > :
> > : When it comes to benchmarks, the www.sybase.com site says that Sybase
> > : holds the world record, but www.oracle.com says it holds the record. I
> > : see in www.tpc.org that the fastest tpc is with Oracle!
> > :
> > : Now apart from benchmarks, what makes either database better?
> > :
> > : I like Oracle as I've used it the most, heres why.
> > : + sqlplus is superior than isql, at least I can check return error
> > : codes.
> > : + PL/SQL is more powerful than TRANSACT/SQL
> > : + I can see qll SQL activity for a particular session (SQLAREA),
> > : can't do it in Sybase?
> > : + Oracle comes standard with many utilities, whereas Sybase doesn't
> > : + Oracle has more options with triggers than Sybase. e.g. per row
> > : triggers and per statement
> > : (In Sybase you must write a cursor loop to action a multiple row
> > : insert for example)
> > : + Monitors are standard with Oracle. (Sybase dont think so)
> > : + Row level locking been for years in Oracle, only recently in
> > : Sybase.
> > : + Oracle can select data from another database on another server
> > : (dblink) Can Sybase?
> > :
> > :
> >
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
>

-----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own Received on Thu Nov 19 1998 - 00:00:00 CST