Backups and Recovery Scenarios

Updated Last – 14-01-2010

# ----------------------- Database Recovery Scenarios: -------------------------- Summary of Scenarios: (***NOT IN ORDER***)

-- Redo Log Group

Scenario 1 - Recovering After Losing a Member of a Multiplexed Online Redo Log GroupScenario 2 - Recovering After the Loss of All Members of an Online Redo Log GroupScenario 3 - Loss of INACTIVE Online Redo Log GroupScenario 4 - Loss of CURRENT Online Redo Log GroupScenario 5 - Recovering After the Loss of All Members of an Online Redo Log Group Using RMANScenario 6 - Recovering After the Loss of All Members of an Online Redo Log Group Using RMAN with Catalog with CommVaultScenario 33 - Create new logfile groups and drop old groups

-- Control file

Scenario 7 - Loss of control fileScenario 8 - Recovering After a lost of all control files using RMANScenario 9 - Recovering After a lost of all control files using control file backup to trace fileScenario 10 - Recovering After a lost of all control files using RMAN with Catalog with CommVaultScenario 11 - Recovering After a lost of all control files and spfile using NO CatalogScenario 12 - Recovering After a lost of all control files and spfile using NO Catalog with CommVault

--Non-System Tablespace/Datafiles

Scenario 13 - One or more of the non-SYSTEM database datafiles have been destroyed due to media failure using RMAN with CatalogScenario 14 - One or more of the non-SYSTEM database datafiles have been destroyed due to media failure using RMAN with Catalog with CommVaultScenario 17 - Missing Data File - non-SYSTEM tablespace fileScenario 18 - Loss of Non-Essential Datafile When Database is DownScenario 19 - Recover a Lost Datafile with No Backup with RMAN with CatalogScenario 20 - Recover a Lost Datafile with No Backup without RMANScenario 21 - Recover a Lost Datafile with No Backup with RMAN with Catalog with CommVault (***AWAITING RESPONSE FROM COMMVAULT***)(They don’t know…)Scenario 29 - Loss of an Online Undo Segment Datafile (Open or Closed Database) with RMAN with Catalog

1

Scenario 30 - Loss of an Online Undo Segment Datafile (Open or Closed Database) with RMAN with NO CatalogScenario 31 - Loss of an Online Undo Segment Datafile (Open or Closed Database) without RMANScenario 32 - Failure during Open Database - tablespace in backup mode with RMAN with Catalog

--SYSTEM Tablespace/Datafile

Scenario 15 - Loss of a SYSTEM tablespace datafile using RMAN with CatalogScenario 16 - Loss of a SYSTEM tablespace datafile without using RMAN

--User Errors

Scenario 22 - Recover from User Errors - dropped table or deleted data with RMAN with CatalogScenario 23 - Recover from User Errors - dropped table or deleted data with RMAN with NO CatalogScenario 24 - Recover from User Errors - dropped table or deleted data - manual data entry Scenario 25 - Recover from User Errors - dropped table or deleted data –Flashback Drop Scenario 26 - Recover from User Errors - dropped table or deleted data –Flashback Table and Query Scenario 27 - Recover from User Errors - dropped table or deleted data – Using Log MinerScenario 28 - Recover from User Errors - dropped table or deleted data – Flashback Database

--Archive Logs

Scenario 34 - Recover archive log using RMAN with CatalogScenario 35 - Recover archive log using RMAN with Catalog with CommVault

--Duplicate Database

Scenario 36 – Duplicate Database using RMAN with CatalogScenario 37 – Duplicate Database using RMAN with Catalog with CommVault(***AWAITING RESPONSE FROM COMMVAULT***)(This fails memory script takes hours to run, it is mounted and trips….)

--Block Corruption

Scenario 38 – Check and repair block corruption using RMAN with Catalog

2

--Background Information

If a media failure has affected the online redo logs of a database, then the appropriate recovery procedure depends on the following:

The configuration of the online redo log: mirrored or non-mirrored The type of media failure: temporary or permanent

The types of online redo log files affected by the media failure: current, active, unarchived, or inactive

--ViewsSelect member from v$logfile;Select * from v$log;Select * from v$archived_log;

--DBA StuffAdd 1 member to group - mirroralter database ADD logfile member 'E:\ORACLE\ORADATA\BACKUPS\REDO02_2.LOG' to group 2;

Drop memberalter database DROP logfile member 'E:\ORACLE\ORADATA\BACKUPS\REDO02_2.LOG';

Will generate error message ...ORA-01609: log 1 is the current log for thread 1 - cannot drop members

keep switching alter system switch logfile;

Restore Archive logrestore archivelog from logseq=42 until logseq=42;

Relationship between SCN and log filesSelect * from v$log_history

-each log file - has series change no's from first to next change...-based on archive log format

Archived Redo Log File Conventions in Oracle

3

Table 7-1 Archived Redo Log Filename Format Parameters

Archive log Format

%s log sequence number%S log sequence number, zero filled%t thread number%T thread number, zero filled%a activation ID%d database ID%r resetlogs ID that ensures unique names are constructed for the archived log files

across multiple incarnations of the database

*.log_archive_format='ARC%S_%D.%T'

e.g. ARC00065_1255702348

Ref:select dbid from v$database;

SQL> select dbid from v$database;

DBID----------1255702348

Displays V$LOG status information that can be crucial in a recovery situation involving online redo logs

Status Description

UNUSED The online redo log has never been written to.

CURRENT The online redo log is active, that is, needed for instance recovery, and it is the log to which the database is currently writing. The redo log can be open or closed.

ACTIVE The online redo log is active, that is, needed for instance recovery, but is not the log to which the database is currently writing.It may be in use for block recovery, and may or may not be archived.

CLEARING The log is being re-created as an empty log after an ALTER DATABASE CLEAR LOGFILE statement. After the log is cleared, then the status changes to UNUSED.

CLEARING_CURREN The current log is being cleared of a closed thread.

4

Status Description

T The log can stay in this status if there is some failure in the switch such as an I/O error writing the new log header.

INACTIVE The log is no longer needed for instance recovery. It may be in use for media recovery, and may or may not be archived.

#-------------------------Scenario 1 - Recovering After Losing a Member of a Multiplexed Online Redo Log Group#-------------------------

If the online redo log of a database is multiplexed, and if at least one member of each online redo log group is not affected by the media failure, then the database continues functioning as normal, but error messages are written to the log writer trace file and the alert_SID.log of the database.

Solve the problem by taking one of the following actions:

If the hardware problem is temporary, then correct it. The log writer process accesses the previously unavailable online redo log files as if the problem never existed.

If the hardware problem is permanent, then drop the damaged member and add a new member by using the following procedure.

Step1SELECT * FROM V$LOG;

Group 1 & 2 inactiveRename group 1 plus 1 member

Step 2Locate the filename of the damaged member in V$LOGFILE. The status is INVALID if the file is inaccessible:

SELECT GROUP#, STATUS, MEMBER FROM V$LOGFILEWHERE STATUS='INVALID';

Step 3

5

Drop the damaged member

ALTER DATABASE DROP LOGFILE MEMBER 'E:\ORACLE\ORADATA\BACKUPS\REDO01.LOG';

If u get error ORA-01609

ALTER SYSTEM SWITCH LOGFILE;

Step 4Add a new member to the group.

ALTER DATABASE ADD LOGFILE MEMBER 'E:\ORACLE\ORADATA\BACKUPS\REDO01.LOG' TO GROUP 1;

If the file you want to add already exists, then it must be the same size as the other group members, and you must specify REUSE. For example:

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/oradata/trgt/redo02b.log' REUSE TO GROUP 2;

#-------------------------Scenario 2 - Recovering After the Loss of All Members of an Online Redo Log Group#-------------------------

If a media failure damages all members of an online redo log group, then different scenarios can occur depending on the type of online redo log group affected by the failure and the archiving mode of the database.

If the damaged log group is active, then it is needed for crash recovery; otherwise, it is not.

Inactive It is not needed for crash recovery

Clear the archived or unarchived group.

Active It is needed for crash recovery

Attempt to issue a checkpoint and clear the log; if impossible, then you must restore a backup and perform incomplete recovery up to the most recent available redo log.

Current It is the log that the database is currently writing to

Attempt to clear the log; if impossible, then you must restore a backup and perform incomplete recovery up to the most recent available redo log.

Step 1Your first task is to determine whether the damaged group is active or inactive.

6

SELECT GROUP#, STATUS, MEMBER FROM V$LOGFILE;

Step 2

Determine which groups are active

SELECT GROUP#, MEMBERS, STATUS, ARCHIVED FROM V$LOG;

If the affected group is inactive, follow the procedure in Losing an Inactive Online Redo Log Group.

If the affected group is active (as in the preceding example), then follow the procedure in "Losing an Active Online Redo Log Group".

# -------------------------------------------------------------------------------- Scenario 3 - Loss of INACTIVE Online Redo Log Group # --------------------------------------------------------------------------------

If all members of an online redo log group with INACTIVE status are damaged, then the procedure depends on whether you can fix the media problem that damaged the inactive redo log group.

Temporary Fix the problem. LGWR can reuse the redo log group when required.

Permanent The damaged inactive online redo log group eventually halts normal database operation. Reinitialize the damaged group manually by issuing the ALTER DATABASE CLEAR LOGFILE statement as described in this section.

Clearing Inactive, Archived Redo

You can clear an inactive redo log group when the database is open or closed. The procedure depends on whether the damaged group has been archived.

7

http://youngcow.net/doc/oracle10g/backup.102/b14191/recoscen008.htm#i1006564%23i1006564

http://youngcow.net/doc/oracle10g/backup.102/b14191/recoscen008.htm#CACEDJAE%23CACEDJAE


To clear an inactive, online redo log group that has been archived, use the following procedure:

If the database is shut down, then start a new instance and mount the database:

STARTUP MOUNT

Initialize the damaged log group. For example, to clear redo log group 1 issue the following statement:

ALTER DATABASE CLEAR LOGFILE GROUP 1;

Clearing Inactive, Not-Yet-Archived Redo

To clear an inactive, online redo log group that has not been archived, use the following procedure:

If the database is shut down, then start a new instance and mount the database:

STARTUP MOUNT

Clear the log using the UNARCHIVED keyword. For example, to clear log group 1, issue:

ALTER DATABASE CLEAR LOGFILE UNARCHIVED GROUP 1;

If there is an offline datafile that requires the cleared log to bring it online, then the keywords UNRECOVERABLE DATAFILE are required. The datafile and its entire tablespace have to be dropped because the redo necessary to bring it online is being cleared, and there is no copy of it. For example, enter:

ALTER DATABASE CLEAR LOGFILE UNARCHIVED GROUP 1 UNRECOVERABLE DATAFILE;

Immediately back up the whole database with an operating system utility, so that you have a backup you can use for complete recovery without relying on the cleared log group

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@RmancatBackup database plus archivelog;Backup archivelog all;

Back up the database's control file with the ALTER DATABASE statement. For example, enter

ALTER DATABASE BACKUP CONTROLFILE TO 'G:\Oracle_Backups\Backups\cf_backup.f';

8

Failure of CLEAR LOGFILE Operation

The ALTER DATABASE CLEAR LOGFILE statement can fail with an I/O error due to media failure when it is not possible to:

Relocate the redo log file onto alternative media by re-creating it under the currently configured redo log filename

Reuse the currently configured log filename to re-create the redo log file because the name itself is invalid or unusable (for example, due to media failure)

In these cases, the ALTER DATABASE CLEAR LOGFILE statement (before receiving the I/O error) would have successfully informed the control file that the log was being cleared and did not require archiving. The I/O error occurred at the step in which the CLEAR LOGFILE statement attempts to create the new redo log file and write zeros to it. This fact is reflected in V$LOG.CLEARING_CURRENT.

# -------------------------------------------------------------------------------- Scenario 4 - Loss of CURRENT Online Redo Log Group # --------------------------------------------------------------------------------

If the database is still running and the lost active redo log is not the current log, then issue the ALTER SYSTEM CHECKPOINT statement.

If successful, then the active redo log becomes inactive, and you can follow the procedure in "Losing an Inactive Online Redo Log Group".

If unsuccessful, or if your database has halted, then perform one of procedures in this section, depending on the archiving mode.

The current log is the one LGWR is currently writing to. If a LGWR I/O fails, then LGWR terminates and the instance crashes. In this case, you must restore a backup, perform incomplete recovery, and open the database with the RESETLOGS option.

To recover from loss of an active online log group in NOARCHIVELOG mode:

If the media failure is temporary, then correct the problem so that the database can reuse the group when required.

Restore the database from a consistent, whole database backup (datafiles and control files)

Mount the database:

STARTUP MOUNT;

9


Because online redo logs are not backed up, you cannot restore them with the datafiles and control files. In order to allow the database to reset the online redo logs, you must first mimic incomplete recovery:

RECOVER DATABASE UNTIL CANCEL;

Open the database using the RESETLOGS option:

ALTER DATABASE OPEN RESETLOGS;



To recover from loss of an active online redo log group in ARCHIVELOG mode:

If the media failure is temporary, then correct the problem so that the database can reuse the group when required. If the media failure is not temporary, then use the following procedure.

Begin incomplete media recovery, recovering up through the log before the damaged log

Ensure that the current name of the lost redo log can be used for a newly created file. If not, then rename the members of the damaged online redo log group to a new location

ALTER DATABASE RENAME FILE "?/oradata/trgt/redo01.log" TO "/tmp/redo01.log";



#-------------------------Scenario 5 - Recovering After the Loss of All Members of an Online Redo Log Group Using RMAN with Catalog#-------------------------

Step 1

Full Backup


10

Step 2

select member from v$Logfile;

We can simulate this scenario by deleting all the online redo log files at the OS level.

ORA-00313

Errors in file e:\oracle\admin\backups\bdump\backups_lgwr_3216.trc:

ORA-00313: open failed for members of log group 1 of thread 1

ORA-00312: online log 1 thread 1: 'E:\ORACLE\ORADATA\BACKUPS\REDO01.LOG'

ORA-27041: unable to open file

OSD-04002: unable to open file

O/S-Error: (OS 2) The system cannot find the file specified.

ORA-00312: online log 1 thread 1: 'E:\ORACLE\ORADATA\BACKUPS\REDO01_2.LOG'

ORA-27041: unable to open file

OSD-04002: unable to open file

O/S-Error: (OS 2) The system cannot find the file specified.

Step 3

Using RMAN we can recover from this error by restoring the database from the backup and recovering to the last available archived redo logfile.

From the alert log we can obtain the last archived file in our case it is sequence 0 as the error shows that it fails to archive the log file sequence 21.

STARTUP MOUNT;select * from v$Log;

