Why and When Should I Backup My Database

http://www.orafaq.
com/wiki/Category:Backup_and_Recovery
Why and when should I backup my database?

Backup and recovery is one of the most important aspects of a DBA's job. If you lose your company's
data, you could very well lose your job. Hardware and software can always be replaced, but your data
may be irreplaceable!
Normally one would schedule a hierarchy of daily, weekly and monthly backups, however consult with
your users before deciding on a backup schedule. Backup frequency normally depends on the following
factors:
Rate of data change/ transaction rate
Database availability/ Can you shutdown for cold backups?
Criticality of the data/ Value of the data to the company
Read-only tablespace needs backing up just once right after you make it read-only
If you are running in archivelog mode you can backup parts of a database over an extended cycle
of days
If archive logging is enabled one needs to backup archived log files timeously to prevent
database freezes
Etc.
Carefully plan backup retention periods. Ensure enough backup media (tapes) are available and that old
backups are expired in-time to make media available for new backups. Off-site vaulting is also highly
recommended.
Frequently test your ability to recover and document all possible scenarios. Remember, it's the little things
that will get you. Most failed recoveries are a result of organizational errors and miscommunication.
[edit]What
strategies are available for backing-up an Oracle database?
The following methods are valid for backing-up an Oracle database:
Export/Import - Exports are "logical" database backups in that they extract logical definitions and
data from the database to a file. See the Import/ Export FAQ for more details.
Cold or Off-line Backups - shut the database down and backup up ALL data, log, and control
files.
Hot or On-line Backups - If the database is available and in ARCHIVELOG mode, set the
tablespaces into backup mode and backup their files. Also remember to backup the control files and
archived redo log files.
RMAN Backups - while the database is off-line or on-line, use the "rman" utility to backup the
database.
It is advisable to use more than one of these methods to backup your database. For example, if you
choose to do on-line database backups, also cover yourself by doing database exports. Also test ALL
backup and recovery scenarios carefully. It is better to be safe than sorry.
Regardless of your strategy, also remember to backup all required software libraries, parameter files,
password files, etc. If your database is in ARCHIVELOG mode, you also need to backup archived log
files.
[edit]What
is the difference between online and offline backups?
A hot (or on-line) backup is a backup performed while the database is open and available for use (read
and write activity). Except for Oracle exports, one can only do on-line backups when the database is
ARCHIVELOG mode.
A cold (or off-line) backup is a backup performed while the database is off-line and unavailable to its
users. Cold backups can be taken regardless if the database is in ARCHIVELOG or NOARCHIVELOG
mode.
It is easier to restore from off-line backups as no recovery (from archived logs) would be required to make
the database consistent. Nevertheless, on-line backups are less disruptive and don't require database
downtime.
Point-in-time recovery (regardless if you do on-line or off-line backups) is only available when the
database is in ARCHIVELOG mode.
[edit]What
is the difference between restoring and recovering?
Restoring involves copying backup files from secondary storage (backup media) to disk. This can be done
to replace damaged files or to copy/move a database to a new location.
Recovery is the process of applying redo logs to the database to roll it forward. One can roll-forward until
a specific point-in-time (before the disaster occurred), or roll-forward until the last transaction recorded in
the log files.
SQL> connect SYS as SYSDBA

SQL> RECOVER DATABASE UNTIL TIME '2001-03-06:16:00:00' USING BACKUP
CONTROLFILE;
RMAN> run {
set until time to_date('04-Aug-2004 00:00:00', 'DD-MON-YYYY HH24:MI:SS');
restore database;
recover database;
}
[edit]My
database is down and I cannot restore. What now?
This is probably not the appropriate time to be sarcastic, but, recovery without backups are not supported.
You know that you should have tested your recovery strategy, and that you should always backup a
corrupted database before attempting to restore/recover it.
Nevertheless, Oracle Consulting can sometimes extract data from an offline database using a utility called
DUL (Disk UnLoad - Life is DUL without it!). This utility reads data in the data files and unloads it into
SQL*Loader or export dump files. Hopefully you'll then be able to load the data into a working database.
Note that DUL does not care about rollback segments, corrupted blocks, etc, and can thus not guarantee
that the data is not logically corrupt. It is intended as an absolute last resort and will most likely cost your
company a lot of money!
DUDE (Database Unloading by Data Extraction) is another non-Oracle utility that can be used to extract
data from a dead database. More info about DUDE is available at http://www.ora600.nl/.
[edit]How
does one backup a database using the export utility?
Oracle exports are "logical" database backups (not physical) as they extract data and logical definitions
from the database into a file. Other backup strategies normally back-up the physical data files.
One of the advantages of exports is that one can selectively re-import tables, however one cannot rollforward from an restored export. To completely restore a database from an export file one practically
needs to recreate the entire database.
Always do full system level exports (FULL=YES). Full exports include more information about the
database in the export file than user level exports. For more information about the Oracle export and
import utilities, see the Import/ Export FAQ.
[edit]How
does one put a database into ARCHIVELOG mode?
The main reason for running in archivelog mode is that one can provide 24-hour availability and
guarantee complete data recoverability. It is also necessary to enable ARCHIVELOG mode before one
can start to use on-line database backups.
Issue the following commands to put a database into ARCHIVELOG mode:

SQL>
SQL>
SQL>
SQL>
SQL>
CONNECT sys AS SYSDBA

STARTUP MOUNT EXCLUSIVE;
ALTER DATABASE ARCHIVELOG;
ARCHIVE LOG START;
ALTER DATABASE OPEN;
Alternatively, add the above commands into your database's startup command script, and bounce the
database.
The following parameters needs to be set for databases in ARCHIVELOG mode:
log_archive_start
log_archive_dest_1
log_archive_dest_state_1
log_archive_format
=
=
=
=
TRUE
'LOCATION=/arch_dir_name'
ENABLE
%d_%t_%s.arc
NOTE 1: Remember to take a baseline database backup right after enabling archivelog mode. Without it
one would not be able to recover. Also, implement an archivelog backup to prevent the archive log
directory from filling-up.
NOTE 2:' ARCHIVELOG mode was introduced with Oracle 6, and is essential for database point-in-time
recovery. Archiving can be used in combination with on-line and off-line database backups.
NOTE 3: You may want to set the following INIT.ORA parameters when enabling ARCHIVELOG
mode: log_archive_start=TRUE, log_archive_dest=..., and log_archive_format=...
NOTE 4: You can change the archive log destination of a database on-line with the ARCHIVE LOG
START TO 'directory'; statement. This statement is often used to switch archiving between a set of
directories.
NOTE 5: When running Oracle Real Application Clusters (RAC), you need to shut down all nodes before
changing the database to ARCHIVELOG mode. See the RAC FAQ for more details.
[edit]I've
lost an archived/online REDO LOG file, can I get my DB back?
The following INIT.ORA/SPFILE parameter can be used if your current redologs are corrupted or blown
away. It may also be handy if you do database recovery and one of the archived log files are missing and
cannot be restored.
NOTE: Caution is advised when enabling this parameter as you might end-up losing your entire
database. Please contact Oracle Support before using it.
_allow_resetlogs_corruption = true
This should allow you to open the database. However, after using this parameter your database will be
inconsistent (some committed transactions may be lost or partially applied).
Steps:
Do a "SHUTDOWN NORMAL" of the database
Set the above parameter
Do a "STARTUP MOUNT" and "ALTER DATABASE OPEN RESETLOGS;"
If the database asks for recovery, use an UNTIL CANCEL type recovery and apply all available
archive and on-line redo logs, then issue CANCEL and reissue the "ALTER DATABASE OPEN
RESETLOGS;" command.
Wait a couple of minutes for Oracle to sort itself out
Do a "SHUTDOWN NORMAL"
Remove the above parameter!
Do a database "STARTUP" and check your ALERT.LOG file for errors.
Extract the data and rebuild the entire database
[edit]User
managed backup and recovery
This section deals with user managed, or non-RMAN backups.

[edit]How
does one do off-line database backups?
Shut down the database from sqlplus or server manager. Backup all files to secondary storage (eg.
tapes). Ensure that you backup all data files, all control files and all log files. When completed, restart
your database.
Do the following queries to get a list of all files that needs to be backed up:
select name from sys.v_$datafile;
select member from sys.v_$logfile;
select name from sys.v_$controlfile;

Sometimes Oracle takes forever to shutdown with the "immediate" option. As workaround to this problem,
shutdown using these commands:
alter system checkpoint;
shutdown abort
startup restrict
shutdown immediate
Note that if your database is in ARCHIVELOG mode, one can still use archived log files to roll forward
from an off-line backup. If you cannot take your database down for a cold (off-line) backup at a convenient
time, switch your database into ARCHIVELOG mode and perform hot (on-line) backups.
[edit]How
does one do on-line database backups?
Each tablespace that needs to be backed-up must be switched into backup mode before copying the files
out to secondary storage (tapes). Look at this simple example.
ALTER TABLESPACE xyz BEGIN BACKUP;
! cp xyzFile1 /backupDir/
ALTER TABLESPACE xyz END BACKUP;
It is better to backup tablespace for tablespace than to put all tablespaces in backup mode. Backing them
up separately incurs less overhead. When done, remember to backup your control files. Look at this
example:
ALTER SYSTEM SWITCH LOGFILE;
-- Force log switch to update control file
headers
ALTER DATABASE BACKUP CONTROLFILE TO '/backupDir/control.dbf';
NOTE: Do not run on-line backups during peak processing periods. Oracle will write complete database
blocks instead of the normal deltas to redo log files while in backup mode. This will lead to excessive
database archiving and even database freezes.
[edit]My
database was terminated while in BACKUP MODE, do I need to

recover?
If a database was terminated while one of its tablespaces was in BACKUP MODE (ALTER TABLESPACE
xyz BEGIN BACKUP;), it will tell you that media recovery is required when you try to restart the database.
The DBA is then required to recover the database and apply all archived logs to the database. However,
from Oracle 7.2, one can simply take the individual datafiles out of backup mode and restart the
database.
ALTER DATABASE DATAFILE '/path/filename' END BACKUP;
One can select from V$BACKUP to see which datafiles are in backup mode. This normally saves a
significant amount of database down time. See script end_backup2.sql in the Scripts section of this site.
From Oracle9i onwards, the following command can be used to take all of the datafiles out of hotbackup
mode:
ALTER DATABASE END BACKUP;
This command must be issued when the database is mounted, but not yet opened.
[edit]Does
Oracle write to data files in begin/hot backup mode?
When a tablespace is in backup mode, Oracle will stop updating its file headers, but will continue to write
to the data files.
When in backup mode, Oracle will write complete changed blocks to the redo log files. Normally only
deltas (change vectors) are logged to the redo logs. This is done to enable reconstruction of a block if
only half of it was backed up (split blocks). Because of this, one should notice increased log activity and
archiving during on-line backups.
To solve this problem, simply switch to RMAN backups.
[edit]RMAN
backup and recovery
This section deals with RMAN backups:

