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).