11

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@RmancatRUN { SHUTDOWN IMMEDIATE;STARTUP MOUNT; ALLOCATE CHANNEL ch1 TYPE Disk; RESTORE DATABASE; RECOVER DATABASE; Sql ‘ALTER DATABASE OPEN’;}

OR

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@RmancatRUN {SHUTDOWN IMMEDIATE;STARTUP MOUNT; set until sequence XX thread 1;ALLOCATE CHANNEL ch1 TYPE Disk; RESTORE DATABASE; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS; }

#-------------------------Scenario 6 - Recovering After the Loss of All Members of an Online Redo Log Group Using RMAN with Catalog with CommVault#-------------------------

Step 1Full Backup

12

Step 2

Shutdown immediateDeleting all redo log filesStartup mount

13

Need to enter details of Catalog Connect

Script Preview

Run {allocate channel ch1 type 'sbt_tape'PARMS="BLKSIZE=0"; restore database ; recover database ;}

No log files…..

Outcome of this, it can’t find any redo log files…

This will not restore redo log file, you need to create them.

ALTER DATABASE OPEN;

#-------------------------Scenario 7 - Recovering After a lost of single control file#-------------------------

Step 1

Shut down the database. Delete one control file

Step 2

Startup open;Check log file;

RC1: Thread not mountedThu Oct 08 16:53:20 2009ORA-00202: controlfile: 'e:\oracle\oradata\BACKUPS\control02.ctl'ORA-27041: unable to open fileOSD-04002: unable to open fileO/S-Error: (OS 2) The system cannot find the file specified.

Step 3

Shut down the database.

Copy any one of the existing control files into the location of the missing control file (Of course this will not be an option if every one of the control files has been lost.)

Rename the copy of the control file with the name of the missing control file name.

15

Startup open;

Should open assuming no issues.

#-------------------------Scenario 8 - Recovering After a lost of all control files using RMAN with Catalog#-------------------------

Step 1

Shut down the database. Rename all control files

Step 2

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@RmancatRUN { STARTUP NOMOUNT; ALLOCATE CHANNEL ch1 TYPE Disk; RESTORE CONTROLFILE; (Or RESTORE CONTROLFILE FROM AUTOBACKUP)SQL 'ALTER DATABASE MOUNT'; RECOVER DATABASE; SQL 'ALTER DATABASE OPEN RESETLOGS'; }

2 outcomes:

Successful: (depends on the status of the database, if its clean)(quick)

Prior to performing the next RMAN backup, it will be necessary to reset the database information in the RMAN catalog.

Full Backup whenever you issue an ALTER DATABASE OPEN RESETLOGS you must always reset the database in RMAN?

RMAN-03002: failure of backup command at 09/17/2007 14:52:42RMAN-06004: ORACLE error from recovery catalog database: RMAN-20003: target database incarnation not found in recovery catalog

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@RmancatRESET DATABASE;

Full Backup – new baseline

16


Failure: (maybe can of worms…)

ORA-01547

RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

When prompted for the non-existing logfile type 'CANCEL', then open the database with 'resetlogs'.

If this does not work the datafiles definitely need more archivelog information to become consistent.

RESTORE DATABASE;RECOVER DATABASE UNTIL SEQUENCE xxxx;ALTER DATABASE OPEN RESETLOGS;

LIST ARCHIVELOG ALL;LIST BACKUP;

But even the RESETLOGS won’t work yet – we need to do some recovery first.

Well let’s finish up. First off, Oracle actually needs to look at the ONLINE logs. By the way, there’s one thing to be careful of here… check it out:

col member format a40select l.status, memberfrom v$logfile inner join v$log l using (group#);

(LOOK FOR CURRENT LOG)

recover database using backup controlfile until cancel;

FILENAME/u04/oracle/oradata/jt10g/redo02.log

May not work (try using another log file - view is showing you the BACKUP controlfile – see view above)

recover database using backup controlfile until cancel;/u04/oracle/oradata/jt10g/redo03.log

Looks like we still need to apply the last log.

recover database using backup controlfile until cancel;

17

point to filename /u04/oracle/product/10.2.0/db_1/dbs/arch1_6_621627183.dbf

Media recovery complete

alter database open resetlogs;

#-------------------------Scenario 9 - Recovering After a lost of all control files using control file backup to trace file#-------------------------

Step 1

Assume you have issued command and saved the file

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;------------------------- TRACEFILE------------------------- Below are two sets of SQL statements, each of which creates a newcontrol file and uses it to open the database.

A) The first set opens the database with the NORESETLOGS option and should be used only if the current versions of all online logs are available.

B) The second set opens the database with the RESETLOGS option and should be used if online logs are unavailable.

Step 2

Copy the trace file script to /backup directory to rebuild the control file. For the purposes of this example, the file will be renamed as BACKUPS_rebuild_controlfile.sql.

18

BACKUPS_rebuild_controlfile.sql.-------------------------------------------------------------------------------------------------------STARTUP MOUNTCREATE CONTROLFILE REUSE DATABASE "BACKUPS" NORESETLOGS ARCHIVELOG-- SET STANDBY TO MAXIMIZE PERFORMANCE MAXLOGFILES 5 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 1 MAXLOGHISTORY 226LOGFILE GROUP 1 'E:\ORACLE\ORADATA\BACKUPS\REDO01.LOG' SIZE 100M, GROUP 2 'E:\ORACLE\ORADATA\BACKUPS\REDO02.LOG' SIZE 100M, GROUP 3 'E:\ORACLE\ORADATA\BACKUPS\REDO03.LOG' SIZE 100M-- STANDBY LOGFILEDATAFILE 'E:\ORACLE\ORADATA\BACKUPS\SYSTEM01.DBF', 'E:\ORACLE\ORADATA\BACKUPS\UNDOTBS01.DBF', 'E:\ORACLE\ORADATA\BACKUPS\INDX01.DBF', 'E:\ORACLE\ORADATA\BACKUPS\TOOLS01.DBF', 'E:\ORACLE\ORADATA\BACKUPS\USERS01.DBF'CHARACTER SET WE8ISO8859P1;-------------------------------------------------------------------------------------------------------

Step 3

set ORACLE_SID=BACKUPSsqlplus /nolog CONN SYS/Backups AS SYSDBA Select * from v$instance;SHUTDOWN IMMEDIATE; Rename ALL control files E.G. control01.xxx

@ E:\ORACLE\ORADATA\BACKUPS\BACKUPS_rebuild_controlfile.sql

SHUTDOWN IMMEDIATE; STARTUP OPEN;

#-------------------------Scenario 10 - Recovering After a lost of all control files using RMAN with Catalog with CommVault#-------------------------

set ORACLE_SID=BACKUPSsqlplus /nolog

19

CONN SYS/Backups AS SYSDBA Shutdown immediateDeleting all control filesStartup nomount;

20

run {allocate channel ch1 type 'sbt_tape'PARMS="BLKSIZE=0"; restore controlfile to '<GalaxyBaseTempPath>/ctrlFile<JobId>'; replicate controlfile from '<GalaxyBaseTempPath>/ctrlFile<JobId>';sql 'alter database mount'; release channel ch1;}

Copies control file first to temp location on the local host

C:\Program Files\CommVault\Galaxy\Base\Temp

Then copies it over…


Successful:

Failure:

ORA-01152ORA-01110

It could be your control files are out of date with rest of the database !

Recovery

Make sure it is in MOUNT;

22

Script Preview

run {allocate channel ch1 type 'sbt_tape'PARMS="BLKSIZE=0"; recover database ;}

Full Backup

You can tick both Restore Control File & Recover same time….

#-------------------------Scenario 11 - Recovering After a lost of all control files and spfile using NO Catalog#-------------------------

set ORACLE_SID=BACKUPSsqlplus /nologCONN SYS/Backups AS SYSDBA

Need to knowselect dbid from v$database;

DBID----------2073096330

Shutdown immediate;Deleting all control files

***MAKE SURE NO SPACES***

rman Target SYS/BACKUPS@BACKUPS NOcatalogSET DBID=2073096330;Startup nomount FORCE;SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'G:\Oradata\Recovery_Area\backups\Rman_Backups\Ora_cf%F';restore spfile to 'E:\oracle\ora92\database\INITBackups.ora' from autobackup;restore controlfile from 'g:\Oradata\Recovery_Area\backups\Rman_Backups\ ORA_CFC-2073096330-20091015-01';alter database mount;recover database;alter database open resetlogs;backup database;

Failure:

RMAN-06172 (if u get this check there are no spaces in path !!!)

23

If so, check setting

SHOW ALL;

CONFIGURE CONTROLFILE AUTOBACKUP ON;CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'G:\Oradata\Recovery_Area\backups\Rman_Backups\Ora_cf%F';Full Backup


Check location g:\Oradata\Recovery_Area\backups\Rman_Backups\

Look for the last file

#-------------------------Scenario 12 - Recovering After a lost of all control files and spfile using NO Catalog with CommVault#-------------------------

Tried 2 ways : first way incorrect, second way correct

First way:

Full Backup with CommVault

set ORACLE_SID=BACKUPSsqlplus /nologCONN SYS/Backups AS SYSDBA Shutdown immediate;Deleting all control filesStartup nomount FORCE;

24

Restore control files first…

26

Script Preview

SET DBID ;run {allocate channel ch1 type 'sbt_tape'PARMS="BLKSIZE=0"; restore control ;}

RMAN Log

Rman Script:[SET DBID 2073096330;run {allocate channel ch1 type 'sbt_tape'PARMS="BLKSIZE=262144,ENV=(CV_mmsApiVsn=2,CV_channelPar=ch1,ThreadCommandLine= RESTORE -jm 10 -a 2:0 -cl 10 -ins 50 -at 0 -j 104254 -bal 0 -bap 0 -rap 0 -rcp 0 -mav 0 -ms 1 -p 1 -cn glasbs2 -vm Instance001 -vm glasbs2.vws.vh20.net)"TRACE 0; restore controlfile ;sql 'alter database mount';}

27

exit;]Rman Log:[Recovery Manager: Release 9.2.0.1.0 - ProductionCopyright (c) 1995, 2002, Oracle Corporation. All rights reserved.RMAN> RMAN> connected to target database: BACKUPS (not mounted)using target database controlfile instead of recovery catalog

RMAN> executing command: SET DBID

RMAN> 2> 3> 4> 5> 6> 7> allocated channel: ch1channel ch1: sid=10 devtype=SBT_TAPEchannel ch1: CommVault Systems for Oracle: Version 7.0.0(BUILD76)

Starting restore at 16-OCT-09

released channel: ch1RMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03002: failure of restore command at 10/16/2009 09:39:44RMAN-06563: controlfile or SPFILE must be restored using FROM AUTOBACKUPRMAN> Recovery Manager complete.]RMAN> Recovery Manager complete.]***NOT SURE WHY ‘From Autobackup’ is disabled***

Could it be when you setup RMAN with no catalog ???

If I create within CommVault to back up a database, but do not specify catalog, I get this:

28

This is a correct message for Oracle 8. Since Oracle 9 we can use the controlfile autobackup feature.

Second Way:


set ORACLE_SID=BACKUPSsqlplus /nologCONN SYS/Backups AS SYSDBA Shutdown immediate;Deleting all control filesStartup nomount FORCE;

Lets restore control files first

29

Script Preview

SET DBID 2073096330;run {allocate channel ch1 type 'sbt_tape'PARMS="BLKSIZE=262144"; restore controlfile to '<GalaxyBaseTempPath>/ctrlFile<JobId>'from autobackup ; replicate controlfile from '<GalaxyBaseTempPath>/ctrlFile<JobId>';sql 'alter database mount'; release channel ch1;}

Takes longer….

Successful:

It’s mounted:

Next recover

31

Script Preview

run {allocate channel ch1 type 'sbt_tape'PARMS="BLKSIZE=262144"; recover database ;}

Successful:

It’s open:

33

#-------------------------Scenario 13 - One or more of the non-SYSTEM database datafiles have been destroyed due to media failure using RMAN with Catalog#-------------------------

Step 1

Full Backup


SELECT FILE#,NAME FROM V$DATAFILE;

USERS tablespace is unavailable. The USERS tablespace will need to be restored from a backup to a different mount point.

File#5

Step 2

set ORACLE_SID=BACKUPSsqlplus /nologCONN SYS/Backups AS SYSDBA ALTER TABLESPACE USERS OFFLINE IMMEDIATE; SHUTDOWN IMMEDIATE EXIT#Delete file

Step 3