[edit]What
is RMAN and how does one use it?
Recovery Manager (or RMAN) is an Oracle provided utility for backing-up, restoring and recovering
Oracle Databases. RMAN ships with the database server and doesn't require a separate installation. The
RMAN executable is located in your ORACLE_HOME/bin directory.
In fact RMAN, is just a Pro*C application that translates commands to a PL/SQL interface. The PL/SQL
calls are statically linked into the Oracle kernel, and does not require the database to be opened (mapped
from the ?/rdbms/admin/recover.bsq file).
RMAN can do off-line and on-line database backups. It cannot, however, write directly to tape, but various
3rd-party tools (like Veritas, Omiback, etc) can integrate with RMAN to handle tape library management.
RMAN can be operated from Oracle Enterprise Manager, or from command line. Here are the command
line arguments:
Argument
Value
Description
----------------------------------------------------------------------------target
quoted-string connect-string for target database
catalog
quoted-string connect-string for recovery catalog
nocatalog
none
if specified, then no recovery catalog
cmdfile
quoted-string name of input command file
log
quoted-string name of output message log file
trace
quoted-string name of output debugging message log file
append
none
if specified, log is opened in append mode
debug
optional-args activate debugging
msgno
none
show RMAN-nnnn prefix for all messages
send
quoted-string send a command to the media manager
pipe
string
building block for pipe names
timeout
integer
number of seconds to wait for pipe input
----------------------------------------------------------------------------Here is an example:
[oracle@localhost oracle]$ rman
Recovery Manager: Release 10.1.0.2.0 - Production
Copyright (c) 1995, 2004, Oracle. All rights reserved.
RMAN> connect target;
connected to target database: ORCL (DBID=1058957020)
RMAN> backup database;
...
[edit]How
does one backup and restore a database using RMAN?
The biggest advantage of RMAN is that it only backup used space in the database. RMAN doesn't put
tablespaces in backup mode, saving on redo generation overhead. RMAN will re-read database blocks
until it gets a consistent image of it. Look at this simple backup example.
rman target sys/*** nocatalog
run {
allocate channel t1 type disk;
backup
format '/app/oracle/backup/%d_t%t_s%s_p%p'
(database);
release channel t1;

}
Example RMAN restore:
rman target sys/*** nocatalog
run {
allocate channel t1 type disk;
# set until time 'Aug 07 2000 :51';
restore tablespace users;
recover tablespace users;
release channel t1;
}
The examples above are extremely simplistic and only useful for illustrating basic concepts. By default
Oracle uses the database controlfiles to store information about backups. Normally one would rather
setup a RMAN catalog database to store RMAN metadata in. Read the Oracle Backup and Recovery
Guide before implementing any RMAN backups.
Note: RMAN cannot write image copies directly to tape. One needs to use a third-party media manager
that integrates with RMAN to backup directly to tape. Alternatively one can backup to disk and then
manually copy the backups to tape.
[edit]How
does one backup and restore archived log files?
One can backup archived log files using RMAN or any operating system backup utility. Remember to
delete files after backing them up to prevent the archive log directory from filling up. If the archive log
directory becomes full, your database will hang! Look at this simple RMAN backup scripts:
RMAN> run {
2> allocate channel dev1 type disk;
3> backup
4>
format '/app/oracle/archback/log_%t_%sp%p'
5>
(archivelog all delete input);
6> release channel dev1;
7> }
The "delete input" clause will delete the archived logs as they are backed-up.
List all archivelog backups for the past 24 hours:
RMAN> LIST BACKUP OF ARCHIVELOG FROM TIME 'sysdate-1';
Here is a restore example:

RMAN> run {
2> allocate channel dev1 type disk;
3> restore (archivelog low logseq 78311 high logseq 78340 thread 1 all);
4> release channel dev1;
5> }
[edit]How
does one create a RMAN recovery catalog?
Start by creating a database schema (usually called rman). Assign an appropriate tablespace to it and
grant it the recovery_catalog_owner role. Look at this example:
sqlplus sys
SQL> create user rman identified by rman;
SQL> alter user rman default tablespace tools temporary tablespace temp;
SQL> alter user rman quota unlimited on tools;
SQL> grant connect, resource, recovery_catalog_owner to rman;
SQL> exit;
Next, log in to rman and create the catalog schema. Prior to Oracle 8i this was done by running
the catrman.sql script.
rman catalog rman/rman
RMAN> create catalog tablespace tools;
RMAN> exit;
You can now continue by registering your databases in the catalog. Look at this example:
rman catalog rman/rman target backdba/backdba
RMAN> register database;
One can also use the "upgrade catalog;" command to upgrade to a new RMAN release, or the "drop
catalog;" command to remove an RMAN catalog. These commands need to be entered twice to confirm
the operation.
[edit]How
does one integrate RMAN with third-party Media Managers?
The following Media Management Software Vendors have integrated their media management software
with RMAN (Oracle Recovery Manager):
Veritas NetBackup - http://www.veritas.com/
EMC Data Manager (EDM) - http://www.emc.com/
HP OMNIBack/ DataProtector - http://www.hp.com/
IBM's Tivoli Storage Manager (formerly ADSM) - http://www.tivoli.com/storage/
EMC Networker - http://www.emc.com/
BrightStor ARCserve Backup - http://www.ca.com/us/data-loss-prevention.aspx
Sterling Software's SAMS:Alexandria (formerly from Spectralogic) - http://www.sterling.com/sams/
SUN's Solstice Backup - http://www.sun.com/software/whitepapers/backup-n-storage/
CommVault Galaxy - http://www.commvault.com/
etc...
The above Media Management Vendors will provide first line technical support (and installation guides)
for their respective products.
A complete list of supported Media Management Vendors can be found
at: http://www.oracle.com/technology/deploy/availability/htdocs/bsp.htm
When allocating channels one can specify Media Management spesific parameters. Here are some
examples:
Netbackup on Solaris:
allocate channel t1 type 'SBT_TAPE'
PARMS='SBT_LIBRARY=/usr/openv/netbackup/bin/libobk.so.1';
Netbackup on Windows:
allocate channel t1 type 'SBT_TAPE' send "NB_ORA_CLIENT=client_machine_name";
Omniback/ DataProtector on HP-UX:
allocate channel t1 type 'SBT_TAPE' PARMS='SBT_LIBRARY=
/opt/omni/lib/libob2oracle8_64bit.sl';
or:
allocate channel 'dev_1' type 'sbt_tape' parms
'ENV=OB2BARTYPE=Oracle8,OB2APPNAME=orcl,OB2BARLIST=machinename_orcl_archlogs)'
;
[edit]How
does one clone/duplicate a database with RMAN?
The first step to clone or duplicate a database with RMAN is to create a new INIT.ORA and password file
(use the orapwd utility) on the machine you need to clone the database to. Review all parameters and
make the required changed. For example, set the DB_NAME parameter to the new database's name.
Secondly, you need to change your environment variables, and do a STARTUP NOMOUNT from sqlplus.
This database is referred to as the AUXILIARY in the script below.
Lastly, write a RMAN script like this to do the cloning, and call it with "rman cmdfile dupdb.rcv":
connect target sys/secure@origdb
connect catalog rman/rman@catdb
connect auxiliary /
run
set
set
set
set
set
{
newname
newname
newname
newname
newname
for
for
for
for
for
datafile
datafile
datafile
datafile
datafile
1
2
3
4
5
to
to
to
to
to
'/ORADATA/u01/system01.dbf';
'/ORADATA/u02/undotbs01.dbf';
'/ORADATA/u03/users01.dbf';
'/ORADATA/u03/indx01.dbf';
'/ORADATA/u02/example01.dbf';
allocate auxiliary channel dupdb1 type disk;

set until sequence 2 thread 1;
duplicate target database to dupdb
logfile
GROUP 1 ('/ORADATA/u02/redo01.log') SIZE 200k REUSE,
GROUP 2 ('/ORADATA/u03/redo02.log') SIZE 200k REUSE;
}
The above script will connect to the "target" (database that will be cloned), the recovery catalog (to get
backup info), and the auxiliary database (new duplicate DB). Previous backups will be restored and the
database recovered to the "set until time" specified in the script.
Notes: the "set newname" commands are only required if your datafile names will different from the target
database.
The newly cloned DB will have its own unique DBID.
[edit]Can
one restore RMAN backups without a CONTROLFILE and

RECOVERY CATALOG?
Details of RMAN backups are stored in the database control files and optionally a Recovery Catalog. If
both these are gone, RMAN cannot restore the database. In such a situation one must extract a control
file (or other files) from the backup pieces written out when the last backup was taken. Let's look at an
example:
Let's take a backup (partial in our case for ilustrative purposes):
$ rman target / nocatalog
Recovery Manager: Release 10.1.0.2.0 - 64bit Production
using target database controlfile instead of recovery catalog
RMAN> backup datafile 1;
Starting backup at 20-AUG-04
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=146 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/oradata/orcl/system01.dbf
channel ORA_DISK_1: starting piece 1 at 20-AUG-04
channel ORA_DISK_1: finished piece 1 at 20-AUG-04
piece handle=
/
flash_recovery_area/ORCL/backupset/2004_08_20/o1_mf_nnndf_TAG20040820T153256_0
lczd9tf_.bkp comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:45
including current controlfile in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 20-AUG-04
channel ORA_DISK_1: finished piece 1 at 20-AUG-04
piece handle=
/
flash_recovery_area/ORCL/backupset/2004_08_20/o1_mf_ncsnf_TAG20040820T153256_0
lczfrx8_.bkp comment=NONE
Finished backup at 20-AUG-04[/code]
Now, let's destroy one of the control files:
SQL> show parameters CONTROL_FILES

NAME
TYPE
VALUE
------------------------------------ ---------------------------------------control_files
string
/oradata/orcl/control01.ctl,
/oradata/orcl/control02.ctl,
/oradata/orcl/control03.ctl
SQL> shutdown abort;
ORACLE instance shut down.
SQL> ! mv /oradata/orcl/control01.ctl /tmp/control01.ctl</pre>
Now, let's see if we can restore it. First we need to start the databaase in NOMOUNT mode:
SQL> startup NOMOUNT
ORACLE instance started.
Total System Global Area
Fixed Size
Variable Size
Database Buffers
Redo Buffers
289406976
1301536
262677472
25165824
262144
bytes
bytes
bytes
bytes
bytes</pre>
Now, from SQL*Plus, run the following PL/SQL block to restore the file:
DECLARE
v_devtype
VARCHAR2(100);
v_done
BOOLEAN;
v_maxPieces NUMBER;
TYPE t_pieceName IS TABLE OF varchar2(255) INDEX BY binary_integer;
v_pieceName t_pieceName;
BEGIN
-- Define the backup pieces... (names from the RMAN Log file)
v_pieceName(1) :=
'/flash_recovery_area/ORCL/backupset/2004_08_20/o1_mf_ncsnf_TAG20040820T153256
_0lczfrx8_.bkp';
v_pieceName(2) :=
'/flash_recovery_area/ORCL/backupset/2004_08_20/o1_mf_nnndf_TAG20040820T153256
_0lczd9tf_.bkp';
v_maxPieces
:= 2;
-- Allocate a channel... (Use type=>null for DISK, type=>'sbt_tape' for

TAPE)
v_devtype := DBMS_BACKUP_RESTORE.deviceAllocate(type=>NULL, ident=>'d1');
-- Restore the first Control File...
DBMS_BACKUP_RESTORE.restoreSetDataFile;
-- CFNAME mist be the exact path and filename of a controlfile taht was
backed-up
DBMS_BACKUP_RESTORE.restoreControlFileTo(cfname=>'/app/oracle/oradata/orcl/con
trol01.ctl');
dbms_output.put_line('Start restoring '||v_maxPieces||' pieces.');
FOR i IN 1..v_maxPieces LOOP
dbms_output.put_line('Restoring from piece '||v_pieceName(i));
DBMS_BACKUP_RESTORE.restoreBackupPiece(handle=>v_pieceName(i),
done=>v_done, params=>null);
exit when v_done;
END LOOP;
-- Deallocate the channel...
DBMS_BACKUP_RESTORE.deviceDeAllocate('d1');
EXCEPTION
WHEN OTHERS THEN
DBMS_BACKUP_RESTORE.deviceDeAllocate;
RAISE;
END;
/
Let's see if the controlfile was restored:
SQL> ! ls -l /oradata/orcl/control01.ctl
-rw-r----1 oracle
dba
3096576 Aug 20 16:45
/oradata/orcl/control01.ctl[/code]
We should now be able to MOUNT the database and continue recovery...
SQL> ! cp /oradata/orcl/control01.ctl /oradata/orcl/control02.ctl
SQL> ! cp /oradata/orcl/control01.ctl /oradata/orcl/control03.ctl
SQL> alter database mount;
SQL> recover database using backup controlfile;

ORA-00279: change 7917452 generated at 08/20/2004 16:40:59 needed for thread 1
ORA-00289: suggestion :
/flash_recovery_area/ORCL/archivelog/2004_08_20/o1_mf_1_671_%u_.arc
ORA-00280: change 7917452 for thread 1 is in sequence #671
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/oradata/orcl/redo02.log
Log applied.
Media recovery complete.
Database altered.
SQL> alter database open resetlogs;
Database altered.
Archivelog mode and datafile recovery (non-SYSTEM

tablespace)
If you are running your database in Archive Log mode, and you loose a datafile (maybe due to user errors
or disk failure), follow these steps:
If the datafile belongs to optional tablespaces like tools, users, etc. and doesn't contain any
meaningful data, you can simply drop the tablespace including contents and recreate your
tablespace.
If the datafile holds key organizational data, you need to recover the data.
If you database was up and running when this took place, do a shutdown abort.
SQL> shutdown abort;
Mount the database in restricted mode.
SQL> startup restrict mount;
Check the list of files for which media recovery will be needed.
SQL> select * from v$recovery_log;
Copy an intact copy of the datafile from secondary storage (backup media).
Copy all the archive log files to the required destination.
Recover the database:
SQL> recover database;
In case of complete recovery:
SQL> alter database open;
In case of a partial recovery:
SQL> alter database open resetlogs;
Take a backup immediately.
Archivelog mode and redolog recovery

There are two situations:
[edit]The
Redo Logfile was current
The redolog file under consideration was being written by LGWR when the crash occured.
shutdown abort;
Copy the intact backup of the redo logfile from the tape
startup;
[edit]The
Redo Logfile was Inactive
The redolog file under consideration was being sitting ideal, while the second set of redolog files were
written.
shutdown abort;
Copy the intact backup of the redo logfile from the tape
startup mount;
Copy the Archive Files to required destination.
recover database until cancel;
alter database open resetlogs;
Take a cold backup.
Backup
Backups are the principle means available to provide protection to a firm's information resources from
loss. It should not be considered an exaggeration to think that reliable backups are the most important
product of any computer operations group.
Also see Recovery.
[edit]Reasons
for doing backups
The objective of all backups is to restore a system to a good known state. There are many reasons why a
backup could be needed:
Recover from accidental file deletions - The most common need for backups is to recover from
user errors and accidents.
Recover from Application Errors - Bad data or processing faults may make it necessary to
restore application data to a known good state.
Restore a Prior State of the System - Changes to the application environment such as applying
patches or operating system upgrades may have a bad impact on a production system. Undoing
such a change may be very tricky if it can be done at all. Performing a full backup prior to the change
is good insurance that upgrade faults can be recovered.
Recover from Hardware Failure - Hardware faults can cause data errors or more likely crash
the system. It is not unusual for interrupted processing to leave an application in an indeterminate
state. Many commercial database management systems include recovery mechanisms to cleanup
the mess.
Recover from Loss of System or Site - Commercial applications and operating environments
may be recoverable from vendor media but application data and customization recovery requires a
sound backup. Media should be stored off-site. If the building is destroyed it is not very helpful if all
the backups were sitting in a rack next to the computer.
Backup planning
Backups should be done whenever there is a logical breakpoint in the business cycle (at the end of a
business day, for example). Business requirements will dictate the time constraints around the backup
window. There is almost never enough time. It is not an uncommon practice to oversimplify backups to
save time, but this is almost always at the expense of recovery time, and recovery time is almost always
critical.
Backup planning is nothing new, but it has grown complicated due to constant adoption to ever-changing
technology. Let us see some backup strategies:
Preparing to recover
The following steps should be followed in the event of a media or system failure. In the event of a disaster
(the physical system or computer room is destroyed), these steps should not be used and theDatabase
Administrator should refer to the Business Continuity manual for the Organization.
Remain calm and do not panic.
Determine the severity of the failure.
Assess the recovery strategies. If necessary, refer to an Oracle Backup and Recovery Manual or
call Oracle World Wide Support for assistance (See the organization's Site Guide for account
information).
If the disk containing the online backup is accessible, use that data to restore the database,
otherwise work with the UNIX or Windows administrators to restore necessary files from tape.
Recover the database.
If an incomplete recovery was necessary, get a cold backup of the database immediately to
protect the company against another failure in the near future.
[edit]Why is Recovery Essential

To improve performance, Oracle keeps many changes in memory, even after they are committed. It may
also write data to the datafiles to free up memory, even though the changes have not been committed. At
the time of a failure, all data in memory is lost. In order to ensure no committed changes are lost, Oracle
records all operations in an online redo logfile. The information in the log file allows Oracle to redo any
operations that may be lost in a failure. Writing to the logfile does not hurt performance, because these
writes are sequential and very fast. Writing to datafiles on the other hand is random and can be very slow
because the disk block to be modified on disk must be located, and the disk head properly positioned for
every write.
To Understand Recovery more clearly, we need to Understand two "Buzz Words", Roll Forward and
Rollback.
[edit]Roll forward
During the roll forward phase, Oracle replays transactions in the online redo log beginning with the
checkpoint position. The checkpoint position in the place in the redo log where changes associated with
previous redo entries had been saved to the datafiles before the failure (Each data file, in its header, has
a checkpoint structure the contents gets incremented every time LGWR issues a checkpoint to the
DBWR. The checkpoint structure has two structures checkpoint counter and SCN). As Oracle replays the
redo operations, it applies both committed and uncommitted changes to the datafiles. At the conclusion of
the roll forward phase, the data files contain all committed changes, as well as new uncommitted changes
(applied during roll forward) and old uncommitted changes (saved to the datafiles to free up space in
buffer cache prior to the failure). Some questions which arises here are:
Committed changes - Due to the way DBWR writes it is possible that, data changed and
committed in the Database Block Buffers, make entry in the Online RedoLog files, but may not
necessarily be written to the Database Files by DBWR.
Uncommitted Changes - DBWR may write uncommitted changes to the Database File
(During High Transaction Activities), to make room in the Database Block Buffers, for new
transactions.
[edit]Rollback
During the rollback phase, Oracle searches out changes associated with dead transactions that had not
committed before the failure occurred. It then uses transaction tables in rollback segment to rollback the
change to its previous value. At the completion of this phase, the data returns to a transactionally
consistent state. Oracle can be open during the rollback phase. Any new transaction that tries to modify a
row locked by a dead transaction will need to rollback the transaction blocking its path to release the lock.
When the database is opened a start SCN is recorded in the control file for every data file associated in
the database and a stop SCN is set to Infinity.
During normal database operation's, The SCN and the checkpoint counter, information in the data file
header is incremented every time a checkpoint is done.
When the database is shutdown with the normal or immediate option, an end SCN is recorded in the data
file header, This information is also recorded in the control files, i.e. end SCN of the datafile is equal to the
stop SCN of the control file.
When database is opened the next time, Oracle makes two checks:
If end SCN in the data file header matches its corresponding stop SCN in the control file.
If checkpoint in the data file header matches its corresponding checkpoint counter in the control
file.
Let us say you shut down the database in ABORT mode:
checkpoint is not performed and the STOP SCN in the control file is left at infinity (the same state
when you started or opened your data files).
For example end SCN in the datafile header is "1000" and stop SCN in the control file is "Infinity"
In this case Oracle performs crash recovery and as a part of crash, Oracle reads the on-line redo log files
and applies the changes to the database as a part of the roll forward and reads the rollback segment's
transaction table to perform transaction recovery (roll backward).
You can often use the table V$RECOVER_FILE to determine which files to recover. This table lists all files
that need to be recovered, and explains why they need to be recovered.NoteThe table is not useful if the
control file currently in use is a restored backup or a new control file created since the media failure
occurred. A restored or re-created control file does not contain the information Oracle needs to fill
V$RECOVER_FILE accurately.
The following query displays the file ID numbers of datafiles that require recovery:
SELECT file#, online, error
FROM v$recover_file;
Backup Plan
[edit]General
Backup and Recovery Operations
The ability to maintain a consistent set of data is probably the most important part of a Database
Administrator's job. In the event of a system failure, the need for data recovery becomes a top priority.
Without a backup procedure in place, the ability to restore data to a consistent state is severely hindered
or even impossible. The purpose of this discussion is to outline the backup and recovery procedures to be
used by an Organization with regards to the Oracle databases that are directly supported by Technical
Services and all related operating system files. Below are detailed instructions on how the backups
should be performed to achieve a variety of successful recovery scenarios.
[edit]General
assumptions
Oracle DBAs Will be fully responsible for the following:
Defining backup times in the backup cycle
Maintaining any scripts required to perform database backups and restores
In the event of needed recovery operations, the Database Administrators will work closely
with the NT and UNIX administrators to restore the appropriate datafiles and executables to the
appropriate locations on the desired systems
UNIX Administrator Will be fully responsible for the following:
Any configurations regarding enterprise backup software and hardware on the UNIX
backup server
Maintaining the backup schedules for the UNIX O/S and related files
Windows Administrator Will be fully responsible for the following:
Any configurations regarding enterprise backup software and hardware on the NT backup
server
Maintaining the backup schedules for the NT O/S and related files
UNIX/Windows operators Will be fully responsible for the following:
Arranging the transportation of tape media to and from offsite storage facilities, adhering
to the specified retention policies herein.

The following rules apply globally:
When referring to backup schedules and retention policies, this document assumes these
actions are performed against both the database files and any related executables or scripts
necessary to restore the database from media failure. These include the following:
The entire $ORACLE_BASE directory structure.
The entire /home directory structure
/etc/oratab
/usr/lbin files: oraenv, dbhome, coraenv
All Oracle database related files specified in DBA backup scripts

The backup/recovery procedures listed herein are based upon Organizations current
uptime requirements of 6x24

[edit]Backup
schedules
Below is an illustration of a typical two week backup cycle using the backup schedules noted above. This
backup cycle ensures that in the event of media failure the worst case scenario would be to lose 24 hours
worth of data.
RMAN Online Backups

This articles describes how to do on-line backups with RMAN.
Contents
[hide]
1 Ensure the database is in ARCHIVELOG MODE

2 Ensure the database is running
3 Use RMAN to backup
4 Also see
[edit]Ensure
the database is in ARCHIVELOG MODE
RMAN can only take online backups if the database is in ARCHIVELOG mode.
SQL> select LOG_MODE from v$database;

LOG_MODE
-----------ARCHIVELOG
1 row selected.
[edit]Ensure
the database is running
Ensure your database is up and running before starting the on-line backup:
SQL> startup;
Total System Global Area
Fixed Size
Variable Size
209715200 bytes
1289748 bytes
138412524 bytes
Database Buffers
Redo Buffers
Database mounted.
Database opened.
SQL> exit;
[edit]Use
67108864 bytes
2904064 bytes
RMAN to backup
Now, let's use RMAN to backup the database:
$ rman target /
Recovery Manager: Release 10.2.0.1.0 - Production on Wed May 30 20:32:56 2007
connected to target database: O10GR2 (DBID=1094333359)
Starting backup at 30-MAY-07
using target database control file instead of recovery catalog
input datafile fno=00001
name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/system01.dbf
name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/sysaux01.dbf
name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/example01.dbf
name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/users01.dbf
name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/undotbs01.dbf
channel ORA_DISK_1: starting piece 1 at 30-MAY-07
channel ORA_DISK_1: finished piece 1 at 30-MAY-07
piece
handle=/app/oracle/product/10.2.0/db_1/flash_recovery_area/O10GR2/backupset/20
07_05_30/o1_mf_nnndf_TAG20070530T203304_35vjv1k4_.bkp tag=TAG20070530T203304
comment=NONE
including current control file in backupset

piece
07_05_30/o1_mf_ncsnf_TAG20070530T203304_35vjxrl5_.bkp tag=TAG20070530T203304
comment=NONE
Finished backup at 30-MAY-07
RMAN Offline Backups

This articles describes how to do off-line backups with RMAN. RMAN can be used for offline backups
regardless if the database is in ARCHIVELOG or NOARCHIVELOG mode.
SQL> select LOG_MODE from v$database;

LOG_MODE
-----------NOARCHIVELOG
1 row selected.
[edit]Ensure
the database is in MOUNT mode
Shutdown the database and start the instance in mount mode:
SQL> shutdown immediate;

Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
Total System Global Area 209715200
Fixed Size
1289748
Variable Size
138412524
Database Buffers
67108864
Redo Buffers
2904064
Database mounted.
SQL> exit
bytes
bytes
bytes
bytes
bytes
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 Production
With the Partitioning, Oracle Label Security, OLAP and Data Mining options
[edit]Use
RMAN to backup
Now, let's use RMAN to backup the database:
$ rman target /
Recovery Manager: Release 10.2.0.1.0 - Production on Wed May 30 20:23:56 2007
connected to target database: O10GR2 (DBID=1094333359, not open)
Starting backup at 30-MAY-07
name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/system01.dbf
name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/sysaux01.dbf
name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/example01.dbf
name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/users01.dbf
name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/undotbs01.dbf
piece
07_05_30/o1_mf_nnndf_TAG20070530T202407_35vjb7cs_.bkp tag=TAG20070530T202407
comment=NONE
including current control file in backupset

piece
07_05_30/o1_mf_ncsnf_TAG20070530T202407_35vjdny9_.bkp tag=TAG20070530T202407
comment=NONE
Finished backup at 30-MAY-07
RMAN Restores
RMAN can be used to restore Oracle databases.
[edit]Point
in time restores
Using the SET UNTIL TIME command to prevent RMAN from restoring a too-recent version of the
controlfile. For example:
run {
2> set until time 'sysdate-1/24' ;
3> allocate channel d1 type disk;
4> restore controlfile;}
User Managed Online Backups

If your business requires you to operate 24 Hours a day, 7 days a week, you should take online or hot
backups. To use hot backups you should operate the database in ARCHIVELOG mode. As my day to day
activities (for all my 7 X 24 systems), I schedule my Hot backups to fire automatically every day. The
duration (interval) for the hot backups are picked up based on the low transaction (DML activities) interval
for the system under consideration. Hot backups are nothing but putting your tablespaces in backup
mode and backing up your online datafiles associated with your tablespaces.
[edit]Steps
for Hot Backup's
Check to see if your database is in archive log mode, by issuing
SQL> archive log list;
If "not", put your database in archive log by following the sequence below, (assuming your
database is up and running)
SQL> alter database close;

SQLPLUS>alter database archivelog;
SQL>alter database open;
Obtain the oldest online log sequence number by issuing
SQL> archive log list;

Database log mode ARCHIVELOG
Automatic archival ENABLED
Archive destination
Oldest online log sequence
Next log sequence to archive
Current log sequence
You need to keep all archived files starting from the sequence number specified in "Oldest online
log sequence". Though recovery will start from "Current log sequence" (SCN where backup has
started).
Make a list of all tablespaces, and associated databafiles in your database
SQL> select tablespace_name,file_name from dba_data_files;
Set the tablespaces you want to backup in hot backup mode
SQL> ALTER tablespace
BEGIN BACKUP;
Backup the datafiles associated with the tablespaces, using OS command like "cp" or "tar".
Set the tablespace back in normal mode
SQL> ALTER TABLESPACE
END BACKUP;
Repeat steps for all the tablespaces.
Force a log switch, so that Oracle will create an archived log file
SQL> ALTER SYSTEM SWITCH LOGFILE;
Backup control file
SQL> ALTER DATABASE BACKUP CONTROLFILE TO filespec;
Copy the backup controlfile created to an external device.
Copy the archived log files, starting with the required sequence number to external storage.
[edit]Some
points worth remembering
You need to backup all the archived log files, these files are very important to do recovery.
It is advisable to backup all your tablespaces (except read-only tablespaces), else complete
recovery is not possible.
Backup of online redo log files are not required, as the online log file has the end of backup
marker and would cause corruption if used in recovery.
It is Preferable to start the hot backups at low activity time.
When hot backups are in progress you "cannot" shutdown the database in NORMAL or
IMMEDIATE mode (and it is also not desirable to ABORT).
[edit]What
happens during Hot Backup's
When alter tablespace begin backup is issued, the datafiles which belongs to the tablespaces are
flagged as hot-backup-in-progress.
The command would checkpoint all data files that are in the hot backup mode. I.e DBWR is asked
to write dirty database block buffers to files, and LGWR or CKPT will update the file headers with the
current SCN number.
An interesting point to pay attention to is the concept of "split blocks". For example let us say that
the Oracle block size chosen is (DB_BLOCK_SIZE), by you is 8K and the OS (operating systems)
block size is 2K. OS always copies files as OS Blocks (not Oracle block size). When OS is copying
the first 4K of the datafile (block), there are chances that the a block (database block buffers are
Oracle block size 8K in this case) may be updated in the buffers and may be written to the datafile by
DBWR (basically overlaying the original 8K block in the datafile). Now when OS is copying the
second 4K of the datafile (block), the two portions of the blocks are "not" consistent. To avoid this
blunder this condition, Oracle tracks the blocks which are written to the files by DBWR. If a block
belonging to a datafile stays in the database block buffers for a long time, then the block is only
logged once (in the online redolog files). But if DBWR flushes the database block buffer to the disk
and read it once again from the datafiles, there is a possibility that it may be got into the buffers for
Updates. In these situation the before image copy of the block is logged into the online redo log files.
Logging the before image of a data block to the redo log files before the first change, helps
Oracle in reconstructing a fractured block (two portions of block not being consistent, because of
variation between OS and Oracle block size). The undocumented parameter
_LOG_BLOCKS_DURING_BACKUP which by default is "TRUE" will make sure that the logging of
before image happens.
Due to the conditions discussed above excessive REDO LOG INFORMATION is generated
during HOT BACKUPS.

I have put together a Shell Script (UNIX), to automate your "Hot Backups". Please test the script
throughly before implementing this in you Production Environment (Unix Flavors)
#! /bin/ksh
# The script can be tailored to meet your Environment
# Plug in appropriate values between the "<>" to meet your environment
# The following values needs to be replaced
# <ORACLE_SID>
# <ORACLE_HOME>
# <COLD_BACKUP_DIRECTORY>
# <email_address>
# <username>
# <password>
trap
2 3
# Set up environmental variables - Oracle specific

#
export ORACLE_SID=<ORACLE_SID>
export ORACLE_HOME=<ORACLE_HOME>
export PATH=$PATH:/$ORACLE_HOME/bin
# Set up variables to hold directory information

#
HOT=<HOT_BACKUP_DIRECTORY>
LOG=<BACKGROUND_DUMP_DEST>/alert_${ORACLE_SID}.log
# Make sure that the Lock File does not exists this confirms that
# the previous cron job has finished its activity of cold backup
#
if [ -f ${HOT}/hotbackup.lock ]; then
mail <email_address> <<-EOF
ERROR - HOT BACKUP For "${ORACLE_SID}" Has Failed
Previous Hot Backup was not completely Successful !
EOF
exit 1
else
touch ${HOT}/hotbackup.lock
fi
# Make sure that the Database Is up and running
# If not inform the concerned person
#
database_up=`ps -ef | grep pmon_${ORACLE_SID} | grep -v grep | wc -l`
if [ $database_up -eq 0 ]
then
ERROR - COLD BACKUP For "${ORACLE_SID}" Has Failed
Database Should be up to take a trace of the data files - Please
Investigate!
EOF
exit 1
fi
# Make sure that the Database Is running in archive log mode
#
sqlplus /nolog <<-EOF
connect / as sysdba
spool ${HOT}/archive_mode.lst
archive log list
spool off
EXIT
EOF
archive_mode=`grep -i "No Archive Mode*" ${HOT}/archive_mode.lst|grep -v grep|
wc -l`
if [ $archive_mode -eq 1 ]
then
mail <<email_address> <<-EOF

Database Is Not Running in Archive Log Mode as Desired
during Hot Backup's - Please put the database in Archive Log Mode and
restart!
EOF
exit 1
fi
# Find the count of 'alter tablespace .* begin backup' and
# 'alter tablespace .* end backup' in your alert logs
# if both are equal this signifies the previous hot backup is successful
#
if [ -f $LOG ] ; then
Bgn_Bkp=egrep -ci 'âlter tablespace .* begin backup' $LOG
End_Bkp=egrep -ci 'âlter tablespace .* end backup' $LOG
Diff_Bkp=expr $Bgn_Bkp - $End_Bkp
else
Could not locate Alert Log - Please Investigate !
EOF
exit 1
fi
# Logon to sqlplus - preferably as a DBA
# the sql script, generates a files called ora_HOT_backup.sql
# The file contains all the commands to perform hot backup's
# 1. Backup control file before starting hot backup.
# 2. Put first tablespace online.
# 3. Backup the datafile associated with the tablespaces and compress them (to
save space).
# 4. Bring the first tablespace online.
# 5. Repeat steps 2 through 5 till all tablespaces are backed up
#
sqlplus <<username>/<password> <<-EOF
column tablespace_name noprint
column seqn noprint
set pagesize 0
set linesize 132
set feedback off
set sqlprompt ""
Whenever SQLERROR exit FAILURE
select chr(1) tablespace_name, -9999 seqn,
'alter system switch logfile;'
from dual
UNION
select chr(1) tablespace_name, -9998 seqn,

'alter database backup controlfile to ||
'${HOT}/controlfile_${ORACLE_SID}.HOT.full.before reuse;'
from dual
UNION
select tablespace_name, 0,
'alter tablespace '||tablespace_name||' begin backup;'
from sys.dba_tablespaces
where status = 'ONLINE'
UNION
select tablespace_name, file_id,
'!compress < '||file_name||'> ${HOT}/' ||
substr(file_name,instr(file_name,'/',-1) + 1) || '.Z'
from sys.dba_data_files
where status = 'AVAILABLE'
UNION
select tablespace_name, 9999,
'alter tablespace '||tablespace_name||' end backup;'
from sys.dba_tablespaces
where status = 'ONLINE'
UNION
select chr(255) tablespace_name, 9998 seqn,
'alter database backup controlfile to ||
'${HOT}/controlfile_${ORACLE_SID}.HOT.full.after reuse;'
from dual
UNION
select chr(255) tablespace_name, 9999 seqn,
'alter system switch logfile;'
from dual
ORDER
BY 1, 2
spool ora_HOT_backup.sql
/
spool off
start ora_HOT_backup.sql
exit
EOF
# Find the count of 'alter tablespace .* begin backup' and
# 'alter tablespace .* end backup' in your alert logs
# if both are equal this signifies the previous hot backup is successful
# Else mail the concerned person associated with the backup's.
#
Bgn_Bkp=egrep -ci 'âlter tablespace .* begin backup' $LOG
End_Bkp=egrep -ci 'âlter tablespace .* end backup' $LOG
if [ $Bgn_Bkp != expr $End_Bkp + $Diff_Bkp ] ; then
ERROR : HOT BACKUP For "${ORACLE_SID}" Has Failed

Number of "Begin Backup" statenents does not equal "End Backup"
Please Investigate Immediately !
EOF
exit 1
fi
User Managed Offline Backups

Cold backup is a process of copying the physical files (database files, redolog files and control files) of
your database to an secondary storage media (may be a tape, CD, or different disk designated to hold
cold backup files).
In my normal practice, I like to schedule an cold backup every Sunday midnight. This again depends on
the transaction load on the database, whether customer agree for the operation, etc. The pre-requisite for
the cold backup is that the database should be brought down. This may raise a question whether a 7 X 24
database can be a target. Hot Backups are always possible for such scenarios, but I would always put in
my PDD (project definition documentation) the risks of not having a cold backups at least once in a while.
Finally it is the duty of the DBA to convince the customer. The series of steps are:
To perform a cold backup first you need to shut down the database with the normal option. If you
perform an abort or immediate shutdown you should restart the database in restrict mode and
shutdown again with the normal option.
Then you use the OS backup utility (cp, tar, cpio, or copy) to copy all the physical files associated
with the database to a secondary device. It is also advisable to backup your initialization files and
archive files.
While taking a off-line backup or online backup, since the blocks (physical files are made of blocks), are
physically copied to the secondary media, there is a possibility that if a block is corrupted in the physical
files, it gets propagated (copied) to the secondary media, causing difficulty in recovering. t is advised to
do DB Verify and other known checks to make sure that the physical files have no problems.
Here is a Shell Script (UNIX) to automate your "Cold Backups". Please test the script throughly
before implementing this in you Production Environment (Unix/Linux Flavors)
#! /bin/ksh
# <ORACLE_SID>
# <ORACLE_HOME>
# <COLD_BACKUP_DIRECTORY>
# <email_address>
# <username>
# <password>
#
trap 2 3
#
#
#
# Set up variables to hold directory information
#
COLD=<COLD_BACKUP_DIRECTORY>
#
#
if [ -f ${COLD}/coldbackup.lock ]; then
mail <email_address> <<EOF
Previous Cold Backup is not completed !
EOF
exit 1
else
touch ${COLD}/coldbackup.lock
fi
#
# Make sure that the Database Is up and running
#
then
Database Should be up to take a trace of the data files - Please Investigate!
EOF
exit 1
fi
sqlplus <username>/<password> < column tablespace_name noprint
column seqn noprint
set pagesize 0
set linesize 132
set feedback off
set sqlprompt ""
Whenever SQLERROR exit FAILURE
SELECT 'compress < '||file_name||'> ${COLD}/' ||
substr(file_name,instr(file_name,'/',-1) + 1) || '.Z'
FROM sys.dba_data_files
UNION
SELECT 'compress < '||member||'> ${COLD}/' ||
substr(member,instr(member,'/',-1) + 1) || '.Z'
from sys.v$logfile
UNION
SELECT
'compress < '||name||'> ${COLD}/' ||
substr(name,instr(name,'/',-1) + 1) || '.Z'
FROM sys.v$controlfile
spool ora_COLD_backup.sh
/
spool off
exit
EOF
#
# Make sure that the Database Is Down Before you initiate the Cold Backup
# If not bring down the database
# If not successful inform the concerned Person
if [ $ora_users_num -ne 0 ]
then
sqlplus /nolog <<END
connect / as sysdba
shutdown
exit
END
fi
#
# Double Check if the Database is brugh down before you start cold backup
# If not inform the concerned person.
#
if [ $database_up -ne 0 ]
then

Database could be brough down - Please Investigate !
EOF
exit 1
fi
chmod +x ora_COLD_backup.sh
./ora_COLD_backup.sh
rm ${COLD}/coldbackup.lock
Logical Backups/Exports
Export and Import are used primarily for the following tasks:
data archival
upgrading to new releases of Oracle
backing up Oracle databases
moving data between Oracle databases
Export and Import allow you to accomplish the following tasks:
store Oracle data in operating system files independent of any database.
store definitions of database objects (such as tables, clusters, and indexes) with or without the
data.
store inactive or temporary data.
back up only tables whose data has changed since the last export, using either an incremental or
a cumulative export.
restore tables that were accidentally dropped, provided they were exported recently.
restore a database by importing from incremental or cumulative exports.
selectively back up parts of your database in a way that requires less storage space than a
system backup.
move data from an older to a newer version of Oracle.
move data between Oracle databases.
move data between different hardware and operating- system environments.
move data from one owner to another.
move data from one tablespace or schema to another.
save space or reduce fragmentation in your database.
The basic concept behind Export is to extract the object definitions and table data from an Oracle
database and store them in Oracle-binary format. Object definitions include DDL (Dynamic Definition
Language) to create the database objects such as tablespaces, tables, indexes, sequences, users .etc.
The resulting Oracle-binary file can be stored on disk or any other auxiliary storage devices. Since the
resulting export file is Binary, it cannot be read by any other devices except Oracles Import utility. Export
writes export files using the character set specified for the user session; for example, 7-bit ASCII or IBM
Code Page 500 (EBCDIC). You can access key words used for exports by typing
exp HELP=y
To use Export utility CATEXP.SQL or CATALOG.SQL (which in turn call CATEXP.SQL) must be run after
the database has been created. CATEXP.SQL has to be run only once when the database is created. In
case CATEXP.SQL was not called by CATALOG.SQL (due to CATALOG.SQL not finding the file
CATEXP.SQL where it needs), you can run CATEXP.SQL as user SYS. Be careful not to run
CATALOG.SQL once again as it might destroy your data dictionaries.
To use export you must have CREATE SESSION privilege on an Oracle database. Once you have
CREATE SESSION privilege you can export objects belonging to your schema. To export objects owned
by another user, you must have the EXP_FULL_DATABASE privilege. DBA role will be granted this
privilege.
I usually prefer to use parameter file as directive to exports, where in all the directives are written in a flat
file and export utility reads directives from the parameter file. Using .par extension for your parameter file
is preferable. Parameter files are noting but text files, so use a text editor (vi, edit, ne.etc.) to create the
file. Let us look at a sample parameter file let us say exp.par, you can also name the file junk.par or
junk.jk, no restrictions:
FILE=exp020999.dmp
LOG=exp020999.log
FULL=Y
COMPRESS=Y
After writing the parameter files invoke the export utility

exp username/password parfile=exp.par
The values in the parameter files can be as follows:
BUFFER - The parameter BUFFER determines the maximum number of rows in an array fetched
by Export.
Buffer_size = rows_in_array * maximum_row_size
If a table having a LONG datatype is Exported , or if BUFFER is specified as zero, only one row at a
time is fetched.
COMPRESS - Specifies how Export will manage the initial extent for the table data. This
parameter is helpful during database re-organization. Export the objects (especially tables and
indexes) with COMPRESS=Y. If your table was spawning 20 Extents of 1M each (which is not
desirable, taking into account performance), if you export the table with COMPRESS=Y, the DDL
generated will have initial of 20M. Later on when importing the extents will be coalesced. Sometime it
is found desirable to export with COMPRESS=N, in situations where you do not have contiguous
space on your disk (tablespace), and you do not want your imports to bomb.
CONSISTENT - If massive updates/rollbacks are taking place when you have kicked off the
exports, then the exports will not be consistent under normal conditions. If you set CONSISTENT=Y
then a rollback segment is designated to backout the effect of any uncommitted transactions. I.e. a
value changed to 100 when you have kicked off the exports and before the exports finishes, the
changes being undone. The negative effect are exports being slower cause they have to check the
consistency by cross referring the rollback segments.
CONSTRAINTS - A flag to indicate whether to export table constraints.
DIRECT - Specifying DIRECT=Y causes export to do Direct Path Exports, bypassing the
evaluation layer.
FEEDBACK - Specify that Export should display a progress meter in the for of a dot for x number
of rows exported. For example setting FEEDBACK=10, would display a dot each time 10 rows has
been exported. This is done for each table exported.
FILE - The name of the export file.
FULL - Specifies whether Export should export the entire database or not. This includes all users,
there schemas, data dictionaries.
GRANTS - Specifies whether grants should be exported or not.
INCTYPE - Specifies the type of incremental export. Options are COMPLETE, CUMULATIVE,
and INCREMENTAL.
INDEXES - Specifies whether indexes should be exported or not.
LOG - Specifies a file name to receive information and error messages.
OWNER - Specifies a list of usernames whose objects will be exported.
RECORD - A flag to indicate whether to record an incremental or cumulative export in the

database.
RECORDLENGTH- Specifies the length, in bytes, of the file record. The RECORDLENGTH
parameter is necessary when you must transfer the export file to another operating system that uses
a different default value.
ROWS - Specifies whether the rows of table data should be exported or not.
STATISTICS - Specifies the type of database optimizer statistics to generate when the exported
data is imported later. Options are ESTIMATE, COMPUTE and NONE
TABLES - Specifies the list of tables to export.
USERID - Specifies the username/password of the user initiating the export
Some Tips While Exporting
If transactions continue to access sequence numbers during an export, sequence numbers can
be skipped. Sequence numbers can be skipped only when cached sequence numbers are in use (for
eg. Setting SEQUENCE_CACHED_ENTRIES=10 in you init.ora file). Let us assume a sequence
vtx_seq accessed by you application, and the parameter SEQUENCE_CACHED_ENTRIES is set to
10 in you init.ora file. Now 1-10 sequence numbers are cached in the memory. At this point if you
export, then the exported next sequence number for the sequence vtx_seq is 11. So 1-10 sequence
numbers cached but unused are lost.
If a table is named emp#, and if you parameter file contains the line
TABLES=(emp#, dept, invoice)

Then the line succeeding emp# i.e. dept, invoice is treated as a comment. To get around with this
condition enclose the table name having # in quotation marks
TABLES=("emp#", dept, invoice)
The maximum file size your parfile is limited to 8K on versions below 8i. So listing the tables one
per line will go over 8K fairly quickly. 8i removes this restriction. To get around this condition try to list
all table names on a single line.
Exports can be done in two methods:
Conventional - In conventional path export uses SQL statement "SELECT * FROM TABLE" to
extract data from database tables. Data is then read from disk into a buffer (private buffer or buffer
cache) and rows are transferred into evaluation buffer, The data after passing expression evaluation
(equivalent Insert statement generated and validated), is transferred to the Export Client which then
writes the data into the export file. Some interesting points about conventional exports are:
Conventional path export only exports in the user session character set. I.e. any settings
done for a session using "ALTER SESSION SET NLS_CHARACTERSET=US7ASCII".
If a conventional export was done on Oracle version 7.1 onwards, the format of the
export file was changed to include stored procedures, functions, and packages that have
comments embedded in them. As a result if you want to import a dump file (7.1 onwards) to a
Oracle database lower than 7.1 version a patch has to be applied. All other objects (except
stored procedures, functions, and packages) can be imported without a patch.
Direct - In direct path export the data is read directly bypassing the evaluation buffer. It also
optimizes the use of SELECT * FROM TABLE statement. It is used in conjunction with the database
in direct read mode, which makes use of private buffers instead of public buffers and hence less
resources are consumed and performance is improved. interesting points about direct exports are:
Direct path Export is available after Oracle version 7.3.
The Export Parameter BUFFER, used to specify the size of the fetch array, applies only
to conventional exports and has "no" effect on direct path exports.
The Export parameter RECORDLENGTH can be used to specify the size of the Export
I/O Buffer.
If you have done a Direct path export of 7.3 release database, and want to build a 7.2
release database using this export, backward compatibility is not possible in Direct path Export.
Instead use conventional exports.
Direct path export only exports in the database character set. I.e. any settings done for a
session has no effect and must be set the same as database character set, else export will
terminate with a warning. Check your parameter NLS_CHARACTERSET by logging in as "SYS
AS SYSDBA" and issuing "show NLS_CHARACTERSET".
Direct path Exports cannot be invoked using interactive mode
To reduce contention with other users for database resources during direct path export,
you can use direct read mode. To enable direct read mode, enter the following line in your init.ora
file. Compatible = . where db_version number is 7.1.5 or higher.
Exports can be of three categories:
Incremental Exports - An incremental export backs up only the tables that have changed since
the last incremental, cumulative, or complete export. For example if one row is added or updated to a
table since the last incremental, cumulative, or complete export was done the entire table is exported.
Tables which have not been modified are not exported.
Incremental exports cannot be specified as Read consistent i.e. CONSISTENT=Y
The activity is tracked in SYS.INCEXP, then updates the table with a new ITIME and EXPID.
Incremental exports can only be done in full database mode (FULL=Y). Only users having
EXP_FULL_DATABASE role can run incremental exports.
A look at the parameter file incexp.par
FILE= incremental020999.dmp
LOG= incremental020999.log
INCTYPE=INCREMENTAL
Cumulative Exports - An cumulative export backs up only the tables that have changed since
the last cumulative, or complete export. In essence a cumulative export compresses a number of
incremental exports into a single cumulative file. For example let us assume at time "A" a cumulative
export was done, at time "B" a record was deleted from table emp_mast , at time "C" an incremental
export was done (incremental export pickup table emp_mast, since a record is deleted). At time "D"
an record was inserted in emp_dtl, at time "E" an incremental export was done (incremental export
pickup table emp_dtl, since a record is inserted). At time "F" when cumulative export is done it picks
up table emp_mast and also emp_dtl since these two table have changed since the last cumulative
was done. A look at the parameter file cumexp.par
FILE= cumulative020999.dmp
LOG= cumulative 020999.log
INCTYPE=CUMULATIVE
Complete Exports - A complete export establishes a base for incremental and cumulative
exports. It is equivalent to a full database export, except that it updates the tables that track
incremental and cumulative exports. If you do not specify INCTYPE=COMPLETE then the tables that
track incremental and cumulative exports are not updated. A look at the parameter file
completeexp.par
FILE= complete020999.dmp
LOG= complete020999.log
INCTYPE=COMPLETE
There are three modes in which you can export, all users have at least two modes available by default; a
user with EXP_FULL_DATABASE role has three choices, The modes are:
Exporting Table - You can export a table, or group of tables in a schema; You can probably write
your parameter file (exptables.par) as shown below:
FILE=exptables020999.dmp
LOG=exptables020999.log
TABLES=(table1, table2, table3)

Exporting Users - If you desire you can export all objects in a users schema (such as tables,
data, grants and indexes). By default a ordinary user can only export his current schema. A user with
EXP_FULL_DATABASE privilege can export other users schema. You can typically write a parameter
file (expschema.par) to export Your schema as below:
FILE=expschema.dmp
LOG=expschema.log
Exporting Full Database - You have to have EXP_FULL_DATABASE privilege, to carry on this
operation. You can typically write a parameter file (expfulldb.par) to export full database as below
FULL=Y
FILE=expfulldb.dmp
LOG=expfulldb.log
I have put together a Shell Script (UNIX), to automate your "Logical Backup's/Exports". Please test
the script throughly before implementing this in you Production Environment (Unix Flavors)
#! /bin/ksh
# <ORACLE_SID>
# <ORACLE_HOME>
# <EXPORT_DIR>
# <email_address>
# <username>
# <password>
#
trap 2 3
#
#
export EXPORT_DIR=<EXPORT_DIR>
#
#
if [ -f ${EXPORT_DIR}/fullexport.lock ]; then
ERROR - EXPORT BACKUP For "${ORACLE_SID}" Has Failed
Previous Export Backup is not completed !
EOF
exit 1
else
touch ${EXPORT_DIR}/fullexport.lock
fi
################################################################
#
# This function takes the Full export backup of the database.
# Export will be used only as a last resort if all other options
# of recovery fails. This involves creation of a new database and
# importing data into it.
#
# The parametr file fullexp.par is responsible for guiding how the export
# will behave. Please understand it thoroughly before starting
# the export procedure.
#
# It is Safe to Take Exports only when the database is up and
# no other users have logged on and nobody should be using
# the database. If export is taken while some users have logged
# on to the application and are using it, the export will be
# inconsistent and data integrity will be lost.
#
################################################################
#
# Check if the database is up or not.
#
database_up=`ps -ef|sed 's/ $//g' | grep "ora_...._${ORACLE_SID}" | grep -v
grep | wc -l`
then
ERROR - Export Backup for "${ORACLE_SID}" Has Failed
Database Is Not Up - Please Investigate !
EOF
exit 0
else
EXPORT_FILE_NAME=`date '+fullexport%y%m%d'`.dmp
LOG_FILE_NAME=`date '+fullexport%y%m%d'`.log
mknod ${EXPORT_DIR}/${EXPORT_FILE_NAME} p
chmod +rw ${EXPORT_DIR}/$EXPORT_FILE_NAME
#
# Building the export parameter file fullexp.par
#
cat <<END > ${EXPORT_DIR}/fullexp.par
FILE=${EXPORT_DIR}/${EXPORT_FILE_NAME}
FULL=Y
COMPRESS=Y
LOG=${EXPORT_DIR}/${LOG_FILE_NAME}
END
cat ${EXPORT_DIR}/${EXPORT_FILE_NAME} | compress > ${EXPORT_DIR}/$
{EXPORT_FILE_NAME}.Z &
exp <userid>/<password> parfile=${EXPORT_DIR}/fullexp.par
# compress ${EXPORT_DIR}/${EXPORT_FILE_NAME}
rm -f ${EXPORT_DIR}/fullexp.par
rm -f ${EXPORT_DIR}/fullexport.lock
Export Backup for "${ORACLE_SID}" Completed
EOF
fi
Complete Media Recovery

Contents
[hide]
1 Media recovery commands

o
1.1 RECOVER DATABASE
1.2 RECOVER TABLESPACE
1.3 RECOVER DATAFILE
2 Media recovery types

o
2.1 Performing Closed Database Recovery
2.2 Performing Open-Database, Offline-Tablespace Recovery
2.3 Performing Open-Database, Offline-Tablespace Individual Recovery
[edit]Media
recovery commands
There are three basic media recovery commands, which differ only in the way the set of files being
recovered is determined. They all use the same criteria for determining if files can be recovered. Media
recovery signals an error if it cannot get the lock for a file it is attempting to recover. This prevents two
recovery sessions from recovering the same file. It also prevents media recovery of a file that is in use.
You should be familiar with all media recovery commands before performing media recovery.
[edit]RECOVER
DATABASE
RECOVER DATABASE performs media recovery on all online datafiles that require redo to be applied. If
all instances were cleanly shutdown, and no backups were restored, RECOVER DATABASE indicates a
no recovery required error. It also fails if any instances have the database open (since they have the
datafile locks). To perform media recovery on an entire database (all tablespaces), the database must be
mounted EXCLUSIVE and closed.
[edit]RECOVER
TABLESPACE
RECOVER TABLESPACE performs media recovery on all datafiles in the tablespaces listed. To translate
the tablespace names into datafile names, the database must be mounted and open. The tablespaces
must be offline to perform the recovery. An error is indicated if none of the files require recovery.
[edit]RECOVER
DATAFILE
RECOVER DATAFILE lists the datafiles to be recovered. The database can be open or closed, provided
the media recovery locks can be acquired. If the database is open in any instance, then datafile recovery
can only recover off-line files.
[edit]Media
recovery types
Complete Media Recovery can be classified into three categories:

[edit]Performing
Closed Database Recovery
If the database is open, shut it down using the Server Manager Shutdown Abort mode of the
Shutdown Database dialog box, or the SHUTDOWN command with the ABORT option.
If you're recovering from a media error, correct it if possible.
If files are permanently damaged, restore the most recent backup files (taken as part of a full or
partial backup) of only the datafiles damaged by the media failure. Do not restore any undamaged
datafiles or any online redo log files. If the hardware problem has been repaired, and damaged
datafiles can be restored to their original locations, do so, and skip Step 6 of this procedure. If the
hardware problem persists, restore the datafiles to an alternative storage device of the database
server and continue with this procedure.
Start Server Manager and connect to Oracle with administrator privileges.
Start a new instance and mount, but do not open, the database using either the Server Manager
Startup Database dialog box (with the Startup Mount radio button selected), or the STARTUP
command with the MOUNT option.
If one or more damaged datafiles were restored to alternative locations in Step 3, the new
location of these files must be indicated to the control file of the associated database.
All datafiles you want to recover must be online during complete media recovery. To get the
datafile names, check the list of datafiles that normally accompanies the current control file, or query
the V$DATAFILE view. Then, issue the ALTER DATABASE command with the DATAFILE ONLINE
option to ensure that all datafiles of the database are online.
To start closed database recovery of all damaged datafiles in one step, use either the Server
Manager Apply Recovery Archive dialog box, or an equivalent RECOVER DATABASE statement.
To start closed database recovery of an individual damaged datafile, use the RECOVER
DATAFILE statement in Server Manager.

Now Oracle begins the roll forward phase of media recovery by applying the necessary redo log
files (archived and online) to reconstruct the restored datafiles. Unless the application of files is
automated, Oracle prompts you for each required redo log file.
Oracle continues until all required archived redo log files have been applied to the restored
datafiles. The online redo log files are then automatically applied to the restored datafiles and notifies
you when media recovery is complete. If no archived redo log files are required for complete media
recovery, Oracle does not prompt for any. Instead, all necessary online redo log files are applied, and
media recovery is complete.
After performing closed database recovery, the database is recovered up to the moment that
media failure occurred. You can then open the database using the SQL command ALTER DATABASE
with the OPEN option.
[edit]Performing
Open-Database, Offline-Tablespace Recovery
At this point, an open database has experienced a media failure, and the database remains open while
the undamaged datafiles remain online and available for use. The damaged datafiles are automatically
taken off-line by Oracle.
The starting point for this recovery operation can vary, depending on whether you left the
database open after the media failure occurred.
If the database was shut down, start a new instance, and mount and open the database.
Perform this operation using the Server Manager Startup Database dialog box (with the Startup
Open radio button selected), or with the STARTUP command with the OPEN option. After the
database is open, take all tablespaces that contain damaged datafiles offline.
If the database is still open and only damaged datafiles of the database are offline, take
all tablespaces containing damaged datafiles offline. Oracle identifies damaged datafiles via error
messages. Tablespaces can be taken offline using either the Take Offline menu item of Server
Manager, or the SQL command ALTER TABLESPACE with the OFFLINE option. If possible, take
the damaged tablespaces offline with temporary priority (to minimize the amount of recovery).
Correct the hardware problem that caused the media failure. If the hardware problem cannot be
repaired quickly, you can proceed with database recovery by restoring damaged files to an alternative
storage device.
partial backup) of only the datafiles damaged by the media failure. Do not restore undamaged
datafiles, online redo log files, or control files. If the hardware problem has been repaired and the
datafiles can be restored to their original locations, do so. If the hardware problem persists, restore
the datafiles to an alternative storage device of the database server.
If one or more damaged datafiles were restored to alternative locations (Step 3), indicate the new
locations of these files to the control file of the associated database.
After connecting with administrator privileges, use the RECOVER TABLESPACE statement in
Server Manager to start offline tablespace recovery of all damaged datafiles in one or more offline
tablespaces using one step.
Oracle begins the roll forward phase of media recovery by applying the necessary redo log files
(archived and online) to reconstruct the restored datafiles. Unless the applying of files is automated,
Oracle prompts for each required redo log file.
datafiles. The online redo log files are then automatically applied to the restored datafiles to complete
media recovery. If no archived redo log files are required for complete media recovery, Oracle does
not prompt for any. Instead, all necessary online redo log files are applied, and media recovery is
complete.
The damaged tablespaces of the open database are now recovered up to the moment that media
failure occurred. You can bring the offline tablespaces online using the Place Online menu item of
Server Manager, or the SQL command ALTER TABLESPACE with the ONLINE option.
[edit]Performing
Open-Database, Offline-Tablespace Individual Recovery
Identical to the preceding operation, here an open database has experienced a media failure, and
remains open while the undamaged datafiles remain online and available for use. The damaged datafiles
are automatically taken offline by Oracle.
The starting point for this recovery operation can vary, depending on whether you left the
database open after the media failure occurred.
If the database was shut down, start a new instance, and mount and open the database.
Perform this operation using the Server Manager Startup Database dialog box (with the Startup
Open radio button selected), or with the STARTUP command with the OPEN option. After the
database is open, take all tablespaces that contain damaged datafiles offline.
If the database is still open and only damaged datafiles of the database are offline, take
all tablespaces containing damaged datafiles offline. Oracle identifies damaged datafiles via error
messages. Tablespaces can be taken offline using either the Take Offline menu item of Server
Manager, or the SQL command ALTER TABLESPACE with the OFFLINE option. If possible, take
the damaged tablespaces offline with temporary priority (to minimize the amount of recovery).
Correct the hardware problem that caused the media failure. If the hardware problem cannot be
repaired quickly, you can proceed with database recovery by restoring damaged files to an alternative
storage device.
partial backup) of only the datafiles damaged by the media failure. Do not restore undamaged
datafiles, online redo log files, or control files. If the hardware problem has been repaired and the
datafiles can be restored to their original locations, do so. If the hardware problem persists, restore
the datafiles to an alternative storage device of the database server.
If one or more damaged datafiles were restored to alternative locations (Step 3), indicate the new
locations of these files to the control file of the associated database.
After connecting with administrator privileges, use the RECOVER DATAFILE statement in Server
Manager to start offline tablespace recovery of all damaged datafiles in one or more offline
tablespaces using one step.
Oracle begins the roll forward phase of media recovery by applying the necessary redo log files
(archived and online) to reconstruct the restored datafiles. Unless the applying of files is automated,
Oracle prompts for each required redo log file.
datafiles. The online redo log files are then automatically applied to the restored datafiles to complete
media recovery. If no archived redo log files are required for complete media recovery, Oracle does
not prompt for any. Instead, all necessary online redo log files are applied, and media recovery is
complete.
The damaged tablespaces of the open database are now recovered up to the moment that media
failure occurred. You can bring the offline tablespaces online using the Place Online menu item of
Server Manager, or the SQL command ALTER TABLESPACE with the ONLINE option.
Incomplete Media Recovery

There are three basic media recovery commands, which differ only in the way the set of files being
recovered is determined. They all use the same criteria for determining if files can be recovered. Media
recovery signals an error if it cannot get the lock for a file it is attempting to recover. This prevents two
recovery sessions from recovering the same file. It also prevents media recovery of a file that is in use.
You should be familiar with all media recovery commands before performing media recovery.
RECOVER DATABASE Command - RECOVER DATABASE performs media recovery on all

online datafiles that require redo to be applied. If all instances were cleanly shutdown, and no
backups were restored, RECOVER DATABASE indicates a no recovery required error. It also fails if
any instances have the database open (since they have the datafile locks). To perform media
recovery on an entire database (all tablespaces), the database must be mounted EXCLUSIVE and
closed.
RECOVER TABLESPACE Command - RECOVER TABLESPACE performs media recovery on all

datafiles in the tablespaces listed. To translate the tablespace names into datafile names, the
database must be mounted and open. The tablespaces must be offline to perform the recovery. An
error is indicated if none of the files require recovery.
RECOVER DATAFILE Command - RECOVER DATAFILE lists the datafiles to be recovered. The
database can be open or closed, provided the media recovery locks can be acquired. If the database
is open in any instance, then datafile recovery can only recover offline files.
InComplete Media Recovery can be classified into three categories:
Performing Cancel-Based Recovery
1. If the database is still open and incomplete media recovery is necessary, shut down
the database using the Server Manager Shutdown Abort mode of the Shutdown Database dialog
box, or the SHUTDOWN command with the ABORT option.
2. Make a full backup of the database (all datafiles, a control file, and the parameter files
of the database) as a precautionary measure, in case an error is made during the recovery
procedure.
3. If a media failure occurred, correct the hardware problem that caused the media
failure.
4. If the current control files do not match the physical structure of the database at the
intended time of recovery (for example, if a datafile was added after the point in time to which
you intend to recover), then restore a backup of the control file that reflects the databases
physical file structure (contains the names of datafiles and online redo log files) at the point at
which incomplete media recovery is intended to finish. Review the list of files that correspond to
the current control file as well as each control file backup to determine the correct control file to
use. If necessary, replace all current control files of the database with the correct control file
backup. You can, alternatively, create a new control file to replace the missing one.
5. Restore backup files (taken as part of a full or partial backup) of all the datafiles of the
database. All backup files used to replace existing datafiles must have been taken before the
intended time of recovery. For example, if you intend to recover to redo log sequence number 38,
then restore all datafiles with backups completed before redo log sequence number 38. If you do
not have a backup of a specific datafile, you can create an empty replacement file, which can be
recovered.If a datafile was added after the intended time of recovery, it is not necessary to
restore a backup for this file, as it will no longer be used for the database after recovery is
complete.
6. Start Server Manager and connect to Oracle with administrator privileges.
7. Start a new instance and mount the database. You can perform this operation using
the Server Manager Startup Database dialog box with the Startup Mount radio button selected,
or the STARTUP command with the MOUNT option.
8. If one or more damaged datafiles were restored to alternative locations in Step 5, the
new locations of these files must be indicated to the control file of the associated database.
9. If a backup of the control file is being used with this incomplete recovery (that is, a
control file backup or re-created control file was restored in Step 4), indicate this in the dialog box
or command used to start recovery (that is, specify the USING BACKUP CONTROLFILE
parameter).
10. Use Server Manager Apply Recovery Archives dialog box, or an equivalent
RECOVER DATABASE UNTIL CANCEL statement to begin cancel-based recovery.

11. Oracle begins the roll forward phase of media recovery by applying the necessary
redo log files (archived and online) to reconstruct the restored datafiles. Unless the application of
files is automated, Oracle supplies the name it expects to find from LOG_ARCHIVE_DEST and
requests you to stop or proceed with applying the log file. If the control file is a backup file, you
must supply names of online logs. Oracle continues to apply redo log files.
12. Continue applying redo log files until the most recent, undamaged redo log file has
been applied to the restored datafiles.

13. Enter "CANCEL" to cancel recovery after Oracle has applied the redo log file just
prior to the damaged file. Cancel-based recovery is now complete. Oracle returns a message
indicating whether recovery is successful.
14. The first time you open the database subsequent to incomplete media recovery, you
must explicitly specify whether to reset the log sequence number by including either the
RESETLOGS or NORESETLOGS option.
Resetting the redo log
discards any redo information that was not applied during recovery,
ensuring that it will never be applied

reinitializes the control file information about online redo logs and redo
threads
clears the contents of the online redo logs
creates the online redo log files if they do not currently exist
resets the log sequence number to 1
NoReset Logs - To preserve the log sequence number when opening a database
after recovery, use the SQL command ALTER DATABASE with the OPEN NORESETLOGS
option.
Performing Time-Based Recovery -
procedure.
failure.
complete.
9. All datafiles of the database must be online unless an offline tablespace was taken
offline normally. To get the names of all datafiles to recover, check the list of datafiles that
normally accompanies the control file being used or query the V$DATAFILE view. Then, use the
ALTER DATABASE command and the DATAFILE ONLINE option to make sure that all datafiles
of the database are online.
10. Issue the RECOVER DATABASE UNTIL TIME statement to begin time-based
recovery. The time is always specified using the following format, delimited by single quotation
marks: YYYY-MM-DD:HH24:MI:SS.
12. Continue applying redo log files until the last required redo log file has been applied
to the restored datafiles. Oracle automatically terminates the recovery when it reaches the
correct time, and returns a message indicating whether recovery is successful.
Use the following rules when deciding to specify RESETLOGS or NORESETLOGS:
Reset the log sequence number if you used a backup of the control file in
recovery, no matter what type of recovery was performed (complete or incomplete).
Reset the log sequence number if the recovery was actually incomplete. For
example, you must have specified a previous time or SCN, not one in the future.
Do not reset logs if recovery was complete (unless you used a backup control
file). This applies when you intentionally performed complete recovery and when you
performed incomplete recovery but actually recovered all changes in the redo logs anyway.
Do not reset logs if you are using the archived logs of this database for a standby
database. If the log must be reset, then you will have to re-create your standby database.
Performing Change-Based Recovery -
procedure.
failure.
complete.
9. All datafiles of the database must be online unless an offline tablespace was taken
offline normally. To get the names of all datafiles to recover, check the list of datafiles that
normally accompanies the control file being used or query the V$DATAFILE view. Then, use the
ALTER DATABASE command and the DATAFILE ONLINE option to make sure that all datafiles
of the database are online.
10. Issue the RECOVER DATABASE UNTIL CHANGE statement to begin change-based
recovery. The SCN is specified as a decimal number without quotation marks.

12. Continue applying redo log files until the last required redo log file has been applied
to the restored datafiles. Oracle automatically terminates the recovery when it reaches the
correct time, and returns a message indicating whether recovery is successful.
Use the following rules when deciding to specify RESETLOGS or NORESETLOGS:
Reset the log sequence number if you used a backup of the control file in
recovery, no matter what type of recovery was performed (complete or incomplete).
Reset the log sequence number if the recovery was actually incomplete. For
example, you must have specified a previous time or SCN, not one in the future.
Do not reset logs if recovery was complete (unless you used a backup control
file). This applies when you intentionally performed complete recovery and when you
performed incomplete recovery but actually recovered all changes in the redo logs anyway.
Do not reset logs if you are using the archived logs of this database for a standby
database. If the log must be reset, then you will have to re-create your standby database.
Datafile belonging to UNDO tablespace

This is a recovery scenario in which a datafile in a UNDO or ROLLBACK SEGMENT tablespace has been
lost or damaged to a point that Oracle cannot recognize them anymore. Trying to startup the database will
result in ORA-1157, ORA-1110, and possibly an operating system level error such as ORA-7360. Trying to
shut down the database in normal or immediate mode will result in ORA-1116, ORA-1110, and possibly an
operating system level error such as ORA-7368.
There are typically two scenarios under this:
[edit]Database
was cleanly shut down
I.e. Datafile was accidentally dropped using operating system command, when the database was cleanly
shutdown. If you are ABSOLUTELY POSITIVE that the database was cleanly shutdown, i.e., it was closed
with either shutdown NORMAL or IMMEDIATE (DO NOT follow this procedure if the database was shut
down ABORT or if it crashed), then the simplest solution is to offline drop the missing datafile, open the
database in restricted mode, and then drop and recreate the rollback tablespace to which the file
belonged the steps performed are:.
Make sure the database was last cleanly shut down. Check the alert.log file for this instance. Go
to the bottom of the file and make sure the last time you shut the database down you got the
messages: "alter database dismount Completed: alter database dismount" This also includes the
case of a clean shutdown followed by a failed attempt to startup the database. In that case, Oracle
will issue error messages and shut itself down abort. For the purposes of this solution, though, this
counts as a clean shutdown. If that is not the case, i.e., if the last time YOU shut the database down it
was in abort mode, or the database crashed itself, it is NOT safe to proceed, the scenario for this type
of recovery is discussed below.
Mount the database in restricted mode. STARTUP RESTRICT MOUNT
Offline drop the lost datafile.

ALTER DATABASE DATAFILE OFFLINE DROP;
Open the database.

ALTER DATABASE OPEN.
Drop the rollback tablespace to which the datafile belonged.
Recreate the rollback tablespace with all its rollback segments. Remember to bring the rollbacks
online after you create them.
Make the database available to all users.
ALTER SYSTEM DISABLE RESTRICTED SESSION;
[edit]Database
was NOT cleanly shut down
I.e. Datafile was accidentally dropped using operating system command, when the database was not
cleanly shutdown using SHUTDOWN ABORT COMMAND.
Check the alert.log file for this instance.
Comment out the ROLLBACK_SEGMENTS parameter and add the following line:
_corrupted_rollback_segments = ( ,...., ) i.e., the above list should contain all the rollbacks originally
listed in the ROLLBACK_SEGMENTS parameter.
Mount the database in restricted mode. STARTUP RESTRICT MOUNT
Offline drop the lost datafile.

ALTER DATABASE DATAFILE OFFLINE DROP;
Open the database.

ALTER DATABASE OPEN.
Drop the rollback tablespace to which the datafile belonged.
Recreate the rollback tablespace with all its rollback segments. Remember to bring the rollbacks
online after you create them.
Make the database available to all users.
ALTER SYSTEM DISABLE RESTRICTED SESSION;
Control file recovery

Described below are the different control file recovery scenarios:
Contents
[hide]
1 One control file lost

2 Lost all control files
o
2.1 Restore from backup controlfile
2.2 Restore from RMAN backup
2.3 Manually recreate the control file
[edit]One
control file lost
Assuming you have mirrored your control files i.e. using two or more control files:
If database is up and running, quickly copy the good control file over the bad control file.
alter system checkpoint;
If database went down when you accidentally dropped the control file, copy the good copy over
the bad one and restart.
[edit]Lost
all control files
If all control files are lost (or you are only using one control file):
[edit]Restore
from backup controlfile
In this case you should have created a backup of your control file using, ALTER DATABASE BACKUP
CONTROLFILE TO TRACE;
if database is up and running, shutdown abort
startup mount
recover database from commands in controlfile trace
take a backup
[edit]Restore
from RMAN backup
Oracle automatically backs up the control file when the DB is backed up. To restore, issue the
following RMAN commands.
set dbid ???;

restore controlfile;
[edit]Manually
recreate the control file
Issue the CREATE CONTROL FILE statement against the DB. Lookup the syntax in the SQL reference
guide. Most of the info required to rebuild the control file should be in the alert.log.
Example:
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "orcl"
NORESETLOGS [archivelog/noarchivelog]
MAXLOGFILES 5
MAXLOGMEMBERS 3
MAXDATAFILES 10
MAXINSTANCES 1
MAXLOGHISTORY 113
LOGFILE
GROUP 1 'D:\ORACLE\ORADATA\ORCL\REDO01.LOG' SIZE 10M,

GROUP 2 'D:\ORACLE\ORADATA\ORCL\REDO02.LOG' SIZE 10M,
GROUP 3 'D:\ORACLE\ORADATA\ORCL\REDO03.LOG' SIZE 10M
DATAFILE
'D:\ORACLE\ORADATA\ORCL\SYSTEM01.DBF' SIZE xxx,
'D:\ORACLE\ORADATA\ORCL\USERS01.DBF' SIZE xxx,
...
CHARACTER SET [characater_set];
One or more datafiles damaged

This page describes the procedure to follow when one or more database datafiles are damaged:
Restore an intact copy of the datafile from backup (tape)
Check the directory of archive logs for the number of archived log files. There should be a
sufficient number of files for recovery. All the archived logfiles with timestamp after the latest hot
backup should be present. If they are not present restore them from tape to the archive directory.
Start sqlplus:
sqlplus
connect SYS AS SYSDBA
SQL> shutdown abort
Oracle Instance Aborted
SQL> startup mount
Oracle Instance Started
Database Mounted
SQL> select * from v$recover_file;
This will give you a list of files on which media recovery will be done. Take a printout of this.
SQL> select * from v$recovery_log;
This will give you the list of archived log files which will be applied to the database for a
rollforward. This list is very important. Check in the archive log directory to ascertain the presence of
all the files. If some file is not present on the archive directory, copy them from tape. If some file is not
present at all, then you will have to perform incomplete recovery.
SQL> recover database ( in case of regular recovery )
If you perform incomplete recovery, enter recover database until cancel. SQL*Plus will prompt
you for files to apply. Just keep on pressing RETURN till the absent file is prompted. Enter CANCEL.
After some time, the message Media Recovery Complete will appear. If due to any reason the
archived log files are not found in the proper directory, SQL*Plus will ask for the logfile with the
sequence no and the name. You must copy the file to the archive directory and then give the name to
SQL*Plus. If the files are present and still SQL*Plus prompts for the filename, just enter AUTO at the
prompt of file name and the appropriate log files will be applied automatically.
SQL> alter database open

Statement Processed
If you have performed incomplete recovery, enter alter database open resetlogs.
SQL> shutdown
Database Closed
Database Dismounted
Oracle Instance Shutdown
SQL> startup mount
Database Mounted
SQL> alter database backup controlfile to
/u01/ORADATA/archive/prodcontrolfile.backup reuse;
Statement Processed
SQL> Alter database open
Statement Processed
SQL> exit
At this point it is advisable to run a hot backup or, better still, a cold backup.
Datafile damaged and backup not available

A datafile can still be recovered if no backup exists for it, provided:
all redolog files since the creation of the datafile are available
the control file contains the name of the damaged file (that is, the control file is current, or is a
backup taken after the damaged datafile was added to the database)
[edit]Recovery
steps
Assume that file /u01/ORADATA/data/data01.dbf of tablespace DATA is damaged and you don't have a
backup of the datafile:
Start SQL*Plus:
SQL> connect SYS AS SYSDBA

connected
SQL> shutdown abort
Oracle Instance Aborted
SQL> startup mount
SQL> alter database create datafile '/u01/ORADATA/data/data01.dbf';
Statement Processed
SQL> recover datafile '/u01/ORADATA/data/data01.dbf';
Statement Processed
SQL> select * from v$datafile;
You will see a list of datafiles. If the status of the recovered file is not ONLINE, issue the following
command:
SQL> alter database datafile '/u01/ORADATA/data/data01.dbf' online;

Statement Processed
SQL> alter database open;
Statement Processed
SQL> select * from dba_tablespaces;
If the status of the tablespace is not ONLINE, issue the following command.
SQL> alter tablespace DATA online;

Statement Processed
Recovering from user errors

Sometimes you may have to recover from some unintentional but undesirable user errors like:
a table has been dropped or truncated; or
some data has been deleted and committed which was not required.
User errors normally requires some time based recovery procedure. Here the database will be running
and there will be no outward signs of a failure, but you have to recreate the database at a certain point of
time.
Shutdown the database:
SQLPLUS> connect SYS as SYSDBA

connected
SQLPLUS> shutdown
Database Closed
Database Dismounted
ORACLE Instance Shut Down
Copy all the datafiles, redo logs and controlfiles from an earliest hot backup.
Recover the database:
SQLPLUS> startup mount

Database Mounted
SQLPLUS> recover database until 2000-07-11:15:30:00 using backup controlfile
Note that you want to recover till 11th July, 2000 3:30 PM. The format of the time string is YYYY-MMDD:HH:MI:SS. When SQL*Plus prompts you for archived logfiles to apply, just enter AUTO. The database
will be recreated till the indicated time. After that the following message will appear.
Media Recovery Complete.
Open the database:
SQLPLUS> alter database open resetlogs;

Statement Processed
SQLPLUS> exit
Now the old archived logfiles are useless. Delete them and take a backup of the database.
Oracle Secure Backup

Oracle Secure Backup (OSB) provides centralized tape backup management for the Oracle Database
and file systems in mixed, diverse environments reducing the cost and complexity of tape backup and
restoration.
[edit]Oracle
Secure Backup Express
OSB Express is provided free with the Oracle DB and application products, but can only be used to
backup one server to one attached tape drive. If you need to backup to multiple drive, you need to license
OSB separately.
[edit]Oracle
Secure Backup
Full featured version of OSB.
Recovery Manager
Recovery Manager (RMAN) is an Oracle provided utility for backing-up, restoring and recovering Oracle
Databases. RMAN ships with the Oracle database and doesn't require a separate installation. The RMAN
executable is located in your ORACLE_HOME/bin directory. In fact, RMAN, is just a Pro*C application
that translates commands to a PL/SQL interface. The PL/SQL calls are statically linked into the Oracle
kernel, and does not require the database to be opened (mapped from the ?/rdbms/admin/recover.bsq
file).
Contents
[hide]
1 Benefits of RMAN
2 Getting started
3 Using a recovery catalog
4 Writing to tape
5 Also see
[edit]Benefits
of RMAN
Some of the benefits provided by RMAN include:
Backups are faster and uses fewer tapes (RMAN will skip empty blocks)
Less database archiving while database is being backed-up
RMAN checks the database for block corruptions
Automated restores from the catalog
Files are written out in parallel instead of sequentially
[edit]Getting
started
RMAN can be operated from Oracle Enterprise Manager, or from command line. Here are the command
line arguments:
Argument
Value
Description
----------------------------------------------------------------------------target
quoted-string connect-string for target database
catalog
quoted-string connect-string for recovery catalog
nocatalog
none
if specified, then no recovery catalog
cmdfile
quoted-string name of input command file
log
quoted-string name of output message log file
trace
quoted-string name of output debugging message log file
append
none
if specified, log is opened in append mode
debug
optional-args activate debugging
msgno
none
show RMAN-nnnn prefix for all messages
send
quoted-string send a command to the media manager
pipe
string
building block for pipe names
timeout
integer
number of seconds to wait for pipe input
-----------------------------------------------------------------------------
Here is an example:
[oracle@localhost oracle]$ rman

Recovery Manager: Release 10.1.0.2.0 - Production
RMAN> connect target;
...
[edit]Using
a recovery catalog
Start by creating a database schema (usually called rman). Assign an appropriate tablespace to it and
grant it the recovery_catalog_owner role. Look at this example:
sqlplus sys/ as sysdba

SQL> create user rman identified by rman;
SQL> alter user rman default tablespace tools temporary tablespace temp;
SQL> alter user rman quota unlimited on tools;
SQL> grant connect, resource, recovery_catalog_owner to rman;
SQL> exit;
Next, log in to rman and create the catalog schema. Prior to Oracle 8i this was done by running the
catrman.sql script.
rman catalog rman/rman

RMAN> create catalog tablespace tools;
RMAN> exit;
You can now continue by registering your databases in the catalog. Look at this example:
rman catalog rman/rman target backdba/backdba

RMAN> register database;
[edit]Writing
to tape
RMAN can do off-line and on-line database backups. It cannot, however, write directly to tape. A MML
(Media Manager Layer) is required to interface between RMAN and the tape drive/library. Various 3rdparty tools (like Veritas Netbackup, Data Protector, TSM, etc) are available that can integrate with RMAN
to handle the tape library management.
To see what tapes were used for a particular backup, run this query against the RMAN catalog database:
SELECT media, start_time, completion_time FROM rc_backup_piece

WHERE db_id = (SELECT db_id FROM rc_database WHERE UPPER(name) = 'ORCL')
AND completion_time BETWEEN TO_DATE('27-DEC-2007 12:38:36','DD-MON-YYYY
HH24:MI:SS')
AND TO_DATE('28-DEC-2007 01:39:27','DD-MON-YYYY
HH24:MI:SS')
/
How does one create a new database?

One can create and modify Oracle databases using the Oracle DBCA (Database Configuration Assistant)
utility. The dbca utility is located in the $ORACLE_HOME/bin directory. The Oracle Universal Installer
(oui) normally starts it after installing the database server software to create the starter database.
One can also create databases manually using scripts. This option, however, is falling out of fashion as it
is quite involved and error prone. Look at this example for creating an Oracle 9i or higher database:
CONNECT SYS AS SYSDBA
ALTER SYSTEM SET DB_CREATE_FILE_DEST='/u01/oradata/';
ALTER SYSTEM SET DB_CREATE_ONLINE_LOG_DEST_1='/u02/oradata/';
ALTER SYSTEM SET DB_CREATE_ONLINE_LOG_DEST_2='/u03/oradata/';
CREATE DATABASE;
Also see Creating a New Database.
[edit]What
database block size should I use?
Oracle recommends that your database block size match, or be multiples of your operating system block
size. One can use smaller block sizes, but the performance cost is significant. Your choice should depend
on the type of application you are running. If you have many small transactions as with OLTP, use a
smaller block size. With fewer but larger transactions, as with a DSS application, use a larger block size.
If you are using a volume manager, consider your "operating system block size" to be 8K. This is because
volume manager products use 8K blocks (and this is not configurable).
[edit]What
database aspects should be monitored?
One should implement a monitoring system to constantly monitor the following aspects of a database.
This can be achieved by writing custom scripts, implementing Oracle's Enterprise Manager, or buying
a third-party monitoring product. If an alarm is triggered, the system should automatically notify the DBA
(e-mail, text, etc.) to take appropriate action.
Infrastructure availability:
Is the database up and responding to requests
Are the listeners up and responding to requests
Are the Oracle Names and LDAP Servers up and responding to requests
Are the Application Servers up and responding to requests
Etc.
Things that can cause service outages:
Is the archive log destination filling up?
Objects getting close to their max extents
Tablespaces running low on free space / Objects that would not be able to extend
User and process limits reached
Etc.
[edit]How
does one rename a database?
Follow these steps to rename a database:
Start by making a full database backup of your database (in case you need to restore if this
procedure is not working).
Execute this command from sqlplus while connected to 'SYS AS SYSDBA':
ALTER DATABASE BACKUP CONTROLFILE TO TRACE RESETLOGS;
Locate the latest dump file in your USER_DUMP_DEST directory (show parameter
USER_DUMP_DEST) - rename it to something like dbrename.sql.
Edit dbrename.sql, remove all headers and comments, and change the database's name. Also
change "CREATE CONTROLFILE REUSE ..." to "CREATE CONTROLFILE SET ...".
Shutdown the database (use SHUTDOWN NORMAL or IMMEDIATE, don't ABORT!) and run
dbrename.sql.
Rename the database's global name:
ALTER DATABASE RENAME GLOBAL_NAME TO new_db_name;

[edit]Can
one rename a database user (schema)?
No, this is listed as Enhancement Request 158508. Workaround (including 9i):
Do a user-level export of user A
create new user B
import the user while renaming it
import system/manager fromuser=A touser=B
drop user A
Workaround (starting 10g)
Do a data pump schema export of user A
expdp system/manager schemas=A [directory=... dumpfile=... logfile=...]
import the user while renaming it
impdp system/manager schemas=A remap_schema=A:B [directory=... dumpfile=...

logfile=...]
drop user A
[edit]Can
one rename a tablespace?
From Oracle 10g Release 1, users can rename tablespaces. Example:

ALTER TABLESPACE ts1 RENAME TO ts2;
However, you must adhere to the following restrictions:
COMPATIBILITY must be set to at least 10.0.1
Cannot rename SYSTEM or SYSAUX
Cannot rename an offline tablespace
Cannot rename a tablespace that contains offline datafiles
For older releases, use the following workaround:
Export all of the objects from the tablespace
Drop the tablespace including contents
Recreate the tablespace
Import the objects
[edit]How
does one see the uptime for a database?
Look at the following SQL query:

SELECT to_char(startup_time,'DD-MON-YYYY HH24:MI:SS') "DB Startup Time"
FROM
sys.v_$instance;
[edit]Can
one resize tablespaces and data files?
Add more files to tablespaces

To add more space to a tablespace, one can simply add another file to it. Example:
ALTER TABLESPACE USERS ADD DATAFILE '/oradata/orcl/users1.dbf' SIZE 100M;
Resize datafiles
One can manually increase or decrease the size of a datafile from Oracle 7.2 using the following
command:
ALTER DATABASE DATAFILE 'filename2' RESIZE 100M;
Because you can change the sizes of datafiles, you can add more space to your database without adding
more datafiles. This is beneficial if you are concerned about reaching the maximum number of datafiles
allowed in your database.
Manually reducing the sizes of datafiles allows you to reclaim unused space in the database. This is
useful for correcting errors in estimations of space requirements.
Extend datafiles
Also, datafiles can be allowed to automatically extend if more space is required. Look at the following
commands:
CREATE TABLESPACE pcs_data_ts
DATAFILE 'c:ora_appspcspcsdata1.dbf' SIZE 3M
AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED
DEFAULT STORAGE ( INITIAL 10240
NEXT 10240
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0)
ONLINE
PERMANENT;
ALTER DATABASE DATAFILE 1 AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED;
[edit]How
do I find the overall database size?
The biggest portion of a database's size comes from the datafiles. To find out how many megabytes are
allocated to ALL datafiles:
select sum(bytes)/1024/1024 "Meg" from dba_data_files;
To get the size of all TEMP files:

select nvl(sum(bytes),0)/1024/1024 "Meg" from dba_temp_files;
To get the size of the on-line redo-logs:
select sum(bytes)/1024/1024 "Meg" from sys.v_$log;
Putting it all together into a single query:
select a.data_size+b.temp_size+c.redo_size "total_size"
from ( select sum(bytes) data_size
from dba_data_files ) a,
( select nvl(sum(bytes),0) temp_size
from dba_temp_files ) b,
( select sum(bytes) redo_size
from sys.v_$log ) c;
Another query ("Free space" reports data files free space):
col "Database Size" format a20
col "Free space" format a20
select round(sum(used.bytes) / 1024 / 1024 ) || ' MB' "Database Size"
,
round(free.p / 1024 / 1024) || ' MB' "Free space"
from (select bytes from v$datafile
union all
select bytes from v$tempfile
union all
select bytes from v$log) used
,
(select sum(bytes) as p from dba_free_space) free
group by free.p
/
[edit]How
do I find the used space within the database size?
Select from the DBA_SEGMENTS or DBA_EXTENTS views to find the used space of a database.
Example:
SELECT SUM(bytes)/1024/1024 "Meg" FROM dba_segments;
[edit]Where
can one find the high water mark for a table?
There is no single system table which contains the high water mark (HWM) for a table. A table's HWM can
be calculated using the results from the following SQL statements:
SELECT BLOCKS
FROM
DBA_SEGMENTS
WHERE OWNER=UPPER(owner) AND SEGMENT_NAME = UPPER(table);
ANALYZE TABLE owner.table ESTIMATE STATISTICS;
SELECT EMPTY_BLOCKS
FROM
DBA_TABLES
WHERE OWNER=UPPER(owner) AND TABLE_NAME = UPPER(table);
Thus, the tables' HWM = (query result 1) - (query result 2) - 1
NOTE: You can also use the DBMS_SPACE package and calculate the HWM = TOTAL_BLOCKS UNUSED_BLOCKS - 1.
[edit]How
do I find used/free space in a TEMPORARY tablespace?
Unlike normal tablespaces, true temporary tablespace information is not listed in DBA_FREE_SPACE.
Instead use the V$TEMP_SPACE_HEADER view:
SELECT tablespace_name, SUM(bytes_used), SUM(bytes_free)
FROM
V$temp_space_header
GROUP BY tablespace_name;
To report true free space within the used portion of the TEMPFILE:
SELECT
A.tablespace_name tablespace, D.mb_total,

SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_used,
D.mb_total - SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_free
FROM
v$sort_segment A,
(
SELECT
B.name, C.block_size, SUM (C.bytes) / 1024 / 1024 mb_total
FROM
v$tablespace B, v$tempfile C
WHERE
B.ts#= C.ts#
GROUP BY B.name, C.block_size
) D
WHERE
A.tablespace_name = D.name
GROUP by A.tablespace_name, D.mb_total;
[edit]How
can one see who is using a temporary segment?
For every user using temporary space, there is an entry in SYS.V_$LOCK with type 'TS'.
All temporary segments are named 'ffff.bbbb' where 'ffff' is the file it is in and 'bbbb' is first block of the
segment.
If your temporary tablespace is set to TEMPORARY, all sorts are done in one large temporary segment.
For usage stats, see SYS.V_$SORT_SEGMENT
From Oracle 8, one can just query SYS.v$sort_usage. Look at these examples:
select s.username, u."USER", u.tablespace, u.contents, u.extents, u.blocks
from
sys.v_$session s, sys.v_$sort_usage u
where s.saddr = u.session_addr
/
select s.osuser, s.process, s.username, s.serial#,
sum(u.blocks)*vp.value/1024 sort_size
from
sys.v_$session s, sys.v_$sort_usage u, sys.v_$parameter vp
where s.saddr = u.session_addr
and vp.name = 'db_block_size'
and s.osuser like '&1'
group by s.osuser, s.process, s.username, s.serial#, vp.value
/
[edit]Who
is using which UNDO or TEMP segment?
Execute the following query to determine who is using a particular UNDO or Rollback Segment:
SQL> SELECT TO_CHAR(s.sid)||','||TO_CHAR(s.serial#) sid_serial,
2
NVL(s.username, 'None') orauser,
3
s.program,
4
r.name undoseg,
5
t.used_ublk * TO_NUMBER(x.value)/1024||'K' "Undo"
6
FROM sys.v_$rollname
r,
7
sys.v_$session
s,
8
sys.v_$transaction t,
9
sys.v_$parameter
x
10
WHERE s.taddr = t.addr
11
AND r.usn
= t.xidusn(+)
12
AND x.name = 'db_block_size'
SID_SERIAL ORAUSER
PROGRAM
UNDOSEG
Undo
---------- ---------- ------------------------------ --------------- ------260,7
SCOTT
sqlplus@localhost.localdomain _SYSSMU4$
8K
(TNS V1-V3)
Execute the following query to determine who is using a TEMP Segment:

SQL> SELECT b.tablespace,
2
ROUND(((b.blocks*p.value)/1024/1024),2)||'M' "SIZE",
3
a.sid||','||a.serial# SID_SERIAL,
4
a.username,
5
a.program
6
FROM sys.v_$session a,
7
sys.v_$sort_usage b,
8
sys.v_$parameter p
9
WHERE p.name = 'db_block_size'
10
AND a.saddr = b.session_addr
11 ORDER BY b.tablespace, b.blocks;
TABLESPACE SIZE
SID_SERIAL USERNAME PROGRAM
---------- ------- ---------- -------- -----------------------------TEMP
24M
260,7
SCOTT
sqlplus@localhost.localdomain
(TNS V1-V3)
[edit]How
does one get the view definition of fixed views/tables?
Query v$fixed_view_definition. Example:

SELECT * FROM v$fixed_view_definition WHERE view_name='V$SESSION';
[edit]How
full is the current redo log file?
Here is a query that can tell you how full the current redo log file is. Handy for when you need to predict
when the next log file will be archived out.
SQL> SELECT le.leseq
"Current log sequence No",
2
100*cp.cpodr_bno/le.lesiz "Percent Full",
3
cp.cpodr_bno
"Current Block No",
4
le.lesiz
"Size of Log in Blocks"
5
FROM x$kcccp cp, x$kccle le
6
WHERE le.leseq =CP.cpodr_seq
7
AND bitand(le.leflg,24) = 8
8 /
Current log sequence No Percent Full Current Block No Size of Log in Blocks
----------------------- ------------ ---------------- --------------------416
48.6669922
49835
102400
[edit]Tired
of typing sqlplus '/as sysdba' every time you want to do

something?
If you are tired of typing sqlplus "/as sysdba" every time you want to perform some DBA task,
implement the following shortcut:
On Unix/Linux systems:
Add the following alias to your .profile or .bash_profile file:
alias sss='sqlplus "/as sysdba"'
On Windows systems:
Create a batch file, sss.bat, add the command to it, and place it somewhere in your PATH. Whenever you
now want to start sqlplus as sysdba, just type "sss". Much less typing for ya lazy DBA's.
Note: From Oracle 10g you don't need to put the "/AS SYSDBA" in quotes anymore.
[edit]What
patches are installed within an Oracle Home?
DBA's often do not document the patches they install. This may lead to situations where a feature works
on machine X, but not on machine Y. This FAQ will show how you can list and compare the patches
installed within your Oracle Homes.
All patches that are installed with Oracle's OPatch Utility (Oracle's Interim Patch Installer) can be listed by
invoking the opatch command with the lsinventory option. Here is an example:
$ cd $ORACLE_HOME/OPatch
$ opatch lsinventory
Invoking OPatch 10.2.0.1.0
Oracle interim Patch Installer version 10.2.0.1.0
Copyright (c) 2005, Oracle Corporation. All rights reserved..
...
Installed Top-level Products (1):
Oracle Database 10g
There are 1 products installed in this Oracle Home.
There are no Interim patches installed in this Oracle Home.
10.2.0.1.0
OPatch succeeded.
NOTE: If OPatch is not installed into your Oracle Home ($ORACLE_HOME/OPatch), you may need to
download it from Metalink and install it yourself.
[edit]How
does one give developers access to trace files (required as

input to tkprof)?
The alter session set sql_trace=true command generates trace files in USER_DUMP_DEST that can be
used by developers as input to tkprof. On Unix the default file mask for these files are "rwx r-- ---".
There is an undocumented INIT.ORA parameter that will allow everyone to read (rwx r-- r--) these trace
files:
_trace_files_public = true
Include this in your INIT.ORA file and bounce your database for it to take effect.
Oracle database Performance Tuning FAQ

General Oracle database Performance Tuning FAQ. Remember: The best performance comes from the
unnecessary work you don't do.
Contents
[hide]
1 Why and when should one tune?

2 Where should the tuning effort be directed?
3 What tools/utilities does Oracle provide to assist with performance tuning?
4 When is cost based optimization triggered?
5 How can one optimize %XYZ% queries?
6 Where can one find I/O statistics per table?
7 My query was fine last week and now it is slow. Why?
8 Does Oracle use my index or not?
9 Why is Oracle not using the darn index?

10 When should one rebuild an index?
11 How does one tune Oracle Wait event XYZ?
12 What is the difference between DBFile Sequential and Scattered Reads?
13 How does one tune the Redo Log Buffer?
[edit]Why
and when should one tune?
One of the biggest responsibilities of a DBA is to ensure that the Oracle database is tuned properly. The
Oracle RDBMS is highly tunable and allows the database to be monitored and adjusted to increase its
performance.
One should do performance tuning for the following reasons:
The speed of computing might be wasting valuable human time (users waiting for response);
Enable your system to keep-up with the speed business is conducted; and
Optimize hardware usage to save money (companies are spending millions on hardware).
Although this site is not overly concerned with hardware issues, one needs to remember than you cannot
tune a Buick into a Ferrari.
[edit]Where
should the tuning effort be directed?
Consider the following areas for tuning. The order in which steps are listed needs to be maintained to
prevent tuning side effects. For example, it is no good increasing the buffer cache if you can reduce I/O by
rewriting a SQL statement.
Database Design (if it's not too late):

Poor system performance usually results from a poor database design. One should
generally normalize to the 3NF. Selective denormalization can provide valuable performance
improvements. When designing, always keep the "data access path" in mind. Also look at proper
data partitioning, data replication, aggregation tables for decision support systems, etc.
Application Tuning:
Experience shows that approximately 80% of all Oracle system performance problems are
resolved by coding optimal SQL. Also consider proper scheduling of batch tasks after peak
working hours.
Memory Tuning:
Properly size your database buffers (shared_pool, buffer cache, log buffer, etc) by looking at your
wait events, buffer hit ratios, system swapping and paging, etc. You may also want to pin large
objects into memory to prevent frequent reloads.
Disk I/O Tuning:
Database files needs to be properly sized and placed to provide maximum disk subsystem
throughput. Also look for frequent disk sorts, full table scans, missing indexes, row chaining, data
fragmentation, etc.
Eliminate Database Contention:
Study database locks, latches and wait events carefully and eliminate where possible.
Tune the Operating System:
Monitor and tune operating system CPU, I/O and memory utilization. For more information, read
the related Oracle FAQ dealing with your specific operating system.
[edit]What
tools/utilities does Oracle provide to assist

with performance tuning?
Oracle provides the following tools/ utilities to assist with performance
monitoring and tuning:
ADDM (Automated Database Diagnostics Monitor) introduced in Oracle

10g
TKProf
Statspack
Oracle Enterprise Manager - Tuning Pack (cost option)
Old UTLBSTAT.SQL and UTLESTAT.SQL - Begin and end stats monitoring
[edit]When
is cost based optimization triggered?
It's important to have statistics on all tables for the CBO (Cost Based Optimizer)
to work correctly. If one table involved in a statement does not have statistics,
and optimizer dynamic sampling isn't performed, Oracle has to revert to rulebased optimization for that statement. So you really want for all tables to have
statistics right away; it won't help much to just have the larger tables analyzed.
Generally, the CBO can change the execution plan when you:
Change statistics of objects by doing an ANALYZE;
Change some initialization parameters (for example: hash_join_enabled,

sort_area_size, db_file_multiblock_read_count).
[edit]How
can one optimize %XYZ% queries?
It is possible to improve %XYZ% (wildcard search) queries by forcing the

optimizer to scan all the entries from the index instead of the table. This can be
done by specifying hints.
If the index is physically smaller than the table (which is usually the case) it will
take less time to scan the entire index than to scan the entire table.
[edit]Where
can one find I/O statistics per table?
The STATSPACK and UTLESTAT reports show I/O per tablespace. However,
they do not show which tables in the tablespace has the most I/O operations.
The $ORACLE_HOME/rdbms/admin/catio.sql script creates
a sample_io procedure and table to gather the required information. After
executing the procedure, one can do a simple SELECT * FROM
io_per_object; to extract the required information.
For more details, look at the header comments in the catio.sql script.
[edit]My
query was fine last week and now it is slow.
Why?
The likely cause of this is because the execution plan has changed. Generate a
current explain plan of the offending query and compare it to a previous one
that was taken when the query was performing well. Usually the previous plan
is not available.
Some factors that can cause a plan to change are:
Which tables are currently analyzed? Were they previously analyzed? (ie.
Was the query using RBO and now CBO?)
Has OPTIMIZER_MODE been changed in INIT<SID>.ORA?
Has the DEGREE of parallelism been defined/changed on any table?
Have the tables been re-analyzed? Were the tables analyzed using
estimate or compute? If estimate, what percentage was used?
Have the statistics changed?
Has the SPFILE/ INIT<SID>.ORA parameter

DB_FILE_MULTIBLOCK_READ_COUNT been changed?
Has the INIT<SID>.ORA parameter SORT_AREA_SIZE been changed?
Have any other INIT<SID>.ORA parameters been changed?
What do you think the plan should be? Run the query with hints to see if this
produces the required performance.
It can also happen because of a very high high water mark. Typically when a
table was big, but now only contains a couple of records. Oracle still needs to
scan through all the blocks to see if they contain data.
[edit]Does
Oracle use my index or not?
One can use the index monitoring feature to check if indexes are used by an
application or not. When the MONITORING USAGE property is set for an
index, one can query the v$object_usage to see if the index is being used or
not. Here is an example:
SQL> CREATE TABLE t1 (c1 NUMBER);

Table created.
SQL> CREATE INDEX t1_idx ON t1(c1);
Index created.
SQL> ALTER INDEX t1_idx MONITORING USAGE;
Index altered.
SQL>
SQL> Prompt this view should be consulted as the owner of
the object of interest (e.g. system will mostly see an
empty view).
SQL> SELECT table_name, index_name, monitoring, used FROM
v$object_usage;
TABLE_NAME
INDEX_NAME
MON USE
----------------------------------------------------------- --- --T1
T1_IDX
YES NO
SQL> SELECT * FROM t1 WHERE c1 = 1;
no rows selected
SQL> SELECT table_name, index_name, monitoring, used FROM
v$object_usage;
TABLE_NAME
INDEX_NAME
MON USE
----------------------------------------------------------- --- --T1
T1_IDX
YES YES
To reset the values in the v$object_usage view, disable index monitoring and
re-enable it:
ALTER INDEX indexname NOMONITORING USAGE;

ALTER INDEX indexname MONITORING
USAGE;
[edit]Why
is Oracle not using the darn index?
This problem normally only arises when the query plan is being generated by
the Cost Based Optimizer (CBO). The usual cause is because the CBO
calculates that executing a Full Table Scan would be faster than accessing the
table via the index. Fundamental things that can be checked are:
USER_TAB_COLUMNS.NUM_DISTINCT - This column defines the

number of distinct values the column holds.
USER_TABLES.NUM_ROWS - If NUM_DISTINCT = NUM_ROWS then

using an index would be preferable to doing a FULL TABLE SCAN. As the
NUM_DISTINCT decreases, the cost of using an index increase thereby
making the index less desirable.
USER_INDEXES.CLUSTERING_FACTOR - This defines how ordered the

rows are in the index. If CLUSTERING_FACTOR approaches the number
of blocks in the table, the rows are ordered. If it approaches the number of
rows in the table, the rows are randomly ordered. In such a case, it is
unlikely that index entries in the same leaf block will point to rows in the
same data blocks.
Decrease the INIT<SID>.ORA parameter

DB_FILE_MULTIBLOCK_READ_COUNT - A higher value will make the
cost of a FULL TABLE SCAN cheaper.
Remember that you MUST supply the leading column of an index, for the index
to be used (unless you use a FAST FULL SCAN or SKIP SCANNING).
There are many other factors that affect the cost, but sometimes the above can
help to show why an index is not being used by the CBO. If from checking the
above you still feel that the query should be using an index, try specifying an
index hint. Obtain an explain plan of the query either using TKPROF with
TIMED_STATISTICS, so that one can see the CPU utilization, or with

AUTOTRACE to see the statistics. Compare this to the explain plan when not
using an index.
[edit]When
should one rebuild an index?
You can run the ANALYZE INDEX <index> VALIDATE STRUCTURE command
on the affected indexes - each invocation of this command creates a single row
in the INDEX_STATS view. This row is overwritten by the next ANALYZE
INDEX command, so copy the contents of the view into a local table after each
ANALYZE. The 'badness' of the index can then be judged by the ratio of
'DEL_LF_ROWS' to 'LF_ROWS'.
For example, you may decide that index should be rebuilt if more than 20% of
its rows are deleted:
select del_lf_rows * 100 / decode(lf_rows,0,1,lf_rows)

from index_stats
where name = 'index_ name';
[edit]How
does one tune Oracle Wait event XYZ?
Here are some of the wait events from V$SESSION_WAIT and

V$SYSTEM_EVENT views:
db file sequential read: Tune SQL to do less I/O. Make sure all objects
are analyzed. Redistribute I/O across disks.
buffer busy waits: Increase DB_CACHE_SIZE (DB_BLOCK_BUFFERS

prior to 9i)/ Analyze contention from SYS.V$BH ("buffer busy waits" was
replaced with "read by other session" Oracle 10g).
log buffer space: Increase LOG_BUFFER parameter or move log files to

faster disks
log file sync: If this event is in the top 5, you are committing too often (talk
to your developers)
log file parallel write: deals with flushing out the redo log buffer to disk.
Your disks may be too slow or you have an I/O bottleneck.
Two useful sections in Oracle's Database Performance Tuning Guide:
Table of Wait Events and Potential Causes
Wait Events Statistics
[edit]What
is the difference between DBFile Sequential

and Scattered Reads?
Both "db file sequential read" and "db file scattered read" events signify time
waited for I/O read requests to complete. Time is reported in 100's of a second
for Oracle 8i releases and below, and 1000's of a second for Oracle 9i and
above. Most people confuse these events with each other as they think of how
data is read from disk. Instead they should think of how data is read into the
SGA buffer cache.
db file sequential read:
A sequential read operation reads data into contiguous memory (usually a
single-block read with p3=1, but can be multiple blocks). Single block I/Os are
usually the result of using indexes. This event is also used for rebuilding the
controlfile and reading datafile headers (P2=1). In general, this event is
indicative of disk contention on index reads.
db file scattered read:
Similar to db file sequential reads, except that the session is reading multiple
data blocks and scatters them into different discontinuous buffers in the SGA.
This statistic is NORMALLY indicating disk contention on full table scans.
Rarely, data from full table scans could be fitted into a contiguous buffer area,
these waits would then show up as sequential reads instead of scattered reads.
The following query shows average wait time for sequential versus scattered
reads:
prompt
select
READ"
from
where
and
"AVERAGE WAIT TIME FOR READ REQUESTS"

a.average_wait "SEQ READ", b.average_wait "SCAT
sys.v_$system_event a, sys.v_$system_event b
a.event = 'db file sequential read'
b.event = 'db file scattered read';
[edit]How
does one tune the Redo Log Buffer?
The size of the Redo log buffer is determined by the LOG_BUFFER parameter
in your SPFILE/INIT.ORA file. The default setting is normally 512 KB or (128 KB
* CPU_COUNT), whichever is greater. This is a static parameter and its size
cannot be modified after instance startup.
SQL> show parameters log_buffer

NAME
TYPE
value
------------------------------------ ---------------------------------------log_buffer
integer
262144
When a transaction is committed, info in the redo log buffer is written to a Redo
Log File. In addition to this, the following conditions will trigger LGWR to write
the contents of the log buffer to disk:
Whenever the log buffer is MIN(1/3 full, 1 MB) full; or
Every 3 seconds; or
When a DBWn process writes modified buffers to disk (checkpoint).
Larger LOG_BUFFER values reduce log file I/O, but may increase the time
OLTP users have to wait for write operations to complete. In general, values
between the default and 1 to 3MB are optimal. However, you may want to make
it bigger to accommodate bulk data loading, or to accommodate a system with
fast CPUs and slow disks. Nevertheless, if you set this parameter to a value
beyond 10M, you should think twice about what you are doing.
SQL> SELECT name, value

2
FROM SYS.v_$sysstat
3
WHERE NAME in ('redo buffer allocation retries',
4
'redo log space wait time');
NAME
value
--------------------------------------------------------------- ---------redo buffer allocation retries
3
redo log space wait time
0
Statistic "REDO BUFFER ALLOCATION RETRIES" shows the number of times

a user process waited for space in the redo log buffer. This value is cumulative,
so monitor it over a period of time while your application is running. If this value
is continuously increasing, consider increasing your LOG_BUFFER (but only if
you do not see checkpointing and archiving problems).
"REDO LOG SPACE WAIT TIME" shows cumulative time (in 10s of
milliseconds) waited by all processes waiting for space in the log buffer. If this
value is low, your log buffer size is most likely adequate.
DBMS SHARED POOL

This article explains how to use the DBMS_SHARED_POOL package to manage the SHARED_POOL in
the instance's SGA:
Contents
[hide]
1 Install the DBMS_SHARED_POOL package

2 Check for objects in the Shared Pool larger than X KBytes
3 Pin something into the Shared Pool
4 Unpin something from the Shared Pool
5 Check what objects are pinned
[edit]Install
the DBMS_SHARED_POOL package
connect SYS AS SYSDBA

@?/rdbms/admin/dbmspool.sql
@?/rdbms/admin/prvtpool.plb
[edit]Check
for objects in the Shared Pool larger than X KBytes
set serveroutput on size 50000

exec dbms_shared_pool.sizes(200);
[edit]Pin
something into the Shared Pool
exec dbms_shared_pool.keep('SYS.STANDARD');
[edit]Unpin
something from the Shared Pool
exec dbms_shared_pool.unkeep('SYS.STANDARD');
[edit]Check
what objects are pinned
SELECT * FROM v$db_object_cache WHERE kept = 'YES';
PS: Looks like Oracle pins some objects by itself.
Improving Buffer Cache Hit Ratio

Many DBAs do their best to get a 99% or better buffer cache hit ratio, but quickly discover that the
performance of their database isn't improving as the hit ratio gets better.
Here is a query to get your database's current hit ratio:
SQL> -- Get
SQL> SELECT
Ratio"
2
FROM
3
WHERE
4
AND
5
AND
6 /
initial Buffer Hit Ratio reading...

ROUND((1-(phy.value / (cur.value + con.value)))*100,2) "Cache Hit
v$sysstat cur, v$sysstat con, v$sysstat phy
cur.name = 'db block gets'
con.name = 'consistent gets'
phy.name = 'physical reads'
Cache Hit Ratio

--------------90.75
However, to show how meaningless this number is, let's artificially increase it:
SQL>
SQL>
SQL>
2
3
4
5
6
7
8
-- Let's artificially increase the buffer hit ratio...

DECLARE
v_dummy dual.dummy%TYPE;
BEGIN
FOR I IN 1..10000000 LOOP
SELECT dummy INTO v_dummy FROM dual;
END LOOP;
END;
/
PL/SQL procedure successfully completed.
Let's see what happened:
SQL>
SQL> -- Let's measure it again...
SQL> SELECT
Ratio"
2
FROM
3
WHERE
4
AND
5
AND
6 /
ROUND((1-(phy.value / (cur.value + con.value)))*100,2) "Cache Hit

v$sysstat cur, v$sysstat con, v$sysstat phy
cur.name = 'db block gets'
con.name = 'consistent gets'
phy.name = 'physical reads'
Cache Hit Ratio

--------------99.94
Conclusion: Don't even bother trying to tune the Buffer Hit Ratio!
There are better ways to tune now. The Oracle Wait Interface (OWI) provides exact details. No need to
rely on fuzzy meaningless counters anymore.
Explain Plan
EXPLAIN PLAN parses a query and records the "plan" that Oracle devises to execute it. By examining
this plan, you can find out if Oracle is picking the right indexes and joining your tables in the most efficient
manner. There are a few different ways to utilize Explain Plan. We will focus on using it
through SQL*Plus since most Oracle programmers have access to SQL*Plus.
Contents
[hide]
1 Creating a Plan Table

2 Explain Plan Syntax
3 Formatting the output
4 Some Examples
5 Using SQL*Plus Autotrace
6 Also see
[edit]Creating
a Plan Table
The first thing you will need to do is make sure you have a table called PLAN_TABLE available in your
schema. The following script will create it for you if you don't have it already:
@?/rdbms/admin/utlxplan.sql
[edit]Explain
Plan Syntax
EXPLAIN PLAN FOR your-sql-statement;
or
EXPLAIN PLAN SET STATEMENT_ID = statement_id FOR your-sql-statement;
[edit]Formatting
the output
After running EXPLAIN PLAN, Oracle populates the PLAN_TABLE table with data that needs to be
formatted to presented to the user in a more readable format. Several scripts exist for this, however, one
of the easiest methods available is to cast dbms_xplan.display to a table and select from it (see examples
below).
[edit]Some
Examples
SQL> EXPLAIN PLAN FOR select * from dept where deptno = 40;
Explained.
SQL> set linesize 132
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------
Plan hash value: 2852011669

-------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost (%CPU)|
Time
|
-------------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
1 |
20 |
1
(0)|
00:00:01 |
|
1 | TABLE ACCESS BY INDEX ROWID| DEPT
|
1 |
20 |
1
(0)|
00:00:01 |
|* 2 |
INDEX UNIQUE SCAN
| PK_DEPT |
1 |
|
0
(0)|
00:00:01 |
-------------------------------------------------------------------------------------Predicate Information (identified by operation id):
--------------------------------------------------2 - access("DEPTNO"=40)
14 rows selected.
[edit]Using
SQL*Plus Autotrace
SQL*Plus also offers an AUTOTRACE facility that will display the query plan and execution statistics as
each query executes. Example:
SQL> SET AUTOTRACE ON

SQL> select * from dept where deptno = 40;
DEPTNO DNAME
LOC
---------- -------------- ------------40 OPERATIONS
BOSTON
Execution Plan
---------------------------------------------------------Plan hash value: 2852011669
-------------------------------------------------------------------------------------| Id | Operation
| Name
Time
|
-------------------------------------------------------------------------------------|
|
|
1 |
20 |
1
(0)|
00:00:01 |
|
|
1 |
20 |
1
(0)|
00:00:01 |
|* 2 |
INDEX UNIQUE SCAN
| PK_DEPT |
1 |
|
0
(0)|
00:00:01 |
--------------------------------------------------2 - access("DEPTNO"=40)
Statistics
---------------------------------------------------------0 recursive calls
0 db block gets
2 consistent gets
0 physical reads
0 redo size
443 bytes sent via SQL*Net to client
374 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
DBMS XPLAN
DBMS_XPLAN (DBMS Explain Plan) is a PL/SQL package used for formatting and displaying SQL query
plans.
[edit]Examples
Statements:
explain plan for select * from t1 where num_col = '1';

select * from table(dbms_xplan.display);
Statements with sample output:
SQL> EXPLAIN PLAN FOR select * from dept where deptno = 40;
Explained.
SQL> set linesize 132
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------Plan hash value: 2852011669
-------------------------------------------------------------------------------------| Id | Operation
| Name
Time
|
-------------------------------------------------------------------------------------|
|
|
1 |
20 |
1
(0)|
00:00:01 |
|
|
1 |
20 |
1
(0)|
00:00:01 |
|* 2 |
INDEX UNIQUE SCAN
| PK_DEPT |
1 |
|
0
(0)|
00:00:01 |
--------------------------------------------------2 - access("DEPTNO"=40)
14 rows selected.
Hint
A hint is code snippet that is embedded into a SQL statement to suggest to Oracle how the statement
should be executed. Some examples: ALL_ROWS, FIRST_ROWS, CHOOSE, RULE, INDEX, FULL,
ORDERED, STAR.
Hints should only be used as a last-resort if statistics were gathered and the query is still following a suboptimal execution plan.
Contents
[hide]
1 Hint syntax
2 Available hints
3 Some examples
4 Also see
[edit]Hint
syntax
Hints must be included into a comment followed by a +-sign right after the first keyword of the statement.
Examples:
--+RULE
/*+RULE */
[edit]Available
hints
Some of the more useful hints are:
ORDERED - usually with USE_NL to get Oracle to not hash join
INDEX(t index_name) - where Oracle chooses the wrong index over the correct one
NO_INDEX - prevent an index from being used
INDEX_COMBINE - merging bitmap indexes (use when Oracle does not merge bitmap indexes)
FIRST_ROWS(n) - when you only want the first few rows
PARALLEL - to force parallel query on certain specific queries
GATHER_PLAN_STATISTICS - used as a handy sql trace
DYNAMIC_SAMPLING - used as alternative to statistics for large-scale warehouse queries
OPT_PARAM - used to control optimizer behavior at query level (added in 10.2.0.3)
QB_NAME - specify query block name when tuning complex queries. It helps in finding a
particular query for troubleshooting (10 and up)
CARDINALITY - give the optimizer better information
[edit]Some
examples
Example suggesting that a FULL TABLE SCAN method be used:
SELECT /*+ FULL(x) */ FROM tab1 x WHERE col1 = 10;
Suggest that Oracle uses a specific index:
SELECT /*+ INDEX(x emp_idx1) */ ... FROM scott.emp x...
Suggest that Oracle DOES NOT USE a specific index:
SELECT /*+ NO_INDEX(x emp_idx1) */ ... FROM scott.emp x...
SQL Trace
This article lists the commands required to trace SQL statements executed by a user, an application or
the entire database.
Contents
[hide]
1 Tracing a SQL session
1.1 Start session trace
1.2 Stop session trace
1.3 Tracing other user's sessions

