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: Jared.Still_at_radisys.com

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: ListGuru_at_fatcity.com (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).