Restore and recover the affected tablespace datafile while renaming it to use a different location to avoid the failed media.

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@RmancatRUN { STARTUP MOUNT; ALLOCATE CHANNEL ch3 TYPE Disk; SET NEWNAME FOR DATAFILE 5 TO ‘E:\ORACLE\ORADATA\BACKUPS\NEWMEDIA\USERS01.DBF';

34

RESTORE TABLESPACE USERS; SWITCH DATAFILE ALL; #UPDATE THE CONTROL FILE WITH NEW NAME/LOCATION RECOVER TABLESPACE USERS; ALTER DATABASE OPEN; SQL 'ALTER TABLESPACE USERS ONLINE'; RELEASE CHANNEL ch3; } QUIT

#-------------------------Scenario 14 - One or more of the non-SYSTEM database datafiles have been destroyed due to media failure using RMAN with Catalog with CommVault#-------------------------


set ORACLE_SID=BACKUPSsqlplus /nologCONN SYS/Backups AS SYSDBA ALTER TABLESPACE USERS OFFLINE IMMEDIATE; SHUTDOWN IMMEDIATE; #Delete fileSTARTUP MOUNT; EXIT

35

Options

Restore Data & Recover - selectedOpen DB – not selected (options tab)

Script generated

Rman Script:[run {allocate channel ch1 type 'sbt_tape'PARMS="BLKSIZE=262144,ENV=(CV_mmsApiVsn=2,CV_channelPar=ch1,ThreadCommandLine= RESTORE -jm 142 -a 2:0 -cl 10 -ins 50 -at 0 -j 104265 -bal 0 -bap 0 -rap 0 -rcp 0 -mav 0 -ms 1 -p 2 -cn glasbs2 -vm Instance001 -vm glasbs2.vws.vh20.net)"TRACE 0;restore (tablespace 'USERS' ) ;recover tablespace 'USERS' ;}exit;]Rman Log:[Recovery Manager: Release 9.2.0.1.0 - ProductionCopyright (c) 1995, 2002, Oracle Corporation. All rights reserved.RMAN>connected to recovery catalog database

36

RMAN>connected to target database: BACKUPS (DBID=2073096330)RMAN> 2> 3> 4> 5> 6> 7> 8>allocated channel: ch1channel ch1: sid=9 devtype=SBT_TAPEchannel ch1: CommVault Systems for Oracle: Version 7.0.0(BUILD76)Starting restore at 16-OCT-09channel ch1: starting datafile backupset restorechannel ch1: specifying datafile(s) to restore from backup setrestoring datafile 00005 to E:\ORACLE\ORADATA\BACKUPS\NEWMEDIA\USERS01.DBFchannel ch1: restored backup piece ( Appended)piece handle=1jkrukvc_1_1 tag=TAG20091016T125156 params=NULLchannel ch1: restore completeFinished restore at 16-OCT-09Starting recover at 16-OCT-09starting media recoverymedia recovery completeFinished recover at 16-OCT-09released channel: ch1RMAN>Recovery Manager complete.]Still MOUNTED

Restore

Recover – selectedOpen DB – reset logs – (no I think…..) (options tab)

rman Script:[run {allocate channel ch1 type 'sbt_tape'PARMS="BLKSIZE=262144,ENV=(CV_mmsApiVsn=2,CV_channelPar=ch1,ThreadCommandLine= RESTORE -jm 142 -a 2:0 -cl 10 -ins 50 -at 0 -j 104266 -bal 0 -bap 0 -rap 0 -rcp 0 -mav 0 -ms 1 -p 2 -cn glasbs2 -vm Instance001 -vm glasbs2.vws.vh20.net)"TRACE 0;recover database ;sql "alter database open";}exit;]Rman Log:[Recovery Manager: Release 9.2.0.1.0 - ProductionCopyright (c) 1995, 2002, Oracle Corporation. All rights reserved.RMAN>connected to recovery catalog databaseRMAN>connected to target database: BACKUPS (DBID=2073096330)

37

RMAN> 2> 3> 4> 5> 6> 7>allocated channel: ch1channel ch1: sid=11 devtype=SBT_TAPEchannel ch1: CommVault Systems for Oracle: Version 7.0.0(BUILD76)Starting recover at 16-OCT-09starting media recoverymedia recovery completeFinished recover at 16-OCT-09sql statement: alter database openreleased channel: ch1RMAN>Recovery Manager complete.]

#-------------------------Scenario 15 - Loss of a SYSTEM tablespace datafile using RMAN with Catalog#-------------------------

Step 1

Full Backup



Step 2

set ORACLE_SID=BACKUPSsqlplus /nologCONN SYS/Backups AS SYSDBA SHUTDOWN IMMEDIATE EXIT#Delete file

38

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@RmancatRUN { STARTUP MOUNT; ALLOCATE CHANNEL ch3 TYPE Disk; RESTORE datafile 1; RECOVER datafile 1; ALTER DATABASE OPEN; RELEASE CHANNEL ch3; } QUIT

Full Backup

#-------------------------Scenario 16 - Loss of a SYSTEM tablespace datafile without using RMAN #-------------------------

Step 1

Full Backup


set ORACLE_SID=BACKUPSsqlplus /nologCONN SYS/Backups AS SYSDBA SHUTDOWN IMMEDIATE #Delete fileSTARTUP MOUNT;

Step 2

Find the file numbers of the files which need to be recovered by querying V$RECOVER_FILE and V$DATAFILE.

39

SELECT FILE#,ONLINE_STATUS,ERROR FROM V$RECOVER_FILE;


SELECT FILE#,NAME FROM V$DATAFILE WHERE FILE#=1;

Step 3

Take the lost datafile offline so that the database can be opened:

ALTER DATABASE DATAFILE 'E:\ORACLE\ORADATA\BACKUPS\SYSTEM01.DBF' OFFLINE;

Step 4

Restore the lost datafile from the most recent backup. Say from Cold backup.

COPY G:\Oracle_Backups\Backups\system01.dbf E:\ORACLE\ORADATA\BACKUPS\system01.dbf

Step 5

Recover the datafile or the entire tablespace, depending upon which is most appropriate.

If all of the files which make up a tablespace were affected by the media failure, then issue the command:

40

RECOVER TABLESPACE SYSTEM; Press return if prompted for the logfile to use during recovery. Continue pressing the return key when prompted until the recovery process displays the message "Media recovery complete."

OR

Otherwise if only an individual datafile of a tablespace was affected, the single datafile may be recovered independently. Recovering only the affected datafile can reduce the recovery time.

RECOVER DATAFILE ' E:\ORACLE\ORADATA\BACKUPS\system01.dbf ';

Successful:

Step 6

Bring the datafile, then the tablespace online after the file has been recovered: ALTER DATABASE DATAFILE 'E:\ORACLE\ORADATA\BACKUPS\system01.dbf' ONLINE;

Step 7

Open the database. ALTER DATABASE OPEN;

Step 8

Bring the SYSTEM tablespace online. ALTER TABLESPACE SYSTEM ONLINE;

Verify the status of all datafiles to make sure that there aren't additional problems: SELECT FILE#,ONLINE_STATUS,ERROR FROM V$RECOVER_FILE;

If the result is "no rows selected" then that means that there are no additional datafiles requiring recovery.

Verify that there aren't any additional database files which are offline. SELECT FILE#, STATUS FROM V$DATAFILE;

Failure:

ORA-01190ORA-01110

Controlfiles are out of sync with datafiles.

41

When cold backup was done, trace of controlfile was done.

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

Delete control files

BACKUPS_rebuild_controlfile_v2.sql.-------------------------------------------------------------------------------------------------------STARTUP NOMOUNTCREATE CONTROLFILE REUSE DATABASE "BACKUPS" RESETLOGS ARCHIVELOG-- SET STANDBY TO MAXIMIZE PERFORMANCE MAXLOGFILES 5 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 1 MAXLOGHISTORY 226LOGFILE GROUP 1 'E:\ORACLE\ORADATA\BACKUPS\REDO01.LOG' SIZE 100M, GROUP 2 'E:\ORACLE\ORADATA\BACKUPS\REDO02.LOG' SIZE 100M, GROUP 3 'E:\ORACLE\ORADATA\BACKUPS\REDO03.LOG' SIZE 100M-- STANDBY LOGFILEDATAFILE 'E:\ORACLE\ORADATA\BACKUPS\SYSTEM01.DBF', 'E:\ORACLE\ORADATA\BACKUPS\UNDOTBS01.DBF', 'E:\ORACLE\ORADATA\BACKUPS\INDX01.DBF', 'E:\ORACLE\ORADATA\BACKUPS\TOOLS01.DBF', 'E:\ORACLE\ORADATA\BACKUPS\NEWMEDIA\USERS01.DBF'CHARACTER SET WE8ISO8859P1;-------------------------------------------------------------------------------------------------------

ORA-01189ORA-01110

What we have is system tablespace is out of syc with the rest of tablespaces in the control files. Point being you can’t mix or match !

You need a backup of tablespace that is quite recent or cold backup of the entire database.

Restore from previous full backup.

42

#-------------------------Scenario 17 - Missing Data File - non-SYSTEM tablespace file#-------------------------

Situation: A datafile has been deleted via OS commands while the database was down. The datafile and its associated tablespace were intended to be deleted therefore the goal is to simply get the database started up quickly.

Step 1

Full Backup


Step 2


ORA-01157ORA-01110

Step 3

If intentional:

ALTER DATABASE DATAFILE 'E:\ORACLE\ORADATA\BACKUPS\UNDOTBS01.DBF' OFFLINE DROP;

If not, offline:

ALTER DATABASE DATAFILE 'E:\ORACLE\ORADATA\BACKUPS\UNDOTBS01.DBF' OFFLINE;


Step 4

However, it is also necessary to remove the tablespace associated with the datafile from the data dictionary to prevent errors from occurring during attempted access to objects within the affected tablespace.

43

DROP TABLESPACE USERS INCLUDING CONTENTS CASCADE CONSTRAINTS;

#-------------------------Scenario 18 - Loss of Non-Essential Datafile When Database is Down#-------------------------

Situation: This scenario assumes that the datafile for the INDX tablespace has been deleted.

Step 1

Full Backup


Step 2


Step 3

Does DBA have scripts to rebuild indexes manually ?

Yes:Take datafile offline and open databaseRebuild datafile and run scripts

No:INDX datafile should be restored and recovered as with any other datafileGo to step 4

Step 4

Startup open;

ORA-01157ORA-01110

44

Step 5

set ORACLE_SID=BACKUPSsqlplus /nologCONN SYS/Backups AS SYSDBA SHUTDOWN IMMEDIATE;STARTUP MOUNT; Step 6




In this example, file #3 has been listed in V$RECOVER_FILE as needing recovery.

To find out the path/name of file #3, query V$DATAFILE: SELECT FILE#,NAME FROM V$DATAFILE WHERE FILE#=3; The result is: E:\ORACLE\ORADATA\BACKUPS\INDX01.DBF

45

Step 7

Take the lost datafile offline so that the database can be opened: ALTER DATABASE DATAFILE 'E:\ORACLE\ORADATA\BACKUPS\INDX01.DBF' OFFLINE; ALTER DATABASE OPEN;

The database is now available for production use. However any queries which rely on indexes will be expected to take longer until the indexes are rebuilt.

Step 8

Drop the INDX tablespace.

Note: Dropping of the INDX tablespace should not be done if there are any objects located within the INDX tablespace which won't be re-built by using the DBA's index rebuild scripts.

DROP TABLESPACE INDX INCLUDING CONTENTS CASCADE CONSTRAINTS;

Step 9

Re-create the INDX tablespace using the same datafile filename using the reuse option. CREATE TABLESPACE INDX DATAFILE 'E:\ORACLE\ORADATA\BACKUPS\INDX01.DBF' SIZE 50M REUSE AUTOEXTEND OFF EXTENT MANAGEMENT LOCAL AUTOALLOCATE LOGGING ONLINE;

Step 10

Re-build all of the indexes with the DBA's index rebuild scripts.

46

#-------------------------Scenario 19 - Recover a Lost Datafile with No Backup with RMAN with Catalog#-------------------------

Situation: The USERS tablespace contains 2 datafiles. The database has been backed up, but the 2nd datafile was added after the most recent database backup. Therefore there is no backup of the 2nd datafile.

Step 1

Full Backup


Step 2


Select tablespace_name, extent_management, contents,segment_space_management from dba_tablespaces;

Select *from dba_data_files;

47

Add datafile

ALTER TABLESPACE USERS ADD DATAFILE‘E:\ORACLE\ORADATA\BACKUPS\NEWMEDIA\USERS02.DBF' SIZE 205M;

Step 3


Step 4

Startup open;

ORA-01157ORA-01110

Step 5

Determine the file# and original path/filename for each file in the database which will need to be restored and recovered.


For this example, datafile 6 has been lost, which is used for the USERS tablespace. The original file path is: E:\ORACLE\ORADATA\BACKUPS\NEWMEDIA\USERS02.DBF

48

Step 6

set ORACLE_SID=BACKUPSsqlplus /nologCONN SYS/Backups AS SYSDBA SHUTDOWN IMMEDIATE STARTUP MOUNT; ALTER DATABASE DATAFILE 'E:\ORACLE\ORADATA\BACKUPS\NEWMEDIA\USERS02.DBF' OFFLINE; ALTER DATABASE CREATE DATAFILE 'E:\ORACLE\ORADATA\BACKUPS\NEWMEDIA\USERS02.DBF'; ALTER DATABASE DATAFILE 'E:\ORACLE\ORADATA\BACKUPS\NEWMEDIA\USERS02.DBF' ONLINE;

Step 7

The data contained within the missing 2nd datafile will then be reconstructed from the archivelog files data during the RMAN recovery process.

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@RmancatRUN { ALLOCATE CHANNEL ch3 TYPE Disk; RECOVER TABLESPACE USERS; ALTER DATABASE OPEN; RELEASE CHANNEL ch3; } QUIT

The database is now available for production use.

Full Backup

49

#-------------------------Scenario 20 - Recover a Lost Datafile with No Backup without RMAN#-------------------------

As Scenario 19 – steps 3,4,5

Next, Step 6 (modified)

set ORACLE_SID=BACKUPSsqlplus /nologCONN SYS/Backups AS SYSDBA SHUTDOWN IMMEDIATE STARTUP MOUNT; ALTER DATABASE DATAFILE 'E:\ORACLE\ORADATA\BACKUPS\NEWMEDIA\USERS02.DBF' OFFLINE; ALTER DATABASE CREATE DATAFILE 'E:\ORACLE\ORADATA\BACKUPS\NEWMEDIA\USERS02.DBF'; ALTER DATABASE DATAFILE 'E:\ORACLE\ORADATA\BACKUPS\NEWMEDIA\USERS02.DBF' ONLINE; RECOVER TABLESPACE USERS; ALTER DATABASE OPEN;

Successful:

Failure:

ORA-00279: change 671807 generated at 10/23/2009 15:45:12 needed for thread 1ORA-00289: suggestion :G:\ORADATA\RECOVERY_AREA\BACKUPS\ARCHIVELOGS\ARC00021_2073096330.001ORA-00280: change 671807 for thread 1 is in sequence #21

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}ALTER DATABASE OPEN;ORA-00308: cannot open archived log 'ALTER'ORA-27041: unable to open fileOSD-04002: unable to open fileO/S-Error: (OS 2) The system cannot find the file specified.

Enter

AUTOALTER DATABASE OPEN;

Then successful

50

#-------------------------Scenario 21 - Recover a Lost Datafile with No Backup with RMAN with Catalog with CommVault#-------------------------

Situation: The USERS tablespace contains 3 datafiles. The database has been backed up, but the 3rd datafile was added after the most recent database backup. Therefore there is no backup of the 3rd datafile.

Step 1

Full Backup using CommVault

Step 2


Select tablespace_name, extent_management, contents,segment_space_management from dba_tablespaces;

Select *from dba_data_files;

51

Add datafile

ALTER TABLESPACE USERS ADD DATAFILE‘E:\ORACLE\ORADATA\BACKUPS\NEWMEDIA\USERS03.DBF' SIZE 205M;

Step 3


Step 4

Startup open;

Maybe get errors:

ORA-01157ORA-01110

Step 5



Step 6

set ORACLE_SID=BACKUPSsqlplus /nologCONN SYS/Backups AS SYSDBA SHUTDOWN IMMEDIATE STARTUP MOUNT;

Step 7

Recover users tablespace

52

Script Preview

run {allocate channel ch1 type 'sbt_tape'PARMS="BLKSIZE=0"; recover tablespace 'USERS';}

Generates error, so try again

RMAN-06094: datafile 7 must be restored

run {allocate channel ch1 type 'sbt_tape'PARMS="BLKSIZE=0"; restore tablespace 'USERS'; recover tablespace 'USERS';}

55

Generates Error

RMAN-06023

56

#-------------------------Scenario 22 - Recover from User Errors - dropped table or deleted data with RMAN with Catalog#-------------------------