2 Tracing an entire database
3 Identifying trace files
4 Size of trace files
5 Formatting output
6 Also see
7 External links
[edit]Tracing
[edit]Start
a SQL session
session trace
To start a SQL trace for the current session, execute:
ALTER SESSION SET sql_trace = true;
You can also add an identifier to the trace file name for later identification:
ALTER SESSION SET sql_trace = true;

ALTER SESSION SET tracefile_identifier = mysqltrace;
[edit]Stop
session trace
To stop SQL tracing for the current session, execute:
ALTER SESSION SET sql_trace = false;
[edit]Tracing
other user's sessions
DBA's can use DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION to trace problematic database

sessions. Steps:
Get the SID and SERIAL# for the process you want to trace.
SQL> select sid, serial# from sys.v_$session where ...

SID
SERIAL#
---------- ---------8
13607
Enable tracing for your selected process:
SQL> ALTER SYSTEM SET timed_statistics = true;

SQL> execute dbms_system.set_sql_trace_in_session(8, 13607, true);
Ask user to run just the necessary to demonstrate his problem.
Disable tracing for your selected process:
SQL> execute dbms_system.set_sql_trace_in_session(8,13607, false);
Look for trace file in USER_DUMP_DEST:
$ cd /app/oracle/admin/oradba/udump
$ ls -ltr
total 8
-rw-r----1 oracle
dba
[edit]Tracing
2764 Mar 30 12:37 ora_9294.trc
an entire database
To enable SQL tracing for the entire database, execute:
ALTER SYSTEM SET sql_trace = true SCOPE=MEMORY;
To stop, execute:
ALTER SYSTEM SET sql_trace = false SCOPE=MEMORY;
[edit]Identifying
trace files
Trace output is written to the database's UDUMP directory.

