Documente Academic
Documente Profesional
Documente Cultură
-- Control file
--Non-System Tablespace/Datafiles
1
Scenario 30 - Loss of an Online Undo Segment Datafile (Open or Closed
Database) with RMAN with NO Catalog
Scenario 31 - Loss of an Online Undo Segment Datafile (Open or Closed
Database) without RMAN
Scenario 32 - Failure during Open Database - tablespace in backup mode
with RMAN with Catalog
--SYSTEM Tablespace/Datafile
--User Errors
Scenario 22 - Recover from User Errors - dropped table or deleted data with
RMAN with Catalog
Scenario 23 - Recover from User Errors - dropped table or deleted data with
RMAN with NO Catalog
Scenario 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 Miner
Scenario 28 - Recover from User Errors - dropped table or deleted data –
Flashback Database
--Archive Logs
--Duplicate Database
--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:
--Views
Select member from v$logfile;
Select * from v$log;
Select * from v$archived_log;
--DBA Stuff
Add 1 member to group - mirror
alter database ADD logfile member
'E:\ORACLE\ORADATA\BACKUPS\REDO02_2.LOG' to group 2;
Drop member
alter database DROP logfile member
'E:\ORACLE\ORADATA\BACKUPS\REDO02_2.LOG';
keep switching
alter system switch logfile;
-each log file - has series change no's from first to next change...
-based on archive log format
3
Table 7-1 Archived Redo Log Filename Format Parameters
*.log_archive_format='ARC%S_%D.%T'
e.g. ARC00065_1255702348
Ref:
select dbid from v$database;
DBID
----------
1255702348
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_CURRENT The current log is being cleared of a closed thread.
The log can stay in this status if there is some failure
4
Status Description
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.
• 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.
Step1
SELECT * FROM V$LOG;
Step 2
Locate the filename of the damaged member in V$LOGFILE. The status is
INVALID if the file is inaccessible:
Step 3
Drop the damaged member
5
ALTER DATABASE DROP LOGFILE MEMBER
'E:\ORACLE\ORADATA\BACKUPS\REDO01.LOG';
Step 4
Add a new member to the group.
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:
#-------------------------
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.
Step 1
Your first task is to determine whether the damaged group is active or
inactive.
6
Step 2
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.
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.
To clear an inactive, online redo log group that has been archived, use the
following procedure:
7
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:
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:
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:
Back up the database's control file with the ALTER DATABASE statement.
For example, enter
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)
# --------------------------------------------------------------------------------
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".
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.
If the media failure is temporary, then correct the problem so that the
database can reuse the group when required.
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:
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
#-------------------------
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
We can simulate this scenario by deleting all the online redo log files at the
OS level.
ORA-00313
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@Rmancat
RUN
{
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALLOCATE CHANNEL ch1 TYPE Disk;
RESTORE DATABASE;
RECOVER DATABASE;
Sql ‘ALTER DATABASE OPEN’;
}
OR
#-------------------------
Scenario 6 - Recovering After the Loss of All Members of an Online Redo Log
Group Using RMAN with Catalog with CommVault
#-------------------------
Step 1
Full Backup
12
Step 2
Shutdown immediate
Deleting all redo log files
Startup mount
13
14
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…..
This will not restore redo log file, you need to create them.
#-------------------------
Scenario 7 - Recovering After a lost of single control file
#-------------------------
Step 1
Step 2
Startup open;
Check log file;
Step 3
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;
#-------------------------
Scenario 8 - Recovering After a lost of all control files using RMAN with
Catalog
#-------------------------
Step 1
Step 2
2 outcomes:
Prior to performing the next RMAN backup, it will be necessary to reset the
database information in the RMAN catalog.
16
rman Target SYS/BACKUPS@BACKUPS catalog
Rmancat/Rmancat@Rmancat
Backup database plus archivelog;
Backup archivelog all;
ORA-01547
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;
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:
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)
17
point to filename
/u04/oracle/product/10.2.0/db_1/dbs/arch1_6_621627183.dbf
#-------------------------
Scenario 9 - Recovering After a lost of all control files using control file
backup to trace file
#-------------------------
Step 1
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 MOUNT
CREATE CONTROLFILE REUSE DATABASE "BACKUPS" NORESETLOGS
ARCHIVELOG
-- SET STANDBY TO MAXIMIZE PERFORMANCE
MAXLOGFILES 5
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
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 LOGFILE
DATAFILE
'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=BACKUPS
sqlplus /nolog
CONN SYS/Backups AS SYSDBA
Select * from v$instance;
SHUTDOWN IMMEDIATE;
@ 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=BACKUPS
sqlplus /nolog
19
CONN SYS/Backups AS SYSDBA
Shutdown immediate
Deleting all control files
Startup nomount;
20
21
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;
}
C:\Program Files\CommVault\Galaxy\Base\Temp
Successful:
Failure:
ORA-01152
ORA-01110
It could be your control files are out of date with rest of the database !
Recovery
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=BACKUPS
sqlplus /nolog
CONN SYS/Backups AS SYSDBA
Need to know
select dbid from v$database;
DBID
----------
2073096330
Shutdown immediate;
Deleting all control files
Failure:
RMAN-06172 (if u get this check there are no spaces in path !!!)
23
If so, check setting
SHOW ALL;
#-------------------------
Scenario 12 - Recovering After a lost of all control files and spfile using NO
Catalog with CommVault
#-------------------------
First way:
set ORACLE_SID=BACKUPS
sqlplus /nolog
CONN SYS/Backups AS SYSDBA
Shutdown immediate;
Deleting all control files
Startup nomount FORCE;
24
25
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,T
hreadCommandLine= 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 - Production
Copyright (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
28
This is a correct message for Oracle 8. Since Oracle 9 we can use the
controlfile autobackup feature.
Second Way:
set ORACLE_SID=BACKUPS
sqlplus /nolog
CONN SYS/Backups AS SYSDBA
Shutdown immediate;
Deleting all control files
Startup nomount FORCE;
29
30
Script Preview
Takes longer….
Successful:
It’s mounted:
Next recover
31
32
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
File#5
Step 2
set ORACLE_SID=BACKUPS
sqlplus /nolog
CONN 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.
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=BACKUPS
sqlplus /nolog
CONN SYS/Backups AS SYSDBA
ALTER TABLESPACE USERS OFFLINE IMMEDIATE;
SHUTDOWN IMMEDIATE;
#Delete file
STARTUP MOUNT;
EXIT
35
Options
Script generated
Rman Script:
[run {
allocate channel ch1 type 'sbt_tape'
PARMS="BLKSIZE=262144,ENV=(CV_mmsApiVsn=2,CV_channelPar=ch1,T
hreadCommandLine= 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 - Production
Copyright (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: ch1
channel ch1: sid=9 devtype=SBT_TAPE
channel ch1: CommVault Systems for Oracle: Version 7.0.0(BUILD76)
Starting restore at 16-OCT-09
channel ch1: starting datafile backupset restore
channel ch1: specifying datafile(s) to restore from backup set
restoring datafile 00005 to
E:\ORACLE\ORADATA\BACKUPS\NEWMEDIA\USERS01.DBF
channel ch1: restored backup piece ( Appended)
piece handle=1jkrukvc_1_1 tag=TAG20091016T125156 params=NULL
channel ch1: restore complete
Finished restore at 16-OCT-09
Starting recover at 16-OCT-09
starting media recovery
media recovery complete
Finished recover at 16-OCT-09
released channel: ch1
RMAN>
Recovery Manager complete.
]
Still MOUNTED
Restore
Recover – selected
Open 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,T
hreadCommandLine= 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 - Production
Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.
RMAN>
connected to recovery catalog database
RMAN>
connected to target database: BACKUPS (DBID=2073096330)
37
RMAN> 2> 3> 4> 5> 6> 7>
allocated channel: ch1
channel ch1: sid=11 devtype=SBT_TAPE
channel ch1: CommVault Systems for Oracle: Version 7.0.0(BUILD76)
Starting recover at 16-OCT-09
starting media recovery
media recovery complete
Finished recover at 16-OCT-09
sql statement: alter database open
released channel: ch1
RMAN>
Recovery Manager complete.
]
#-------------------------
Scenario 15 - Loss of a SYSTEM tablespace datafile using RMAN with
Catalog
#-------------------------
Step 1
Full Backup
Step 2
set ORACLE_SID=BACKUPS
sqlplus /nolog
CONN SYS/Backups AS SYSDBA
SHUTDOWN IMMEDIATE
EXIT
#Delete file
38
rman Target SYS/BACKUPS@BACKUPS catalog
Rmancat/Rmancat@Rmancat
RUN
{
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=BACKUPS
sqlplus /nolog
CONN SYS/Backups AS SYSDBA
SHUTDOWN IMMEDIATE
#Delete file
STARTUP 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;
Step 3
Take the lost datafile offline so that the database can be opened:
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
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
Step 8
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-01190
ORA-01110
41
When cold backup was done, trace of controlfile was done.
BACKUPS_rebuild_controlfile_v2.sql.
-------------------------------------------------------------------------------------------------------
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "BACKUPS" RESETLOGS
ARCHIVELOG
-- SET STANDBY TO MAXIMIZE PERFORMANCE
MAXLOGFILES 5
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
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 LOGFILE
DATAFILE
'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-01189
ORA-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.
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
set ORACLE_SID=BACKUPS
sqlplus /nolog
CONN SYS/Backups AS SYSDBA
SHUTDOWN IMMEDIATE
EXIT
#Delete file
ORA-01157
ORA-01110
Step 3
If intentional:
If not, offline:
Step 4
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
set ORACLE_SID=BACKUPS
sqlplus /nolog
CONN SYS/Backups AS SYSDBA
SHUTDOWN IMMEDIATE
EXIT
#Delete file
Step 3
Yes:
Take datafile offline and open database
Rebuild datafile and run scripts
No:
INDX datafile should be restored and recovered as with any other datafile
Go to step 4
Step 4
Startup open;
ORA-01157
ORA-01110
44
Step 5
set ORACLE_SID=BACKUPS
sqlplus /nolog
CONN SYS/Backups AS SYSDBA
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
Step 6
Find the file numbers of the files which need to be recovered by querying
V$RECOVER_FILE and V$DATAFILE.
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
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.
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
#-------------------------
Step 1
Full Backup
Step 2
Select *
from dba_data_files;
47
Add datafile
Step 3
set ORACLE_SID=BACKUPS
sqlplus /nolog
CONN SYS/Backups AS SYSDBA
SHUTDOWN IMMEDIATE
EXIT
#Delete file
Step 4
Startup open;
ORA-01157
ORA-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=BACKUPS
sqlplus /nolog
CONN 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.
Full Backup
49
#-------------------------
Scenario 20 - Recover a Lost Datafile with No Backup without RMAN
#-------------------------
set ORACLE_SID=BACKUPS
sqlplus /nolog
CONN 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:
Enter
AUTO
ALTER DATABASE OPEN;
Then successful
50
#-------------------------
Scenario 21 - Recover a Lost Datafile with No Backup with RMAN with
Catalog with CommVault
#-------------------------
Step 1
Step 2
Select *
from dba_data_files;
51
Add datafile
Step 3
set ORACLE_SID=BACKUPS
sqlplus /nolog
CONN SYS/Backups AS SYSDBA
SHUTDOWN IMMEDIATE
EXIT
#Delete file
Step 4
Startup open;
ORA-01157
ORA-01110
Step 5
Find the file numbers of the files which need to be recovered by querying
V$RECOVER_FILE and V$DATAFILE.
Step 6
set ORACLE_SID=BACKUPS
sqlplus /nolog
CONN SYS/Backups AS SYSDBA
SHUTDOWN IMMEDIATE
STARTUP MOUNT;
Step 7
52
53
54
Script Preview
run {
allocate channel ch1 type 'sbt_tape'
PARMS="BLKSIZE=0";
recover tablespace 'USERS'
;
}
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)
/
begin
for i in 1..150
loop
insert into t values (i);
end loop;
end;
commit
/
Step 3
57
select count(*) from t
/
25
Errors
RMAN-03002
RMAN-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
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)
/
begin
for i in 1..150
loop
insert into tt values (i);
end loop;
end;
commit
/
Step 3
59
75
Step 4 (restore of database + archive logs on top)
Errors
RMAN-03002
RMAN-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
#-------------------------
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
You can view the dropped objects in the recycle bin from two dictionary views:
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.
If after drop table orders we already created, the dropped table can be
recovered by new name.
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.
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.
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
Create table
Ziltch
Step 2
Step 3
Restoring table
63
flashback table “BIN$DQ2wRd/iSGyLVbAsOfaqiQ==$0” to before drop;
purge recyclebin;
purge dba_recyclebin;
#-------------------------
Scenario 26 - Recover from User Errors - dropped table or deleted data –
Flashback Table and Query
#-------------------------
Flashback Table operations are not valid for the following object types:
However, if the following DDL commands are issued, the flashback table
command does not work:
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.
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:
Step 2
65
NAME TYPE VALUE
------------------------------------ ----------- -------
undo_management string MANUAL
undo_retention integer 900
undo_tablespace string
undo_management='AUTO'
undo_retention=1200
undo_tablespace='UNDOTBS01'
TABLESPACE_NAME RETENTION
------------------------------ -----------
UNDOTBS01 NOGUARANTEE
MAX(UNDOBLKS)
-------------
77 (Test Database just created, no activity)
66
FORMULA SIZE UNDO TABLESPACE = (Result / 10 minutes (length) / 60
Seconds) * 8192 * 1200
Step 4 – Example 1
RollBack;
67
Insert into Scott.emp
Select * from Scott.emp as of timestamp
(systimestamp - interval '10' minute)
minus
Select * from Scott.emp;
You can use the VERSIONS BETWEEN clauses to retrieve all historical data
related to a row.
Step 5 – Example 2
68
values ('DANIEL',2000);
commit;
commit;
Step 6
select *
from emp
versions between scn minvalue and maxvalue;
NAME SALARY
---------- ----------
DANIEL 3000
DANIEL 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:
69
Step 7
Desc flashback_transaction_query;
select *
from emp
versions between scn minvalue and maxvalue;
select *
from dba_transaction_query
70
where xid = 'xxxxxx';
desc t
INSERT INTO t
SELECT owner, table_name, tablespace_name
FROM all_tables
WHERE owner = 'SYS';
COMMIT;
INSERT INTO t
SELECT owner, table_name, tablespace_name
FROM all_tables
WHERE owner = 'WMSYS';
COMMIT;
INSERT INTO t
SELECT owner, table_name, tablespace_name
FROM all_tables
WHERE owner = 'CTXSYS';
COMMIT;
71
SELECT current_scn, SYSTIMESTAMP
FROM v$database;
-- 5607552 02-MAY-07 12.47.38.187000 PM -07:00
conn / as sysdba
desc t
INSERT INTO t
SELECT owner, table_name, tablespace_name
FROM all_tables
WHERE owner = 'SYS';
COMMIT;
72
SELECT current_scn, SYSTIMESTAMP
FROM v$database;
-- 5607709 02-MAY-07 12.51.46.187000 PM -07:00
INSERT INTO t
SELECT owner, table_name, tablespace_name
FROM all_tables
WHERE owner = 'WMSYS';
COMMIT;
INSERT INTO t
SELECT owner, table_name, tablespace_name
FROM all_tables
WHERE owner = 'CTXSYS';
COMMIT;
conn / as sysdba
73
FLASHBACK TABLE <schema_name.table_name>
TO RESTORE POINT <restore_point>
[<ENABLE | DISABLE> TRIGGERS]
CREATE TABLE t
ENABLE ROW MOVEMENT AS
SELECT owner, table_name, tablespace_name
FROM all_tables
WHERE 1=2;
desc t
INSERT INTO t
SELECT owner, table_name, tablespace_name
FROM all_tables
WHERE owner = 'SYS';
COMMIT;
INSERT INTO t
SELECT owner, table_name, tablespace_name
FROM all_tables
WHERE owner = 'WMSYS';
COMMIT;
INSERT INTO t
SELECT owner, table_name, tablespace_name
FROM all_tables
WHERE owner = 'CTXSYS';
COMMIT;
74
GROUP BY owner;
#-------------------------
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.
#-------------------------
Scenario 28 - Recover from User Errors - dropped table or deleted data –
Flashback Database
#-------------------------
Also
75
GV_$FLASHBACK_DATABASE_LOG V_$FLASHBACK_DATABASE_LOG
Dependent
GV_$FLASHBACK_DATABASE_LOGFILE V_$FLASHBACK_DATABASE_LOGFILE
Objects
GV_$FLASHBACK_DATABASE_STAT V_$FLASHBACK_DATABASE_STAT
Initialization Parameters
Setting the
location of
the
db_recovery_file_dest=/oracle/flash_recovery_area
flashback
recovery
area
Setting the
size of the
flashback db_recovery_file_dest_size=2147483648
recovery
area
Setting the
retention
time for -- 2 days
flashback db_flashback_retention_target=2880
files (in
minutes)
76
SELECT flashback_on, log_mode
FROM v$database;
As SYS As ACKERS
SELECT current_scn
FROM v$database;
SELECT oldest_flashback_scn,
oldest_flashback_time
FROM
gv$flashback_database_log;
COMMIT;
77
COMMIT;
SHUTDOWN immediate;
-- be sure to substitute
your SCN
FLASHBACK DATABASE TO SCN
19513917;
or
FLASHBACK 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');
*/
78
SELECT *
FROM
gv$flashback_database_stat;
shutdown immediate;
SELECT flashback_on,
log_mode
FROM v$database;
host
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):
--Connect as the newly created testuser and create the test table and logging
table
conn testuser/testuser;
79
create table testuser.test (id int, name varchar2(5)) tablespace users;
create table testuser.logging (timestamp date, loginfo varchar2(15))
tablespace users;
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.
Table altered.
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:
80
SQL> create restore point before_test1;
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:
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:
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:
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
81
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:
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
Database altered.
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).
82
3 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.
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:
COUNT(*)
----------
50
TIMESTAMP LOGINFO
--------- ---------------
27-MAY-08 Begin procedure
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:
83
SQL> startup mount;
ORACLE instance started.
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:
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
COUNT(*)
----------
0
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:
Conclusion
84
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
FILE #2
E:\ORACLE\ORADATA\BACKUPS\UNDOTBS01.DBF
85
Step 3
set ORACLE_SID=BACKUPS
sqlplus /nolog
CONN SYS/Backups AS SYSDBA
SHUTDOWN IMMEDIATE
EXIT
#Delete file
Step 4
Startup open;
ORA-01157
ORA-01110
Step 5
Full Backup
#-------------------------
Scenario 30 - Loss of an Online Undo Segment Datafile (Open or Closed
Database) with RMAN with NO Catalog
#-------------------------
Step 1
Full Backup
86
Step 2
FILE #2
E:\ORACLE\ORADATA\BACKUPS\UNDOTBS01.DBF
Step 3
set ORACLE_SID=BACKUPS
sqlplus /nolog
CONN SYS/Backups AS SYSDBA
SHUTDOWN IMMEDIATE
EXIT
#Delete file
Step 4
Startup open;
ORA-01157
ORA-01110
Step 5
87
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
E:\ORACLE\ORADATA\BACKUPS\UNDOTBS01.DBF
Step 3
set ORACLE_SID=BACKUPS
sqlplus /nolog
CONN SYS/Backups AS SYSDBA
SHUTDOWN IMMEDIATE
EXIT
#Delete file
Step 4
Startup open;
ORA-01157
ORA-01110
Step 5
88
Find the file numbers of the files which need to be recovered by querying
V$RECOVER_FILE and V$DATAFILE.
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 DATAFILE
'E:\ORACLE\ORADATA\BACKUPS\UNDOTBS01.DBF';
Step 8
Bring the datafile, then the tablespace online after the file has been
recovered:
89
ALTER DATABASE DATAFILE
'E:\ORACLE\ORADATA\BACKUPS\UNDOTBS01.DBF' ONLINE;
Step 9
Step 10
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
Step 2
90
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:
Step 4
You have forgotten you have placed TABLESPACE users in backup mode,
much later.
Shutdown immediate;
Errors
ORA-01149
ORA-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").
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:
Or
Alternately you may issue commands to take just the tablespace or datafile
out of backup mode:
91
ALTER TABLESPACE USERS 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:
no rows selected
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
92
Backup database plus archivelog;
Backup archivelog all;
#-------------------------
Scenario 33 - Create new logfile groups and drop old groups
#-------------------------
Step 1
Step 2
93
Step 3
ORA-00313
ORA-00312
Step 4
Query the V$LOGFILE view to determine which logfile members are invalid:
SELECT GROUP#,STATUS,MEMBER FROM V$LOGFILE;
Drop groups
94
ALTER DATABASE DROP LOGFILE GROUP 1;
ALTER DATABASE DROP LOGFILE GROUP 2;
ALTER DATABASE DROP LOGFILE GROUP 3;
Switch the current logfile group until none of the original logfile groups (1,3)
are being used.
95
#-------------------------
Scenario 34 - Recover archive log using RMAN with Catalog
#-------------------------
Steps 1
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:
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.
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 2
Where (***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 name
96
FROM v$archived_log
WHERE thread# = 1
AND dest_id = 1
AND sequence# BETWEEN 24 and 28;
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
Say
where
http://download.oracle.com/docs/cd/B19306_01/backup.102/b14194/rcmsynta
008.htm#sthref121
97
rman Target SYS/BACKUPS@BACKUPS catalog
Rmancat/Rmancat@Rmancat
run {
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
Supplementary Information
RESETLOGS_CHANGE# RESETLOGS_TIME
PRIOR_RESETLOGS_CHANGE# PRIOR_RESETLOGS_TIME
1608517
98
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#;
2 1 1 E:\ORACLE\ORADATA\BACKUPS\REDO02.LOG 23
1546511
2 ONLINE E:\ORACLE\ORADATA\BACKUPS\REDO02.LOG
99
DICTIONARY_END END_OF_REDO BACKUP_COUNT
ARCHIVAL_THREAD# ACTIVATION#
214 703959219
F:\ORADATA\RECOVERY_AREA\BACKUPS\ARCHIVELOGS\ARC00023_2073
096330.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
1 (DEST_ID Point 5)
23 (SEQUENCE# Point 4)
--Point 7 – In a disaster situation where all files are lost you can only
recover to the last SCN in the archived redo logs
1608494
To recover
run {
shutdown immediate;
startup mount;
# set until sequence 9923; # alternatively, you can specify log sequence number
restore database;
recover database;
100
}
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.
.
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
101
Use this view to find out to which place archived redo logs are copied:
v$archive_dest
v$archive_dest_status
This view allows to find status and errors for each of the defined
v$archived_log
102
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).
v$log_history
-each log file - has series change no's from first to next change...
-based on archive log format
V$RECOVERY_LOG
103
Select * from V$RECOVERY_LOG
#-------------------------
Scenario 35 - Recover archive log using RMAN with Catalog with CommVault
#-------------------------
Step 1
Step 2
140 701543782
F:\ORADATA\RECOVERY_AREA\BACKUPS\ARCHIVELOGS\ARC00034_20
73096330.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
Step 3 - In a disaster situation where all files are lost you can only
recover to the last SCN in the archived redo logs
104
Step 4 – Restore from CommVault archive logs
105
106
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.
Step 1
Step 2
107
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#
215 703959219
G:\ORADATA\RECOVERY_AREA\BACKUPS\ARCHIVELOGS\ARC00023_2
073096330.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
Step 4
108
list backup of archivelog sequence between 22 and 23;
109
Piece Name: 2uit2mfj_1_1
110
1 23 3404201 17-JAN-08 3424009 18-JAN-08
111
Piece Name: 1fjrr9c1_1_1
112
Piece Name:
G:\ORADATA\RECOVERY_AREA\BACKUPS\RMAN_BACKUPS\ORA_DF69
971060
1_S41_S1
113
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
114
115
Script Preview
run {
allocate channel ch1 type 'sbt_tape'
PARMS="BLKSIZE=0";
restore (archivelog
from logseq 22
until logseq 23 thread = 1 );
}
Done….
116
#-------------------------
Scenario 36 – Duplicate Database using RMAN with Catalog
#-------------------------
Step 1
Full Backup
Step 2
Step 3
Next add the appropriate entries into the tnsnames.ora and listener.ora files in
the $ORACLE_HOME/network/admin directory.
(SID_DESC =
(GLOBAL_DBNAME = DUP)
(ORACLE_HOME = e:\oracle\ora92)
(SID_NAME = DUP)
)
DUP =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = glasbs2)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = DUP)
(INSTANCE_NAME = DUP)
(GLOBAL_NAME =DUP)
)
)
117
# Reload listener
lsnrctl reload
Step 4
Check connectivity
Tnsping DUP
Step 5
initDUP.ora
*.db_create_file_dest ='’e:\oracle\oradata\DUP'
*.DB_FILE_NAME_CONVERT=('E:\oracle\oradata\BACKUPS\','E:\oracle\orada
ta\DUP\')
*.LOG_FILE_NAME_CONVERT=('E:\oracle\oradata\BACKUPS\','E:\oracle\orad
ata\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\co
ntrol02.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\Archivelo
gs OPTIONAL REOPEN=300'
*.log_archive_dest_2='LOCATION=g:\oradata\Recovery_Area\DUP\Archivelo
gs 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
118
*.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
Step 8
Step 9
With the duplicate database started we can now connect to it from RMAN.
Step 10
We can then dupicate the database using one of the following commands:
119
Error
RMAN-06054: media recovery requesting unknown log: thread 1 scn 1912736
run {
ALTER DATABASE OPEN RESETLOGS;
}
Step 11
select DBID,NAME,CREATED,RESETLOGS_TIME,LOG_MODE,
CONTROLFILE_CREATED from v$database
#-------------------------
Scenario 37 – Duplicate Database using RMAN with Catalog with CommVault
#-------------------------
The following procedure describes the prerequisite setup steps for creating a
duplicate database:
Step 1
• Run a full backup (along with the log files) on the original database.
120
Step 2
Step 3
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','D
UP_OF_LOG_PATH/REDO')
Make that all the other parameters in the init<SID>.ora file is same as
that in the original database.
*.DB_FILE_NAME_CONVERT=('E:\oracle\oradata\BACKUPS\','E:\oracle\orad
ata\ABC\')
*.LOG_FILE_NAME_CONVERT=('E:\oracle\oradata\BACKUPS\','E:\oracle\or
adata\ABC\')
121
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\A
BC\Archivelogs OPTIONAL REOPEN=300'
*.log_archive_dest_2='LOCATION=g:\oradata\Recovery_Area\A
BC\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\')
122
Step 4
***********VERY IMPORTANT***************
Create directory structure for ABC
Step 5
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.
(SID_DESC =
(GLOBAL_DBNAME = ABC)
(ORACLE_HOME = e:\oracle\ora92)
(SID_NAME = ABC)
)
ABC =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = glasbs2)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = ABC)
(INSTANCE_NAME = ABC)
(GLOBAL_NAME = ABC)
)
)
123
• Restart the Listener.
lsnrctl reload
Step 7
Check connectivity
Tnsping ABC
Step 8
With the duplicate database started we can now connect to it from RMAN.
124
Create a Duplicate Database on the Same Host with the Instance
Configured
125
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.
126
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:
127
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.
128
more information on setting
the parameters in the initial
file, see Prerequisite Setup
Steps for Creating a Duplicate
Database.
129
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';
set newname for datafile
'E:\ORACLE\ORADATA\BACKUPS\NEWMEDIA\USERS02.DBF' to
'E:\oracle\oradata\ABC\USERS02.DBF';
set newname for datafile
'E:\ORACLE\ORADATA\BACKUPS\NEWMEDIA\USERS03.DBF' to
'E:\oracle\oradata\ABC\USERS03.DBF';
allocate auxiliary channel ch1 type 'sbt_tape'
PARMS="BLKSIZE=262144,ENV=(CV_mmsApiVsn=2,CV_channelPar=ch1,T
hreadCommandLine= 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;
130
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
2932242
131
SELECT * FROM v$log
2927472
282 708088571
F:\ORADATA\RECOVERY_AREA\BACKUPS\ARCHIVELOGS\ARC00056_2073
096330.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.
132
#-------------------------
Scenario 38 – Check and repair block corruption using RMAN with Catalog
#-------------------------
ORA-01578 runtime error because there are one or more corrupt blocks
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
Step 1
Step 2
133
Corrupt block relative dba: 0×01400053 (file 5, block 83)
Bad header found during buffer read
Data in bad block:
Step 3
Use RMAN to check a database for both physically and logically corrupt
blocks.
RMAN does not physically backup the database with this command
but 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
Step 5
Now we can tell RMAN to recover all the blocks which it has found as being
corrupt:
134
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
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.
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.
135
• 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.
The main cost of using a catalog is the maintenance overhead required for this
additional database. For example, you have to:
• 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:
136