Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Lots and lots of redo logs

RE: Lots and lots of redo logs

From: Christopher Spence <cspence_at_FuelSpot.com>
Date: Fri, 14 Sep 2001 06:03:28 -0700
Message-ID: <F001.0038E6A4.20010914061020@fatcity.com>

!! Please do not post Off Topic to this List !!

You can only have a max of 8 log groups if I remember correctly.

Yesterday's backup may have failed, and you may have to recover from the day prior or prior's prior. Keep this in mind as well.

With archive log, you can use 6 month old backup, and apply all the logs to become current if for whatever reason all the backups failed and that is all you had.

Another thing to keep in mind is if you plan on using log miner, you may want to look through a log file in the past, via archive log.

Also keep in mind, DDL and data dictionary costs redo, so your redo usage is almost always more than expected. For example if you have to run initjvml.sql, that generates over 100Mb of redo activity. This under normal cases will spin two of your 50Mb logs.

But given these and perhaps other concerns, if your still comfortable, by all means. But in my opinion here is my priorities.

  1. Recoverability
  2. Performance

"Do not criticize someone until you walked a mile in their shoes, that way when you criticize them, you are a mile a way and have their shoes."

Christopher R. Spence
Oracle DBA
Phone: (978) 322-5744
Fax: (707) 885-2275

Fuelspot
73 Princeton Street
North, Chelmsford 01863  

-----Original Message-----
Sent: Friday, September 14, 2001 9:20 AM To: Multiple recipients of list ORACLE-L

!! Please do not post Off Topic to this List !!

I am planning setting up a new database with the redo logs on RAID 1 array
(mirror).

The amount of space available on the array is 16Gb and only the redo logs will be on there.
The application will generate << 2Gb of redo per day and will be backed up
(cold) each night to tape.

If I set up enough groups (MAXLOGFILES) such that the whole array is full of logs (each probably 50Mb in size) can I safely run this in NOARCHIVELOG mode and still expect ARCHIVELOG mode type complete recovery?

The application will not overwrite a log till several days (and several backups) after it was last used, and the logs are protected by RAID. Recovery requirement is only to be able to get back to the "current state" (say that last 24 hours max.) before failure, not recover way back in time.

Are there any other issues (eg. performance) that I should consider?

Any comments much appreciated.

Thanks
- Bill.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Bill Buchan
  INET: wbuchan_at_uk.intasys.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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Christopher Spence INET: cspence_at_FuelSpot.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).
Received on Fri Sep 14 2001 - 08:03:28 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US