The default name for a trace files is INSTANCE_PID_ora_TRACEID.trc where:
INSTANCE is the name of the Oracle instance,
PID is the operating system process ID (V$PROCESS.OSPID); and
TRACEID is a character string of your choosing.
[edit]Size
of trace files
The trace file size is limited by the parameter MAX_DUMP_FILE_SIZE. The unit of this parameter, if you
don't specify the K or M option, is in OS block size.
Be sure this parameter is set to a value high enough for your purpose (e.g. some MB). Of course this
depends on the amount and complexitiy of statements which have to be run while tracing. If this value is
set too low, possibly the dump file size limit will be reached before the execution of the crucial statements
and the trace file will be closed before the interesting parts can be recorded in it.
On the other hand, when this parameter is set to UNLIMITED (default value), if the program to be traced
is working forth and forth and the trace mode is not finished, the trace file can grow without limit which
means until the associated file system or disk is full. A DBA can stop the trace of a session using the
DBMS_MONITOR (10g and up), DBMS_SYSTEM or DBMS_SUPPORT package.
[edit]Formatting
output
Trace output is quite unreadable. However, Oracle provides a utility, called TKProf, that can be used to
format trace output.
Statspack
Statspack is a set of performance monitoring and reporting utilities provided by Oracle starting
from Oracle 8i and above. Statspack provides improved BSTAT/ESTAT functionality, though the old
BSTAT/ESTAT scripts are still available. For more information about STATSPACK, read the
documentation in file $ORACLE_HOME/rdbms/admin/spdoc.txt.
Although AWR and ADDM (introduced in Oracle 10g) provide better statistics than STATSPACK, users that are not licensed to use the
Contents
[hide]
1 Install statspack
2 Take performance snapshots of the database
3 Statspack reporting
4 Other statspack scripts
5 Potential problems
6 External links
[edit]Install
statspack
cd $ORACLE_HOME/rdbms/admin
sqlplus "/ as sysdba" @spdrop.sql
sqlplus "/ as sysdba" @spcreate.sql
prompted
[edit]Take
-- Drop and install statspack

