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