geez, that (and the truncate log problem) were there back when I worked
with Sybase 4.7

they STILL haven't fixed those problems? WHY does anyone use this?


--- Jeremiah Wilton <[EMAIL PROTECTED]> wrote:
> How about the good old "readers can block writers?"  That one never
> fails to make jaws drop.  Not just SQL Server, though.  Informix and
> Sybase too.
> 
> --
> Jeremiah Wilton
> http://www.speakeasy.net/~jwilton
> 
> On Mon, 18 Feb 2002, Jim Hawkins wrote:
> 
> > During the class, I kept a list of all the "I can't believe this is
> > really the case with SQL*Server..." items, and thought you might
> all
> > like to see it.  These are just notes I took on a Palm Pilot, so
> > forgive me if they are a litte undetailed.  I walked away from the
> > class thinking, "this is just MS Access with bells and whistles."
> > I'm not saying it doesn't have its place in the database market,
> but
> > I just don't see how it competes with Oracle and DB2.  If you even
> > want to think about scaling, you have to implement Windows
> > clustering, which is one of the hidden costs I see that Microsoft
> > doesn't come right out and say.
> > 
> > *Row size cannot span multiple 8k pages, therefore max row size =
> 8k
> > 
> > *Cannot take DB out of "archivelog" mode.  Can limit what is posted
> > to txn log, but cannot stop it.
> > 
> > *Txn logs not mirrored.  Must rely on RAID or other mirroring
> > software.
> > 
> > *Separate permissions for RI checking.  Requires two permission
> > grants if foreign key exists - one for child table and one for
> parent
> > table.  Called REFERENCES permission.
> > 
> > *Recommended that ALL production objects owned by DBO - not
> > conducive to multi-schema instances.
> > 
> > *Activities that are restricted during backups:
> > 1.  Creating or modifying databases.
> > 2.  Performing autogrow operations.
> > 3.  Creating indexes.
> > 4.  Performing nonlogged operations.
> > 5.  Shrinking a database.
> > 
> > *Backups directly to tape require the tape to be attached locally
> to SQL Server.
> > 
> > *When txn log fills up, have to just "truncate" the log in order
> for
> > processing to continue.  Leaves system vulnerable until you get a
> > full DB backup.
> > 
> > *If you have a 100GB DB that is full, your backup will be 100GB. 
> No
> > compression of backups!
> 
> -- 
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> -- 
> Author: Jeremiah Wilton
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
> San Diego, California        -- Public Internet access / Mailing
> Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from).  You may
> also send the HELP command for other information (like subscribing).


__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Rachel Carmichael
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to