-- Enter tablespace names when
performance snapshots of the database
sqlplus perfstat/perfstat
exec statspack.snap;
-- Take a performance snapshots
-- or :
exec perfstat.statspack.snap(i_snap_level=>10); -- or instruct statspack to
do gather more details in the snapshot
-- (look up which oracle
version supports which level).
The spauto.sql script can be customized and executed to schedule the collection of STATPACK
snapshots.
[edit]Statspack
reporting
-- Get a list of snapshots

select SNAP_ID, SNAP_TIME from STATS$SNAPSHOT;
@spreport.sql
difference report
[edit]Other
-- Enter two snapshot id's for
statspack scripts
Some of the other statspack scripts are:

sppurge.sql - Purge (delete) a range of Snapshot Id's between the specified begin and end Snap
Id's
spauto.sql - Schedule a dbms_job to automate the collection of STATPACK statistics
spcreate.sql - Installs the STATSPACK user, tables and package on a database (Run as SYS).
spdrop.sql - Deinstall STATSPACK from database (Run as SYS)
spreport.sql - Report on differences between values recorded in two snapshots
sptrunc.sql - Truncates all data in Statspack tables
[edit]Potential
problems
Statpack reporting suffers from the following problems:
Some statistics may only be reported on COMPLETION of a query. For example, if a query runs
for 12 hours, its processing won't be reported during any of the snapshots taken while the query was
busy executing.
If queries are aged out of the shared pool, the stats from V$SQL are reset. This can throw off the
delta calculations and even make it negative. For example, query A has 10,000 buffer_gets at
snapshot 1, but at snapshot #2, it has been aged out of the pool and reloaded and now shows only
1,000 buffer_gets. So, when you run spreport.sql from snapshot 1 to 2, you'll get 1,000-10,000 =
-9,000 for this query.
AWR
AWR (Automatic Workload Repository) is a built-in repository (in the SYSAUX tablespace) that exists in
every Oracle Database. At regular intervals, the Oracle Database makes a snapshot of all of its vital
statistics and workload information and stores them in the AWR.
Contents
[hide]
1 History
2 Licensing
3 Change snapshot settings
4 Also see
5 External links
[edit]History
AWR was first introduced with Oracle 10g.
[edit]Licensing
Only users that licensed Oracle Enterprise Manager Diagnostic Pack are entitled to use AWR. Other
users should continue to use Statspack.
[edit]Change
snapshot settings
BEGIN
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(
retention => 43200,
interval => 10);
END;
/
SELECT * FROM dba_hist_wr_control;
TKProf
TKProf is an Oracle database utility used to format SQL Trace output into human readable format. The
TKProf executable is located in the ORACLE HOME/bin directory.
[edit]Start
TKProf
Syntax is:
tkprof input.trc output.prf [options]
Example:
$ tkprof orcl102_ora_3064.trc output.prf EXPLAIN=scott/tiger SYS=NO
[edit]Sample
output
For the above example, the output would be in file output.prf:
Tkprof: Release 9.2.0.1.0 - Production on Tue Dec 24 15:32:43 2002

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Trace file: ORCL102_ora_3064.trc