Step 1

Full Backup


Step 2

Create table t(i number)/

select count(*) from t;Zilth

beginfor i in 1..150loopinsert into t values (i);end loop;end;

commit/

select count(*) from t/150

Select to_char(sysdate,'DD-MM-YYYY HH24:MI:SS')from dual/ 30-10-2009 14:56:58

Step 3

delete from t where i between 1 and 75/commit/75

57


Step 4 (restore of database + archive logs on top)

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@Rmancatrun{shutdown immediate;startup mount;set until time "to_date('30-10-2009 14:56:58','DD-MM-YYYY HH24:MI:SS')";recover database;}

ErrorsRMAN-03002RMAN-06555

Yours datafiles are newer than 30-10-2009 14:56:58 which contains the committed data ,for incomplete recovery how will you apply redo??

To perform incomplete media recovery, you must restore all datafiles from backups created prior to the time to which you want to recover.

Try again

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@Rmancatrun{shutdown immediate;startup mount;set until time "to_date('30-10-2009 14:56:58','DD-MM-YYYY HH24:MI:SS')";restore database;recover database;alter database open resetlogs;}


58

#-------------------------Scenario 23 - Recover from User Errors - dropped table or deleted data with RMAN with NO Catalog#-------------------------

Step 1

Full Backup


Step 2

Create table tt(i number)/

select count(*) from tt;Zilth

beginfor i in 1..150loopinsert into tt values (i);end loop;end;

commit/

select count(*) from tt/150

Select to_char(sysdate,'DD-MM-YYYY HH24:MI:SS')from dual/02-11-2009 10:59:03

Step 3

delete from t where i between 1 and 75/commit/

59

75Step 4 (restore of database + archive logs on top)

rman Target SYS/BACKUPS@BACKUPS nocatalog run{shutdown immediate;startup mount;set until time "to_date('02-11-2009 10:59:03','DD-MM-YYYY HH24:MI:SS')";recover database;}

ErrorsRMAN-03002RMAN-06555

Yours datafiles are newer than 02-11-2009 10:59:03 which contains the committed data ,for incomplete recovery how will you apply redo??

To perform incomplete media recovery, you must restore all datafiles from backups created prior to the time to which you want to recover.

Try again

rman Target SYS/BACKUPS@BACKUPS nocatalog run{shutdown immediate;startup mount;set until time "to_date('02-11-2009 10:59:03','DD-MM-YYYY HH24:MI:SS')";restore database;recover database;alter database open resetlogs;}

select count(*) from tt/150

#-------------------------Scenario 24 - Recover from User Errors - dropped table or deleted data - manual data entry #-------------------------

If the amount of lost data is minimal, and the table has not been dropped or truncated it may be better to manually re-enter the data which has been lost. This recovery method may also be considered in situations in which the number of transactions which would be lost during a database point in time recovery is high.

60

#-------------------------Scenario 25 - Recover from User Errors - dropped table or deleted data –Flashback Drop #-------------------------

We should remember the thing is you must use automatic undo management to use the Flashback Table feature. It is based on undo information stored in an undo tablespace.

Details

A recycle bin contains all the dropped database objects until,

- You permanently drop them with the PURGE command.- Recover the dropped objects with the UNDROP command.- There is no room in the tablespace for new rows or updates to existing rows.- The tablespace needs to be extended.

You can view the dropped objects in the recycle bin from two dictionary views:

- user_recyclebin - lists all dropped user objects - dba_recyclebin - lists all dropped system-wide objects

The recycle Bin is a logical structure within each tablespace that holds dropped tables and objects related to the tables, such as indexes. The space associated with the dropped table is not immediately available but shows up in the dictionary view dba_free_space.

When space pressure occurs in the tablespace, objects in the recycle bin are deleted in a FIFO fashion.

The dropped objects still belongs to the owner and still counts against the quota for the owner in the tablespace.

flashback table orders to before drop;

If after drop table orders we already created, the dropped table can be recovered by new name.

flashback table orders to before drop rename to orders_droped;

Recycle Bin Considerations and Limitations: Few limitations are:

1. Only non-system locally managed tablespaces can have a recycle bin. However, dependent objects in a dictionary-managed tablespace are protected if the dropped object is in a locally managed tablespace.

A table’s dependent objects are saved in the recycle bin when the table is dropped, except for bitmap join indexes, referential integrity constraints

61

Important Things:1) objects will go to recyclebin or it will not go is based on recyclebin parameter settings.If I set alter system set recyclebin=off then object will not go in recycle bin.

2)Dropped SYS and SYSTEM schema objects are don't go in recyclebin.

3)The un-drop feature brings the table back to its original name, but not the associated objects like indexes and triggers, which are left with the recycled names.Views and procedures defined on the table are not recompiled and remain in the invalid state. These old names must be retrieved manually and then applied to the flashed-back table.

Step 1 - Set-up first

To be able to flashback on you have to use enterprise edition ****

Restore Point Prerequisites:

COMPATIBLE initialization parameter must be > 10.2

SELECT * FROM V$VERSION;Oracle Database 10g Enterprise Edition Release 10.1.0.5.0 - Prod

SELECT * FROM V$OPTION;Flashback Table TRUE Flashback Database TRUE

If not enabled, you get ORA-00439

shutdown immediate;startup mount;alter database archivelog;alter system set DB_FLASHBACK_RETENTION_TARGET=4320;alter system set DB_RECOVERY_FILE_DEST_SIZE=536870912;alter system set DB_RECOVERY_FILE_DEST='E:\Recovery_Area\Dev\Flashback';alter database flashback on;alter database open;show parameter DB_FLASHBACK_RETENTION_TARGET;show parameter DB_RECOVERY_FILE_DEST_SIZE;show parameter DB_RECOVERY_FILE_DEST;

62

We've defined a flasback retension of 4320 minutes (or 72 hours), a recovery file size of 512MB and defined the location for the file recovery area

Step 1 (user – non SYS)

Create table

create table test (col_a varchar(4));

select object_name, original_name, typefrom user_recyclebin;

Ziltch

drop table test;

select object_name, original_name, typefrom user_recyclebin;

Step 2

Create table again

create table test (col_b varchar(4));

Drop table test;

Step 3

Restoring table

63

flashback table “BIN$DQ2wRd/iSGyLVbAsOfaqiQ==$0” to before drop;

Step 4 (Dropping a Table Permanently)

drop table test purge;

Step 5 (Purging the User Recycle Bin)

purge recyclebin;

Step 6 (as above, SYS)

purge dba_recyclebin;

#-------------------------Scenario 26 - Recover from User Errors - dropped table or deleted data –Flashback Table and Query #-------------------------

Flashback Table allows you to recover a table or tables to a specific point in time without restoring a backup. When you use the Flashback Table feature to restore a table to a specific point in time, all associated objects, such as indexes, constraints, and triggers will be restored.

Flashback Table operations are not valid for the following object types:

- Tables that are part of a cluster- Materialized views- Advanced Queuing tables- Static data dictionary tables- System tables- Partitions of a table- Remote tables (via database link)

Flashback Table is extremely useful when a user accidentally inserts, deletes, or updates the wrong rows in a table. It provides a way for users to easily and quickly recover a table to a previous point in time.

However, if the following DDL commands are issued, the flashback table command does not work:

- ALTER TABLE ... DROP COLUMN- ALTER TABLE ... DROP PARTITION- CREATE CLUSTER- TRUNCATE TABLE- ALTER TABLE ... MOVE

64

Plus

Flashback table works in-place by rolling back only the changes made to the table or tables and their dependent objects such as indexes.

Flashback table is different from Flashback drop; Flashback Table undoes recent transactions to an existing table, whereas Flashback Drop recovers a dropped table. Flashback Table use data in the undo tablespace, whereasFlashback Drop uses the recycle bin. TO be able to flashback a table, you must enable row movement for the table as the ROWID in the table change.

Steps to Flashback emp and dept tables to 15 mins before position.

alter table emp enable row movement;alter table dept enable row movement;flashback table emp,deptTo timestamp systimestamp – interval ‘15’ minute;

You can return the Flashback Table command with a timestamp or SCN as long as the undo data is still available. Integrity constraints are not violated when one or more tables are Flashback.

Flashback Query allows a user to “go back in time“ and view the contents of a table as it was existed at some point in the recent past. Before users can take advantage of the Flashback Query features, the DBA must perform two tasks:

1. Make sure that there is an undo tablespace in the database that is large enough to retain changes made by all users for a specified period of time.

2. Specify how long the undo information will be retained for user by flashback queries by using the initialization parameter undo_retention. This parameter is specified in seconds.

See example below.

Step 1 - CREATE UNDO TABLESPACE

Create UNDO Tablespace UNDOTBS01 Datafile 'E:\oracle\product\10.1.0\oradata\Dev\UNDOTBS01.DBF' size 50m autoextend on next 10m;

Step 2

SET THREE PARAMETERSUNDO_MANAGEMENTUNDO_TABLESPACEUNDO_RETENTION

show parameters undo;

65

NAME TYPE VALUE------------------------------------ ----------- -------undo_management string MANUALundo_retention integer 900undo_tablespace string

show parameter spfile; create pfile from spfile;shutdown immediate;

Update parameter file

undo_management='AUTO'undo_retention=1200undo_tablespace='UNDOTBS01'

Startup Database based on modified pfileCreate spfile from modified pfileShutdown immediateStartup open

show parameters undo;

NAME TYPE VALUE------------------------------------ ----------- ---------undo_management string AUTOundo_retention integer 1200undo_tablespace string UNDOTBS01

Step 3 Check undo guarantee

Select tablespace_name, retention FROM dba_tablespaces where contents ='UNDO';

TABLESPACE_NAME RETENTION------------------------------ -----------UNDOTBS01 NOGUARANTEE

ALTER TABLESPACE UNDOTBS1 RETENTION GUARANTEE;

Step 4 Size Undo Tablespace

-->Worse case, length of task.

Select max(undoblks) from v$undostat;

MAX(UNDOBLKS)------------- 77 (Test Database just created, no activity)

66

FORMULA SIZE UNDO TABLESPACE = (Result / 10 minutes (length) / 60 Seconds) * 8192 * 1200

(77/10/60) * 8192 * 1200 = 1261568 = 1M

Step 4 – Example 1

Example (assumes the user has correct permissions !!!)

Select * from Scott.emp;

Delete from Scott.emp where empno < 7900;

11 rows deleted.

RollBack;

Select * from Scott.emp;

Select * from Scott.emp as of timestamp(systimestamp - interval '10' minute)minusSelect * from Scott.emp;

67

Insert into Scott.empSelect * from Scott.emp as of timestamp(systimestamp - interval '10' minute)minusSelect * from Scott.emp;

Flashback Row History

Flashback Query was first introduced in Oracle9i to provide a way to view historical data. In Oracle 10g, this feature has been extended. You can now retrieve all versions of the rows that exist or ever existed between the time the query was issued and a point back in time. This type of query is called Flashback Row History.

You can use the VERSIONS BETWEEN clauses to retrieve all historical data related to a row.

Let's take a look at the example below:

Step 5 – Example 2

create table emp (name varchar2(10), salary number(8,2));

insert into emp

68

values ('DANIEL',2000);

commit;

update emp set salary = 3000 where name = 'DANIEL';

commit;

select * from emp;

Step 6

select * from emp versions between scn minvalue and maxvalue;

NAME SALARY---------- ----------DANIEL 3000DANIEL 2000

As you can see, the Flashback Row History feature retrieves all committed occurrences of the row. It provides you with a way to view and repair historical data. In addition, it also provides a new way to audit the rows of a table and retrieve information about the transactions that changed the rows. You can use the transaction ID obtained from Flashback Row History to perform transaction mining using LogMiner or Flashback Transaction History (see next section) to obtain additional information about the transaction.

The VERSION BETWEEN clause does not change the query plan. You can use the clause in a SELECT statement against a view. However, you cannot use the VERSION BETWEEN clause in a view definition.

The row history data is stored in the undo tablespace. The undo_retention initialization parameter specifies how long the database will keep the committed undo information. If a new transaction needs to use undo space and there is not enough free space left, any undo information older than the specified undo retention period will be overwritten. Therefore, you may not be able to see all the row histories. However, you can set the undo tablespace option to RETENTION GUARANTEE to retain all row histories.

To verify the retention value for the tablespace, you can issue the following statement:

select tablespace_name, retention From dba_tablespaces;

69

Step 7

The Flashback Transaction History feature provides a way to view changes made to the database at the transaction level. It allows you to diagnose problems in your database and perform analysis and audit transactions. You can use this feature in conjunction with the Flash Row History feature to roll back the changes made by a transaction. You can also use this feature to audit user and application transactions. The Flashback Transaction History provides a faster way to undo a transaction than LogMiner.

You can retrieve the transaction history from flashback_transaction_query view:

Desc flashback_transaction_query;

select * from emp versions between scn minvalue and maxvalue;

select * from dba_transaction_query

70

where xid = 'xxxxxx';

Step 8 – Example 3 (Flashback To SCN)

FLASHBACK TABLE <schema_name.table_name>TO SCN <scn_number>[<ENABLE | DISABLE> TRIGGERS]

CREATE TABLE tENABLE ROW MOVEMENT ASSELECT owner, table_name, tablespace_nameFROM all_tablesWHERE 1=2;

desc t

SELECT table_name, row_movementFROM user_tables;

SELECT current_scn, SYSTIMESTAMPFROM v$database;-- 5607529 02-MAY-07 12.46.50.906000 PM -07:00

INSERT INTO tSELECT owner, table_name, tablespace_nameFROM all_tablesWHERE owner = 'SYS';

COMMIT;


INSERT INTO tSELECT owner, table_name, tablespace_nameFROM all_tablesWHERE owner = 'WMSYS';

COMMIT;


INSERT INTO tSELECT owner, table_name, tablespace_nameFROM all_tablesWHERE owner = 'CTXSYS';

COMMIT;

71


SELECT owner, COUNT(*)FROM tGROUP BY owner;

conn / as sysdba

set linesize 121col owner format a10

FLASHBACK TABLE Ackers.t TO SCN 5607547;


FLASHBACK TABLE Ackers.t TO SCN 5607540;


Step 9 – Example 4 (Flashback to Timestamp)

FLASHBACK TABLE <schema_name.table_name>TO TIMESTAMP <timestamp>[<ENABLE | DISABLE> TRIGGERS]


desc t



INSERT INTO tSELECT owner, table_name, tablespace_nameFROM all_tables

72

WHERE owner = 'SYS';

COMMIT;



COMMIT;



COMMIT;



conn / as sysdba

set linesize 121col owner format a10

