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

Home -> Community -> Usenet -> c.d.o.server -> Re: Newbie backup question

Re: Newbie backup question

From: Howard J. Rogers <howardjr_at_www.com>
Date: Sat, 10 Mar 2001 10:20:27 +1100
Message-ID: <3aa9650b@news.iprimus.com.au>

You will absolutely *have* to run in archivelog mode.

You can't just copy datafiles some place whilst the database is up and running (and you say you want 24x7), and expect them to be meaningful. They will be internally all over the place, as bits of files are copied at the O/S level whilst things are happening to the rest of the file within Oracle. The only thing that can patch that mess back together into a consistent, and useable, datafile is the application of redo. And you have to be able to apply ALL redo since the earliest time the file started to be copied. The only way you can guarantee to be able to do that is to take copies of all redo generated -ie, take archives.

Archives, however, will simply be produced one after the other, without end. And that means you have to manage them -even a Terrabyte-sized disk, if such a thing existed, would eventually run out of space. At which point, no further archives can be produced, and your database will hang until someone sorts the problem out. That rather rules out running the thing in 'unattended' mode. On the other hand, if you are clever with the script your Users want to execute, you could arrange for, say, the archives from two days ago to be deleted as the new backup completes (theoretically, you only need the archives since the time the last backup started, but you'd want to allow some leeway).

The whole concept of doing recovery in that scenario 'unattended', however, beggars belief. It ain't going to work. Not reliably, anyway!

If you don't mind data loss (and you say you don't), and don't mind a bit of down-time, then yes, you can run in noarchivelog mode. You guarantee usable datafiles that way by the simple expedient of shutting the database down, and copying them cold -since nothing can be happening to them in Oracle, because it's shut down, the O/S is guaranteed to take consistent copies. Given that you say the database is small, the downtime could be a matter of minutes. Recovery in noarchivelog mode *is* something that could run relatively unattended, since it only involves copying *.* from one location to another. Even I could probably knock up a script to achieve that!

In summary, I think you've got mutually exclusive goals. If the thing needs to be simple and unattended, go cold backups in noarchivelog mode... but you'll have to have a downtime window to do that in. If the thing needs to be up and running 24hours a day, 7 days a week, you'll have to run archivelog, and the goal of unattendability goes out the window. I simply don't see how you can achieve both.

Regards
HJR "Brian Dick" <bdick_at_home.com> wrote in message news:D66q6.13243$PR.91127_at_news1.wwck1.ri.home.com...
> I am mainly an application developer, but I've been tossed onto a project
> that needs a quick solution for backup. We have no "real" DBA, just me as
 a
> "de facto" DBA.
>
> The project uses Oracle V8.1.6 as an imbedded database, so it needs to run
> almost entirely unattended and 24x7. The database is relatively small and
 is
> configured to run in NOARCHIVE mode.
>
> But the users of the system do want to be able to frequently run a script
> that takes a full backup of the database. If the system incurrs a media
> crash, then the users would run a script for a restore from the backup.
 Loss
> of data from the time of backup to the time of restore is NOT an issue.
>
> I've read the Oracle8i Backup and Recovery Guide a couple of times, and I
 am
> confused with all of the options available. I think my requirements are
> fairly simple and all of these ARCHIVE/NOARCHIVE, consistent/inconsistent,
> complete/incomplete decisions really blur the picture.
>
> I know the above scenario is less than optimal, but I have to play with
 the
> cards I have been delt. We plan to have a robust backup/recovery process
 in
> the next version of our system (promise <g>).
>
> Later,
> BEDick
>
>
>
Received on Fri Mar 09 2001 - 17:20:27 CST

Original text of this message

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