Sort options: default
******************************************************************************
**
count
= number of times OCI procedure was executed
cpu
= cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk
= number of physical reads of buffers from disk
query
= number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows
= number of rows processed by the fetch or execute call
******************************************************************************
**
select *
from
employee where emp_id = 3737
call
count
rows
------- --------------Parse
10
0
Execute
10
0
Fetch
20
10
------- --------------total
40
10
cpu
elapsed
disk
query
-------- ---------- ---------- ---------- ---------0.00
0.03
0.00
0.00
0.34
0.35
72
4730
-------- ---------- ---------- ---------- ---------0.34
0.39
72
4730
Misses in library cache during parse: 1

Optimizer goal: CHOOSE
Parsing user id: 59
Rows
------1
current
Row Source Operation

--------------------------------------------------TABLE ACCESS FULL EMPLOYEE
How to read AWR reports

TogenerateAWR,readmyarticle
http://bashdba.blogspot.com/search/label/AWR?updatedmax=20110927T12%3A36%3A0004%3A00&max
results=20
OKletstartanalysingAWR
ThisistheexampleofAWRreport.IhavetriedheretodiscussthefindingofsampleAWRreportIhavegenerated.
ReportHeader
Thissectionisselfexplanatorywhichprovidesdatabasename,id,instanceifRAC,platforminformationandsnap
interval.(databaseworkloadtimedurationinreview).
Thisreportisforinstancenumber2ofmyRACenvironment.SoifyouneedtotheanalysisonRACenvironment,
youneedtodoitseparatelyofalltheinstancesintheRACtoseeifalltheinstancesarebalancedthewaythey
shouldbe.
DBName
TestRAC
DBId
Instance Instnum
3626203793 TestRac2
HostName
TestRAC
Platform
Release RAC
2 17Aug1119:08 11.1.0.6.0 YES
CPUs Cores Sockets Memory(GB)
Linux64bitforAMD
SnapId
Startup
Time
SnapTime
Sessions
31.44
Cursors/Session
BeginSnap:
28566 27Sep1101:00:21
130
4.8
EndSnap:
28567 27Sep1102:00:43
135
4.5
Elapsed:
60.35(mins)
DBTime:
15.07(mins)
Begin
End
BufferCache:
5,888M
5,888M StdBlockSize:
SharedPoolSize:
8,704M
8,704M LogBuffer:
8K
138,328K
LoadProfile
Thissectionprovidesthesnapshotofthedatabaseworkloadoccurredduringthesnapshotinterval.
PerSecond PerTransaction PerExec PerCall

DBTime(s):
0.3
0.1
0.00
0.00
DBCPU(s):
0.3
0.1
0.00
0.00
48,933.6
19,916.2
1,124.4
457.7
Blockchanges:
195.9
79.7
Physicalreads:
80.5
32.8
Physicalwrites:
4.3
1.8
Usercalls:
141.4
57.6
Parses:
123.2
50.2
2.2
0.9
1,940,807.0
789,918.9
4.3
1.7
127.6
51.9
Rollbacks:
0.0
0.0
Transactions:
2.5
Redosize:
Logicalreads:
Hardparses:
W/AMBprocessed:
Logons:
Executes:
DBtime(s):
Itstheamountoftimeoraclehasspentperformingdatabaseusercalls.Notitdoesnotincludebackground
processes.
DBCPU(s):
ItstheamountofCPUtimespentonusercalls.SameasDBtimeitdoesnotincludebackgroundprocess.Thevalue
isinmicroseconds
Redosize:
Forexample,thetablebelowshowsthatanaveragetransactiongeneratesabout19,000ofredodataalongwith
around48,000redopersecond.
Logicalreads:
ConsistentGets+DBblocksGets=Logicalreads
BlockChanges:
Thenumberofblockmodifiedduringthesampleinterval
Physicalreads:
NoofblockrequestcausingI/Ooperation
Physicalwrites:
Numberofphysicalwritesperformed
Usercalls:
Numberofuserqueriesgenerated
Parses:
Thetotalofallparses;bothhardandsoft.
HardParses:
TheparsesrequiringacompletelynewparseoftheSQLstatement.Theseconsumebothlatchesandsharedpool
area.
SoftParses:
Softparsesarenotlistedbutderivedbysubtractingthehardparsesfromparses.Asoftparsereusesaprevioushard
parse;henceitconsumesfarfewerresources.
Sorts:
Noofsortsperformed
Logons:
Nooflogonsduringtheinterval
Executes:
NoofSQLExecutes
Transactions:
Nooftransactionspersecond
InstanceEfficiencyPercentages(Target100%)
Instanceefficiencyshouldbecloseto100%
BufferNowait%:
99.99 RedoNoWait%:
100.00
BufferHit%:
93.06 InmemorySort%:
100.00
LibraryHit%:
98.67 SoftParse%:
98.20
ExecutetoParse%:
3.40 LatchHit%:
99.98
ParseCPUtoParseElapsd%:
0.01 %NonParseCPU:
96.21
ExecutetoParse%amdParseCPUtoParseElapsd%:
Ifthethevaluearelowlikeintheabovecaseof3.40and0.01meansthattherecouldbeaparsingproblem.You
mayneedtolookatbindvariableissuesorsharedpoolsizingissue.
RedoNoWait%:
Usuallythisstatsis99orgreater
InmemorySort%:
Thiscantellyouhowefficientisyousort_area_size,hash_area_sizeorpga_aggrigate_targetare.Ifyoudonthave
adequatesizesofsort,hashandpgaparameters,thenyouinmemorysortpercentwillgodown
Softparse%:
with98.20%forthesoftparsemeaningthatabout1.72%(100softparse)ishappeningforhardparsing.You
mightwanttolookatyoubindvariablesissues.
LatchHit%:
shouldbecloseto100.
%NonParseCPU:
Mostofourstatementswerealreadyparsedsoweweren'tdoingalotofreparsing.ReparsingishighonCPUand
shouldbeavoided.
SharedPoolStatistics
Begin
End
MemoryUsage%:
73.86
75.42
%SQLwithexecutions>1:
92.61
93.44
%MemoryforSQLw/exec>1:
94.33
94.98
MemoryUsage%isthesharedpoolusage.Soherewehaveuse73.86percentofoursharedpoolandoutofthat
almost94percentisbeingreused.ifMemoryUsage%istoolargelike90%itcouldmeanthatyoursharedpoolis
toolsmallandifthepercentisin50forexamplethenthiscouldmeanthatyousharedpoolistoolarge
Top5TimedForegroundEvents
Event
Waits
DBCPU
logfilesync
dbfilescatteredread
librarycachepin
dbfilesequentialread
Time(s)
Avgwait(ms)
%DBtime
1,019
WaitClass
112.73
25,642
43
4.73 Commit
3,064
40
13
4.43 UserI/O
136,267
27
2.98 Concurrency
7,608
24
2.71 UserI/O
itscriticaltolookintothissection.Ifyouturnoffthestatisticparameter,thentheTime(s)wont
appear.WaitanalysisshouldbedonewithrespecttoTime(s)astherecouldbemillionofwaitsbutifthathappens
forasecondorsothenwhocares.Therefore,timeisveryimportantcomponent.
Soyouhaveseveraldifferenttypesofwaits.SoyoumayseethedifferentwaitsonyourAWRreport.So
letsdiscussthemostcommonwaits.
dffiletypewaits:
dbfilesequentialread:
Isthewaitthatcomesfromthephysicalsideofthedatabase.itrelatedtomemorystarvationandnonselectiveindex
use.sequentialreadisanindexreadfollowedbytablereadbecauseitisdoingindexlookupswhichtellsexactly
whichblocktogoto
dbfilescatteredread:
causedduetofulltablescansmaybebecauseofinsufficientindexesorunavilablityofupdatedstatistics
directPathwrites:
Youwontseethemunlessyouaredoingsomeappendsordataloads
directPathreads:
couldhappenifyouaredoingalotofparallelqueryactivity
dbfileparallelwrites/read:
ifyouaredoingalotofpartitionactivitythenexpecttoseethatwaiteven.itcouldbeatableorindexpartition
dbfilesinglewrite:
ifyouseethiseventthanprobablyyouhavealotofdatafilesinyourdatabase.
directpathreadtempordirectpathwritetemp:
thiswaiteventshowsTempfileactivity(sort,hashes,temptables,bitmap)
checkpgaparameterorsortareaorhashareaparameters.Youmightwanttoincreasethem
buffer type waits

so what's going on in your memory
latch: cache buffer chains:
check hot objects
free buffer waits:
insufficient buffers, process holding buffers too long or i/o subsystem is over loaded. Also check you db
writes may be getting clogged up.
buffer busy waits:
see what is causing them further along in report. most of the time its data block related.
gc buffer busy:
its in the RAC environment. caused may be because of not enough memory on your nodes,overloaded
interconnect. Also look RAC specific section of the report latch:
cache buffers lru chain Freelist issues, hot blocks latch: cache buffer handles Freelist issues, hot
blocks
buffer busy - See what is causing them further along in report
no free buffers Insufficient buffers, dbwr contention
Log Type Waits

log file parallel write Look for log file contention
log buffer space Look at increasing log buffer size
log file switch (checkpoint incomplete) May indicate excessive db files or slow IO subsystem
log file switch (archiving needed) Indicates archive files are written too slowly
log file switch completion May need more log files per
log file sync Could indicate excessive commits
GC Events
gccr multi block request Full table or index scans
gc current multi block request Full table or index scans
gccr block 2-way Blocks are busy in another instance, check for block level contention or hot blocks
gccr block 3-way Blocks are busy in another instance, check for block level contention or hot blocks
gccr block busy Blocks are busy in another instance, check for block level contention or hot blocks
gccr block congested cr block congestion, check for hot blocks or busy interconnect
gccr block lost Indicates interconnect issues and contention
gc current block 2-way Blocks are busy in another instance, check for block level contention or hot
blocks
gc current block 3-way Blocks are busy in another instance, check for block level contention or hot
blocks
gc current block busy Block is already involved in GC operation, shows hot blocks or congestion
gc current block congested current block congestion, check for hot blocks or busy interconnect
gc current block lost - Indicates interconnect issues and contention
Undo Events
undo segment extension If excessive, tune undo
latch: In memory undo latch If excessive could be bug, check for your version, may have to turn off in
memory undo
wait for a undo record Usually only during recovery of large transactions, look at turning off parallel
undo recovery.
What Next?
Determine wait events of concern
Drill down to specific sections of report for deeper analysis
Use custom scripts, ADDM and Ash to investigate issues
AWR report scenarios

What is AWR:
1. Background process
2. A set of tables
3. A set of reports
4. Takes snapshots of statistics every hour
5. Take snapshots of high-cost SQL every hour
If you do not have Oracle Enterprise Manager tool installed then you can create the AWR reports
manually using the following commands:
1. Creating Snapshot
BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
END;
/
The list of the snapshot Ids along with database Ids is availabe in the view DBA_HIST_SNAPSHOT.
2. Dropping a Range of Snapshots.Refer to the DBA_HIST_SNAPSHOT view column SNAP_ID to view
available snapshots. To delete contain SNAP_ID from from 102 to 122,
BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE (low_snap_id => 102, high_snap_id
=> 122, dbid => 8187786345);
END;
/
3. Modifying Snapshot SettingsIf you want to modify the retention period as 43200 minutes (30 days),
the interval between each snapshot is specified as 30 minutes, and the number of Top SQL to flush for
each SQL criteria as 100 then use following:
BEGIN
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention => 43200,
interval => 30, topnsql => 100, dbid => 7123356265);
END;
/
The dbid is optional.
4. Extract the AWR DataThe awrextr.sql script extracts the AWR data for a range of snapshots from the
database into a Data Pump export file. Once created, this dump file can be transported to another system
where the extracted data can be loaded. To run the awrextr.sql script, you need to be connected to the
database as the SYS user.
To extract AWR data at the SQL prompt, enter:
SQL> @$ORACLE_HOME/rdbms/admin/awrextr.sql
5. Load the AWR DataOnce the export dump file is transported to the target system, you can load the
extracted AWR data using the awrload.sql script. The awrload.sql script will first create a staging schema
where the snapshot data is transferred from the Data Pump file into the database. The data is then
transferred from the staging schema into the appropriate AWR tables. To run the awrload.sql script, you
need to be connected to the database as the SYS user.
To load AWR data at the SQL prompt, enter:
SQL> @$ORACLE_HOME/rdbms/admin/awrload.sql
6. Generate AWR ReportsThe awrrpt.sql SQL script generates an HTML or text report that displays
statistics for a range of snapshot Ids.
To generate an HTML or text report for a range of snapshot Ids, run the awrrpt.sql script at the SQL
prompt:
SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sql
First, you need to specify whether you want an HTML or a text report.
Enter value for report_type: text
Specify the number of days for which you want to list snapshot Ids.
Enter value for num_days: 2
After the list displays, you are prompted for the beginning and ending snapshot Id for the workload
repository report.
Enter value for begin_snap: 95
Enter value for end_snap: 97
Next, accept the default report name or enter a report name. The default name is accepted in the
following example:
Enter value for report_name:
Using the report name awrrpt_1_95_97
The workload repository report is generated.
awrrpt.sql
The awrrpt.sql SQL script generates an HTML or text report that displays statistics for a range of snapshot
Ids.
awrrpti.sql
The awrrpti.sql SQL script generates an HTML or text report that displays statistics for a range of
snapshot Ids on a specified database and instance.
awrsqrpt.sql
The awrsqrpt.sql SQL script generates an HTML or text report that displays statistics of a particular SQL
statement for a range of snapshot Ids. Run this report to inspect or debug the performance of a SQL
statement.
awrsqrpi.sql
The awrsqrpi.sql SQL script generates an HTML or text report that displays statistics of a particular SQL
statement for a range of snapshot Ids on a specified database and instance. Run this report to inspect or
debug the performance of a SQL statement on a specific database and instance.
awrddrpt.sql
The awrddrpt.sql SQL script generates an HTML or text report that compares detailed performance
attributes and configuration settings between two selected time periods.

awrddrpi.sql
The awrddrpi.sql SQL script generates an HTML or text report that compares detailed performance
attributes and configuration settings between two selected time periods on a specific database and
instance.
AWR Architecture
Oracle 10g - awrArchitecture

AWR Features :
Automatic Workload Repository (AWR) collects processes and maintains performance statistics for
problem detection & self tuning purposes.
The AWR is used to collect performance statistics including:
Wait events used to identify performance problems.

Time model statistics indicating the amount of DB time associated with a process from
theV$SESS_TIME_MODEL and V$SYS_TIME_MODEL views.
Active Session History (ASH) statistics from the V$ACTIVE_SESSION_HISTORY view.
Some system and session statistics from the V$SYSSTAT and V$SESSTAT views.
Object usage statistics.
Resource intensive SQL statements.
The repository is a source of information for several other Oracle 10g features including:
Automatic Database Diagnostic Monitor
SQL Tuning Advisor
Undo Advisor
Segment Advisor
AWR Space Requirements
Space requirement for AWR depends on following:

Number of active sessions in system at given time.
Snapshot interval Frequency at which snapshot are captured.

Historical data retention period.
Estimate:
Snapshot interval
: 1 hr
No of sessions
: 10
Retention period : 7 days

=======================================
Space for AWR
: 200 300 MB
=======================================
Initialization parameters & Grants
STATISTICS_LEVEL > TYPICAL or ALL
Note: BASIC turns off in-memory collection of many system statistics.
User running AWR packages needs DBA role.

Note:
For STATISTICS_LEVEL, default setting is TYPICAL which ensures collection of all major
statistics required for database self-management functionality and provides best overall performance.
The default value should be adequate for most environments.
When the STATISTICS_LEVEL parameter is set to ALL, additional statistics are added to the set
of statistics collected with the TYPICAL setting. The additional statistics are timed OS statistics and
plan execution statistics.
Setting the STATISTICS_LEVEL parameter to BASIC disables the collection of many of the
important statistics required by Oracle Database features and functionality, including:
AWR Automated Snapshots
Oracle Database 10g uses a scheduled job, GATHER_STATS_JOB, to collect AWR statistics.
This job is created, and enabled automatically, when you create a new Oracle database under Oracle
Database 10g.
Note: GATHER_STATS_JOB is Oracle defined automatic optimizer statistics collection job run by SYS.
For more information refer DBA_SCHEDULER_JOBS, DBA_SCHEDULER_JOB_RUN_DETAILS
Checking current Configuration in database
Use following query to check the current settings of GATHER_STATS_JOB in any database:
SELECT a.job_name, a.enabled, c.window_name, c.schedule_name,
c.start_date, c.repeat_interval
FROM dba_scheduler_jobs a,
dba_scheduler_wingroup_members b,
dba_scheduler_windows c
WHERE job_name=GATHER_STATS_JOB
And a.schedule_name=b.window_group_name
And b.window_name=c.window_name;
To check the AWR snap interval & Retention time use following query:
SELECT * FROM DBA_HIST_WR_CONTROL
Sample Result
DBID
SNAP_INTERVAL
RETENTION
TOPNSQL
1195050809
+00000 01:00:00.0
+00007 00:00:00.0
DEFAULT
Generate AWR Report

Oracle provides two scripts to produce workload repository reports (awrrpt.sql and awrrpti.sql).
@$ORACLE_HOME/rdbms/admin/awrrpt.sql
@$ORACLE_HOME/rdbms/admin/awrrpti.sql
Note: awrrpt.sql & awrrpti.sql are exactly same except that awrrpti report allows specific instance to
report on. awrrpti.sql asks to enter dbid for particular instance of interest.
Execution of script
DB Id
SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sql
DB Name
Inst Num
Instance
1195050809
O01ABC0
O01ABC0
Specify the Report Type : (html / txt)

Specify the number of days of snapshots to choose: This will show the snap id along with the
time data.
Instance
DB Name
Snap Id
Snap Started
Level
O01ABC0
5653
O01ABC0
01 Apr 2008 01:00
5654
5655
5652
01 Apr 2008 00:00

1
01 Apr 2008 02:00

01 Apr 2008 03:00
1
1
Specify the Begin and End Snapshot Ids: Choose from the list displayed due to previous point.
Specify the Report Name: If leave blank then it will take default file name.
FTP the result in the local drive and view the results
Changing AWR Configuration
Oracle Default Settings

Snap Time
: 1 hr
Snap Retention
: 7 days
Snapshot
Snapshots & Baselines are sets of historical data for a specific time period that are used for
performance comparison.
Change snapshot default settings by using following package:
BEGIN
DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings (
retention => 43200,
interval => 30);
Minutes (= 30 Days). Current value retained if NULL.

Minutes. Current value retained if NULL.
END;
/
Extra snapshots can be taken and existing snapshots can be removed using:
EXEC DBMS_WORKLOAD_REPOSITORY.create_snapshot;
BEGIN
DBMS_WORKLOAD_REPOSITORY.drop_snapshot_range (
low_snap_id => 22,
high_snap_id => 32);
END;
/
Baseline
A baseline is a pair of snapshots that represents a specific period of usage. Once baselines are defined
they can be used to compare current performance against similar periods in the past.
Create Baseline:
BEGIN
DBMS_WORKLOAD_REPOSITORY.create_baseline (
start_snap_id => 210,
end_snap_id
=> 220,
baseline_name => batch baseline);

END;
/
The pair of snapshots associated with a baseline is retained until the baseline is explicitly deleted:
BEGIN
DBMS_WORKLOAD_REPOSITORY.drop_baseline (
baseline_name => batch baseline,
cascade
=> FALSE); Deletes associated snapshots if TRUE.
END;
/
Workload Repository Views
View Name
Description
V$ACTIVE_SESSION_HISTORY
Displays the active session history (ASH) sampled

every second.
V$METRIC
Displays metric information.
V$METRICNAME
Displays the metrics associated with each metric

group.
V$METRIC_HISTORY
Displays historical metrics.
V$METRICGROUP
Displays all metrics groups
DBA_HIST_ACTIVE_SESS_HISTORY
Displays the history contents of the active session

history.
DBA_HIST_BASELINE
Displays baseline information.
DBA_HIST_DATABASE_INSTANCE
Displays database environment information.
DBA_HIST_SNAPSHOT
Displays snapshot information.
DBA_HIST_SQL_PLAN
Displays SQL execution plans.
DBA_HIST_WR_CONTROL
Displays AWR settings.
Automatic Performance Diagnostics

The automatic database diagnostic monitor (ADDM) analyzes the AWR data on regular basis, then
locates the root cause of performance problems, provides recommendation for correcting any
problems, identifies non problem areas of the system.
ADDM analysis is performed every time AWR snapshot is taken and the results are saved in
database.
The goal of ADDM analysis is to reduce a single throughput metric called DB time. DB time is
the cumulative time spent by database server in processing user requests. (DB time includes CPU time
and time of non-idle user sessions).
ADDM does not target individual user response times.
Types of Problems
Following are the types of problems ADDM report addresses:
CPU bottlenecks
Undersized memory structures
I/O capacity issues
High load SQL statements
RAC specific issues
Database configuration issues
Also provides recommendations on hardware changes, database configuration & schema changes.
ADDM Results
ADDM report has following sections:
Problem: Finding that describe the root cause of database performance issue.
Symptom: Finding that contain information that often lead to one or more problem finding.
Information: Findings that are used to report non-problem area of the system.
Recommendations: Composed of action & rationales.
Initialization parameters & Grants
User running the ADDM scripts needs ADVISOR privileges

STATISTICS_LEVEL should be set to TYPICAL or ALL
DBIO_EXPECTED describes the expected performance of the I/O subsystem. The value of
DBIO_EXPECTED is the average time that takes to read a single database block in microsecond.
Default is 10millisecond.
Note:
To modify DBIO_EXPECTED value to 8000 microseconds, execute following as SYS user.
EXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER (
ADDM, DBIO_EXPECTED, 8000);
Running ADDM
We can generate ADDM report in two ways:
By using oracle script $ORACLE_HOME/rdbms/admin/addmrpt.sql

