Re: Backup methods

It sounds like a cold backup would suffice for your needs right now, but either a cold or a hot are fairly easy to do.

Use SQL to create a dynamic script do that if/when you move/add datafiles etc. you wont have to worry about editing your scripts to accomodate the changes you make.

You can apply your archived redo logs to a database recovered by either a cold or a hot backup to the point of failure, you just need the control file as it was at the point of failure, which is no problem because you have at least 2, preferably 3 copies of it on different disks right?.

If recovering to the "point of failure" is not critical to you, then importing from an export is ok, although its not the way I'd do it. And you don't really need the database in archivelog mode if thats the case.

There are plenty of scripts out there to generate your backup scripts from the data dictionary, but IMO it is just as easy to write one on your own as it is to modify one that someone else has written.

hth

"Tom Brown" <tom_at_eazyriders.com> wrote in message news:2_Yo8.6377$tI6.45100144_at_news-text.cableinet.net...
> Hi,
>
> Being quite new to oracle on a DBA front I'm after some advice. How should
i
> be keeping a backup of the database? At the moment i do a nightly export
of
> the database on a per user basis. These are written and zipped into a
> directory. It cycles 'round so at any one time i have the last 3 days
> exports. I have only had to recover one user in the past due to data
> corruption and this export has proved very effective. I do have the
> instances in archive log mode but to be fair i have no idea how to apply
> archive logs to a recovered database to bring it back to a point i time. I
> just rely on the export and then if a problem arises nuke the user,
recreate
> it and import from the export... Is this a very bad thing to be doing? I
> suspect that although 'it works so why fix it' I'm doing something
> fundamentally against what is thought to be the correct approach to back
and
> recovery.
>
> any comments appreciated....
>
> Tom
>
> BTW this is not a database linked in anyway to financial transaction if
that
> makes any difference to the approach taken.
>
>
Received on Fri Mar 29 2002 - 15:15:01 CST