FLASHBACK TABLE Ackers.t TO TIMESTAMPTO_TIMESTAMP('02-MAY-07 12.51.52.050000');


FLASHBACK TABLE Ackers.t TO TIMESTAMPTO_TIMESTAMP('02-MAY-07 12.51.51.500000');

SELECT owner, COUNT(*)

73

FROM tGROUP BY owner;

Step 10 – Example 5 (Flashback to Restore point)

FLASHBACK TABLE <schema_name.table_name>TO RESTORE POINT <restore_point>[<ENABLE | DISABLE> TRIGGERS]


desc t


CREATE RESTORE POINT zero;

INSERT INTO tSELECT owner, table_name, tablespace_nameFROM all_tablesWHERE owner = 'SYS';

COMMIT;

CREATE RESTORE POINT one;


COMMIT;

CREATE RESTORE POINT two;


COMMIT;


74

SELECT scn, time, nameFROM gv$restore_point;

FLASHBACK TABLE t TO RESTORE POINT two;


FLASHBACK TABLE t TO RESTORE POINT one;


FLASHBACK TABLE t TO RESTORE POINT zero;


#-------------------------Scenario 27 - Recover from User Errors - dropped table or deleted data – Using Log Miner#-------------------------

LogMiner is used to view past activity in the database. LogMiner extracts all DDL and DML activity from the redo log files for viewing via the dynamic performance view v$logmnr_contents.

The v$logmnr_contents view also contains the DML statements neededto retrieve the changes made to the database. The LogMiner not actually undo the changes, it only provides the statement that you can use to undo the change.

#-------------------------Scenario 28 - Recover from User Errors - dropped table or deleted data – Flashback Database#-------------------------

Also

Restore Point Prerequisites:

COMPATIBLE initialization parameter must be > 10.2

Flashback Database Prerequisites:

Database must be configured for and running in ARCHIVELOG mode Database must have configured and be using a FLASH_RECOVERY_AREA

75

lashback Database Demo

An alternative strategy to the demo presented here is to use Recovery Manager

RMAN> FLASHBACK DATABASE TO SCN = <system_change_number>;

Dependent Objects

GV_$FLASHBACK_DATABASE_LOG

V_$FLASHBACK_DATABASE_LOG

GV_$FLASHBACK_DATABASE_LOGFILE

V_$FLASHBACK_DATABASE_LOGFILE

GV_$FLASHBACK_DATABASE_STAT

V_$FLASHBACK_DATABASE_STAT

Syntax 1: SCN

FLASHBACK [STANDBY] DATABASE [<database_name>]TO [BEFORE] SCN <system_change_number>

Syntax 2: TIMESTAMP

FLASHBACK [STANDBY] DATABASE [<database_name>]TO [BEFORE] TIMESTMP <system_timestamp_value>

Syntax 3: RESTORE POINT

FLASHBACK [STANDBY] DATABASE [<database_name>]TO [BEFORE] RESTORE POINT <restore_point_name>

Flashback Syntax Elements

OFFALTER DATABASE FLASHBACK OFF

alter database flashback off;

ONALTER DATABASE FLASHBACK ON

alter database flashback on;

Set Retention Target

ALTER SYSTEM SET db_flashback_retention_target = <number_of_minutes>;

alter system set DB_FLASHBACK_RETENTION_TARGET = 2880;

Start flashback on a tablespace

ALTER TABLESPACE <tablespace_name> FLASHBACK ON;

alter tablespace example flashback on;

Stop flashback on a tablespace

ALTER TABLESPACE <tablespace_name> FLASHBACK OFF;

alter tablespace example flashback off;

Initialization Parameters

Setting the location of the flashback recovery area

db_recovery_file_dest=/oracle/flash_recovery_area

Setting the size of the flashback recovery

db_recovery_file_dest_size=2147483648

76

area

Setting the retention time for flashback files (in minutes)

-- 2 daysdb_flashback_retention_target=2880

SELECT flashback_on, log_modeFROM v$database;

set linesize 121col name format a30col value format a30

SELECT name, valueFROM gv$parameterWHERE name LIKE '%flashback%';

As SYS As ACKERS

SELECT current_scnFROM v$database;

SELECT oldest_flashback_scn,oldest_flashback_timeFROM gv$flashback_database_log;

GRANT flashback any table TO Ackers;

77

create table t (mycol VARCHAR2(20))ROWDEPENDENCIES;

INSERT INTO t VALUES ('ABC');

INSERT INTO t VALUES ('DEF');

COMMIT;

CREATE RESTORE POINT before_damage;

INSERT INTO t VALUES ('GHI');

COMMIT;

SELECT ora_rowscn, mycol FROM t;

SHUTDOWN immediate;

startup mount exclusive;

-- be sure to substitute your SCNFLASHBACK DATABASE TO SCN 19513917;orFLASHBACK DATABASE TO RESTORE POINT bef_damage;

/*FLASHBACK DATABASE TO TIMESTAMP (SYSDATE-1/24);

FLASHBACK DATABASE TO TIMESTAMP timestamp'2002-11-05 14:00:00';

FLASHBACK DATABASE TO TIMESTAMP to_timestamp('2002-11-11 16:00:00', 'YYYY-MM-DD HH24:MI:SS');*/

-- this will fail

78

alter database open;

-- this will succeedalter database open resetlogs;

conn Ackers/Ackers

SELECT ora_rowscn, mycol FROM t;

SELECT *FROM gv$flashback_database_stat;

alter system switch logfile;

shutdown immediate;

startup mount exclusive;

alter database flashback off;

alter database noarchivelog;

alter database open;

SELECT flashback_on, log_modeFROM v$database;

host

rman target sys/pwd@orabase

RMAN> crosscheck archivelog all;

RMAN> delete archivelog all;

RMAN> list archivelog all;

Examples: Using Restore Points

(Configuration for Examples)

To create the test user and test table used in the following examples, use the following SQL/PL SQL to create the user and insert 200 rows of sample data (code below assumes you have a USERS tablespace):

79

http://www.devshed.com/#%23

--Create user and grant necessary permissionscreate user testuser identified by testuser;grant create table to testuser;grant create session to testuser;grant create procedure to testuser;grant execute on dbms_lock to testuser;alter user testuser quota 5m on users;

--Connect as the newly created testuser and create the test table and logging tableconn testuser/testuser;create table testuser.test (id int, name varchar2(5)) tablespace users;create table testuser.logging (timestamp date, loginfo varchar2(15)) tablespace users;

--Insert sample data into the test tabledeclarei number(5);beginfor i in 1..200 loopinsert into testuser.test values (i, 'a'||i);end loop;commit;end;/

In this simple example, we'll use a normal restore point to flash back a table to our testing starting point after it has been modified during the testing of a new procedure. For simplicity's sake, the procedure will only delete rows from our table, but it could just as easily have been performing complicated business logic. Because we have flashback logging disabled, it isn't possible for us to perform a flashback database (we'll receive a 'ORA-38726: Flashback database logging is not on.' if we attempt it).

Because we'll be using flashback table, we need to enable row movement for the 'testuser.test' table involved, in effect giving Oracle permission to modify the ROWIDs for the rows in our table when it moved things around during the flashback table.

SQL> alter table testuser.test enable row movement;

Table altered.

Create the 'process_data' procedure, representative of a new batch process we're testing:

SQL> create or replace procedure testuser.process_data is2 begin3 delete from testuser.test where id > 50;

80



4 commit;5 end;6 /

Procedure created.

Next, we'll create a normal restore point 'before_test1' to mark our starting point for testing. This will allow us to return to this point in time to make changes and retest our new batch process without having to note the SCN or guess at the timestamp:

SQL> create restore point before_test1;

Restore point created.

Next, we'll execute the "process_data" procedure. After the procedure has completed, we see that the data has been processed correctly, and only 50 rows remain in the testuser.test table:

SQL> exec testuser.process_data;

PL/SQL procedure successfully completed.

SQL> select count(*) from testuser.test;

COUNT(*)----------50

We've completed testing for the first iteration of our batch process. To allow testing of the procedure to run against the testuser.test table once again, we'll use our restore point to flash back the table to our starting point, and begin the subsequent rounds of testing:

SQL> flashback table testuser.test to restore point before_test1;

Flashback complete.

Once we've completed the testing and our restore point is no longer needed, we're free to drop the restore point from the database. Note that this step isn't actually required, as the restore points will automatically age out of the database, but it's probably a good idea to keep things as tidy as possible. We'll drop the restore point to minimize confusion:

SQL> drop restore point before_test1;

81


Restore point dropped.

illustrate the use of a guaranteed restore point, we'll use an example where we have a new batch process we're testing that will be moving to production in the near future, and would like to test multiple algorithms to determine the most efficient method for processing the data. We'll create a restore point before running the tests, enabling us to in effect "reset" the database back to the exact same point in time before each test.

This will make our testing much easier, ensuring that we're doing an apples-to-apples comparison of the algorithms while minimizing both the amount of work the DBA must do to restore the old data as well as the amount of time spent to do this restore.

Because we'd like to have the ability to utilize the full spectrum of functionality provided by restore points and flashback database, we'll enable flashback database now. Ensure the prerequisites have been met (both Restore Point Prerequisites and Flashback Database Prerequisites above), and use the following steps to enable flashback logging on your database:

oracle @dbatest:~> sqlplus / as sysdba

SQL*Plus: Release 10.2.0.2.0 - Production on Tue May 27 10:18:42 2008

Copyright (c) 1982, 2005, Oracle. All Rights Reserved.

Connected to:Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - ProductionWith the Partitioning, OLAP and Data Mining options

SQL> shutdown immediate;Database closed.Database dismounted.ORACLE instance shut down.SQL> startup mount;ORACLE instance started.

Total System Global Area 159383552 bytesFixed Size 1259696 bytesVariable Size 62916432 bytesDatabase Buffers 92274688 bytesRedo Buffers 2932736 bytesDatabase mounted.SQL> alter database flashback on;

Database altered.

SQL> alter database open;

82





Database altered.

After we've enabled flashback database, we'll create a second test procedure to "process" our data for this example. As in example 1, our procedure will make some basic manipulations on our data, which will represent a more complex business process. This time, however, our procedure will affect more than one table, allowing us to illustrate the effect of the more global flashback database (vs. the flashback table from example 1).

SQL> create or replace procedure testuser.process_data is2 begin3 insert into testuser.logging values (sysdate, 'Begin procedure');4 delete from testuser.test where id > 50;5 insert into testuser.logging values (sysdate, 'End procedure');6 commit;7 end;8 /

Procedure created.

With our batch processing procedure compiled, we're ready to create a guaranteed restore point to "label" the current starting point for use later in flashing back the database:

SQL> create restore point before_test guarantee flashback database;

Restore point created.

As we've now tagged our current point in time, we'll execute the batch processing procedure, and verify that we have only 50 rows remaining in the testuser.test table, and that we've generated some logging in our testuser.logging table:

SQL> exec testuser.process_data(5);

PL/SQL procedure successfully completed.


COUNT(*)----------50

SQL> select * from testuser.logging;

TIMESTAMP LOGINFO--------- ---------------27-MAY-08 Begin procedure

83


27-MAY-08 End procedure

now that we've executed the first test of our new batch process, we need to "reset" the data back to how it appeared before running the test. We'll shut down and remount the database, then use the ''flashback database" command to "reset" the database to our specified restore point:

SQL> shutdown immediate;Database closed.Database dismounted.ORACLE instance shut down.SQL> startup mount;ORACLE instance started.

Total System Global Area 159383552 bytesFixed Size 1259696 bytesVariable Size 62916432 bytesDatabase Buffers 92274688 bytesRedo Buffers 2932736 bytesDatabase mounted.SQL> flashback database to restore point before_test;

Flashback complete.

We've now "reset" the database back to the restore point. We need to re-open the database, but because we're essentially doing a point-in-time recovery, we need to use the "resetlogs" command to recreate the redo logs and create a new instantiation of the database:

SQL> alter database open resetlogs;

Database altered.

We can verify that we once again see 200 rows in the "testuser.test" table, that our "testuser.logging" table is empty, and that we're ready to test another iteration of our batch processing algorithm:


COUNT(*)----------200

SQL> select count(*) from testuser.logging;

COUNT(*)----------0

84



Once we've completed our several iterations of testing, we're ready to remove the guaranteed restore point and free up whatever space the database used to manage the restore point. We accomplish this with the following:

SQL> drop restore point before_test;

Restore point dropped.

Conclusion

Restore points provide a means for a DBA to label a particular point-in-time in the timeline of the database with a user-defined name, without digging into the details of SCNs or timestamps. The guaranteed restore point takes this a step further, providing the ability to guarantee a flashback database is possible until the DBA decides it is no longer needed, along with the ability to perform a flashback database without enabling flashback logging (with a reduced level of functionality). In conclusion, restore points make an invaluable addition to the DBA's arsenal of tools, useful any time a point-in-time recovery is needed.

#-------------------------Scenario 29 - Loss of an Online Undo Segment Datafile (Open or Closed Database) with RMAN with Catalog#-------------------------

Step 1

Full Backup


Step 2


85

FILE #2

E:\ORACLE\ORADATA\BACKUPS\UNDOTBS01.DBF

Step 3


Step 4

Startup open;

ORA-01157ORA-01110

Step 5

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@RmancatRUN { STARTUP MOUNT; ALLOCATE CHANNEL ch3 TYPE Disk; RESTORE datafile 2; RECOVER datafile 2; ALTER DATABASE OPEN; RELEASE CHANNEL ch3; } QUIT

Full Backup

#-------------------------

86

Scenario 30 - Loss of an Online Undo Segment Datafile (Open or Closed Database) with RMAN with NO Catalog#-------------------------

Step 1

Full Backup


Step 2


FILE #2


Step 3


Step 4

Startup open;

ORA-01157ORA-01110

Step 5

87

rman Target SYS/BACKUPS@BACKUPS nocatalog RUN { STARTUP MOUNT; ALLOCATE CHANNEL ch3 TYPE Disk; RESTORE datafile 2; RECOVER datafile 2; ALTER DATABASE OPEN; RELEASE CHANNEL ch3; }QUIT

Full Backup

#-------------------------Scenario 31 - Loss of an Online Undo Segment Datafile (Open or Closed Database) without RMAN#-------------------------

Step 1

Full Backup


Step 2


FILE #2


Step 3

set ORACLE_SID=BACKUPSsqlplus /nologCONN SYS/Backups AS SYSDBA

88

SHUTDOWN IMMEDIATE EXIT#Delete file

Step 4

Startup open;

ORA-01157ORA-01110

Step 5



To find out the path/name of file #2, query V$DATAFILE: SELECT FILE#,NAME FROM V$DATAFILE WHERE FILE#=2; The result is: E:\ORACLE\ORADATA\BACKUPS\UNDOTBS01.DBF