DBMS_ADVISOR package.
Running ADDM using addmrpt.sql
SQL> @$ORACLE_HOME/rdbms/admin/addmrpt.sql
Current Instance
~~~~~~~~~~~~~~~~
DB Id
DB Name
Inst Num Instance

1195050809 O01ABC0
1 O01ABC0
Instances in this Workload Repository schema

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id
Inst Num DB Name
Instance
Host

* 1195050809
1 O01ABC0
O01ABC0
test01
Using 1195050809 for database Id

Using
1 for instance number
Specify the number of days of snapshots to choose from

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing <return> without
specifying a number lists all completed snapshots.
Listing the last 3 days of Completed Snapshots
Automatic Workload Repository (AWR) in Oracle Database 10g
Snap
Instance DB Name Snap Id Snap Started Level
O01ABC0 O01ABC0 6020 16 Apr 2008 08:00 1

6021 16 Apr 2008 09:00 1
6022 16 Apr 2008 10:00 1
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 6020
Begin Snapshot Id specified: 6020
Enter value for end_snap: 6022
Running ADDM using DBMS_ADVISOR APIs
Steps:
Create advisor task. (DBMS_ADVISOR.CREATE_TASK)

Setting required parameters to run specific type of task, such as START_SNAPSHOT,
END_SNAPSHOT parameters. (DBMS_ADVISOR.TASK_PARAMETER)
Execute task. (DBMS_ADVISOR.EXECUTE_TASK)
View results ((DBMS_ADVISOR.GET_TASK_REPORT)
ADDM Views
View Name
Description
DBA_ADVISOR_TASKS
Provides information about existing task, like task id, name, etc.
DBA_ADVISOR_LOG
Contain the current task information such as status, progress,
error messages, and execution times.

DBA_ADVISOR_RECOMMENDATIONS
Complete result of diagnostic task.
DBA_ADVISOR_FINDINGS
Display all symptoms and specific recommendations.
If preparing for 1Z0- 050 certification practice test , you can find Oracle 11g certification practice
questions
Automated AWR reports in Oracle 10g/11g

Email ThisBlogThis!Share to TwitterShare to Facebook
Many Oracle DBA's are aware of power of Oracle

AWR (Automated Workload Repository) feature. If you have license for it then using it's statistic reports
may be very useful to find present hot spots as well one in the history in whole database. Interval
retention of snapshot generation is controlled with history period and time between two snapshots.
Normally DBA control these settings by the predefined Oracle package dbms_workload_repository, by
calling it's procedure dbms_workload_repository.modify_snapshot_settings
In next example, retention period will be defined as 30 days long (43200 min) and the interval between
each snapshot is 15 min (every 15 minutes one snapshot will be taken). Those settings are enough and
satisfactory for most of the today database configurations:
1 EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(43200, 15);
But however long retention policy is, most of DBAs run AWR statistic from time to time, manually. This is
true in two cases:
1.
When something "strange" happened in their database (fire fighter DBA).
2.
Some of us run from time to time to see if anything "is strange", what ever that means (proactive
DBA).
On the other hand when nothing "strange" happened for a longer time, many of data (reports) are lost
because new data push old ones out of repository, loosing many important information how "healthy"
database looks like and behave... This is also sometimes very interesting part indeed!
To overcome all mentioned, following solution gives you chance to automate collecting statistic and save
them in plain html file, which could be stored and analyzed later with no chance of lost of any moment of
life of your database.
001 /* -----------------------------------------------------------------------
---002 Filename: create_awr_report_for_database.sql

003 CR/TR# :
004
005
Purpose : In directory defined with v_dir, create awr

reports for ALL instances (RAC)
time for analyse is 07-18, so put in crontab to run at 18:16 on daily
basis
006
007
008
009
010
Date : 09.09.2009.
Author : Damir Vadas
Remarks : Run as privileged user
011
012
Changes (DD.MM.YYYY, Name, CR/TR#):

------------------------------------------------------------------------013
-- */
014
015
set serveroutput on
016
set linesize 166
017
set pagesize 600
018
set trimout on
019
020
021
022
DECLARE
cursor c_instance is
SELECT instance_number, instance_name
023
FROM gv$instance
024
025
026
ORDER BY 1
;
027
c_dir
CONSTANT VARCHAR2(256) := '/home/oracle';
028
v_dir
VARCHAR2(256) ;
029
030
031
032
033
034
035
v_dbid
v$database.dbid%TYPE;
v_dbname
v$database.name%TYPE;
v_inst_num
v$instance.instance_number%TYPE := 1;
v_begin
NUMBER;
v_end
NUMBER;
036
037
038
039
040
041
v_start_date VARCHAR2(20);
v_end_date
v_options
v_file
NUMBER := 8; -- 0=no options, 8=enable addm feature

UTL_FILE.file_type;
v_file_name
BEGIN
VARCHAR2(20);
VARCHAR(50);
042
043
-- get database id
SELECT dbid, name
044
INTO v_dbid, v_dbname
045
FROM v$database;
046
047
048
-- get end snapshot id

SELECT MAX(snap_id)
049
INTO v_end
050
FROM dba_hist_snapshot
051
052
053
054
055
056
057
WHERE to_char(begin_interval_time,'HH24') = '18';

dbms_output.put_line('end snap_id '||v_end);
-- get start snapshot id
SELECT MAX(snap_id)
INTO v_begin
058
WHERE to_char(begin_interval_time,'HH24') = '07'
059
060
061
AND snap_id < v_end;

dbms_output.put_line('begin snap_id '||v_begin);
062
SELECT to_char(begin_interval_time,'YYMMDD_HH24MI')
063
INTO v_start_date
064
065
066
067
068
069
070
WHERE snap_id = v_begin

AND instance_number = v_inst_num
;
dbms_output.put_line('v_start_date '||v_start_date);
SELECT to_char(begin_interval_time,'HH24MI')
071
INTO v_end_date
072
073
074
075
076
077
WHERE snap_id = v_end

AND instance_number = v_inst_num
;
dbms_output.put_line('v_end_date '||v_end_date);
078
-- Thanx to Yu Denis Sun - we must have directory defined as v_dir

value!
079
execute immediate('create or replace directory xx_some_temp_dir as '''||

v_dir||'''');
080
081
082
083
-- let's go to real work...write awrs to files...

FOR v_instance IN c_instance LOOP
dbms_output.put_line('v_instance.instance_name:'||
v_instance.instance_name);
v_file := UTL_FILE.fopen('XX_SOME_TEMP_DIR', 'awr_' ||
084 v_instance.instance_name ||'_'|| v_instance.instance_number || '_' ||
v_start_date || '_' || v_end_date || '.html', 'w', 32767);
085
FOR c_report IN (
086
SELECT output
087
FROM TABLE(dbms_workload_repository.awr_report_html( v_dbid,
08
v_instance.in
8 stance_number,
089
v_begin,
090
v_end,
091
v_options
092
)
093
)
094
) LOOP
095
UTL_FILE.PUT_LINE(v_file, c_report.output);
096
END LOOP;
097
UTL_FILE.fclose(v_file);
098
END LOOP;
099
execute immediate('drop directory xx_some_temp_dir');
100 EXCEPTION
101
WHEN OTHERS THEN
102
DBMS_OUTPUT.PUT_LINE(SQLERRM);
103
IF UTL_FILE.is_open(v_file) THEN
104
UTL_FILE.fclose(v_file);
105
END IF;
106
BEGIN
107
execute immediate('drop directory xx_some_temp_dir');
108
EXCEPTION
109
WHEN OTHERS THEN
110
null;
111
END;
112
END;
113
/
To run this script there are two minor requirements/constraints that must be obeyed prior running it:
1.
From my point of view, the most important time to monitor database is 07-18 hours, but you may
change it as you wish.
2.
"xx_some_temp_dir" id dinamically created with v_dir value. So create
directory privilege must be available to user which run this script. Keep in mind that Windows has
different path definition against Linux (i.e. c_dir CONSTANT VARCHAR2(256) := 'c:\'; ). Change
any of those values to apply your situation and configuration.
Last step of automation is to place this script in crontab (or windows schedule) and run it on daily basis at
18:16 (or later).
1
16 18 * * * . /home/oracle/MY_DB.env && sqlplus -s "/ as

sysdba" @/u01/rman_backup/scripts/create_awr_report_for_database.sql
Result will be placed in v_dir directory, one file per day, giving you opportunity to analyze them whenever
you like and need. Here is an example for RAC database MY_DB with 4 instances:
Last (but not least) benefit of this approach is that your retention period may be smaller-7 days would be
perfectly fine for most of the cases, because there is statistic already recorded for the whole past period. As
previously said, you define it like:
1 EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(10080, 15);
If you need whole day monitoring (let us say with night shift as well) my suggestion is to modify script to
run against different period, assume 18:00-07:00. As you can see, automatically, result will be saved in
different file name in the same directory. Dividing monitoring on two parts is, from my point of view,
really necessary, and enables DBA to view database in two very different situations OLTP against
night (batch) time. Time that in database life really differ in numbers, statistic values and logical
interpretation of them.
AWR Automatic Workload Repository
Detailed & comprehensive performance history
Based on snapshot (time interval)
Automatic Database Diagnostic Monitor (ADDM)
About 79 DBA_HIST_* tables
Defaults: Hourly snapshots
Weekly retention (month is better)
Overview of important AWR tables

DBA_HIST_SNAPSHOT
PK:
o
SNAP_ID
DBID, INSTANCE_NUMBER
Basic interval characteristics:

o
BEGIN_INTERVAL_TIME
END_INTERVAL_TIME
DBA_HIST_SQLSTAT
PK:
o
SNAP_ID
SQL_ID, PLAN_HASH_VALUE (DBID, INSTANCE_NUMBER)
Basic stats:
o
Time:
o
Executions, Gets, Reads

CPU, Elapsed
Wait time:
o
IO, Concurrency, App
Use deltas rather than totals
Time in microseconds
DBA_HIST_SYSSTAT
PK:
o
SNAP_ID
STAT_ID (DBID, INSTANCE_NUMBER)
AWR snapshots of V$SYSSTAT
Includes STAT_NAME (almost 400!)
Does NOT include deltas, you need to calculate these yourself
Watch out for stat counter resets (bounces)
DB time in units of centiseconds
Use as basis of comparison
DBA_HIST_SQLTEXT
PK:
o
SQL_ID
DBID
No SNAP_ID, INSTANCE_NUMBER
Preserves SQL_TEXT even when found nowhere else
DBA_HIST_SYSTEM_EVENT
PK:
o
SNAP_ID
EVENT_ID (DBID, INSTANCE_NUMBER)
AWR snapshots of V$SYSTEM_EVENT
Includes EVENT_NAME (almost 900!)
Does NOT equal sum of ASH sampling
Time is clearly in units of microseconds
DBA_HIST_SEG_STAT_OBJ
PK:
o
OBJ#, DATAOBJ# (DBID)
Object details (name, owner, type, tablespace)
Several segment types:

o
Table, Table Partition
Index, Index Partition
LOB
Here are few more .
DBA_HIST_ACTIVE_SESS_HISTORY
DBA_HIST_SNAPSHOT
DBA_HIST_SQLSTAT
DBA_HIST_SYSSTAT
DBA_HIST_SQLTEXT
DBA_HIST_SYSTEM_EVENT
DBA_HIST_SEG_STAT
DBA_HIST_SEG_STAT_OBJ
DBA_HIST_WR_CONTROL
AWR settings
Defaults:
one hour snapshots,
one week retention (month is better)
To change:
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(
retention IN NUMBER DEFAULT NULL,
interval IN NUMBER DEFAULT NULL,
topnsql
IN NUMBER DEFAULT NULL,
dbid
IN NUMBER DEFAULT NULL);
Now we have got a outline for AWR. Next we will see some practical scenarios where we can
use AWR.
AUTOMATED TABLESPACE POINT IN TIME RECOVERY

14 Oct, 2011 Vikas Krishna Oracle 11g, Oracle DBA
I have seen people using Flashback Technology more often to restore tables to an earlier
point in time. Automatic tablespace point in time recovery is an other option which we
can use to recover one or more tablespaces to an earlier point in time at the same time
retaining other tablespaces and objects as it is now.
Thanks to my friend Rajeshh who notified me on this feature.
DEMONSTRATION
1) Create a tablespace TS_AUTO
create tablespace ts_auto datafile +AUTO_DATA size 500m;
2) Crate a database user called AUTO_USER with default tablespace as TS_AUTO
create user auto_user identified by auto_user default tablespace ts_auto temporary
tablespace temp quota unlimited on ts_auto;
3) Grant required privileges to the user created in previous step
grant connect,resource to auto_user;
4) Create a database session as auto_user
conn auto_user/auto_user
5) Create a table called T_TEST
create table t_test(t_dt date);
6)Insert some values in to T_TEST
insert into t_test values (sysdate);
/
/
/
commit;
7)Check the data which we had inserted in previous step

select * from auto_user.t_test;
8)Using RMAN backup the database and arvhivelogs
rman target /
backup database plus archivelog;
9)Get the latest log sequence number
SQL> select sequence#,thread# from v$log;
SEQUENCE# THREAD#
- 720
1
718
1
719
1
9) Create a small parameter file
cat /u01/dba/temp/auto_tsptir_check/initEEeE.ora
db_name=TESTDB1
db_unique_name=EEeE_tspitr_TESTDB1
compatible=11.2.0.0.0
db_block_size=8192
db_files=200
sga_target=1G
processes=20
db_create_file_dest=/u01/dba/temp/auto_tsptir_check
log_archive_dest_1=location=/u01/dba/temp/auto_tsptir_check
**note Automated TSPITR creates its own parameter file but the SGA_TARGET in that is
only 200m which will cause the whole procedure to fail due to insufficient memory, That is
the reason we created our own parameter file and will pass the same during ATSPIR
RMAN> set auxiliary INSTANCE parameter file to
/u01/dba/temp/auto_tsptir_check/initEEeE.ora;
executing command: SET auxiliary parameter file
10) Perform Automated Tablespace point in time recovery.
RMAN> RECOVER TABLESPACE ts_auto
UNTIL LOGSEQ 720 THREAD 1
DESTINATION /u01/dba/temp/auto_tsptir_check;
AUXILIARY
**AUXILIARY DESTINATION is where rman stores all the database related files for the
auxiliary instance.
11) Change the status of the tablespace to online
alter tablespace ts_auto online;
Oracle library cache tuning A Real Case Study.

20 Jun, 2011 Rupesh Oracle Core Performance, Oracle DBA
I have made a few comments in previous posts about the latch: library cache and playing
with cursor parameters that can introduce surprises; Here is another one
library cache tuning A Real Case Study.
Scenario :
Users started complaining about very poor application performance, hung and incomplete
transactions. Some severity one ticket for immediate action.
Environment :
Oracle 10g (10.2.0.4) Two node RAC, About 15 different Java and .net legacy applications.
Highly transactional.
11 Gig Shared pool
16 Gig DB cache
Availability : 24*7, Outage unacceptable to business
I made some observations, thought it would be a nice idea to share them with you all.
Here are the citation from AWR report(1 hr.) during the problem period.
Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 39718 07-Jun-11 05:00:13 438 66.3
End Snap: 39719 07-Jun-11 06:00:19 651 64.4
Elapsed: 60.09 (mins)
DB Time: 490.75 (mins)
Very poor response time can be visible from the differences between db time and
elapsed time No wonder why users were complaining.
Load Profile :
Redo size: 698,307.96 9,249.30
Logical reads: 187,227.45 2,479.88
Block changes: 4,078.58 54.02
Physical reads: 29.63 0.39
Physical writes: 79.30 1.05
User calls: 2,638.29 34.94

Parses: 1200.23 5.81
Hard parses: 52.84 0.70
Sorts: 230.95 3.06
Logons: 0.91 0.01
Executes: 601.64 7.97
Transactions: 75.50
Parse count is just half of user calls, so every two user call there is a parse
request.Dammn bad, this going to be a huge CPU consumer.
Hard parses per second is 52.84, if I said very bad for parse count, I should say very
very very bad for hard parse this is very much resource intensive. Unacceptable !!
Instance Efficiency :
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 99.99 In-memory Sort %: 100.00
Library Hit %: 91.75 Soft Parse %: 87.95
Execute to Parse %: 27.13 Latch Hit %: 99.97
Parse CPU to Parse Elapsd %: 2.17 % Non-Parse CPU: 97.35
Low execute to parse ratio denotes CPU is significantly busy in parsing. Soft Parse%
showing, most of the parse are soft parses. It means we should focus on soft parsing
activity.
Parse CPU to Parse Elapsed % is quite low, which indicate some bottleneck is there
related to parsing. It could be a side-effect of huge parsing pressure. Like CPU cycles
are not available.
Library Hit % is very poor, it should be atleast above 95% .
Top 5 Timed Events :

latch: library cache 6,470 16,152 2,496 54.9 Concurrency
CPU time 11,675 39.7
log file sync 193,236 1,109 6 3.8 Commit
log file parallel write 224,479 795 4 2.7 System I/O
db file sequential read 38,110 386 10 1.3 User I/O
High wait on latch: library cache . So very clear that slow performance is due to the
contention in Library cache.
Also looked at SQL ordered by Parse Calls and SQL ordered by Version Count. That
pin point the issue at library chache.
Whats next ? ?
Above observations indicate that there is some serious problem to share the sqls. It could
be a result of bad application code wihout bind variables . Each calls are going for a parse
either soft or hard and no caching. The obvious advantage to caching cursors by session is
reduced parse times, which can leads to faster overall execution times.
Caching Caching .. Lets look at the Oracle caching parameters now. The value was
cursor_sharing= similar
open_cursors= 3000
session_cached_cursors= 100
Two things I played around was cursor_sharing andsession_cached_cursors. I can
ignore open_cursors for time being as it is already high for my environment.
I have chosen to use SESSION_CACHED_CURSORS to help out in this scenario as an
application that is continually closing and reopening cursors, you can monitor its
effectiveness via two more statistics in v$sesstat. The statistic session cursor cache hits
reflects the number of times that a statement the session sent for parsing was found in the
session cursor cache, meaning it didnt have to be reparsed and your session didnt have to
search through the library cache for it. You can compare this to the statistic parse count
(total); subtract session cursor cache hits from parse count (total) to see the number of
parses that actually occurred.
v$sesstat also provides a statistic to monitor the number of cursors each session has in its
session cursor cache.
session cached cursors, by session
select a.value, s.username, s.sid, s.serial#
from v$sesstat a, v$statname b, v$session s
where a.statistic# = b.statistic# and s.sid=a.sid
and b.name = session cursor cache count ;
session cached cursor usage.
select a.value curr_cached, p.value max_cached, s.username, s.sid, s.serial#
from v$sesstat a, v$statname b, v$session s, v$parameter2 p
where a.statistic# = b.statistic# and s.sid=a.sid
and p.name=session_cached_cursors
and b.name = session cursor cache count
Above query gave a result that CUR_CACHED=MAX_CACHED . If the session cursor cache
count is maxed out, session_cursor_cache_hits is low compared to all parses, and you
suspect that the application is re-submitting the same queries for parsing repeatedly, then
increasing SESSION_CURSOR_CACHE_COUNT will help with latch contention and can give
boost to performance.
One fix is ready now i.e increase SESSION_CACHED_CURSOR from 100 to 300 (Decided to
put 300 first and monitor the session cursor caching).
We had a high hard parse rate as well So the second parameters to play around was
CURSOR_SHARING. For poorly coded application Oracle highly recomend to
keep CURSOR_SHARING=FORCE . Also there are few bugs reported with
CURSOR_SHARING=SIMILAR option as well as it is Deprecated from 11g
onwards. [ANNOUNCEMENT: Deprecating the cursor_sharing = SIMILAR setting

[MOS Note ID 1169017.1]]
Conclusion :
Changed initialization parameters for session cached cursors and cursor sharing hence
reduced library cache contention by avoiding parse calls and releasing cpu cycle.
I have changed to
CURSOR_SHARING=FORCE
SESSION_CACHED_CURSOR=300
Certaily you can dynamicaly do CURSOR_SHARING=FORCE
ALTER SYSTEM SET CURSOR_SHARING=FORCE SCOPE=BOTH;
But SESSION_CACHED_CURSOR is not dynamic and you need a bounce to reflects this. I
was in trouble for this because it is a zero tolerence system and outage should be planned a
month before. I cannot wait until that to tune this perf issue. Again there is anotehr back
door method to implement SESSION_CACHED_CURSOR to get effect, but thats a topic for
another blog you can see it in another post here ..
I have mentioned at the very start cursor parameters that can introduce surprises. Yes,
very true. After these two changes all the library cache contention was vanished.
Hard parses reduced from 58 per sec to 1 or 0 per sec. Library hit ratio become 98% and
soft parse ration become 99% and response time become jet fast.
Why use Oracle ASM for Oracle databases

MAY 25, 2011 4 COMMENTS
Ive been in discussions with some customers recently about what is the best way to store Oracle database data.
Needless to say that the foundation should be EMC infrastructure of course, but apart from that, what kind of volume
manager and/or filesystem works best for performance and other features?
There are many volume managers, and many filesystems available, more or less dependent on what hardware and
operating system you run the database.
Some have a long track record, some are new kids on the block. Some are part of the operating system, others are
3rd party add-ons, for which you might need to pay licenses.
One way of storing Oracle database data is Oracle ASM.
Oracle ASM is Oracles volume manager specially designed for Oracle database data. It is available since Oracle
database version 10g and many improvements have been made in versions 11g release 1 and 2. Oracle uses ASM in
their own production environments and it is a core component in many of Oracles own offerings (such as Oracle
Exadata) when maximum performance is needed.
It offers support for Oracle RAC clusters without the requirement to install 3rd party software, such as cluster aware
volume managers or filesystems.
Although ASM is not absolutely required for an Oracle RAC cluster to be supported on EMC systems, we highly
recommend using ASM because it lowers risk, cost, administration overhead and increases performance.
Oracle and other parties have developed alternatives for storage management of Oracle datafiles, such as Oracle
OCFS (and OCFS2), SUN/Oracle ZFS, IBM GPFS and others. However, not all of these support Oracle clustering,
and most of these filesystems (and volume managers) are complex to set up and require intensive tuning to drive
good performance. Support (from Oracle, or OS vendors) can also be an issue.
Compared to standard volume managers and filesystems (either clustered or single system), ASM has a number of
advantages:
It does not require large amounts of memory for cache. The memory not required for file system caching can
be configured for Oracle memory (SGA) where it is more efficient (note that ASM requires typically a few hundred
megabytes for internal administration, shared across all databases)
ASM distributes chunks of data pseudo-randomly across all available logical disks in a disk group, thereby
removing potential performance hot-spots
ASM does not perform any I/O itself so there is no translation layer for Oracle I/O to datafiles into disk
block offsets. I/O from databases is directly applied to disk volumes without modification. This again reduces
overhead and improves performance.
Therefore ASM also does no read-ahead (like filesystems) to read data in (filesystem) cache that is never
used by the database.
ASM does not require intensive tuning such as setting fragment sizes correctly and tuning file system
journals. When creating an ASM disk group you only need to define the chunk size and whether or not to
perform fine striping. It is unlikely to make configuration errors (causing performance issues) if a few simple ASM
configuration guidelines are followed.
ASM does not cause fragmentation (you could argue that ASM balancing is some sort of fragmentation.
However, the allocation units are large enough typically 1MB or more to allow for very little disk seeks to
read a number of subsequent (typically 8K) blocks
ASM does not break large I/Os (i.e. 128K) in multiple smaller ones (4K or 8K) like some filesystems do. One
large I/O is faster than many small ones.
No journal (AKA intent log etc) is required for consistency (this function is already done by Oracle redo
logs and having a journalled filesystem is therefore only overhead).
ASM can be managed from within Oracle tooling and does not require Unix administration (this can be an
advantage or disadvantage depending on responsibilities of various administrators in the organization).
Adding or removing storage to/from ASM is very easy and does not require careful planning (as is the case
with volume managers and filesystems). After adding storage, ASM will automatically rebalance storage so all
disks will be utilized equally. This again increases performance.
ASM works on all major operating systems so it is platform independent.
SAP now supports Oracle ASM.
Finally, EMC fully supports ASM including various tooling that integrate with Oracle (such as Replication
Manager, and backup and reporting tools).
Disadvantages? A few, maybe. Biggest disadvantages that I have identified:
Migration from legacy filesystems to ASM can be a problem and often requires an outage
It is hard (if not impossible) to view ASM contents with standard OS tools. In some cases, ASM data can be
accidentally overwritten by OS admins who are using disk volumes that (to them) seem to be empty. However,
there are administrative ways to prevent this from happening
Backup cannot be done with traditional methods that just backup OS files so you need integrated tooling or
use Oracles native tools (RMAN)
Last but not least, I have encountered a few situations where storage I/O load balancers (multipath drivers) also mess
up the I/Os coming from the higher level. In particular, I have seen Red Hat 5.6 native multipathing breaking 64K or
128K I/Os into multiple 4K I/Os. Still dont know if this is a bug, undocumented feature, or works as designed. But it
does not help Oracle performance. We switched to our own EMC Powerpath driver to replace it and immediately
boosted performance without further tuning.
Make sure you understand the I/O stack end to end. The less complexity the easier it is (and the risk of making
configuration errors). Using ASM (ideally, with EMC Powerpath) removes the risk of misconfigured volume managers,
file systems and I/O path drivers.
Finally, I also have talked to customers who plan to use Oracle ASMs mirroring (ASM normal redundancy setting)
capabilities as a poor mans disaster recovery tool and build stretched clusters across datacenters. Although you can
make it to work, I would strongly recommend not to do so. ASM redundancy was designed to protect from failing
disks, not from failing datacenters. We at EMC can offer something that works better with less risk. More on that on a
future post.
ASM INTERVIEW QUESTIONS

Top 10 ASM Questions
ASM Architecture
Q.1) What init.ora parameters does a user need to
configure for ASM instances?
A. The default parameter settings work perfectly for
ASM. The only parameters needed for 11g ASM:
PROCESSES*
ASM_DISKSTRING*
ASM_DISKGROUPS
INSTANCE_TYPE
ASM is a very passive instance in that it doesnt have a lot concurrent transactions
or queries. So the memory footprint is quite small.
Even if you have 20 dbs connected to ASM , the ASM SGA does not need to change.
This is b/c the ASM metadata is not directly tied to the number of clients
The 11g MEMORY_TARGET (DEFAULT VALUE) will be more than sufficient.

The processes parameter may need to be modified. Use the formula to determine
the approp value:
processes = 40 + (10 + [max number of concurrent database file
creations, and file extend operations possible])*n
Where n is the number of databases connecting to ASM (ASM clients).
The source of concurrent file creations can be any of the following:
Several concurrent create tablespace commands
Creation of a Partitioned table with several tablespaces creations
RMAN backup channels
Concurrent archive logfile creations
Q.2)How does the database interact with the ASM
instance and how do I make ASM go faster?
A. ASM is not in the I/O path so ASM does not impede
the database file access. Since the RDBMS instance
is performing raw I/O, the I/O is as fast as possible.
Cover ASM instance architecture
Cover ASM-Communication via ASMB
The database communicates with ASM instance using the ASMB
(umblicus process) process. Once the database obtains the necessary
extents from extent map, all database IO going forward is processed
through by the database processes, bypassing ASM. Thus we say
ASM is not really in the IO path. So, the question how do we make
ASM go faster..you dont have to.
RDBMS and ASM Instance Interaction
Server
Operating System
DATABASE ASM
(1) Database opens file
(1A) OPEN
(1B) Extent Map
(2) Database Reads file
(2A) READ
(2B) I/O Completes
(3) Database Creates file
(3A) CREATE
(3B) Allocates file
(3C) Extent Map
(3D) Initializes file
(3D) Commit
1A. Database issues open of a database file
1B. ASM sends the extent map for the file to database instance. Starting
with 11g, the RDBMS only receives first 60 extents the remaining extents
in the extent map are paged in on demand, providing a faster open
2A/2B. Database now reads directly from disk
3A.RDBMS foreground initiates a create tablespace for example
3B. ASM does the allocation for its essentially reserving the allocation units
for the file creation
3C. Once allocation phase is done, the extent map is sent to the RDBMS
3D. The RDBMS initialization phase kicks in. In this phase the initializes all
the reserved AUs
3E. If file creation is successful, then the RDBMS commits the file creation
Going forward all I/Os are done by the RDBMS.
Q.3) Do I need to define the RDBMS

FILESYSTEMIO_OPTIONS parameter when I use ASM?
A. No. The RDBMS does I/O directly to the raw disk
devices, the FILESYSTEMIO_OPTIONS parameter is
only for filesystems.
A. Review what the use of FILESYSTEMIO_OPTIONS parameter;
essentially FILESYSTEMIO_OPTIONS is used for filesystem/block
storage.
This parameter controls which IO options are used. The value may be any of
the following:
*asynch - This allows asynchronous IO to be used where supported by the
OS.
*directIO - This allows directIO to be used where supported by the OS.
Direct IO bypasses any Unix buffer cache. *setall - Enables both
ASYNC and DIRECT IO. "none" - This disables ASYNC IO and DIRECT
IO so that Oracle uses normal synchronous writes, without any direct io
options.
A. RDBMS does raw IO against the ASM disks, so need for
FILESYSTEMIO_OPTIONS parameter. The only parameter that needs to
be set is disk_asyncio=true, which is true by default. If using ASMLIB
then even the disk_async does not need to be set.
ASM is also supported for NFS files as ASM disks. In such cases, the
required NFS mount options eliminate the need to set
FILESYSTEMIO_OPTIONS.
Q.4) I read in the ASM Best Practices paper that Oracle
recommends two diskgroups. Why?
A. Oracle recommends two diskgroups to provide a
balance of manageability, utilization, and
performance.
To reduce the complexity of managing ASM and its diskgroups, Oracle recommends that
generally no more than two diskgroups be maintained and managed per RAC cluster or
single ASM instance
oDatabase work area: This is where active database files such as datafiles, control files,
online redo logs, and change tracking files used in incremental backups are stored. This
location is indicated by DB_CREATE_FILE_DEST.
oFlash recovery area: Where recovery-related files are created, such as multiplexed copies
of the current control file and online redo logs, archived redo logs, backup sets, and
flashback log files. This location is indicated by DB-RECOVERY_FILE_DEST.
Having one DATA container means only place to store all your database files, and obviates
the need to juggle around datafiles or having to decide where to place a new tablespace.
By having one container for all your files also means better storage utilization. Making the IT
director very happy. If more storage capacity or IO capacity is needed, just add an ASM
disk.all online activities.
You have to ensure that this storage pool container houses enough spindles to
accommodate the IO rate of all the database objects
Bottom line, one container == one pool manage, monitor, and track
Note however, that additional diskgroups may be added to support tiered storage classes in
Information Lifecycle Management (ILM) or Hierarchical Storage Management (HSM)
deployments
Q.5) We have a 16 TB database. Im curious about the
number of disk groups we should use; e.g. 1 large
disk group, a couple of disk groups, or otherwise?
A. For VLDBs you will probably end up with different
storage tiers; e.g with some of our large customers
they have Tier1 (RAID10 FC), Tier2 (RAID5 FC), Tier3

(SATA), etc. Each one of these is mapped to a
diskgroup.
These custs mapped certain tablespaces to specific tiers; eg, system/rollback/syaux
and latency senstive tablespaces in Tier1, and not as IO critical on Tier2, etc.
For 10g VLDBs its best to set an AU size of 16MB, this is more for metadata space
efficiency than for performance. The 16MB recommendation is only necessary if the
diskgroup is going to be used by 10g databases. In 11g we introduced variable size
extents to solve the metadata problem. This requires compatible.rdbms &
compatible.asm to be set to 11.1.0.0. With 11g you should set your AU size to the largest
I/O that you wish to issue for sequential access (other parameters need to be set to
increase the I/O size issued by Oracle). For random small I/Os the AU size does not
matter very much as long as every file is broken into many more extents than there are
disks.
15
Q.6) We have a new app and dont know our access
pattern, but assuming mostly sequential access, what
size would be a good AU fit?
A. For 11g ASM/RDBMS it is recommended to use 4MB
ASM AU for disk groups.
See Metalink Note 810484.1
For all 11g ASM/DB users, it best to create a disk group using 4 MB ASM AU size. Metalink
Note 810484.1 covers this
Q.7) Would it be better to use BIGFILE tablespaces, or
standard tablespaces for ASM?
A. The use of Bigfile tablespaces has no bearing on ASM
(or vice versa). In fact most database object related
decisions are transparent to ASM.
Nevertheless, Bigfile tablespaces benefits:
Fewer datafiles - which means faster database open (fewer files to
open),
Faster checkpoints, as well fewer files to manage. But you'll need
careful consideration for backup/recovery of these large datafiles.
Q.8) What is the best LUN size for ASM
A. There is no best size! In most cases the storage
team will dictate to you based on their standardized
LUN size. The ASM administrator merely has to
communicate the ASM Best Practices and application
characteristics to storage folks :
Need equally sized / performance LUNs
Minimum of 4 LUNs
The capacity requirement
The workload characteristic (random r/w, sequential r/w) &
any response time SLA
Using this info , and their standards, the storage folks should build a
nice LUN group set for you.
In most cases the storage team will dictate to you what the standardized LUN size
is. This is based on several factors,
including RAID LUN set builds (concatenated, striped, hypers, etc..). Having too
many LUNs elongates boot
time and is it very hard to manage On the flip side, having too few LUNs makes array
cache management difficult to
control and creates un-manageable large LUNs (which are difficult to expand).
The ASM adminstrator merely has to communicate to SA/storage folks that you need
equally sized/performance LUNs and what the capacity requirement is, say 10TB.
Using this info, the workload characteristic (random r/w, sequential r/w), and their
standards, the storage folks should build a nice LUN group set for you
Having too many LUNs elongates boot time and is it very hard to manage (zoning,
provisioning, masking, etc..)...there's a $/LUN barometer!
Q.9) In 11g RAC we want to separate ASM admins from
DBAs and create different users and groups. How do
we set this up?
A. For clarification
Separate Oracle Home for ASM and RDBMS.
RDBMS instance connects to ASM using OSDBA group of the ASM instance.
Thus, software owner for each RDBMS instance connecting to ASM must be
a member of ASM's OSDBA group.
Choose a different OSDBA group for ASM instance (asmdba) than for
RDBMS instance (dba)
In 11g, ASM administrator has to be member of a separate SYSASM group to
separate ASM Admin and DBAs.
Operating system authentication using membership in the group or groups
designated
as OSDBA, OSOPER, and OSASM is valid on all Oracle platforms.
A typical deployment could be as follows:
ASM administrator:
User : asm
Group: oinstall, asmdba(OSDBA), asmadmin(OSASM)
Database administrator:
User : oracle
Group: oinstall, asmdba(OSDBA of ASM), dba(OSDBA)
ASM disk ownership : asm:oinstall
Remember that Database instance connects to ASM instance as
sysdba. The user id the database instance runs as needs to be the
OSDBA group of the ASM instance.
ASM administrator:
User : asm
User : oracle
ASM administrator:
User : asm
User : oracle
Q.10) Can my RDBMS and ASM instances run different
versions?
A. Yes. ASM can be at a higher version or at lower
version than its client databases. Theres two
components of compatiblity:
Software compatibility
Diskgroup compatibility attributes:

compatible.asm
compatible.rdbms
This is a diskgroup level change and not an instance level changeno
rolling upgrade here!
Disk Group Compatibility Example
Start with 10g ASM and RDBMS
Upgrade ASM to 11g
Advance compatible.asm
ALTER DISKGROUP data
SET ATTRIBUTE
compatible.asm = 11.1.0.7.0
10g RDBMS instances are still supported
10g ASM instance can no longer mount the disk
group
22
Upgrade RDBMS to 11g
In the RDBMS instance set initialization parameter
compatible = 11.0
Advance compatible.rdbms
ALTER DISKGROUP data
SET ATTRIBUTE
compatible.rdbms = 11.1.0.7.0
New capabilities enabled
Variable size extents
Fast mirror resync
Preferred read
AUs > 16MB
10g RDBMS instances can no longer access the disk group
23
Compatibility may be set during disk group creation
CREATE DISKGROUP data
DISK /dev/sdd[bcd]1
ATTRIBUTE
compatible.asm = 11.1.0.7.0,
compatible.rdbms = 11.1.0.7.0,
au_size = 4M
compatible.asm and compatible.rdbms cannot
be reversed
Q.11) Where do I run my database listener from; i.e., ASM
HOME or DB HOME?
A. It is recommended to run the listener from the ASM
HOME. This is particularly important for RAC env,
since the listener is a node-level resource. In this
config, you can create additional [user] listeners from
the database homes as needed.
- Allows registering multiple databases on the node to register with the
listener without being tied to a specific database home
- From configuration tool standpoint (netca), we promote best practice
of creating one listener per node with node name suffix (that is
registered with CRS) and subsequent tools that create/upgrade
databases will register instances to that listener. One can always
create multiple listeners in different homes and use'em but that would
complicate the configuration
Backups for ASM:
Q.1) How do I backup my ASM instance?
A. Not applicable! ASM has no files to backup
Unlike the database, ASM does require a controlfile type structure or
any other external metadata to bootstrap itself. All the data ASM needs
to startup is on on-disk structures (disk headers and other disk group
metadata).
A Disk Group is the fundamental object managed by ASM. It is
composed of multiple ASM disks. Each Disk Group is self-describing,
like a standard file system. All the metadata about the usage of the
space in the disk group is completely contained within the disk group.
If ASM can find all the disks in a disk group it can provide access to
the disk group without any additional metadata
Q.2)When should I use RMAN and when should I use
ASMCMD copy?
A. RMAN is the recommended and most complete and
flexible method to backup and transport database files
in ASM.
ASMCMD copy is good for copying single files
Supports all Oracle file types
Can be used to instantiate a Data Guard environment
Does not update the controlfile
Does not create OMF files
RMAN is the most complete and versatile means to backup databases
stored in ASM.
However, many customers use BCV/split-mirrors as backups for ASM
based databases. Many combine BCV mirrors with RMAN backup
of the mirrors. Why would you want to do that? RMAN ensures the
integrity of the database data blocks by running sanity checks as it
backs up the blocks
Now most of you are wondering about the 11g asmcmd copy
command, and how that fits in here. asmcmd cp is not intended to
do wholesale backups (plus youll have to put the database in hot
backup).
In 10g the possible ways to migrate - DBMS_FILE_TRANSFER, rman (copy vs.
backup), or XMLDB FTP
In 11g, we introduced the asmcmd copy command. Key point here is that copy files
out is great for:
1. archive logs
2. Controlfiles
3. Datafiles for debugging
4. Dumpsets (can be done across platforms)
Copying files in:
TTS
Copy in only supported files.
28
ASMCMD Copy
ASMCMD> ls
+fra/dumpsets/expdp_5_5.dat
ASMCMD> cp expdp_5_5.dat sys@rac1.orcl1:+DATA/dumpsets/ex
pdp_5_5.dat
source +fra/dumpsets/expdp_5_5.dat
target +DATA/dumpsets/expdp_5_5.dat
copying file(s)...
file, +DATA/dumpsets/expdp_5_5.dat,
copy committed.
Migration
Q. Im going to do add disks to my ASM diskgroup,
how long will this rebalance take?
A. Rebalance time is heavily driven by the three items:
Amount of data currently in the diskgroup
IO bandwidth available on the server
ASM_POWER_LIMIT or Rebalance Power Level
Use v$asm_operation
31
Q. We are migrating to a new storage array. How do I
move my ASM database from storage A to storage B?
A. Given that the new and old storage are both visible to
ASM, simply add the new disks to the ASM disk group
and drop the old disks. ASM rebalance will migrate
data online. Note 428681.1 covers how to move
OCR/Voting disks to the new storage array
If this is a RAC environment, the Note 428681.1 covers how to move
OCR/Voting disks to the new storage array
ASM_SQL> alter diskgroup DATA
drop disk
data_legacy1, data_legacy2,
data_legacy3
add disk
/dev/sddb1, /dev/sddc1,
/dev/sddd1;
ASM Rebalancing
Automatic online rebalance whenever
storage configuration changes
Only move data proportional to storage
added
No need for manual I/O tuning
Disk Group DATA (legacy disks)
ASM Rebalancing
Online migration to new storage
Disk Group DATA
ASM Rebalancing
Disk Group DATA
ASM Rebalancing
Disk Group DATA
ASM Rebalancing
Disk Group DATA (new disks)
Q. Is it possible to unplug an ASM disk group from one
platform and plug into a server on another platform
(for example, from Solaris to Linux)?
A. No. Cross-platform disk group migration not
supported. To move datafiles between endian-ness
platforms, you need to use XTTS, Datapump or
Streams.
The first problem that you run into here is that Solaris and Linux
format their disks differently. Solaris and Linux do not recognize each
others partitions, etc.
ASM does track the endian-ness of its data. However, currently, the
ASM code does not handle disk groups whose endian-ness does not
match that of the ASM binary.
Experiments have been done to show that ASM disk groups can be
migrated from platforms that share a common format and endian-ness
(i.e. Windows to Linux), but this functionality is not currently officially
supported because is not regularly tested yet.
The following links show how to migrate across platforms
http://downloadwest.
oracle.com/docs/cd/B19306_01/server.102/b25159/outage.htm#CA
CFFIDD
http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10
gR2_PlatformMigrationTTS.pdf
3rd Party Software
40
Q. How does ASM work with multipathing software?
A. It works great! Multipathing software is at a layer
lower than ASM, and thus is transparent.
You may need to adjust ASM_DISKSTRING to specify
only the path to the multipathing pseudo devices.
Multipathing tools provides the following benefits:
oProvide a single block device interface for a multi-pathed LUN
oDetect any component failures in the I/O path; e.g., fabric port, channel adapter, or
HBA.
oWhen a loss of path occurs, ensure that I/Os are re-routed to the available paths,
with no process disruption.
oReconfigure the multipaths automatically when events occur.
oEnsure that failed paths get revalidated as soon as possible and provide autofailback
capabilities.
oConfigure the multi-paths to maximize performance using various load balancing

methods; e.g., round robin, least I/Os queued, or least service time.
When a given disk has several paths defined, each one will be presented as a unique path
name at the OS level; e.g.; /dev/rdsk/c3t19d1s4 and /dev/rdsk/c7t22d1s4 could be pointing
to same disk device. ASM, however, can only tolerate the discovery of one unique device
path per disk. For example, if the asm_diskstring is /dev/rdsk/*, then several paths to the
same device will be discovered, and ASM will produce an error message stating this.
When using a multipath driver, which sits above this SCSI-block layer, the driver will
generally produce a pseudo device that virtualizes the sub-paths. For example, in the
case of EMCs PowerPath, you can use the following asm_diskstring setting of
/dev/rdsk/emcpower*. When I/O is issued to this disk device, the multipath driver will
intercept it and provide the necessary load balancing to the underlying subpaths.
As long as ASM can open/read/write to the multipathing pseudo device, it should
work. Most all MP products are known to work w/ ASM. But remember ASM does not
certify MP products, though we have a list products that work w/ ASM, this is more of
a guide of whats available by platform/OS.
Examples of multi-pathing software include EMC PowerPath, Veritas DMP, Sun Traffic
Manager, Hitachi HDLM, and IBM SDDPCM. Linux 2.6 has a kernel based multipathing
ASM/RDBMS
/dev/
Multipath driver
/dev/sda1 /dev/sdb1
Controller Controller
Cache
Disk
IO cloud
Q. Is ASM constantly rebalancing to manage hot
spots?
A. NoNoNope!!
Bad rumor. ASM provides even distribution of extents across all disks
in a disk group. Since each disk will equal number of extents, no
single disk will be hotter than another. Thus the answer NO, ASM does
not dynamically move hot spots, because hot spots simply do not
occur in ASM configurations.
Rebalance only occurs on storage configuration changes (e.g. add,
drop, or resize disks).
43
I/O Distribution
ASM spreads file extents evenly across all disks in disk group
Since ASM distributes extents evenly, there are no hot spots
Average IOPS per disk during OLTP workload
0
50
100
150
200
250
300
Total
Disk
IOPS
FG1: - cciss/c0d2
FG1: - cciss/c0d3
FG1: - cciss/c0d4
FG1: - cciss/c0d5
FG1: - cciss/c0d6
FG2: - cciss/c0d2
FG2: - cciss/c0d3
FG2: - cciss/c0d4
FG2: - cciss/c0d5
FG2: - cciss/c0d6
FG3: - cciss/c0d2
FG3: - cciss/c0d3
FG3: - cciss/c0d4
FG3: - cciss/c0d5
FG3: - cciss/c0d6
FG4: - cciss/c0d2
FG4: - cciss/c0d3
FG4: - cciss/c0d4
FG4: - cciss/c0d5
FG4: - cciss/c0d6
As indicated, ASM implements the policy of S.A.M.E. that stripes and mirrors
files across all the disks in a Disk Group. If the disks are highly reliable as
the case may be with a high-end array, mirroring can be optionally disabled
for a particular Disk Group. This policy of striping and mirroring across all
disks in a disk group greatly simplifies storage management and provides a
configuration of balanced performance.
Key Value Propositions
Manageability
Simple provisioning
Storage Array migration
VM/FS co-existence
SQL, EM, Command line
Consolidation
Self-tuning
Performance
Distribute load across all
available storage
No ASM code in data path
Availability
Automatic mirror rebuild
Automatic bad block correction
Rolling upgrades
Online patches
RAC and clusterware support
Cost Savings
Shared storage pool
Just-in-Time provisioning
No license fees
No support fees
45
Summary:
ASM requires very few parameters to run
ASM based databases inherently leverage raw disk
performance
No additional database parameters needed to support
ASM
Mixed ASM-database version support
Facilitates online storage changes

RMAN recommended for backing up ASM based
databases
Spreads I/O evenly across all disks to maximize
performance and eliminates hot spots
ASM provides filesystem and volume manager capabilities built into the Oracle database kernel. With
this capability, ASM simplifies storage management tasks, such as creating/laying out databases and
disk space management. Since ASM allows disk management to be done using familiar
create/alter/drop SQL statements, DBAs do not need to learn a new skill set or make crucial decisions
on provisioning.
The following are some key benefits of ASM:
oASM spreads I/O evenly across all available disk drives to prevent hot spots and maximize
performance.
oASM eliminates the need for over provisioning and maximizes storage resource utilization facilitating
database consolidation.
oInherent large file support.
oPerforms automatic online redistribution after the incremental addition or removal of storage
capacity.
oMaintains redundant copies of data to provide high availability, or leverages 3rd party RAID
functionality.
oSupports Oracle Database as well as Oracle Real Application Clusters (RAC).
oCapable of leveraging 3rd party multipathing technologies.
oFor simplicity and easier migration to ASM, an Oracle database can contain ASM and non-ASM files.
Any new files can be created as ASM files whilst existing files can also be migrated to ASM.
oRMAN commands enable non-ASM managed files to be relocated to an ASM disk group.
oEnterprise Manager Database Control or Grid Control can be used to manage ASM disk and file
activities.
ASM reduces Oracle Database cost and complexity without compromising performance or availability
46
ASM Collateral and Content
http://www.oracle.com/technology/asm
ASM 11g New Features
ASM Best Practices
ASM vendor papers
ASM-RAC Customer Case Studies
Extra credit questions
Q. Is ASMLIB required on Linux systems and are there
any benefits to using it?
A. ASMLIB is not required to run ASM, but it is certainly
recommended.
ASMLIB has following benefits:
Simplified disk discovery
Persistent disk names
Efficient use of system resources
o Reduced Overhead
ASMLIB provides the capability for a process (RBAL) to perform a global open/close
on the disks that are being dropped or closed.
This reduces the number of open file descriptors on the system, thus reduces the
probability of running out of global file descriptors on the system. Also, the open
and close operations are reduced, ensuring orderly cleanup of file descriptors when
storage configurations changes occur.
A side benefit of the aforementioned items is a faster startup of the database.
o Disk Management and Discovery

With ASMLib the ASM disk name is automatically taken from the name given it by the
administrative tool. This simplifies adding disks and correlating OS names with ASM
names, as well as eliminates erroneous disk management activities since disks are
already pre-named.
The default discovery string for ASM is NULL, however, if ASMLIB is used, the
ASMLIB default string replaces the NULL string, making disk discovery much more
straightforward. Note, disk discovery has been one of the big challenges for
administrators.
The ASMLib permissions are persistent across reboot and in the event of major/minor
number changes
In RAC environments, disk identification and discovery as simply as single instance.
Once the disks are labeled on one node, the other clustered nodes simply use the
default disk discovery string, and discovery is seamless.
o No requirement to setup raw links
With ASMLib, there is not a requirement to modify the initializations (e.g. /etc/init.d)
Q. Is it possible to do rolling upgrades on ASMLIB in a
RAC configuration
A. ASMLIB is independent of Oracle Clusterware and
Oracle Database, and thus can be upgraded on its
own
Upgrading ASMLIB one a given node will require that ASMLIB be
disabled/stop, will require the database and ASM to also be
shutdown on that node. Once the ASMLIB is upgarded then the stack can be
restarted.

Why and When Should I Backup My Database

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Why and When Should I Backup My Database

Uploaded by

Copyright:

Available Formats

http://www.orafaq.

Why and when should I backup my database?

Rate of data change/ transaction rate

Database availability/ Can you shutdown for cold backups?

Criticality of the data/ Value of the data to the company

strategies are available for backing-up an Oracle database?

The following methods are valid for backing-up an Oracle database:

is the difference between online and offline backups?

is the difference between restoring and recovering?

SQL> connect SYS as SYSDBA

database is down and I cannot restore. What now?

does one backup a database using the export utility?

does one put a database into ARCHIVELOG mode?

Issue the following commands to put a database into ARCHIVELOG mode:

CONNECT sys AS SYSDBA

lost an archived/online REDO LOG file, can I get my DB back?

Do a "SHUTDOWN NORMAL" of the database

Set the above parameter

Do a "STARTUP MOUNT" and "ALTER DATABASE OPEN RESETLOGS;"

Wait a couple of minutes for Oracle to sort itself out

Remove the above parameter!

Do a database "STARTUP" and check your ALERT.LOG file for errors.

Extract the data and rebuild the entire database

managed backup and recovery

This section deals with user managed, or non-RMAN backups.

does one do off-line database backups?

select name from sys.v_$controlfile;

does one do on-line database backups?

database was terminated while in BACKUP MODE, do I need to

Oracle write to data files in begin/hot backup mode?

backup and recovery

This section deals with RMAN backups:

is RMAN and how does one use it?

does one backup and restore a database using RMAN?

release channel t1;

does one backup and restore archived log files?

Here is a restore example:

does one create a RMAN recovery catalog?

does one integrate RMAN with third-party Media Managers?

Veritas NetBackup - http://www.veritas.com/

EMC Data Manager (EDM) - http://www.emc.com/

HP OMNIBack/ DataProtector - http://www.hp.com/

IBM's Tivoli Storage Manager (formerly ADSM) - http://www.tivoli.com/storage/

EMC Networker - http://www.emc.com/

BrightStor ARCserve Backup - http://www.ca.com/us/data-loss-prevention.aspx

Sterling Software's SAMS:Alexandria (formerly from Spectralogic) - http://www.sterling.com/sams/

SUN's Solstice Backup - http://www.sun.com/software/whitepapers/backup-n-storage/

CommVault Galaxy - http://www.commvault.com/

does one clone/duplicate a database with RMAN?

allocate auxiliary channel dupdb1 type disk;

one restore RMAN backups without a CONTROLFILE and

SQL> show parameters CONTROL_FILES

-- Allocate a channel... (Use type=>null for DISK, type=>'sbt_tape' for

SQL> recover database using backup controlfile;

Archivelog mode and datafile recovery (non-SYSTEM

SQL> shutdown abort;

Mount the database in restricted mode.

SQL> startup restrict mount;

SQL> select * from v$recovery_log;

Copy all the archive log files to the required destination.

Recover the database:

SQL> recover database;

In case of complete recovery:

SQL> alter database open;