RE: Re: Fw: Just got back from SQL*Server 2000 training...
Jared, I was going to respond, but you did a great job for me. Your points were my points exactly. I really tried to go to the SQL*Server class with an open mind thinking "I'm adding a skill set", but I found myself constantly comparing to Oracle. I didn't mean to start the Holy War again, but thought it would make an interesting conversation. A bit more: Having databases in noarchivelog mode, especially during batch loads for data warehouses/datamarts is extremely important for a large database shop like ours. In terms of RAID, I was just pointing out that while we mirror our redo logs to at least two different groups with two different members, I was shocked that the transaction log in SQL*Server was in no way mirrored by SQL*Server. It was either do it at the hardware/OS level or risk it. Not a "Mission Critical" mentality. As for transferring 10GB over the network, this would be just backing up our archive logs, not to mention the datafiles themselves. We do it every day around the clock using our tape silo. We use RMAN with hotbackups directly to tape via Veritas NetBackup enterprise wide. 10GB is trivial in the Oracle world, however, judging by the response I got, not so trivial in the SQL*Server world. One last thing: Having been to the Oracle education classes, I was expecting to learn in depth how SQL*Server uses memory to buffer the database, shared SQL, etc. thinking this would be a major tuning strategy for SQL*Server. Based on the nature of your system, you could gear the equivalent of an SGA accordingly. I almost spit up my two cups of coffee when the instructor showed me the GUI slide-bar that controls memory allocation to SQL*Server. "If you need more, just slide the bar to the right..." I still chuckle... Jim Hawkins Oracle Database Administrator [EMAIL PROTECTED] wrote: >Couldn't resist responding to this. > >*Cannot take DB out of "archivelog" mode. Can limit what is posted to txn >log, but cannot stop it. >>> Why would you want to? So you have the remote possibility >>> of ending up with a corrupt, unrecoverable database if the >>> power supply on the system fails? > >JS: Taking a database out of archive mode is certainly valid for large >load operations. Let's see, I want to load 50 gig of raw data into >my data warehouse tonight, that will generate about 800 gig of redo. > >Do I really want to do generate that much redo, deal with the overhead, >and back it up besides? Or would it be easier to put the DW back in >archive mode and back up the new data? > >*Txn logs not mirrored. Must rely on RAID or other mirroring software. >>> Hardware RAID/mirrors are much better than software, so if >>> you are comparing Oracle software based mirrors to the >>> hardware based ones we use then our way is much faster > >JS: No mention of reliability there though is there? If I don't have >control >over the hardware layout, I want Oracle to mirror the logs, period. > > >Backups directly to tape require the tape to be attached locally to SQL >Server. >>> Okay, if you really want to transfer your 10+GB database over >>> the network each night, I suppose you will need to use Oracle. > >JS: 10+GB over the network is trivial. If you are using anything that >approaches enterprise level backups, you will dedicate some fast pipes >to your network attached tape system. This means that if you're using >for instance Tivoli with a StorageTek Tape Silo,you must copy it first >to disk, since you're not going to have direct access. Making backups >to disk first tends to break any Oracle specific tape cataloging system >( RMAN for instance ) so that files must be located manually in case >of a restore. > >*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? > >JS: This is a poor analogy. It isn't like disk space filling up in >Oracle. >The only disk likely to fill up is the archive log destination, and if >you're doing your job as a DBA, that won't happen. > >I've been to DBA class for Sybase, which has the identical mechanism for >transaction logging. It's crude and vulnerable. > >*If you have a 100GB DB that is full, your backup will be 100GB. No >compression of backups! >>> Valid point here. But I'd rather not trust my backup to a >>> compression scheme anyways. > >Then you must not be backing up to tape, as all tape drive systems >use built in compression. The "I don't trust compression" complaint >is a red herring. > >Jared > > > >-- >Please see the official ORACLE-L FAQ: http://www.orafaq.com >-- >Author: > INET: [EMAIL PROTECTED] > >Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 >San Diego, California-- Public Internet access / Mailing Lists >--
Re:RE: Just got back from SQL*Server 2000 training...
I find both the observations Jim made during the class and the remarks from the SqlServer list as both interesting. Having worked with SQL*Server as well as being an Oracle addict I observe that we each view our RDBMS choices as the best there is which is kind of valid. It's just very interesting how much more you can do when the software vendor is not so self assured that he knows best. Oh, you don't believe MicroSlop knows what is in your best interest? Go read the fine print on your license agreement, you've already agreed to that. Now pardon me while I allow Bill to drive. He says I need a patch for Access & those Oracle tools are in the way and require deleting. Dick Goulet Reply Separator Author: "Jesse; Rich" <[EMAIL PROTECTED]> Date: 2/19/2002 8:43 AM > - 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: 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: Fw: Just got back from SQL*Server 2000 training...
See below... > > Backups directly to tape require the tape to be attached > locally to SQL Server. > >> Okay, if you really want to transfer your 10+GB > database over the > >> network each night, I suppose you will need to use Oracle. > > JS: 10+GB over the network is trivial. If you are using > anything that approaches enterprise level backups, you will > dedicate some fast pipes to your network attached tape > system. This means that if you're using for instance Tivoli > with a StorageTek Tape Silo,you must copy it first to disk, > since you're not going to have direct access. Making backups > to disk first tends to break any Oracle specific tape > cataloging system ( RMAN for instance ) so that files must be > located manually in case of a restore. > I think the real key is that the value of 10GB is quoted as an extreme example! Just affirms my opinion that SQL-Server is where Oracle was over 10 years ago James -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: James Morle 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: Fw: Just got back from SQL*Server 2000 training...
Sounds like the M$ Brainwashing has taken root. :-) John [EMAIL PROTECTED] wrote: > Well there is no arguement there if he is willing to live > with all MS limitations by saying "I don't expect to do this..." > "I can live with this..." blah blah... > > Rich > > >> From: [EMAIL PROTECTED] >> Reply-To: [EMAIL PROTECTED] >> To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> >> Subject: Fw: Just got back from SQL*Server 2000 training... >> Date: Tue, 19 Feb 2002 08:08:21 -0800 >> >> I sent this e-mail to a friend who works with SqlServer and he sent >> this to >> a SqlServer list as You can see from headers >> >> Here are comments of a member :- >> >> Gints Plivna >> IT Sistçmas, Meríeïa 13, LV1050 Rîga >> http://www.itsystems.lv/gints/ >> >> >> >> - Original Message - >> To: "SQL 7 Discussions" <[EMAIL PROTECTED]> >> Sent: Tuesday, February 19, 2002 5:29 PM >> >> >> My two cent's prefaced by >>>>>>. I'm not an Oracle expert, and my >> answers >> reflect my limited (5 years) experience as a DBA... >> >> >> *Row size cannot span multiple 8k pages, therefore max row size = 8k >> >>>>>> I've yet to see a properly designed database that needs more >> >>>>>> than this. Unless he/she doesn't understand that text/image >> >>>>>> data is stored separately >> >> *Cannot take DB out of "archivelog" mode. Can limit what is posted >> to txn >> log, but cannot stop it. >> >>>>>> Why would you want to? So you have the remote possibility >> >>>>>> of ending up with a corrupt, unrecoverable database if the >> >>>>>> power supply on the system fails? >> >> *Txn logs not mirrored. Must rely on RAID or other mirroring software. >> >>>>>> Hardware RAID/mirrors are much better than software, so if >> >>>>>> you are comparing Oracle software based mirrors to the >> >>>>>> hardware based ones we use then our way is much faster >> >> *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. >> >>>>>> No comment. Not sure what he's after here. >> >> *Recommended that ALL production objects owned by DBO - not conducive to >> multi-schema instances. >> >>>>>> This is just a best-practices item. It works both ways. I >> >>>>>> personnally find it easier to use Oracle when everything is >> >>>>>> owned by one user. >> >> *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. >> >>>>>> I've not found this to be a limitation. How often do you >> actually >> >>>>>> do these tasks on a production database, anyways? >> >> Backups directly to tape require the tape to be attached locally to SQL >> Server. >> >>>>>> Okay, if you really want to transfer your 10+GB database over >> >>>>>> the network each night, I suppose you will need to use Oracle. >> >> *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? >> >> *If you have a 100GB DB that is full, your backup will be 100GB. No >> compression of backups! >> >>>>>> Valid point here. But I'd rather not trust my backup to a >> >>>>>> compression scheme anyways. >> >> >> >> >> >> -- >> Please see the official ORACLE-L FAQ: http://www.orafaq.com >> -- >> Author: >> 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). > > > > > > _ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: orantdba 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: Fw: Just got back from SQL*Server 2000 training...
We run a couple of production systems in noarchivelog. This is due to how they operate. They are reporting datamarts and the nightly loads would generate way to much redo to contain. Since all the data originates elsewhere recovery just means redoing a load. Any OLTP should be in archivelog. If you run out of space roll the old archives off to tape and delete from the filesystem. This is no where near the comparison of truncating the txn log. If you need an old log you can still get it back. Single schema?? Depends on the application and its operation. We run multiple schemas on some of our databases and single schema on others. It's a matter of separating different apps or app functions from others. When it makes sense do it. When it doesn't don't. That's why we are DBA's to direct the deveolpers in how these things should be handled. Rodd On Tue, 2002-02-19 at 11:38, Jay Hostetter wrote: Archivelog mode - I don't like putting test databases in archivelog mode. Or databases that are updated once a day. Redo logs are adequate to recover from a power system failure. Mirroring - The problem with relying on hardware mirroring is that it mirrors everything - corruption, delete commands, etc. I learned this one the hard way. Restricted activities- You probably don't have to do this stuff on small SQL Server databases. txn log - Oracle isn't vulnerable when you are backing up/deleting archive logs. single schema - Sounds like some applications that we have had to install, which were developed by lazy programmers who weren't concerned about security. You know, the ones that require a single user with full DBA rights. >>> [EMAIL PROTECTED] 02/19/02 11:08AM >>> I sent this e-mail to a friend who works with SqlServer and he sent this to a SqlServer list as You can see from headers Here are comments of a member :- Gints Plivna IT Sisttmas, Merfena 13, LV1050 Rega http://www.itsystems.lv/gints/ - Original Message - To: "SQL 7 Discussions" <[EMAIL PROTECTED]> Sent: Tuesday, February 19, 2002 5:29 PM My two cent's prefaced by >>. I'm not an Oracle expert, and my answers reflect my limited (5 years) experience as a DBA... *Row size cannot span multiple 8k pages, therefore max row size = 8k >> I've yet to see a properly designed database that needs more >> than this. Unless he/she doesn't understand that text/image >> data is stored separately *Cannot take DB out of "archivelog" mode. Can limit what is posted to txn log, but cannot stop it. >> Why would you want to? So you have the remote possibility >> of ending up with a corrupt, unrecoverable database if the >> power supply on the system fails? *Txn logs not mirrored. Must rely on RAID or other mirroring software. >> Hardware RAID/mirrors are much better than software, so if >> you are comparing Oracle software based mirrors to the >> hardware based ones we use then our way is much faster *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. >> No comment. Not sure what he's after here. *Recommended that ALL production objects owned by DBO - not conducive to multi-schema instances. >> This is just a best-practices item. It works both ways. I >> personnally find it easier to use Oracle when everything is >> owned by one user. *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. >> I've not found this to be a limitation. How often do you actually >> do these tasks on a production database, anyways? Backups directly to tape require the tape to be attached locally to SQL Server. >> Okay, if you really want to transfer your 10+GB database over >> the network each night, I suppose you will need to use Oracle. *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? *If you have a 100GB DB that is full, your backup will be 100GB. No compression of backups! >> Valid point here. But I'd rather not trust my backup to a >> compression scheme anyways. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jay Hostetter INET: [EMAIL PROTECTED] Fat City Network Services
Re: Fw: Just got back from SQL*Server 2000 training...
Couldn't resist responding to this. *Cannot take DB out of "archivelog" mode. Can limit what is posted to txn log, but cannot stop it. >> Why would you want to? So you have the remote possibility >> of ending up with a corrupt, unrecoverable database if the >> power supply on the system fails? JS: Taking a database out of archive mode is certainly valid for large load operations. Let's see, I want to load 50 gig of raw data into my data warehouse tonight, that will generate about 800 gig of redo. Do I really want to do generate that much redo, deal with the overhead, and back it up besides? Or would it be easier to put the DW back in archive mode and back up the new data? *Txn logs not mirrored. Must rely on RAID or other mirroring software. >> Hardware RAID/mirrors are much better than software, so if >> you are comparing Oracle software based mirrors to the >> hardware based ones we use then our way is much faster JS: No mention of reliability there though is there? If I don't have control over the hardware layout, I want Oracle to mirror the logs, period. Backups directly to tape require the tape to be attached locally to SQL Server. >> Okay, if you really want to transfer your 10+GB database over >> the network each night, I suppose you will need to use Oracle. JS: 10+GB over the network is trivial. If you are using anything that approaches enterprise level backups, you will dedicate some fast pipes to your network attached tape system. This means that if you're using for instance Tivoli with a StorageTek Tape Silo,you must copy it first to disk, since you're not going to have direct access. Making backups to disk first tends to break any Oracle specific tape cataloging system ( RMAN for instance ) so that files must be located manually in case of a restore. *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? JS: This is a poor analogy. It isn't like disk space filling up in Oracle. The only disk likely to fill up is the archive log destination, and if you're doing your job as a DBA, that won't happen. I've been to DBA class for Sybase, which has the identical mechanism for transaction logging. It's crude and vulnerable. *If you have a 100GB DB that is full, your backup will be 100GB. No compression of backups! >> Valid point here. But I'd rather not trust my backup to a >> compression scheme anyways. Then you must not be backing up to tape, as all tape drive systems use built in compression. The "I don't trust compression" complaint is a red herring. Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: 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: Fw: Just got back from SQL*Server 2000 training...
Well there is no arguement there if he is willing to live with all MS limitations by saying "I don't expect to do this..." "I can live with this..." blah blah... Rich >From: [EMAIL PROTECTED] >Reply-To: [EMAIL PROTECTED] >To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> >Subject: Fw: Just got back from SQL*Server 2000 training... >Date: Tue, 19 Feb 2002 08:08:21 -0800 > >I sent this e-mail to a friend who works with SqlServer and he sent this to >a SqlServer list as You can see from headers > >Here are comments of a member :- > >Gints Plivna >IT Sistçmas, Meríeïa 13, LV1050 Rîga >http://www.itsystems.lv/gints/ > > > >- Original Message - >To: "SQL 7 Discussions" <[EMAIL PROTECTED]> >Sent: Tuesday, February 19, 2002 5:29 PM > > >My two cent's prefaced by >>>>>>. I'm not an Oracle expert, and my answers >reflect my limited (5 years) experience as a DBA... > > >*Row size cannot span multiple 8k pages, therefore max row size = 8k > >>>>>> I've yet to see a properly designed database that needs more > >>>>>> than this. Unless he/she doesn't understand that text/image > >>>>>> data is stored separately > >*Cannot take DB out of "archivelog" mode. Can limit what is posted to txn >log, but cannot stop it. > >>>>>> Why would you want to? So you have the remote possibility > >>>>>> of ending up with a corrupt, unrecoverable database if the > >>>>>> power supply on the system fails? > >*Txn logs not mirrored. Must rely on RAID or other mirroring software. > >>>>>> Hardware RAID/mirrors are much better than software, so if > >>>>>> you are comparing Oracle software based mirrors to the > >>>>>> hardware based ones we use then our way is much faster > >*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. > >>>>>> No comment. Not sure what he's after here. > >*Recommended that ALL production objects owned by DBO - not conducive to >multi-schema instances. > >>>>>> This is just a best-practices item. It works both ways. I > >>>>>> personnally find it easier to use Oracle when everything is > >>>>>> owned by one user. > >*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. > >>>>>> I've not found this to be a limitation. How often do you actually > >>>>>> do these tasks on a production database, anyways? > >Backups directly to tape require the tape to be attached locally to SQL >Server. > >>>>>> Okay, if you really want to transfer your 10+GB database over > >>>>>> the network each night, I suppose you will need to use Oracle. > >*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? > >*If you have a 100GB DB that is full, your backup will be 100GB. No >compression of backups! > >>>>>> Valid point here. But I'd rather not trust my backup to a > >>>>>> compression scheme anyways. > > > > > >-- >Please see the official ORACLE-L FAQ: http://www.orafaq.com >-- >Author: > 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). _ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: oracle dba 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: Fw: Just got back from SQL*Server 2000 training...
Archivelog mode - I don't like putting test databases in archivelog mode. Or databases that are updated once a day. Redo logs are adequate to recover from a power system failure. Mirroring - The problem with relying on hardware mirroring is that it mirrors everything - corruption, delete commands, etc. I learned this one the hard way. Restricted activities- You probably don't have to do this stuff on small SQL Server databases. txn log - Oracle isn't vulnerable when you are backing up/deleting archive logs. single schema - Sounds like some applications that we have had to install, which were developed by lazy programmers who weren't concerned about security. You know, the ones that require a single user with full DBA rights. >>> [EMAIL PROTECTED] 02/19/02 11:08AM >>> I sent this e-mail to a friend who works with SqlServer and he sent this to a SqlServer list as You can see from headers Here are comments of a member :- Gints Plivna IT Sisttmas, Merfena 13, LV1050 Rega http://www.itsystems.lv/gints/ - Original Message - To: "SQL 7 Discussions" <[EMAIL PROTECTED]> Sent: Tuesday, February 19, 2002 5:29 PM My two cent's prefaced by >>. I'm not an Oracle expert, and my answers reflect my limited (5 years) experience as a DBA... *Row size cannot span multiple 8k pages, therefore max row size = 8k >> I've yet to see a properly designed database that needs more >> than this. Unless he/she doesn't understand that text/image >> data is stored separately *Cannot take DB out of "archivelog" mode. Can limit what is posted to txn log, but cannot stop it. >> Why would you want to? So you have the remote possibility >> of ending up with a corrupt, unrecoverable database if the >> power supply on the system fails? *Txn logs not mirrored. Must rely on RAID or other mirroring software. >> Hardware RAID/mirrors are much better than software, so if >> you are comparing Oracle software based mirrors to the >> hardware based ones we use then our way is much faster *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. >> No comment. Not sure what he's after here. *Recommended that ALL production objects owned by DBO - not conducive to multi-schema instances. >> This is just a best-practices item. It works both ways. I >> personnally find it easier to use Oracle when everything is >> owned by one user. *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. >> I've not found this to be a limitation. How often do you actually >> do these tasks on a production database, anyways? Backups directly to tape require the tape to be attached locally to SQL Server. >> Okay, if you really want to transfer your 10+GB database over >> the network each night, I suppose you will need to use Oracle. *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? *If you have a 100GB DB that is full, your backup will be 100GB. No compression of backups! >> Valid point here. But I'd rather not trust my backup to a >> compression scheme anyways. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jay Hostetter 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...
> - 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).
Fw: Just got back from SQL*Server 2000 training...
I sent this e-mail to a friend who works with SqlServer and he sent this to a SqlServer list as You can see from headers Here are comments of a member :- Gints Plivna IT Sistçmas, Meríeïa 13, LV1050 Rîga http://www.itsystems.lv/gints/ - Original Message - To: "SQL 7 Discussions" <[EMAIL PROTECTED]> Sent: Tuesday, February 19, 2002 5:29 PM My two cent's prefaced by >>. I'm not an Oracle expert, and my answers reflect my limited (5 years) experience as a DBA... *Row size cannot span multiple 8k pages, therefore max row size = 8k >> I've yet to see a properly designed database that needs more >> than this. Unless he/she doesn't understand that text/image >> data is stored separately *Cannot take DB out of "archivelog" mode. Can limit what is posted to txn log, but cannot stop it. >> Why would you want to? So you have the remote possibility >> of ending up with a corrupt, unrecoverable database if the >> power supply on the system fails? *Txn logs not mirrored. Must rely on RAID or other mirroring software. >> Hardware RAID/mirrors are much better than software, so if >> you are comparing Oracle software based mirrors to the >> hardware based ones we use then our way is much faster *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. >> No comment. Not sure what he's after here. *Recommended that ALL production objects owned by DBO - not conducive to multi-schema instances. >> This is just a best-practices item. It works both ways. I >> personnally find it easier to use Oracle when everything is >> owned by one user. *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. >> I've not found this to be a limitation. How often do you actually >> do these tasks on a production database, anyways? Backups directly to tape require the tape to be attached locally to SQL Server. >> Okay, if you really want to transfer your 10+GB database over >> the network each night, I suppose you will need to use Oracle. *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? *If you have a 100GB DB that is full, your backup will be 100GB. No compression of backups! >> Valid point here. But I'd rather not trust my backup to a >> compression scheme anyways. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: 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).
Just got back from SQL*Server 2000 training...
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! Jim Oracle Database Administrator -- _ Jim Hawkins Oracle Database Administrator [EMAIL PROTECTED] __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jim Hawkins 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).