Step 6

Take the lost datafile offline so that the database can be opened: ALTER DATABASE DATAFILE 'E:\ORACLE\ORADATA\BACKUPS\UNDOTBS01.DBF' OFFLINE;

Step 6

Restore the lost datafile from the most recent backup (WHATEVER)host COPY c:\backup\prod3_undo01.dbf c:\u01\prod3\undo01.dbf

Step 7

Recover the datafile or the entire tablespace, depending upon which is most appropriate.

If all of the files which make up a tablespace were affected by the media failure, then issue the command:

RECOVER TABLESPACE undotbs1;

Press return if prompted for the logfile to use during recovery.

89

Otherwise if only an individual datafile of a tablespace was affected, the single datafile may be recovered independently. Recovering only the affected datafile can reduce the recovery time.

RECOVER DATAFILE 'E:\ORACLE\ORADATA\BACKUPS\UNDOTBS01.DBF';

Step 8

Bring the datafile, then the tablespace online after the file has been recovered:

ALTER DATABASE DATAFILE 'E:\ORACLE\ORADATA\BACKUPS\UNDOTBS01.DBF' ONLINE;

Step 9

Open the database. ALTER DATABASE OPEN;

Step 10

Bring the undotbs tablespace online. ALTER TABLESPACE undotbs1 ONLINE;

Step 11

Verify the status of all datafiles to make sure that there aren't additional problems: SELECT FILE#,ONLINE_STATUS,ERROR FROM V$RECOVER_FILE; If the result is "no rows selected" then that means that there are no additional datafiles requiring recovery. Verify that there aren't any additional database files which are offline. SELECT FILE#, STATUS FROM V$DATAFILE;

Full Backup

#-------------------------Scenario 32 - Failure during Open Database - tablespace in backup mode with RMAN with Catalog#-------------------------

Step 1

Full Backup

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@RmancatBackup database plus archivelog;

90

Backup archivelog all;

Step 2

SELECT TABLESPACE_NAME, FILE_NAMEFROM SYS.DBA_DATA_FILESWHERE TABLESPACE_NAME = 'USERS';

Step 3

Mark the beginning of the online tablespace backup. For example, the following statement marks the start of an online backup for the tablespace users:

ALTER TABLESPACE users BEGIN BACKUP;

Step 4

You have forgotten you have placed TABLESPACE users in backup mode, much later.

You need to do backup or whatever

Shutdown immediate;

Errors

ORA-01149ORA-01110

Step 5

Query the V$BACKUP view to determine which files were in backup mode during the failure. SELECT * FROM V$BACKUP;

The results of the query show that file #5,6,7 are still in backup mode (because the file status is "ACTIVE").

91

Step 6

The quickest way to resolve this problem is to issue the following command via sqlplus to take all tablespaces and datafiles out of backup mode:

ALTER DATABASE END BACKUP;

Or

Alternately you may issue commands to take just the tablespace or datafile out of backup mode:

ALTER TABLESPACE USERS END BACKUP;

ALTER DATABASE DATAFILE 'c:\u01\prod3\users01.dbf' END BACKUP;

Step 7


Step 8

If any additional files or tablespaces were in backup mode, errors would have been displayed when the database was opened. But it is still a good idea to verify that there aren't any tablespaces offline for any other reason:

SELECT FILE#,STATUS FROM V$DATAFILE;

SELECT * FROM V$RECOVER_FILE;

no rows selected

SELECT * FROM V$BACKUP;

92

Querying V$BACKUP view should show that the status of all files is "NOT ACTIVE", which means that no datafiles are currently in backup mode.

Full Backup


#-------------------------Scenario 33 - Create new logfile groups and drop old groups#-------------------------

Step 1


Step 2

We have 3 groups with 1 member each

93

SELECT GROUP#, STATUS, MEMBER FROM V$LOGFILE;

SELECT * FROM V$LOG;

Step 3

Kill existing, shutdown and delete/rename

ORA-00313ORA-00312

Step 4

Query the V$LOGFILE view to determine which logfile members are invalid: SELECT GROUP#,STATUS,MEMBER FROM V$LOGFILE;

create 3 more online redo logfile groups, containing 2 mirrored datafiles in each group.

ALTER DATABASE ADD LOGFILE GROUP 4 ('E:\ORACLE\ORADATA\BACKUPS\REDO04_1.LOG', 'E:\ORACLE\ORADATA\BACKUPS\REDO04_2.LOG') SIZE 10M;


94


Get Error ORA-01185 Group 6

Also check parameter 1) MAXLOGFILES - 52) MAXLOGMEMBERS - 3

alter database backup controlfile to trace;

So, you cannot create group 6

Drop groups

ALTER DATABASE DROP LOGFILE GROUP 1; ALTER DATABASE DROP LOGFILE GROUP 2; ALTER DATABASE DROP LOGFILE GROUP 3;

Group 2 in use, bring back Group 2

Switch the current logfile group until none of the original logfile groups (1,3) are being used.

ALTER SYSTEM SWITCH LOGFILE; ALTER SYSTEM SWITCH LOGFILE; ALTER SYSTEM SWITCH LOGFILE;

SELECT GROUP#,STATUS,MEMBER FROM V$LOGFILE;

95

#-------------------------Scenario 34 - Recover archive log using RMAN with Catalog#-------------------------

Steps 1

Find the gap

When the DBA queries the V$ARCHIVE_GAP view and has a record returned, this indicates a gap in the archived redo logs as illustrated below and may require manual intervention by the DBA:

select * from v$archive_gap;

THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#-------- -------------- -------------- 1 24 28

From the output above, the physical standby database is currently missing logs from sequence 24 to sequence 28 for thread 1.

Note that this view only returns the next gap that is currently blocking managed recovery from continuing.

96

After resolving the identified gap and starting managed recovery, the DBA should query the V$ARCHIVE_GAP view again on the physical standby database to determine the next (if any) gap sequence. This process should be repeated until there are no more gaps.

Step 2Where (***NEED TO USE VIEW v$archived_log ***)

After identifying a gap (as shown above), the DBA will need to query the primary database to locate the archived redo logs on the primary database. The following query assumes the local archive destination on the primary database is LOG_ARCHIVE_DEST_1:

SELECT nameFROM v$archived_logWHERE thread# = 1 AND dest_id = 1 AND sequence# BETWEEN 24 and 28;

Step 3 (only if automatic setup been disabled)

Copy the above redo log files to the physical standby database and register them using the ALTER DATABASE REGISTER LOGFILE or restore them

e.g.SQL> ALTER DATABASE REGISTER LOGFILE /u02/oraarchive/TESTDB/arch_t1_s24.dbf';

Step 4

Restore a log file

Say

Restore archive logs between 1 and 8

List backup of archivelog sequence between 1 and 8;

where

97

http://download.oracle.com/docs/cd/B19306_01/backup.102/b14194/rcmsynta008.htm#sthref121

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@Rmancatrun {ALLOCATE CHANNEL ch3 TYPE Disk; set archivelog destination to 'F:\oradata\Recovery_Area\Backups\Temp_Archivelogs';restore archivelog sequence between 1 and 8;RELEASE CHANNEL ch3; }

Or

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@Rmancatrun {ALLOCATE CHANNEL ch3 TYPE Disk; restore archivelog sequence between 1 and 8;RELEASE CHANNEL ch3; }

Supplementary Information

Its easier to understand this by example:-

Flush data from redo logs to archived logs

98



ALTER SYSTEM SWITCH LOGFILE;

--Point 1 - List of incarnation of database

select * from v$database_incarnation;

RESETLOGS_CHANGE# RESETLOGS_TIME PRIOR_RESETLOGS_CHANGE# PRIOR_RESETLOGS_TIME


922270 02-NOV-09 841924 30-OCT-09

--Point 2 - List current SCN

SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL

1608517

--Point 3 - List of change for each redo log file

select a.group#, b.THREAD#, b.members , a.member logfile, SEQUENCE#, FIRST_CHANGE# from v$log b, v$logfile a where a.group#=b.group#;

GROUP# THREAD# MEMBERS LOGFILE SEQUENCE# FIRST_CHANGE#

2 1 1 E:\ORACLE\ORADATA\BACKUPS\REDO02.LOG 23 1546511

--Point 4 – details of redo log

SELECT * FROM v$log

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARCHIVED STATUS FIRST_CHANGE# FIRST_TIME

2 1 23 104857600 1 YES ACTIVE 1546511 24-NOV-09

SELECT * FROM v$logfile

GROUP# STATUS TYPE MEMBER

2 ONLINE E:\ORACLE\ORADATA\BACKUPS\REDO02.LOG

99

--Point 5 – archive log destination

Select DEST_ID,DEST_NAME,STATUS, ARCHIVER,DESTINATION, LOG_SEQUENCE from v$archive_dest;

--Point 6 – archive log details

select * from v$archived_log WHERE SEQUENCE# =23

RECID STAMP NAME DEST_ID THREAD# SEQUENCE# RESETLOGS_CHANGE# RESETLOGS_TIME FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME BLOCKS BLOCK_SIZE CREATOR REGISTRAR STANDBY_DEST ARCHIVED APPLIED DELETED STATUS COMPLETION_TIME DICTIONARY_BEGIN DICTIONARY_END END_OF_REDO BACKUP_COUNT ARCHIVAL_THREAD# ACTIVATION#

214 703959219 F:\ORADATA\RECOVERY_AREA\BACKUPS\ARCHIVELOGS\ARC00023_2073096330.001 1 1 23 922270 02-NOV-09 1546511 24-NOV-09 1608494 26-NOV-09 1816 512 ARCH ARCH NO YES NO NO A 26-NOV-09 NO NO NO 0 1 2141611485

