Be careful to ensure that the message is that a hot backup requires archivelogs, not the use of a particular utility (RMAN) requires archivelogs. I'm surprised that no-one has suggested at least one other possible solution for what your requirements appear to be and that is simply taking a consistent export each night. Obviously the viability of this rather depends upon the size of data involved, but given that you've said that you can lose a days data a consistent export would seem to fit the bill as well. Niall On 4/5/07, jim.silverman@xxxxxxxxxxx <jim.silverman@xxxxxxxxxxx> wrote:
All: Thanks to those who have responded to this issue. Based on this input, it's clear that sending the archived log files to the great by-and-by will in almost every situation lead to an unrecoverable database. I'm going to let my management know that performing hot backups with rman requires the presence of archivelogs, end of story. Best regards, ===================================== Jim Silverman Senior Systems Database Administrator Solucient, LLC - A Thomson Company Telephone: 734-669-7641 FAX: 734-930-7611 E-Mail: jim.silverman@xxxxxxxxxxx -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Silverman, James (TH USA) Sent: Thursday, April 05, 2007 3:11 PM To: oracle-l@xxxxxxxxxxxxx Subject: Can Log Files Be Archived To The Bit Bucket? We manage several non-production 10g databases that are currently shut down and backed up cold every weekend. We'd like to begin backing them up using rman, both to avoid these weekly shutdowns and to gain the ability to recover to a time within 24 hours of a failure. Our plan is to perform Level-0 incremental backups on the weekend, and Level-1s each night during the week; we can live with an incomplete recovery through the most recent Level-1 available. To enable this, we'll need to convert the databases to ARCHIVELOG mode. However, we don't want to have to deal with managing archivelog space, since we often generate a lot of redo that, per the recovery scenario described above, will never be applied. As a result, we'd like to set up our environment such that the archiver's output is not saved anywhere. We tried setting LOG_ARCHIVE_DEST_1 to "LOCATION=/dev/null", and while Oracle didn't complain when we started the instance, the archiver wasn't very happy when it woke up. We've also considered creating a small filesystem to hold the log files and firing up a cron job to periodically clear it out, but we'd rather avoid building such a kludge that would accomplish nothing useful while adding another item to our list of maintenance tasks. Thanks in advance for any suggestions. ===================================== Jim Silverman Senior Systems Database Administrator Solucient, LLC - A Thomson Company Telephone: 734-669-7641 FAX: 734-930-7611 E-Mail: jim.silverman@xxxxxxxxxxx -- //www.freelists.org/webpage/oracle-l -- //www.freelists.org/webpage/oracle-l
-- Niall Litchfield Oracle DBA http://www.orawin.info