RE: Just got back from SQL*Server 2000 training...
> - Original Message - > To: "SQL 7 Discussions" <[EMAIL PROTECTED]> > Sent: Tuesday, February 19, 2002 5:29 PM > > *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. > >> Seems a little like disk space filling up in Oracle. How is this > >> different? Interesting. When this happened to us Oracle-wise, I just moved the oldest archives to a mount point that did have enough room. Since we at least had enough forethought to incorporate several redo log groups, the DB never stopped. And since we never actually deleted any archive logs, we were never at great risk of permanent loss of data. Or we could have also duplexed the arches offsite, too. Because we all know that RAID controllers NEVER fail... "Truncate the log." Yeah, right. Ya know, as much as I have whined about the way Oracle does some things (e.g. stupid-ass security-by-obscurity for DBAs and some wierd things with OiD), I still think it's the best yet available. Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jesse, Rich 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).
RE: Just got back from SQL*Server 2000 training...
Maybe because I heard that Sybase finally implemented row-level locking. As of v10 (and I thought at least early 11 releases), the base unit of locking was the block. And that was the end of my 6-month stint programming with Sybase. Then there was that Interbase fiasco I had before being found by The Oracle... :) Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA -Original Message- Sent: Monday, February 18, 2002 4:49 PM To: Multiple recipients of list ORACLE-L 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? -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jesse, Rich 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).
Re: Just got back from SQL*Server 2000 training...
[Jeremiah Wilton] > 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. Is there a specific list of DBMS systems (Oracle is definitely one, obviously) where "readers don't block writers and writers don't block readers"? I had heard Progress was on that list, but never confirmed. -- James Manning <[EMAIL PROTECTED]> GPG Key fingerprint = B913 2FBD 14A9 CE18 B2B7 9C8E A0BF B026 EEBB F6E4 -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: James Manning 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).
Re: Just got back from SQL*Server 2000 training...
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).
RE: Just got back from SQL*Server 2000 training...
Jeremiah, Do you have an example / link to details of this. Is it just long running "verbs" - eg a full table scan, that can block writers or is there more to this in the case of SQL Server? Thanks, Bruce Reardon -Original Message- Sent: Tuesday, 19 February 2002 8:18 To: Multiple recipients of list ORACLE-L 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: Reardon, Bruce (CALBBAY) 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).
Re: Just got back from SQL*Server 2000 training...
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).