922270 (# RESETLOGS_CHANGE# Point 1)

1 (DEST_ID Point 5)

23 (SEQUENCE# Point 4)

1546511 (FIRST_CHANGE# Point 4) (lowest SCN recorded in the log file)

1608494 (NEXT_CHANGE# (the highest SCN in the log file))

--Point 7 – In a disaster situation where all files are lost you can only recover to the last SCN in the archived redo logs

SELECT ARCHIVELOG_CHANGE# FROM v$database;

1608494

100

To recover

run {

shutdown immediate;

startup mount;

# set until time 'Nov 15 2000 09:00:00';

# set until scn 1000; # alternatively, you can specify SCN

# set until sequence 9923; # alternatively, you can specify log sequence number

restore database;

recover database;

alter database open resetlogs;

}

The system change number (SCN) is an ever-increasing value that uniquely identifies a committed version of the database at a point in time. Every time a user commits a transaction Oracle records a new SCN in redo logs.

oracle uses SCNs in control files datafile headers and redo records. Every redo log file has both a log sequence number and low and high SCN. The low SCN records the lowest SCN recorded in the log file while the high SCN records the highest SCN in the log file..

What is Database Incarnation ?

101

Database incarnation is effectively a new “version” of the database that happens when you reset the online redo logs using “alter database open resetlogs;”.

-- log sequence number

Oracle Database assigns each redo log file a new log sequence number every time a log switch occurs and LGWR begins writing to it. When the database archives redo log files, the archived log retains its log sequence number. A redo log file that is cycled back for use is given the next available log sequence number.

Each online or archived redo log file is uniquely identified by its log sequence number. During crash, instance, or media recovery, the database properly applies redo log files in ascending order by using the log sequence number of the necessary archived and redo log files.

--Views

Use this view to find out to which place archived redo logs are copied:

v$archive_dest

Select DEST_ID,DEST_NAME,STATUS, ARCHIVER,DESTINATION, LOG_SEQUENCE from v$archive_dest;

102

http://onlineappsdba.com/wp-content/uploads/2009/09/incarnation_2.jpg

v$archive_dest_status

This view allows to find status and errors for each of the defined

SELECT DEST_ID, DEST_NAME, STATUS, DATABASE_MODE, RECOVERY_MODE,DESTINATION, ARCHIVED_SEQ# FROM v$archive_dest_status

v$archived_log

Displays successfully archived redo logs. shows received logs on a primary standby database.

SELECT * FROM v$archived_log

v$archive_gap

Lists sequence numbers of the archived los that are known to be missing for each thread on a (physical?) standby database (highest gap only).

SELECT * FROM v$archive_gap

103

v$log_history

Relationship between SCN and log files

-each log file - has series change no's from first to next change...-based on archive log format

V$RECOVERY_LOG

To locate archived log files, view V$ARCHIVED_LOG for all archives orV$RECOVERY_LOG for archives needed during recovery:

Select * from V$RECOVERY_LOG

THREAD#, SEQUENCE#, TIME, ARCHIVE_NAME

#-------------------------Scenario 35 - Recover archive log using RMAN with Catalog with CommVault#-------------------------

Step 1

Full backup with CommVault.

Step 2

Use the query

104

SELECT * FROM v$archived_log ORDER BY SEQUENCE# desc

Delete archive logs – correspond to SEQUENCE# 34, 33 (any)

RECID STAMP NAME DEST_ID THREAD# SEQUENCE# RESETLOGS_CHANGE# RESETLOGS_TIME FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME BLOCKS BLOCK_SIZE CREATOR REGISTRAR STANDBY_DEST ARCHIVED APPLIED DELETED STATUS COMPLETION_TIME DICTIONARY_BEGIN DICTIONARY_END END_OF_REDO BACKUP_COUNT ARCHIVAL_THREAD# ACTIVATION# 140 701543782 F:\ORADATA\RECOVERY_AREA\BACKUPS\ARCHIVELOGS\ARC00034_2073096330.001 1 1 34 610126 20-OCT-09 816162 29-OCT-09 816171 29-OCT-09 1 512 FGRD FGRD NO YES NO NO A 29-OCT-09 NO NO NO 1 1 2140468449

These are archived

Step 3 - In a disaster situation where all files are lost you can only recover to the last SCN in the archived redo logs


Step 4 – Restore from CommVault archive logs

105

Script Preview

run {allocate channel ch1 type 'sbt_tape'PARMS="BLKSIZE=0"; restore (archivelog

from logseq 33 until logseq 34 thread = 1 );}

Error

RMAN-20242: specification does not match any archive log in the recovery catalog

Deleted logs from a previous database incarnation. So could not see the archive logs.

Try again.

Delete archive logs based on latest database incaranation

Step 1


RESETLOGS_CHANGE# RESETLOGS_TIME PRIOR_RESETLOGS_CHANGE# PRIOR_RESETLOGS_TIME 922270 02-NOV-09 841924 30-OCT-09

Step 2

SELECT * FROM v$archived_log WHERE RESETLOGS_CHANGE#=922270 ORDER BY SEQUENCE# desc

Delete archive logs – correspond to SEQUENCE# 23, 22 (any)

These are archived

108


215 703959219 G:\ORADATA\RECOVERY_AREA\BACKUPS\ARCHIVELOGS\ARC00023_2073096330.001 2 1 23 922270 02-NOV-09 1546511 24-NOV-09 1608494 26-NOV-09 1816 512 ARCH ARCH NO YES NO NO A 26-NOV-09 NO NO NO 2 1 2141611485

Step 3

Check

--in a disaster situation where all files are lost you can only recover to the last SCN in the archived redo logs

--Plus current log sequence

Step 4

Check rmancat - see if archive logs exist

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@Rmancat

109

list backup of archivelog sequence between 22 and 23;

List of Backup Sets===================

BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------36095 1K DISK 00:00:01 27-SEP-07 BP Key: 36098 Status: EXPIRED Tag: TAG20070927T152509 Piece Name: G:\ORADATA\RECOVERY_AREA\BACKUPS\RMAN_BACKUPS\ORA_DF634404310_S75_S1

List of Archived Logs in backup set 36095 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 22 389331 27-SEP-07 389334 27-SEP-07

BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------36097 8K DISK 00:00:01 27-SEP-07 BP Key: 36100 Status: EXPIRED Tag: TAG20070927T152509 Piece Name: G:\ORADATA\RECOVERY_AREA\BACKUPS\RMAN_BACKUPS\ORA_DF634404312_S76_S1


BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------36401 10K SBT_TAPE 00:00:13 28-SEP-07 BP Key: 36403 Status: AVAILABLE Tag: TAG20070928T113706 Piece Name: 2tit2mf2_1_1

List of Archived Logs in backup set 36401 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 22 389331 27-SEP-07 389334 27-SEP-07 1 23 389334 27-SEP-07 389588 27-SEP-07

BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------36402 10K SBT_TAPE 00:00:06 28-SEP-07 BP Key: 36404 Status: AVAILABLE Tag: TAG20070928T113706 Piece Name: 2uit2mfj_1_1

110

List of Archived Logs in backup set 36402 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 22 389331 27-SEP-07 389334 27-SEP-07 1 23 389334 27-SEP-07 389588 27-SEP-07

BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------58550 2M SBT_TAPE 00:00:11 17-JAN-08 BP Key: 58552 Status: EXPIRED Tag: TAG20080117T155740 Piece Name: gpj6d43k_1_1

List of Archived Logs in backup set 58550 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 22 3237653 11-JAN-08 3404201 17-JAN-08

BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------58551 2M SBT_TAPE 00:00:07 17-JAN-08 BP Key: 58553 Status: EXPIRED Tag: TAG20080117T155740 Piece Name: gqj6d444_1_1


BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------58768 282K SBT_TAPE 00:00:12 18-JAN-08 BP Key: 58770 Status: EXPIRED Tag: TAG20080118T084036 Piece Name: h0j6eus4_1_1


BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------58769 282K SBT_TAPE 00:00:07 18-JAN-08 BP Key: 58771 Status: EXPIRED Tag: TAG20080118T084036 Piece Name: h1j6eusk_1_1


111

BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------164252 402K SBT_TAPE 00:00:14 15-APR-08 BP Key: 164254 Status: UNAVAILABLE Tag: TAG20080415T215131 Piece Name: 30jdtmv3_1_1

List of Archived Logs in backup set 164252 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 22 1142143 14-APR-08 1170533 15-APR-08

BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------164253 402K SBT_TAPE 00:00:07 15-APR-08 BP Key: 164255 Status: UNAVAILABLE Tag: TAG20080415T215131 Piece Name: 31jdtmvk_1_1


BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------164453 408K SBT_TAPE 00:00:35 16-APR-08 BP Key: 164455 Status: UNAVAILABLE Tag: TAG20080416T214224 Piece Name: 35je0aq0_1_1


BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------164454 408K SBT_TAPE 00:00:32 16-APR-08 BP Key: 164456 Status: UNAVAILABLE Tag: TAG20080416T214224 Piece Name: 36je0ar4_1_1


BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------216252 512 SBT_TAPE 00:00:24 29-SEP-08 BP Key: 216253 Status: AVAILABLE Tag: TAG20080929T213457 Piece Name: 1fjrr9c1_1_1

112


BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------216804 409K SBT_TAPE 00:00:45 30-SEP-08 BP Key: 216805 Status: AVAILABLE Tag: TAG20080930T213900 Piece Name: 1jjrttvk_1_1


BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------340896 113K SBT_TAPE 00:00:23 07-OCT-09 BP Key: 340897 Status: AVAILABLE Tag: TAG20091007T215759 Piece Name: 16kr7tj7_1_1

List of Archived Logs in backup set 340896 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 22 520706 07-OCT-09 525459 07-OCT-09 1 23 525459 07-OCT-09 525463 07-OCT-09

BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------340942 112K DISK 00:00:01 08-OCT-09 BP Key: 340944 Status: AVAILABLE Tag: TAG20091008T120321 Piece Name: G:\ORADATA\RECOVERY_AREA\BACKUPS\RMAN_BACKUPS\ORA_DF699710601_S40_S1

List of Archived Logs in backup set 340942 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 22 520706 07-OCT-09 525459 07-OCT-09

BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------340943 512 DISK 00:00:02 08-OCT-09 BP Key: 340945 Status: AVAILABLE Tag: TAG20091008T120321 Piece Name: G:\ORADATA\RECOVERY_AREA\BACKUPS\RMAN_BACKUPS\ORA_DF699710601_S41_S1

List of Archived Logs in backup set 340943

113

Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 23 525459 07-OCT-09 525463 07-OCT-09

BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------347781 1K DISK 00:00:01 23-OCT-09 BP Key: 347782 Status: AVAILABLE Tag: TAG20091023T160918 Piece Name: G:\ORADATA\RECOVERY_AREA\BACKUPS\RMAN_BACKUPS\ORA_DF701021358_S120_S1


BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------347795 512 DISK 00:00:01 23-OCT-09 BP Key: 347796 Status: AVAILABLE Tag: TAG20091023T160924 Piece Name: G:\ORADATA\RECOVERY_AREA\BACKUPS\RMAN_BACKUPS\ORA_DF701021364_S122_S1


BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------349164 2K SBT_TAPE 00:00:23 28-OCT-09 BP Key: 349165 Status: AVAILABLE Tag: TAG20091028T152953 Piece Name: 40ksuinh_1_1

List of Archived Logs in backup set 349164 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 22 672283 23-OCT-09 672302 23-OCT-09 1 23 672302 23-OCT-09 672310 23-OCT-09

BS Key Size Device Type Elapsed Time Completion Time------- ---------- ----------- ------------ ---------------362826 909K SBT_TAPE 00:00:16 04-DEC-09 BP Key: 362827 Status: AVAILABLE Tag: TAG20091204T123016 Piece Name: 7dl02eep_1_1

List of Archived Logs in backup set 362826 Thrd Seq Low SCN Low Time Next SCN Next Time

114

---- ------- ---------- --------- ---------- --------- 1 22 1546508 24-NOV-09 1546511 24-NOV-09 1 23 1546511 24-NOV-09 1608494 26-NOV-09

We can get it….

Step 4 – Restore from CommVault archive logs

115

Script Preview

run {allocate channel ch1 type 'sbt_tape'PARMS="BLKSIZE=0"; restore (archivelog

from logseq 22 until logseq 23 thread = 1 );}

Done….

117

#-------------------------Scenario 36 – Duplicate Database using RMAN with Catalog#-------------------------

Step 1

Full Backup


Step 2

First we must create a password file for the duplicate instance:

Use Orapwd utlity

orapwd file=E:\oracle\ora92\database\PWDDUP.ORA password=DUP entries=5

Step 3

Next add the appropriate entries into the tnsnames.ora and listener.ora files in the $ORACLE_HOME/network/admin directory.

Remember to load the new configuration into the listener:

# Added to the listener.ora

(SID_DESC = (GLOBAL_DBNAME = DUP) (ORACLE_HOME = e:\oracle\ora92) (SID_NAME = DUP) )

# Added to the tnsnames.ora

DUP = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = glasbs2)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = DUP) (INSTANCE_NAME = DUP) (GLOBAL_NAME =DUP) ) )

118

# Reload listenerlsnrctl reload

Step 4

Check connectivity

Tnsping DUP

Step 5

Create pfile from spfile of source databaseRename initDUP.ora

Modify plus add extra parameter (in red)

initDUP.ora

