Re: trying out recovery

Try switching the logfile after you create the table but before you drop and switch the logfile again.

The archive log is only going to apply up to the most recent changes. So if the only thing that is logged is the creation and drop in the same logfile there isn't an option to restore just the table by just recovering until cancel. If you timed it you could probably recover with the TIME option.

For what it is worth...
I have found that if you do not switch the logfile before and after the backup and you lose data
What happens when you attempt to recover is that it asks for an archive log that hasn't been written to disk. This is a connundrun in itself.

The one thing you can do is point it to the active online redo log at that point in time and use that as your archive log. In general that is the only way to grab all the data completely when recovering up to the current time.

I have done recover until TIME but that has always proved to be flaky and doing the translation of the timestamp on the fly is just one more thing you don't want to do if you are under time constraints. (my two cents on that)
I'd ask other people who have done TIME recovery for advice.

Best of,

        heidi

> trying out this recovery scenario on a test DB,
> to recover from a 'drop table'
>
> 1) shutdown DB
> 2) take a backup of a single datafile which makes a tbs 'DATA1'
> 3) startup mount
> 4) issue 'alter db archivelog' and 'archive log start'
> 5) create a table 'TAB' in tbs 'DATA1' and insert some records and commit
*try switching the logfile here; a before log*

> 6) drop the table 'TAB'
> 7) Issue 'alter database switch logfile'
> 8) shutdown, restore the backup datafile and startup mount
Received on Mon May 15 2000 - 06:58:42 CDT