Flashback

Flashback database and backup scenario:
------------------------------------------------
If you flashback a database to a GRP (Guaranteed Restore Point) that has been set in the database, all backups that were taken after the GRP was created can no longer be used.  You can however restore the database to a point in time prior to the GRP creation.


SQL> shutdown immediate
startup mount
flashback database to restore point TEST;

Total System Global Area  384143360 bytes
Fixed Size                  2154016 bytes
Variable Size             301990368 bytes
Database Buffers           75497472 bytes
Redo Buffers                4501504 bytes


Database mounted.
SQL>
Flashback complete.


SQL> alter database open resetlogs;


Database altered.

Now you can restore and recover the database from any backup taken BEFORE the GRP was created.  See below:

Recovery Manager: Release 11.1.0.7.0 - Production on Thu Dec 2 11:03:52 2010

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: SBX11107 (DBID=472398487, not open)

RMAN> run {
2> restore database;
3> recover database;
4> }

Starting restore at 02-DEC-2010
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=152 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00002 to /u03/oradata/sbx11107/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u03/oradata/sbx11107/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00006 to /u02/oradata/sbx11107/xmldb_01.dbf
channel ORA_DISK_1: reading from backup piece /orabkup/sbx11107/rman/datafile_l0/df_sbx11107_02Dec10_1054_451_1_dbf.rmn
channel ORA_DISK_1: piece handle=/orabkup/sbx11107/rman/datafile_l0/df_sbx11107_02Dec10_1054_451_1_dbf.rmn tag=SBX11107_INCR. LEV 0
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:01:36
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
.....
.....
.....
channel ORA_DISK_1: piece handle=/orabkup/sbx11107/rman/datafile_l0/df_sbx11107_02Dec10_1054_450_1_dbf.rmn tag=SBX11107_INCR. LEV 0
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:02:35
Finished restore at 02-DEC-2010

Starting recover at 02-DEC-2010
using channel ORA_DISK_1

starting media recovery

archived log file name=/orabkup/temp_arch/1_1_736684842.dbf thread=1 sequence=1
archived log file name=/orabkup/temp_arch/1_2_736684842.dbf thread=1 sequence=2
archived log file name=/orabkup/temp_arch/1_3_736684842.dbf thread=1 sequence=3
media recovery complete, elapsed time: 00:00:02
Finished recover at 02-DEC-2010

RMAN> sql 'alter database open';

sql statement: alter database open

RMAN>

Comments

Post a Comment

Popular posts from this blog

RMAN-10038: database session for channel prm3 terminated unexpectedly

Problem: I had an issue where I was trying to build a 1.7 TB Data Guard environment and kept receiving the highlighted error below.  I thought it was some type of fluke so I restarted the job 2 more times only to receive the same error. Fix: After researching the issue, I found it was because the sqlnet.ora needed to be configured correctly.  I added the entry " SQLNET.EXPIRE_TIME = 10 " to the sqlnet.ora on both the source and the target database servers under the RDBMS $ORACLE_HOME/network/admin.  Upon restarting the RMAN active database standby build, it was able to move past this error and built successfully. Starting backup at 07-MAY-17 channel prm1: starting datafile copy input datafile file number=00003 name=+DATA/testdb/datafile/undotbs1.262.940412881 channel prm2: starting datafile copy input datafile file number=00129 name=+DATA/testdb/datafile/welldoc1.390.940509955 channel prm3: starting datafile copy input datafile file number=00130 name=+DATA/test
Read more

ORA-17630: Mismatch in the remote file protocol version client 2 server 3

I was trying to create an Oracle Data Guard environment (physical standby) from an Oracle database running version 12.1.0.2. The database was running an older PSU version ("Database Patch Set Update : 12.1.0.2.161018 (24006101)") to be specific. Upon trying to build the standby by using RMAN DUPLICATE with ACTIVE DATABASE, I ran into the below error: executing Memory Script Starting backup at 16-JUL-18 RMAN-03009: failure of backup command on prm1 channel at 07/16/2018 13:51:46 ORA-17629: Cannot connect to the remote database server ORA-17630: Mismatch in the remote file protocol version client 2 server 3 continuing other job steps, job failed will not be re-run released channel: prm1 released channel: prm2 released channel: prm3 released channel: prm4 released channel: prm5 released channel: stb1 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: ====================
Read more

ORA-00338: log {n} of thread {n} is more recent than control file

I received the following error in a primary database's alert log that I was supporting recently.   ORA-00312: online log 5 thread 1: '+DATA/db_name/onlinelog/group_5.297.846947859' ORA-00338: log 5 of thread 1 is more recent than control file The database has a DataGuard environment as well and below are the steps that I took to resolve the issue. 1.  First, I checked the status of the redo logs and their current sizes and status. SQL> select group#,bytes/1024/1024,status from v$log;     GROUP# BYTES/1024/1024 STATUS ---------- --------------- ----------------          1              50 INACTIVE          2              50 INACTIVE          3              50 INACTIVE          4             250 INACTIVE          5             250 INACTIVE          6             250 CURRENT 2.  As you can see, groups 1, 2, 3 have 50 MB redo log group sizes while group 4, 5, 6 are 250 MB redo log group sizes.  This is something that I highly suspect was/is the issue.  So I
Read more