*.db_create_file_dest ='’e:\oracle\oradata\DUP'*.DB_FILE_NAME_CONVERT=('E:\oracle\oradata\BACKUPS\','E:\oracle\oradata\DUP\')*.LOG_FILE_NAME_CONVERT=('E:\oracle\oradata\BACKUPS\','E:\oracle\oradata\DUP\')

*.background_dump_dest='e:\oracle\admin\DUP\bdump'*.compatible='9.2.0.0.0'*.control_files='e:\oracle\oradata\DUP\control01.ctl','e:\oracle\oradata\DUP\control02.ctl','e:\oracle\oradata\DUP\control03.ctl'*.core_dump_dest='e:\oracle\admin\DUP\cdump'*.db_block_size=8192*.db_cache_size=25165824*.db_domain=''*.db_file_multiblock_read_count=16*.db_name='DUP'*.fast_start_mttr_target=300*.hash_join_enabled=TRUE*.instance_name='DUP'*.java_pool_size=0*.large_pool_size=8388608*.log_archive_dest_1='LOCATION=F:\oradata\Recovery_Area\DUP\Archivelogs OPTIONAL REOPEN=300'*.log_archive_dest_2='LOCATION=g:\oradata\Recovery_Area\DUP\Archivelogs OPTIONAL REOPEN=300'*.log_archive_format='ARC%S_%D.%T'*.log_archive_start=true*.open_cursors=300*.pga_aggregate_target=25165824*.processes=150*.query_rewrite_enabled='FALSE'*.remote_login_passwordfile='EXCLUSIVE'*.shared_pool_size=50331648*.sort_area_size=524288

119

*.star_transformation_enabled='FALSE'*.timed_statistics=TRUE*.undo_management='AUTO'*.undo_retention=15360000*.undo_tablespace='UNDOTBS1'*.user_dump_dest='e:\oracle\admin\DUP\udump'

Step 6

***********VERY IMPORTANT***************Create directory structure for DUP

Step 7

Create windows Service - Need to create service BEFORE create database

ORADIM -NEW -SID DUP -STARTMODE AUTO -PFILE 'E:\oracle\ora92\database\INITDUP.ORA'

Step 8

Next we start the database in NOMOUNT mode:

STARTUP FORCE NOMOUNT;

Step 9

With the duplicate database started we can now connect to it from RMAN.

For the duplication to work we must connect to the original database (TARGET), the recovery catalog (CATALOG) and our duplicate database (DUP):

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@Rmancat AUXILIARY SYS/DUP@DUP

Step 10

We can then dupicate the database using one of the following commands:

# Duplicate database to TARGET's current state.DUPLICATE TARGET DATABASE TO DUP;

# Duplicate database to TARGET's state 4 days ago.DUPLICATE TARGET DATABASE TO DUP UNTIL TIME 'SYSDATE-4';

120

ErrorRMAN-06054: media recovery requesting unknown log: thread 1 scn 1912736

run {ALTER DATABASE OPEN RESETLOGS;}

Checked the archive log files there are there…

Step 11

Check the database

select INSTANCE_NAME,HOST_NAME,STARTUP_TIME,STATUS from v$instance;

select DBID,NAME,CREATED,RESETLOGS_TIME,LOG_MODE,CONTROLFILE_CREATED from v$database

select file_name from dba_data_files;

#-------------------------Scenario 37 – Duplicate Database using RMAN with Catalog with CommVault#-------------------------

Prerequisite Setup Steps for Creating a Duplicate Database

The following procedure describes the prerequisite setup steps for creating a duplicate database:

Before You Begin:

Review information on the Duplicate Database feature before beginning this procedure.

Prerequisite setup steps:

Prerequisite setup steps:

Step 1

Run a full backup (along with the log files) on the original database.

Create a duplicate Oracle database instance. If using a different host, create the duplicate database instance on the destination host.

121

http://documentation.commvault.com/commvault/release_8_0_0/books_online_1/english_us/features/restore/oracle.htm#Duplicate%20Database

Step 2

First we must create a password file for the duplicate instance:

Use Orapwd utlity (specific password required)

orapwd file=E:\oracle\ora92\database\PWDABC.ORA password= change_on_install entries=5

Step 3

o Copy the init<SID>.ora file from the original database to the duplicate database instance.

Create pfile from spfile;

o Update the database name and the database file locations in the init<SID>.ora file for the duplicate database instance. Also, add the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters in the init<SID>.ora file. The DB_FILE_NAME_CONVERT parameter is used to redirect the data files and temp files to a target location. Similarly, the LOG_FILE_NAME_CONVERT parameter can be used to redirect the archive log files to a target location. The syntax is as follows:

DB_FILE_NAME_CONVERT=('SOURCE_OF_DF_PATH/','DUP_OF_DF_PATH/','SOURCE_OF_TEMP_PATH/','DUP_OF_TEMP_PATH/',...)

LOG_FILE_NAME_CONVERT=('SOURCE_OF_LOG_PATH/REDO','DUP_OF_LOG_PATH/REDO')

When using these parameters on a Windows computer, the file paths should be entered in uppercase.

Make that all the other parameters in the init<SID>.ora file is same as that in the original database.

In the case of table restore, provide the log_archive_dest_1 parameter in the init<auxiliary_sid>.ora file for the specified auxiliary instance.

*.DB_FILE_NAME_CONVERT=('E:\oracle\oradata\BACKUPS\','E:\oracle\oradata\ABC\')

*.LOG_FILE_NAME_CONVERT=('E:\oracle\oradata\BACKUPS\','E:\oracle\oradata\ABC\')

122

Configure file

*.background_dump_dest='e:\oracle\admin\ABC\bdump'*.compatible='9.2.0.0.0'*.control_files='e:\oracle\oradata\ABC\control01.ctl','e:\oracle\oradata\ABC\control02.ctl','e:\oracle\oradata\ABC\control03.ctl'*.core_dump_dest='e:\oracle\admin\ABC\cdump'*.db_block_size=8192*.db_cache_size=25165824*.db_domain=''*.db_file_multiblock_read_count=16*.db_name='ABC'*.fast_start_mttr_target=300*.hash_join_enabled=TRUE*.instance_name='ABC'*.java_pool_size=0*.large_pool_size=8388608*.log_archive_dest_1='LOCATION=F:\oradata\Recovery_Area\ABC\Archivelogs OPTIONAL REOPEN=300'*.log_archive_dest_2='LOCATION=g:\oradata\Recovery_Area\ABC\Archivelogs OPTIONAL REOPEN=300'*.log_archive_format='ARC%S_%D.%T'*.log_archive_start=true*.open_cursors=300*.pga_aggregate_target=25165824*.processes=150*.query_rewrite_enabled='FALSE'*.remote_login_passwordfile='EXCLUSIVE'*.shared_pool_size=50331648*.sort_area_size=524288*.star_transformation_enabled='FALSE'*.timed_statistics=TRUE*.undo_management='AUTO'*.undo_retention=15360000*.undo_tablespace='UNDOTBS1'*.user_dump_dest='e:\oracle\admin\ABC\udump'*.DB_FILE_NAME_CONVERT=('E:\oracle\oradata\BACKUPS\','E:\oracle\oradata\ABC\')

*.LOG_FILE_NAME_CONVERT=('E:\oracle\oradata\BACKUPS\','E:\oracle\oradata\ABC\')

123

Step 4

***********VERY IMPORTANT***************Create directory structure for ABC

Step 5

Create new Oracle Services if using a Windows computer.

Create windows Service - Need to create service BEFORE create database

ORADIM -NEW -SID ABC -STARTMODE AUTO -PFILE 'E:\oracle\ora92\database\INITABC.ORA'

Step 6

If using the same host, add the duplicate database instance name in the Listener.ora and Tnsnames.ora files.

If using a different host, add the duplicate database instance name in the Listener.ora file on the destination host and Tnsnames.ora files on the destination and source hosts. Also, add the original database name in the Tnsnames.ora file on the destination host.

# Added to the listener.ora

(SID_DESC = (GLOBAL_DBNAME = ABC) (ORACLE_HOME = e:\oracle\ora92) (SID_NAME = ABC) )

# Added to the tnsnames.ora

ABC = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = glasbs2)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = ABC) (INSTANCE_NAME = ABC) (GLOBAL_NAME = ABC) ) )

124

Restart the Listener.

lsnrctl reload

Step 7

Check connectivity

Tnsping ABC

Step 8

Startup the duplicate database instance in the NOMOUNT mode.

Step 9 (create in CommVault new instance with ‘change_on_install’ hard-coded in)

Provide a valid connect string for the auxiliary channel (used to duplicate the database). The system assumes and uses sys/change_on_install for the auxiliary channel. If using a different host, make sure that a valid connect string (sys/sys@<SID name>) is provided in the Instance Properties (Details) tab instead of a '/'.

With the duplicate database started we can now connect to it from RMAN.

For the duplication to work we must connect to the original database (TARGET), the recovery catalog (CATALOG) and our duplicate database (ABC):

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@Rmancat AUXILIARY SYS/ABC@ABC

See next section for details….

If using a different host, ensure that the Oracle iDataAgent is installed on the Destination host.

If required, you can create a new Oracle instance for the duplicate database in the CommCell Console, open the instance properties and verify that the Oracle instance status of the duplicate database is STARTED.

125

http://documentation.commvault.com/commvault/release_8_0_0/books_online_1/english_us/en-us/universl/instances/details.htm

Create a Duplicate Database on the Same Host with the Instance Configured

The following procedure describes the steps involved in creating a duplicate database on the same host with the instance configured.

Review information on the Duplicate Database feature before beginning this procedure.

Perform the Prerequisite Setup Steps for Creating a Duplicate Database. (see previous section)

Required Capability: See Capabilities and Permitted Actions

To create a duplicate database on the same host with the instance configured:

1. From the CommCell Console, right-click the source host instance then select All Tasks -> Restore.

2. From the Oracle Restore Options (General) dialog box, select the Duplicate DB checkbox then enter the Catalog Connect string and click Advanced.

3.

4. From the Duplicate tab in the Oracle Duplicate Options dialog box, configure the following fields:

126

http://documentation.commvault.com/commvault/release_8_0_0/books_online_1/english_us/en-us/universl/restore/oracle/duplicate.htm

http://documentation.commvault.com/commvault/release_8_0_0/books_online_1/english_us/en-us/universl/restore/oracle/resopt.htm

http://documentation.commvault.com/commvault/release_8_0_0/books_online_1/english_us/features/user_admin/user_admin.htm#Capabilities%20and%20Permitted%20Actions

http://documentation.commvault.com/commvault/release_8_0_0/books_online_1/english_us/features/restore/how_to/oracle/pre_steps_for_dup_db.htm


http://documentation.commvault.com/commvault/release_8_0_0/books_online_1/english_us/features/restore/oracle.htm#Duplicate%20Database

o Duplicate To - Select this option then enter the name for the duplicate database in the Database Name field.

o Pfile - For Oracle 10g and 9i, type in or Browse to the location of the Startup Pfile.

o Open Restricted - For Oracle 10g, you can select this option if you want to open the database in restricted mode.

o Log File - Select this option, then specify Group or File and click the appropriate Add button to enter specifications for the redo log group/file.

5. From the Recover tab in the Advanced Restore Options dialog box, select the appropriate recover option.

127

http://documentation.commvault.com/commvault/release_8_0_0/books_online_1/english_us/en-us/universl/restore/oracle/recover.htm

6. Select any other desired options, then click Redirect in the Advanced Restore Options dialog box.

7. From the Redirect tab, choose one of the following then click OK:

128

http://documentation.commvault.com/commvault/release_8_0_0/books_online_1/english_us/en-us/universl/restore/oracle/redirect.htm

o To redirect all tablespaces to the same location, select the Redirect All Table Spaces to: checkbox then type in or Browse to the new path.

o To redirect tablespaces/datafiles to different locations, select the Redirect checkbox then click the desired objects in the Object column to highlight them, and either type in or Browse to the new path. Click Apply. Repeat this process until all tablespaces/datafiles have been redirected.

To redirect the database temp file, use the DB_FILE_NAME_CONVERT parameter in the initial file for the new database instance. Similarly, to redirect the log files, you can either use the LOG_FILE_NAME_CONVERT parameter in the initial file or use the Log File option in the Advanced Restore Options (Duplicate) dialog box. For

129



more information on setting the parameters in the initial file, see Prerequisite Setup Steps for Creating a Duplicate Database.

8. From the Duplicate DB Options tab in the Oracle Duplicate Options dialog box, configure the following options as desired:

o Time Zone - Select a time zone for a point-in-time recovery.

o No Filename Check - Select this option to prevent RMAN from performing a check for target datafiles sharing the same names as the duplicated files to see if they are in use. This option is required when you are using the same path (i.e., the standby and primary datafiles and logs have identical filenames).

9. Click OK on the Advanced Restore Options dialog box.

130

http://documentation.commvault.com/commvault/release_8_0_0/books_online_1/english_us/en-us/universl/restore/oracle/duplicate_db_options.htm




Script Preview

******DATA RESTORE SCRIPT******

run {

set newname for datafile 'E:\ORACLE\ORADATA\BACKUPS\INDX01.DBF' to 'E:\oracle\oradata\ABC\INDX01.DBF';

set newname for datafile 'E:\ORACLE\ORADATA\BACKUPS\SYSTEM01.DBF' to 'E:\oracle\oradata\ABC\SYSTEM01.DBF';

set newname for datafile 'E:\ORACLE\ORADATA\BACKUPS\TOOLS01.DBF' to 'E:\oracle\oradata\ABC\TOOLS01.DBF';

set newname for datafile 'E:\ORACLE\ORADATA\BACKUPS\UNDOTBS01.DBF' to 'E:\oracle\oradata\ABC\UNDOTBS01.DBF';

set newname for datafile 'E:\ORACLE\ORADATA\BACKUPS\NEWMEDIA\USERS01.DBF' to 'E:\oracle\oradata\ABC\USERS01.DBF';



allocate auxiliary channel ch1 type 'sbt_tape'

PARMS="BLKSIZE=262144,ENV=(CV_mmsApiVsn=2,CV_channelPar=ch1,ThreadCommandLine= RESTORE -jm 14 -a 2:0 -cl 73 -ins 65 -at 0 -j 0 -bal 0 -bap 0 -rap 0 -rcp 0 -mav 0 -ms 1 -p 2 -cn glasbs2 -vm Instance001)"

TRACE 0;

duplicate target database to ABC

PFILE= E:\oracle\ora92\database\INITABC.ORA

;

}

exit;

131

Begin or schedule the restore. Once the job begins, if you see a pop-up message about the database state, ensure that the duplicate database is in NOMOUNT mode then click Yes to continue.

Errors

1.

RMAN-05500: the auxiliary database must be not mounted when issuing a DUPLICATE command

It mounts the database in the job – need to shutdown and restart in nomount

2.

RMAN-06054: media recovery requesting unknown log: thread 1 scn 2927472

Backups database



922270 02-NOV-09 841924 30-OCT-09

SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL;

2932242

select a.group#, b.THREAD#, b.members , a.member logfile, SEQUENCE#, FIRST_CHANGE# from v$log b, v$logfile a where a.group#=b.group#;

SELECT * FROM v$log

132


2927472

select * from v$archived_log WHERE RESETLOGS_CHANGE#= 922270 AND SEQUENCE# =56 ORDER by SEQUENCE# DESC


282 708088571 F:\ORADATA\RECOVERY_AREA\BACKUPS\ARCHIVELOGS\ARC00056_2073096330.001 1 1 56 922270 02-NOV-09 2927468 12-JAN-10 2927472 12-JAN-10 1 512 FGRD FGRD NO YES NO NO A 12-JAN-10 NO NO NO 1 1 2141611485

Basically select last archive log generated on the day of the backup.

10. Verify that the restore completed successfully and that the database is restored to the destination host. If you selected the Recover option verify that the database is consistent.

#-------------------------Scenario 38 – Check and repair block corruption using RMAN with Catalog#-------------------------

ORA-01578 runtime error because there are one or more corrupt blocks

How can corrupt blocks be caused?

133

First of all we have two different kinds of block corruption:- physical corruption (media corrupt)- logical corruption (soft corrupt)

Physical corruption can be caused by defected memory boards, controllers or broken sectors on a hard disk;

Logical corruption can among other reasons be caused by an attempt to recover through a NOLOGGING action.

There are two initialization parameters for dealing with block corruption:- DB_BOCK_CHECKSUM (calculates a checksum for each block before it is written to disk, every time)causes 1-2% performance overhead- DB_BLOCK_CHECKING (server process checks block for internal consistency after every DML)causes 1-10% performance overhead

If performance is not a big issue then you should use these!

Normally RMAN checks only for physically corrupt blockswith every backup it takes and every image copy it makes.RMAN doesn not automatically detect logical corruption by default!We have to tell it to do so by using CHECK LOGICAL!

Step 1

Block corruption detected

select last_name, salary from employees;

ORA-01578: ORACLE data block corrupted (file # 5, block # 83)

Step 2

Check alert log

Wed Apr 5 08:17:40 2006Hex dump of (file 5, block 83) in trace file/u01/app/oracle/admin/orcl/udump/orcl_ora_14669.trcCorrupt block relative dba: 0×01400053 (file 5, block 83)Bad header found during buffer readData in bad block:

Step 3

Use RMAN to check a database for both physically and logically corrupt blocks.

134

rman Target SYS/BACKUPS@BACKUPS catalog Rmancat/Rmancat@Rmancat

backup validate check logical database;

RMAN does not physically backup the database with this commandbut it reads all blocks and checks for corruptions.If it finds corrupted blocks it will place the information about the corruption into a view:

Step 4

Check for block corruption

select * from v$backup_corruption;

select * from v$copy_corruption;

select * from v$database_block_corruption;

Step 5

Now we can tell RMAN to recover all the blocks which it has found as being corrupt:

blockrecover corruption list;

Extra Notes-- Deciding Whether to Use RMAN with a Recovery Catalog-- Benefits of Using the Recovery Catalog as the RMAN Repository-- Costs of Using the Recovery Catalog as the RMAN Repository

135

Deciding Whether to Use RMAN with a Recovery Catalog

By default, RMAN connects to the target database in NOCATALOG mode, meaning that it uses the control file in the target database as the sole repository of RMAN metadata. Perhaps the most important decision you make when using RMAN is whether to create a recovery catalog as the RMAN repository for normal production operations. A recovery catalog is a schema created in a separate database that contains metadata obtained from the target control file.

In general, Oracle Corporation advises using a catalog when you manage multiple databases. If you have more than one database to back up, then you can create one systemwide recovery catalog and store metadata for all the databases in this catalog. Hence, you avoid the extra space requirements and memory overhead of maintaining multiple databases, each with a single catalog. You need to take extra precautions when backing up the catalog, however, because if you lose the catalog then you lose the metadata for multiple target databases.

Benefits of Using the Recovery Catalog as the RMAN Repository

When you use a recovery catalog, RMAN can perform a wider variety of automated backup and recovery functions than when you use the control file in the target database as the sole repository of metadata. The following features are available only with a catalog:

You can store metadata about multiple target databases in a single catalog. You can store metadata about multiple incarnations of a single target database

in the catalog. Hence, you can restore backups from any incarnation. Resynchronizing the recovery catalog at intervals less than the

CONTROL_FILE_RECORD_KEEP_TIME setting, you can keep historical metadata.

You can report the target database schema at a noncurrent time. You can store RMAN scripts in the recovery catalog. When restoring and recovering to a time when the database files that exist in

the database are different from the files recorded in the mounted control file, the recovery catalog specifies which files that are needed. Without a catalog, you must first restore a control file backup that lists the correct set of database files.

If the control file is lost and must be restored from backup, and if persistent configurations have been made to automate the tape channel allocation, these configurations are still available when the database is not mounted.

Costs of Using the Recovery Catalog as the RMAN Repository

The main cost of using a catalog is the maintenance overhead required for this additional database. For example, you have to:

136

Find a database other than the target database to store the recovery catalog (otherwise, the benefits of maintaining the catalog are lost), or create a new database

Create enough space on the database for the RMAN metadata (as described in "Configuring the Recovery Catalog Database")

Back up the recovery catalog metadata Upgrade the recovery catalog when necessary

Hence, unless you manage a network of databases, you may choose to avoid the overhead and use the control file as the exclusive repository of metadata. When you use a control file as the RMAN repository, RMAN still functions effectively. If you do not use a catalog, read the section "Managing the RMAN Repository Without a Recovery Catalog". Specifically, make sure you:

Consider the costs of not using a recovery catalog, as described in "Understanding Catalog-Only Command Restrictions"

Develop a strategy for backing up the repository, as described in "Backing Up and Restoring the Control File"

137

http://download-east.oracle.com/docs/cd/B10501_01/server.920/a96566/rcmrepos.htm#436032






Backups and Recovery Scenarios

Documents

Transcript of Backups and Recovery Scenarios