Database Software

To be on the safe side, somehow, I'll do like this:

- shutdown immediate - this if the database is up and running

- rename the datafile folder, get a copy of spfile and controlfile to a safe location

- create the old folder for the datafiles

- startup nomount

- restore controlfile from the desired backup

- put the database in mount mode

- restore database until time

- recover database until time

Best regards

R-MAN wrote:
Hello Team,
Today is 25th May '17 and I want to restore the data till 16th may only.
How I shall proceed.
Do I need to drop the database first and then I shall restore controlfile and restore/recover database or any other option is there.
My point is - Do I need to drop the database first and then restore it from backup piece of 16th may or I can go without dropping the database.
Regards,
Ronak

a) I think you need to backup database 25th May 17. Yes I know, it will be a second backup and probably wont be used.

b) Drop database (to be sure the space storage used is released), be carefull to do NOT delete the backups.

c) Restore spfile, controlfile, database from backup 16th,

d) Perform an incomplete database recovery to desired time or SCN

No, just to a point in time recovery. If are are trying to restore and recover a deleted tablespace, you will however also have to restore a backup controlfile where the tablespace still existed. If your backup, archivelog and existing data is sufficient, the following should work:

$ rman target /

startup force mount

RMAN> run {

set until time "to_date('16-MAY-2017 00:00:00','DD-MON-YYYY HH24:MI:SS')";

restore database;

recover database;

}

RMAN> alter database open resetlogs;

Dude! wrote:
No, just to a point in time recovery. If are are trying to restore and recover a deleted tablespace, you will however also have to restore a backup controlfile where the tablespace still existed. If your backup, archivelog and existing data is sufficient, the following should work:
$ rman target /
startup force mount
RMAN> run {
set until time "to_date('16-MAY-2017 00:00:00','DD-MON-YYYY HH24:MI:SS')";
restore database;
recover database;
}
RMAN> alter database open resetlogs;

Sometimes in test environments when you add new dafiles after the first restoration process, those datafiles remains in storage devices if I just run the restore process. Thats why I prefer to drop the database to be sure that all current datafiles are deleted. Also, this happends when you restore same database but now using the OMF notation, all old datafiles are not replaced by new ones because new ones have new names.

I was merely answering the OP's question whether it was necessary to drop the database first and the answer is simply: no, it's not necessary. Nothing else was mentioned.

I think the question is based on a common misconception, hence the thread subject "same server, same name". Which is that RMAN cannot restore and recover a database that already exists, or that the database will have to be created first in order to restore and recover "into". Both is wrong. It is not necessary to drop a database prior to restoring it, regardless of the type of recovery performed. The RMAN restore process will automatically restore and overwrite existing database files as required and necessary for the recovery process to be able to apply archvielogs to recover to the specified time. For this to work however, the existing database must not be open and started with only the controlfile mounted, of course.

Hello Dude,

Thanks.

But how it will be possible to restore the database to 16th May '17 without dropping the database which is having data till 25th May '17.

Regards,

Ronak

1st option:

- with current controlfile put the database in mount and run recover database with SET UNTIL TIME clause

2nd option:

- restore a previous controlfile, put the database in mount mode - run restore database.

R-MAN wrote:
Hello Dude,
Thanks.
But how it will be possible to restore the database to 16th May '17 without dropping the database which is having data till 25th May '17.
Regards,
Ronak

Because the first step (rman restore) restores (completely overwrites) the data files from the last level 0 backup PRIOR TO your "until" time.  Then you 'recover' and level 1 backups and/or archivelogs are used to roll the db forward from that level 0 backup up to your SET UNTIL time.

Hello EdStevens,

So , what I understand is that if we don't drop the target database and initiated the refresh, It'll get completed.

We will not be getting error like 'DATAFILE already exists or any". Correct ?

Again, the RMAN restore process will automatically restore and overwrite existing database files as required and necessary for the recovery process to be able to apply the archvielogs to recover to the specified time.

RMAN decides what files need to be overwritten and whether it is more efficient to use image copies, full backup, incremental backups or archivelogs, and it will not restore or recover datafiles that do not need to be restored or recovered or have already been restored, etc.

Thanks Dude.

Regards,

Ronak

R-MAN wrote:
Thanks Dude.
Regards,
Ronak

You did not mentioned if the source and target server are the same.

I mean, source server is the one where you perform the backup.

the target server is the one where you restore the backup.

If both are same, you can safety just restore the database. Restoration process will overwrite your current datafiles.

if don't, both servers are different, then, in target server I advise that always drop de database before restoring process.

Hello Juan,

Thanks.

If I go without dropping the database in different server, then what are the implications ?

Regards

Well, I prefer to drop the database because in my target environments, sometimes I create a new tablespaces (new datafiles), so, this new tablespaces are not know by my source database.

Then, when I take a new backup from source database, if I just restore the database, this restoration process will not delete/drop the datafiles also will not been overwriten because on source database the tablespaces created, on target database, don't exists. Then this datafiles still on target server just using storage. Thats why I drop the database on target server and then restore the database, this guarrantee that all storage used by old database was freeded/released.

Thanks Dude.