Re: Scheme for Frequent Backups and Reloads

the redo logs cannot be used to "undo" changes made to the database, except, as you outlined before, restoring an older datafile, and recovering the database to a specific SCN or a point in time, as you described.

to speed up the recovery process, you might consider placing copies of the backup datafiles in a separate directory, and creating symbolic links to point to the datafiles.

if, for example, you could move the datafiles in /u01/oradata/sid (when the database is down, of course) to /u01/sid_data1 and create symbolic links from the original location(s), like this: ln -s /u01/sid_data1/file.dbf /u01/oradata/sid/file1.dbf

then you can also put copies of the backup files in another location, for example /u01/sid_data2

allow the developers to run their tests, and when it is time to recover, simply replace all of the symbolic links to point to the pristine copies of the cold backup, and be ready to bring the database backup up very quickly.

then you can restore copies of the backup files to the first directory (/u01/sid_data1) location, and then you'd be ready to simply replace the symbolic links again.

as far as loading new data, why not have the developers have the developers keep the scripts/code they use to load the data, and then they can reload the data after a restore.

<teefamcg_at_my-deja.com> wrote in message news:8t7lhs$44e$1_at_nnrp1.deja.com...
> Hello, I have an 8.1.6.2 Oracle database running on an Unix platform. So as
> not to impact the production environment or other development environments,
> developers will use this database to develop and test a purge procedure.
> Once the delete code is run, they will want to recover the database back to
> its status before the delete. I have a cold backup, which we can use by
> shutting down the database, removing the dbf files, copying over the
> compressed backup files and uncompressing. After about an hour and a half,
> they can restart the database. This process is unsatisfactory for two
> reasons: 1. It takes a fair amount of time. 2. If the developer wants to
> create specific, new data to purge, they would have to input the data, create
> a new cold backup (over an hour), before testing the code again.
>
> I would like somehow to use the archive logs. With a small test, I was able
> to recover the database fairly quickly using 'recover database until time
> ....' and specifying a time after I new data was created and before the
> delete happened. But the database was completely recovered, including the
> delete. So my questions are: 1. Can I use the archive logs for this
> purpose, and how can I recover the data without the delete? 2. Once I 'alter
> database open resetlogs', do I need to keep the archivelogs from before the
> database was shutdown? Can they be deleted, and the next time I recover the
> database will I only need the archive logs since this most recent restart?
>
> Your words of wisdom are welcome. I do not want to use the Export/Import
> functionality because a full Export/Import would take more time than using
> the cold backup files, and the incremental will not handle well that the
> tables already exist. Thanks, Jamil
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Received on Wed Oct 25 2000 - 20:35:56 CDT