Embed Size (px)
DESCRIPTION
bkp
Citation preview
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 roll-
forward 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> CONNECT sys AS SYSDBASQL> STARTUP MOUNT EXCLUSIVE;SQL> ALTER DATABASE ARCHIVELOG;SQL> ARCHIVE LOG START;SQL> 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 = TRUElog_archive_dest_1 = 'LOCATION=/arch_dir_name'log_archive_dest_state_1 = ENABLElog_archive_format = %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 restrictshutdown 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 databasecatalog quoted-string connect-string for recovery catalognocatalog none if specified, then no recovery catalogcmdfile quoted-string name of input command filelog quoted-string name of output message log filetrace quoted-string name of output debugging message log fileappend none if specified, log is opened in append modedebug optional-args activate debuggingmsgno none show RMAN-nnnn prefix for all messagessend quoted-string send a command to the media managerpipe string building block for pipe namestimeout integer number of seconds to wait for pipe input-----------------------------------------------------------------------------
Here is an example:
[oracle@localhost oracle]$ rmanRecovery Manager: Release 10.1.0.2.0 - ProductionCopyright (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> backup4> 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 sysSQL> 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/rmanRMAN> 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/backdbaRMAN> 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@origdbconnect catalog rman/rman@catdbconnect auxiliary /
run {set newname for datafile 1 to '/ORADATA/u01/system01.dbf';set newname for datafile 2 to '/ORADATA/u02/undotbs01.dbf';set newname for datafile 3 to '/ORADATA/u03/users01.dbf';set newname for datafile 4 to '/ORADATA/u03/indx01.dbf';set newname for datafile 5 to '/ORADATA/u02/example01.dbf';
allocate auxiliary channel dupdb1 type disk;set until sequence 2 thread 1;
duplicate target database to dupdblogfile 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 / nocatalogRecovery Manager: Release 10.1.0.2.0 - 64bit ProductionCopyright (c) 1995, 2004, Oracle. All rights reserved.
connected to target database: ORCL (DBID=1046662649)using target database controlfile instead of recovery catalog
RMAN> backup datafile 1;
Starting backup at 20-AUG-04allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=146 devtype=DISKchannel ORA_DISK_1: starting full datafile backupsetchannel ORA_DISK_1: specifying datafile(s) in backupsetinput datafile fno=00001 name=/oradata/orcl/system01.dbfchannel ORA_DISK_1: starting piece 1 at 20-AUG-04channel ORA_DISK_1: finished piece 1 at 20-AUG-04piece handle=/flash_recovery_area/ORCL/backupset/2004_08_20/o1_mf_nnndf_TAG20040820T153256_0lczd9tf_.bkp comment=NONEchannel ORA_DISK_1: backup set complete, elapsed time: 00:00:45channel ORA_DISK_1: starting full datafile backupsetchannel ORA_DISK_1: specifying datafile(s) in backupsetincluding current controlfile in backupsetincluding current SPFILE in backupsetchannel ORA_DISK_1: starting piece 1 at 20-AUG-04channel ORA_DISK_1: finished piece 1 at 20-AUG-04piece handle=/flash_recovery_area/ORCL/backupset/2004_08_20/o1_mf_ncsnf_TAG20040820T153256_0lczfrx8_.bkp comment=NONEchannel ORA_DISK_1: backup set complete, elapsed time: 00:00:04Finished backup at 20-AUG-04[/code]
Now, let's destroy one of the control files:
SQL> show parameters CONTROL_FILESNAME TYPE VALUE------------------------------------ ----------- ------------------------------control_files string /oradata/orcl/control01.ctl, /oradata/orcl/control02.ctl, /oradata/orcl/control03.ctlSQL> 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 NOMOUNTORACLE instance started.
Total System Global Area 289406976 bytesFixed Size 1301536 bytesVariable Size 262677472 bytesDatabase Buffers 25165824 bytesRedo Buffers 262144 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/control01.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 1ORA-00289: suggestion :/flash_recovery_area/ORCL/archivelog/2004_08_20/o1_mf_1_671_%u_.arcORA-00280: change 7917452 for thread 1 is in sequence #671
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}/oradata/orcl/redo02.logLog 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;ORACLE instance started.Total System Global Area 209715200 bytesFixed Size 1289748 bytesVariable Size 138412524 bytesDatabase Buffers 67108864 bytesRedo Buffers 2904064 bytesDatabase mounted.Database opened.SQL> exit;
[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:32:56 2007Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database: O10GR2 (DBID=1094333359)
RMAN> backup database;
Starting backup at 30-MAY-07using target database control file instead of recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: sid=141 devtype=DISKchannel ORA_DISK_1: starting full datafile backupsetchannel ORA_DISK_1: specifying datafile(s) in backupsetinput datafile fno=00001 name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/system01.dbfinput datafile fno=00003 name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/sysaux01.dbfinput datafile fno=00005 name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/example01.dbfinput datafile fno=00004 name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/users01.dbfinput datafile fno=00002 name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/undotbs01.dbfchannel ORA_DISK_1: starting piece 1 at 30-MAY-07channel ORA_DISK_1: finished piece 1 at 30-MAY-07piece handle=/app/oracle/product/10.2.0/db_1/flash_recovery_area/O10GR2/backupset/2007_05_30/o1_mf_nnndf_TAG20070530T203304_35vjv1k4_.bkp tag=TAG20070530T203304 comment=NONEchannel ORA_DISK_1: backup set complete, elapsed time: 00:01:26channel ORA_DISK_1: starting full datafile backupsetchannel ORA_DISK_1: specifying datafile(s) in backupsetincluding current control file in backupsetincluding current SPFILE in backupsetchannel ORA_DISK_1: starting piece 1 at 30-MAY-07channel ORA_DISK_1: finished piece 1 at 30-MAY-07piece handle=/app/oracle/product/10.2.0/db_1/flash_recovery_area/O10GR2/backupset/2007_05_30/o1_mf_ncsnf_TAG20070530T203304_35vjxrl5_.bkp tag=TAG20070530T203304 comment=NONEchannel ORA_DISK_1: backup set complete, elapsed time: 00:00:03Finished 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;ORACLE instance started.Total System Global Area 209715200 bytesFixed Size 1289748 bytesVariable Size 138412524 bytesDatabase Buffers 67108864 bytesRedo Buffers 2904064 bytesDatabase mounted.SQL> exitDisconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - ProductionWith 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 2007Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database: O10GR2 (DBID=1094333359, not open)
RMAN> backup database;
Starting backup at 30-MAY-07using target database control file instead of recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: sid=156 devtype=DISKchannel ORA_DISK_1: starting full datafile backupsetchannel ORA_DISK_1: specifying datafile(s) in backupsetinput datafile fno=00001 name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/system01.dbfinput datafile fno=00003 name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/sysaux01.dbf
input datafile fno=00005 name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/example01.dbfinput datafile fno=00004 name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/users01.dbfinput datafile fno=00002 name=/app/oracle/product/10.2.0/db_1/oradata/o10gr2/undotbs01.dbfchannel ORA_DISK_1: starting piece 1 at 30-MAY-07channel ORA_DISK_1: finished piece 1 at 30-MAY-07piece handle=/app/oracle/product/10.2.0/db_1/flash_recovery_area/O10GR2/backupset/2007_05_30/o1_mf_nnndf_TAG20070530T202407_35vjb7cs_.bkp tag=TAG20070530T202407 comment=NONEchannel ORA_DISK_1: backup set complete, elapsed time: 00:01:15channel ORA_DISK_1: starting full datafile backupsetchannel ORA_DISK_1: specifying datafile(s) in backupsetincluding current control file in backupsetincluding current SPFILE in backupsetchannel ORA_DISK_1: starting piece 1 at 30-MAY-07channel ORA_DISK_1: finished piece 1 at 30-MAY-07piece handle=/app/oracle/product/10.2.0/db_1/flash_recovery_area/O10GR2/backupset/2007_05_30/o1_mf_ncsnf_TAG20070530T202407_35vjdny9_.bkp tag=TAG20070530T202407 comment=NONEchannel ORA_DISK_1: backup set complete, elapsed time: 00:00:03Finished 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 ARCHIVELOGAutomatic archival ENABLEDArchive destinationOldest online log sequenceNext log sequence to archiveCurrent 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 1else touch ${HOT}/hotbackup.lockfi
# 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 mail <email_address> <<-EOF ERROR - COLD BACKUP For "${ORACLE_SID}" Has Failed Database Should be up to take a trace of the data files - Please Investigate! EOF exit 1fi
# Make sure that the Database Is running in archive log mode# If not inform the concerned person#sqlplus /nolog <<-EOF connect / as sysdba spool ${HOT}/archive_mode.lst archive log list spool off EXITEOFarchive_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 ERROR - HOT BACKUP For "${ORACLE_SID}" Has Failed 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 1fi
# 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 '^alter tablespace .* begin backup' $LOG End_Bkp=egrep -ci '^alter tablespace .* end backup' $LOG Diff_Bkp=expr $Bgn_Bkp - $End_Bkpelse mail <email_address> <<-EOF ERROR - HOT BACKUP For "${ORACLE_SID}" Has Failed Could not locate Alert Log - Please Investigate ! EOF exit 1fi
# 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 exitEOF
# 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 '^alter tablespace .* begin backup' $LOGEnd_Bkp=egrep -ci '^alter tablespace .* end backup' $LOGif [ $Bgn_Bkp != expr $End_Bkp + $Diff_Bkp ] ; then
mail <email_address> <<-EOF ERROR : HOT BACKUP For "${ORACLE_SID}" Has Failed Number of "Begin Backup" statenents does not equal "End Backup" Please Investigate Immediately ! EOF exit 1fi
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 # 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#COLD=<COLD_BACKUP_DIRECTORY>## 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 ${COLD}/coldbackup.lock ]; then mail <email_address> <<EOFERROR - COLD BACKUP For "${ORACLE_SID}" Has FailedPrevious Cold Backup is not completed !EOF exit 1else touch ${COLD}/coldbackup.lockfi## 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 mail <email_address> <<EOFERROR - COLD BACKUP For "${ORACLE_SID}" Has FailedDatabase Should be up to take a trace of the data files - Please Investigate!EOF exit 1fi
sqlplus <username>/<password> < column tablespace_name noprintcolumn seqn noprintset pagesize 0set linesize 132set feedback offset sqlprompt ""Whenever SQLERROR exit FAILURESELECT 'compress < '||file_name||'> ${COLD}/' ||substr(file_name,instr(file_name,'/',-1) + 1) || '.Z'FROM sys.dba_data_filesUNIONSELECT 'compress < '||member||'> ${COLD}/' ||substr(member,instr(member,'/',-1) + 1) || '.Z'from sys.v$logfileUNIONSELECT'compress < '||name||'> ${COLD}/' ||substr(name,instr(name,'/',-1) + 1) || '.Z'FROM sys.v$controlfilespool ora_COLD_backup.sh/spool offexitEOF## 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 Persondatabase_up=`ps -ef | grep pmon_${ORACLE_SID} | grep -v grep | wc -l`if [ $ora_users_num -ne 0 ]then sqlplus /nolog <<ENDconnect / as sysdbashutdownexitENDfi## Double Check if the Database is brugh down before you start cold backup# If not inform the concerned person.#database_up=`ps -ef | grep pmon_${ORACLE_SID} | grep -v grep | wc -l`if [ $database_up -ne 0 ]then mail <email_address> <<EOFERROR - COLD BACKUP For "${ORACLE_SID}" Has FailedDatabase could be brough down - Please Investigate !
EOF exit 1fichmod +x ora_COLD_backup.sh./ora_COLD_backup.shrm ${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# 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># <EXPORT_DIR># <email_address># <username># <password>#trap 2 3## Set up environmental variables - Oracle specific#export EXPORT_DIR=<EXPORT_DIR>export ORACLE_SID=<ORACLE_SID>export ORACLE_HOME=<ORACLE_HOME>export PATH=$PATH:/$ORACLE_HOME/bin## 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 ${EXPORT_DIR}/fullexport.lock ]; thenmail <email_address> <<EOFERROR - EXPORT BACKUP For "${ORACLE_SID}" Has FailedPrevious Export Backup is not completed !EOFexit 1elsetouch ${EXPORT_DIR}/fullexport.lockfi################################################################## 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`if [ $database_up -eq 0 ]thenmail <email_address> <<EOFERROR - Export Backup for "${ORACLE_SID}" Has FailedDatabase Is Not Up - Please Investigate !EOFexit 0elseEXPORT_FILE_NAME=`date '+fullexport%y%m%d'`.dmpLOG_FILE_NAME=`date '+fullexport%y%m%d'`.logmknod ${EXPORT_DIR}/${EXPORT_FILE_NAME} pchmod +rw ${EXPORT_DIR}/$EXPORT_FILE_NAME## Building the export parameter file fullexp.par#cat <<END > ${EXPORT_DIR}/fullexp.parFILE=${EXPORT_DIR}/${EXPORT_FILE_NAME}FULL=YCOMPRESS=YLOG=${EXPORT_DIR}/${LOG_FILE_NAME}ENDcat ${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.parrm -f ${EXPORT_DIR}/fullexport.lockmail <email_address> <<EOFExport Backup for "${ORACLE_SID}" CompletedEOFfi
Complete Media RecoveryContents
[hide]
1 Media recovery commands
o 1.1 RECOVER DATABASE
o 1.2 RECOVER TABLESPACE
o 1.3 RECOVER DATAFILE
2 Media recovery types
o 2.1 Performing Closed Database Recovery
o 2.2 Performing Open-Database, Offline-Tablespace Recovery
o 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.
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 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.
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 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.
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 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.
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 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 -
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. 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.
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 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.
13. 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.
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 -
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. 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.
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 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.
13. 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.
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
o 2.2 Restore from RMAN backup
o 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 NOMOUNTCREATE CONTROLFILE REUSE DATABASE "orcl"NORESETLOGS [archivelog/noarchivelog]MAXLOGFILES 5 MAXLOGMEMBERS 3 MAXDATAFILES 10 MAXINSTANCES 1 MAXLOGHISTORY 113LOGFILE 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 10MDATAFILE '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:
sqlplusconnect SYS AS SYSDBASQL> shutdown abortOracle Instance AbortedSQL> startup mountOracle Instance StartedDatabase MountedSQL> 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 openStatement Processed
If you have performed incomplete recovery, enter alter database open resetlogs.
SQL> shutdownDatabase ClosedDatabase DismountedOracle Instance ShutdownSQL> startup mountOracle Instance StartedDatabase MountedSQL> alter database backup controlfile to /u01/ORADATA/archive/prodcontrolfile.backup reuse;Statement ProcessedSQL> Alter database openStatement ProcessedSQL> 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 SYSDBAconnected
SQL> shutdown abortOracle Instance Aborted
SQL> startup mountOracle Instance Started
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 SYSDBAconnectedSQLPLUS> shutdownDatabase ClosedDatabase DismountedORACLE Instance Shut Down
Copy all the datafiles, redo logs and controlfiles from an earliest hot backup.
Recover the database:
SQLPLUS> startup mountOracle Instance StartedDatabase 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-MM-
DD: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 ProcessedSQLPLUS> 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 databasecatalog quoted-string connect-string for recovery catalognocatalog none if specified, then no recovery catalogcmdfile quoted-string name of input command filelog quoted-string name of output message log filetrace quoted-string name of output debugging message log fileappend none if specified, log is opened in append modedebug optional-args activate debuggingmsgno none show RMAN-nnnn prefix for all messagessend quoted-string send a command to the media managerpipe string building block for pipe namestimeout integer number of seconds to wait for pipe input-----------------------------------------------------------------------------
Here is an example:
[oracle@localhost oracle]$ rmanRecovery Manager: Release 10.1.0.2.0 - ProductionCopyright (c) 1995, 2004, Oracle. All rights reserved.
RMAN> connect target;
connected to target database: ORCL (DBID=1058957020)
RMAN> backup database;...
[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 sysdbaSQL> 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/rmanRMAN> 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/backdbaRMAN> 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 3rd-
party 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 SYSDBAALTER 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 BLOCKSFROM DBA_SEGMENTSWHERE OWNER=UPPER(owner) AND SEGMENT_NAME = UPPER(table);
ANALYZE TABLE owner.table ESTIMATE STATISTICS;
SELECT EMPTY_BLOCKSFROM DBA_TABLESWHERE 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_headerGROUP 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_freeFROM 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 ) DWHERE A.tablespace_name = D.nameGROUP 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.blocksfrom sys.v_$session s, sys.v_$sort_usage uwhere s.saddr = u.session_addr/
select s.osuser, s.process, s.username, s.serial#, sum(u.blocks)*vp.value/1024 sort_sizefrom sys.v_$session s, sys.v_$sort_usage u, sys.v_$parameter vpwhere 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 [email protected] _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 [email protected] (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 lsinventoryInvoking OPatch 10.2.0.1.0
Oracle interim Patch Installer version 10.2.0.1.0Copyright (c) 2005, Oracle Corporation. All rights reserved.....Installed Top-level Products (1):
Oracle Database 10g 10.2.0.1.0There are 1 products installed in this Oracle Home.There are no Interim patches installed in this Oracle Home.
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 rule-
based 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_statswhere 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 "AVERAGE WAIT TIME FOR READ REQUESTS"select a.average_wait "SEQ READ", b.average_wait "SCAT READ"from sys.v_$system_event a, sys.v_$system_event bwhere a.event = 'db file sequential read'and 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_bufferNAME 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 3redo 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 50000exec 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 initial Buffer Hit Ratio reading...SQL> SELECT ROUND((1-(phy.value / (cur.value + con.value)))*100,2) "Cache Hit Ratio" 2 FROM v$sysstat cur, v$sysstat con, v$sysstat phy 3 WHERE cur.name = 'db block gets' 4 AND con.name = 'consistent gets' 5 AND phy.name = 'physical reads' 6 /
Cache Hit Ratio--------------- 90.75
However, to show how meaningless this number is, let's artificially increase it:
SQL>
SQL> -- Let's artificially increase the buffer hit ratio...SQL> DECLARE 2 v_dummy dual.dummy%TYPE; 3 BEGIN 4 FOR I IN 1..10000000 LOOP 5 SELECT dummy INTO v_dummy FROM dual; 6 END LOOP; 7 END; 8 /
PL/SQL procedure successfully completed.
Let's see what happened:
SQL>SQL> -- Let's measure it again...SQL> SELECT ROUND((1-(phy.value / (cur.value + con.value)))*100,2) "Cache Hit Ratio" 2 FROM v$sysstat cur, v$sysstat con, v$sysstat phy 3 WHERE cur.name = 'db block gets' 4 AND con.name = 'consistent gets' 5 AND phy.name = 'physical reads' 6 /
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 132SQL> 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 ONSQL> select * from dept where deptno = 40;
DEPTNO DNAME LOC---------- -------------- ------------- 40 OPERATIONS BOSTON
Execution Plan----------------------------------------------------------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)
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 132SQL> 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.
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 sub-
optimal 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
o 1.1 Start session trace
o 1.2 Stop session trace
o 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 a SQL session
[edit]Start 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 -ltrtotal 8-rw-r----- 1 oracle dba 2764 Mar 30 12:37 ora_9294.trc
[edit]Tracing 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/adminsqlplus "/ as sysdba" @spdrop.sql -- Drop and install statspacksqlplus "/ as sysdba" @spcreate.sql -- Enter tablespace names when prompted
[edit]Take performance snapshots of the database
sqlplus perfstat/perfstatexec 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 snapshotsselect SNAP_ID, SNAP_TIME from STATS$SNAPSHOT; @spreport.sql -- Enter two snapshot id's for difference report
[edit]Other 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 2002Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Trace file: ORCL102_ora_3064.trc
Sort options: default
********************************************************************************count = number of times OCI procedure was executedcpu = cpu time in seconds executingelapsed = elapsed time in seconds executingdisk = number of physical reads of buffers from diskquery = number of buffers gotten for consistent readcurrent = 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 cpu elapsed disk query current rows------- ------ -------- ---------- ---------- ---------- ---------- ----------Parse 10 0.00 0.03 0 0 0 0Execute 10 0.00 0.00 0 0 0 0Fetch 20 0.34 0.35 72 4730 0 10------- ------ -------- ---------- ---------- ---------- ---------- ----------total 40 0.34 0.39 72 4730 0 10 Misses in library cache during parse: 1Optimizer goal: CHOOSEParsing user id: 59 Rows Row Source Operation------- --------------------------------------------------- 1 TABLE ACCESS FULL EMPLOYEE
How to read AWR reportsTo generate AWR, read my article
http://bash-dba.blogspot.com/search/label/AWR?updated-max=2011-09-27T12%3A36%3A00-04%3A00&max-results=20
OK let start analysing AWR
This is the example of AWR report. I have tried here to discuss the finding of sample AWR report I have generated.
Report Header
This section is self explanatory which provides database name, id, instance if RAC , platform information and snap interval. (database workload time duration in review).This report is for instance number 2 of my RAC environment. So if you need to the analysis on RAC environment, you need to do it separately of all the instances in the RAC to see if all the instances are balanced the way they should be.
DB Name DB Id Instance Inst numStartup
TimeRelease RAC
TestRAC 3626203793 TestRac2 2 17-Aug-11 19:08 11.1.0.6.0 YES
Host Name Platform CPUs Cores Sockets Memory (GB)
TestRAC Linux 64-bit for AMD 8 8 2 31.44
Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 28566 27-Sep-11 01:00:21 130 4.8
End Snap: 28567 27-Sep-11 02:00:43 135 4.5
Elapsed: 60.35 (mins)
DB Time: 15.07 (mins)
Begin End
Buffer Cache: 5,888M 5,888M Std Block Size: 8K
Shared Pool Size: 8,704M 8,704M Log Buffer: 138,328K
Load ProfileThis section provides the snapshot of the database workload occurred during the snapshot interval.
Per Second Per Transaction Per Exec Per Call
DB Time(s): 0.3 0.1 0.00 0.00
DB CPU(s): 0.3 0.1 0.00 0.00
Redo size: 48,933.6 19,916.2
Logical reads: 1,124.4 457.7
Block changes: 195.9 79.7
Physical reads: 80.5 32.8
Physical writes: 4.3 1.8
User calls: 141.4 57.6
Parses: 123.2 50.2
Hard parses: 2.2 0.9
W/A MB processed: 1,940,807.0 789,918.9
Logons: 4.3 1.7
Executes: 127.6 51.9
Rollbacks: 0.0 0.0
Transactions: 2.5
DB time(s):Its the amount of time oracle has spent performing database user calls. Not it does not include background processes.DB CPU(s):Its the amount of CPU time spent on user calls. Same as DB time it does not include background process. The value is in microsecondsRedo size: For example, the table below shows that an average transaction generates about 19,000 of redo data along with around 48,000 redo per second.Logical reads:Consistent Gets+ DB blocks Gets = Logical readsBlock Changes:The number of block modified during the sample intervalPhysical reads:No of block request causing I/O operationPhysical writes:Number of physical writes performedUser calls:Number of user queries generatedParses:The total of all parses; both hard and soft.Hard Parses: The parses requiring a completely new parse of the SQL statement. These consume both latches and shared pool area.Soft Parses:Soft parses are not listed but derived by subtracting the hard parses from parses. A soft parse reuses a previous hard parse; hence it consumes far fewer resources.Sorts:No of sorts performedLogons:No of logons during the intervalExecutes:No of SQL ExecutesTransactions:
No of transactions per second
Instance Efficiency Percentages (Target 100%)
Instance efficiency should be close to 100 %
Buffer Nowait %: 99.99 Redo NoWait %: 100.00
Buffer Hit %: 93.06 In-memory Sort %: 100.00
Library Hit %: 98.67 Soft Parse %: 98.20
Execute to Parse %: 3.40 Latch Hit %: 99.98
Parse CPU to Parse Elapsd %: 0.01 % Non-Parse CPU: 96.21
Execute to Parse % amd Parse CPU to Parse Elapsd %:
If the the value are low like in the above case of 3.40 and 0.01 means that there could be a parsing problem. You may need to look at bind variable issues or shared pool sizing issue.
Redo NoWait%:
Usually this stats is 99 or greater
In-memory Sort %:This can tell you how efficient is you sort_area_size, hash_area_size or pga_aggrigate_target are. If you dont have adequate sizes of sort,hash and pga parameters, then you in-memory sort per cent will go down
Soft parse %:with 98.20 % for the soft parse meaning that about 1.72 % (100 -soft parse) is happening for hard parsing. You might want to look at you bind variables issues.
Latch Hit %:should be close to 100.
% Non-Parse CPU:Most of our statements were already parsed so we weren't doing a lot of re parsing. Re parsing is high on CPU and should be avoided.
Shared Pool Statistics
Begin End
Memory Usage %: 73.86 75.42
% SQL with executions>1: 92.61 93.44
% Memory for SQL w/exec>1: 94.33 94.98
Memory Usage % is the shared pool usage. So here we have use 73.86 per cent of our shared pool and out of that almost 94 percent is being re-used. if Memory Usage % is too large like 90 % it could mean that your shared pool is tool small and if the percent is in 50 for example then this could mean that you shared pool is too large
Top 5 Timed Foreground Events
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
DB CPU 1,019 112.73
log file sync 25,642 43 2 4.73 Commit
db file scattered read 3,064 40 13 4.43 User I/O
library cache pin 136,267 27 0 2.98 Concurrency
db file sequential read 7,608 24 3 2.71 User I/O
its critical to look into this section. If you turn off the statistic parameter, then the Time(s) wont appear. Wait analysis should be done with respect to Time(s) as there could be million of waits but if that happens for a second or so then who cares. Therefore, time is very important component.
So you have several different types of waits. So you may see the different waits on your AWR report. So lets discuss the most common waits.
df file type waits:
db file sequential read : Is the wait that comes from the physical side of the database. it related to memory starvation and non selective index use. sequential read is an index read followed by table read because it is doing index lookups which tells exactly which block to go todb file scattered read:caused due to full table scans may be because of insufficient indexes or un-avilablity of updated statisticsdirect Path writes:You wont see them unless you are doing some appends or data loadsdirect Path reads : could happen if you are doing a lot of parallel query activitydb file parallel writes / read: if you are doing a lot of partition activity then expect to see that wait even. it could be a table or index partitiondb file single write:if you see this event than probably you have a lot of data files in your database.direct path read temp or direct path write temp:this wait event shows Temp file activity (sort,hashes,temp tables, bitmap)check pga parameter or sort area or hash area parameters. You might want to increase them
buffer type waits
so what's going on in your memorylatch: cache buffer chains:check hot objectsfree 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 blocksbuffer busy - See what is causing them further along in reportno free buffers – Insufficient buffers, dbwr contention
Log Type Waits
log file parallel write – Look for log file contentionlog buffer space – Look at increasing log buffer sizelog file switch (checkpoint incomplete) – May indicate excessive db files or slow IO subsystemlog file switch (archiving needed) – Indicates archive files are written too slowlylog file switch completion – May need more log files perlog file sync – Could indicate excessive commits
GC Events
gccr multi block request – Full table or index scansgc current multi block request – Full table or index scansgccr block 2-way – Blocks are busy in another instance, check for block level contention or hot blocksgccr block 3-way – Blocks are busy in another instance, check for block level contention or hot blocksgccr block busy – Blocks are busy in another instance, check for block level contention or hot blocksgccr block congested – cr block congestion, check for hot blocks or busy interconnectgccr block lost – Indicates interconnect issues and contentiongc current block 2-way – Blocks are busy in another instance, check for block level contention or hot blocksgc current block 3-way – Blocks are busy in another instance, check for block level contention or hot blocksgc current block busy – Block is already involved in GC operation, shows hot blocks or congestiongc current block congested – current block congestion, check for hot blocks or busy interconnectgc current block lost - Indicates interconnect issues and contention
Undo Events
undo segment extension – If excessive, tune undolatch: 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 concernDrill down to specific sections of report for deeper analysisUse custom scripts, ADDM and Ash to investigate issues
AWR report scenariosWhat is AWR:
1. Background process2. A set of tables3. A set of reports4. Takes snapshots of statistics every hour5. 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 SnapshotBEGINDBMS_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,BEGINDBMS_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:BEGINDBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention => 43200,interval => 30, topnsql => 100, dbid => 7123356265);END;/The dbid is optional.4. Extract the AWR Data The 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.sql5. 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.sql6. 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.sqlFirst, you need to specify whether you want an HTML or a text report.Enter value for report_type: textSpecify the number of days for which you want to list snapshot Ids.Enter value for num_days: 2After the list displays, you are prompted for the beginning and ending snapshot Id for the workload repository report.Enter value for begin_snap: 95Enter value for end_snap: 97Next, 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_97The workload repository report is generated.awrrpt.sqlThe awrrpt.sql SQL script generates an HTML or text report that displays statistics for a range of snapshot Ids.awrrpti.sqlThe 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.sqlThe 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.sqlThe 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.sqlThe awrddrpt.sql SQL script generates an HTML or text report that compares detailed performance attributes and configuration settings between two selected time periods.awrddrpi.sqlThe 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
SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sqlDB Id DB Name Inst Num Instance
—————————————————————————————-
1195050809 O01ABC0 1 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 O01ABC0 5652 01 Apr 2008 00:00 1
5653 01 Apr 2008 01:00 1
5654 01 Apr 2008 02:00 1
5655 01 Apr 2008 03:00 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
SnapshotSnapshots & 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, — Minutes (= 30 Days). Current value retained if NULL.
interval => 30); – 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;
/
BaselineA 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.sqlCurrent 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
Automatic Workload Repository (AWR) in Oracle Database 10g
SnapInstance DB Name Snap Id Snap Started Level———————————————————————————————————————O01ABC0 O01ABC0 6020 16 Apr 2008 08:00 1
6021 16 Apr 2008 09:00 16022 16 Apr 2008 10:00 1
Specify the Begin and End Snapshot Ids~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Enter value for begin_snap: 6020Begin Snapshot Id specified: 6020Enter value for end_snap: 6022
Running ADDM using DBMS_ADVISOR APIsSteps:
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)
Automatic Workload Repository (AWR) in Oracle Database 10g
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/11gEmail 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 Purpose : In directory defined with v_dir, create awr reports for ALL instances (RAC)
005 time for analyse is 07-18, so put in crontab to run at 18:16 on daily basis
006
007 Date : 09.09.2009.
008 Author : Damir Vadas
009
010 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 DECLARE
021 cursor c_instance is
022 SELECT instance_number, instance_name023 FROM gv$instance
024 ORDER BY 1
025 ;
026
027 c_dir CONSTANT VARCHAR2(256) := '/home/oracle';
028 v_dir VARCHAR2(256) ;
029
030 v_dbid v$database.dbid%TYPE;
031 v_dbname v$database.name%TYPE;
032 v_inst_num v$instance.instance_number%TYPE := 1;033 v_begin NUMBER;034 v_end NUMBER;
035 v_start_date VARCHAR2(20);
036 v_end_date VARCHAR2(20);037 v_options NUMBER := 8; -- 0=no options, 8=enable addm feature
038 v_file UTL_FILE.file_type;
039 v_file_name VARCHAR(50);
040
041 BEGIN
042 -- get database id
043 SELECT dbid, name
044 INTO v_dbid, v_dbname045 FROM v$database;
046
047 -- get end snapshot id
048 SELECT MAX(snap_id)
049 INTO v_end
050 FROM dba_hist_snapshot051 WHERE to_char(begin_interval_time,'HH24') = '18';
052 dbms_output.put_line('end snap_id '||v_end);
053
054 -- get start snapshot id
055 SELECT MAX(snap_id)
056 INTO v_begin
057 FROM dba_hist_snapshot
058 WHERE to_char(begin_interval_time,'HH24') = '07'
059 AND snap_id < v_end;
060 dbms_output.put_line('begin snap_id '||v_begin);
061
062 SELECT to_char(begin_interval_time,'YYMMDD_HH24MI')
063 INTO v_start_date
064 FROM dba_hist_snapshot
065 WHERE snap_id = v_begin
066 AND instance_number = v_inst_num
067 ;
068 dbms_output.put_line('v_start_date '||v_start_date);
069
070 SELECT to_char(begin_interval_time,'HH24MI')
071 INTO v_end_date
072 FROM dba_hist_snapshot
073 WHERE snap_id = v_end
074 AND instance_number = v_inst_num
075 ;
076 dbms_output.put_line('v_end_date '||v_end_date);
077
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 -- let's go to real work...write awrs to files...
082 FOR v_instance IN c_instance LOOP
083 dbms_output.put_line('v_instance.instance_name:'||v_instance.instance_name);
084 v_file := UTL_FILE.fopen('XX_SOME_TEMP_DIR', 'awr_' || 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,
088
v_instance.instance_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
o DBID, INSTANCE_NUMBER
Basic interval characteristics:
o BEGIN_INTERVAL_TIME
o END_INTERVAL_TIME
DBA_HIST_SQLSTAT
PK:
o SNAP_ID
o SQL_ID, PLAN_HASH_VALUE (DBID, INSTANCE_NUMBER)
Basic stats:
o Executions, Gets, Reads
Time:
o CPU, Elapsed
Wait time:
o IO, Concurrency, App
Use “deltas” rather than “totals”
Time in microseconds
DBA_HIST_SYSSTAT
PK:
o SNAP_ID
o 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
o DBID
No SNAP_ID, INSTANCE_NUMBER
Preserves SQL_TEXT even when found nowhere else
DBA_HIST_SYSTEM_EVENT
PK:
o SNAP_ID
o 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
o Index, Index Partition
o 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 RECOVERY14 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_AUTOcreate tablespace ts_auto datafile ‘+AUTO_DATA’ size 500m;
2) Crate a database user called AUTO_USER with default tablespace as TS_AUTOcreate 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 stepgrant connect,resource to auto_user;
4) Create a database session as auto_userconn auto_user/auto_user
5) Create a table called T_TESTcreate table t_test(t_dt date);
6)Insert some values in to T_TESTinsert into t_test values (sysdate);///commit;
7)Check the data which we had inserted in previous stepselect * 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 1718 1719 1
9) Create a small parameter file
cat /u01/dba/temp/auto_tsptir_check/initEEeE.ora
db_name=TESTDB1db_unique_name=EEeE_tspitr_TESTDB1compatible=11.2.0.0.0db_block_size=8192db_files=200sga_target=1Gprocesses=20db_create_file_dest=/u01/dba/temp/auto_tsptir_checklog_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 fileusing target database control file instead of recovery catalog
10) Perform Automated Tablespace point in time recovery.RMAN> RECOVER TABLESPACE ts_auto UNTIL LOGSEQ 720 THREAD 1 AUXILIARY DESTINATION ‘/u01/dba/temp/auto_tsptir_check’;
**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 pool16 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/SessionBegin Snap: 39718 07-Jun-11 05:00:13 438 66.3End Snap: 39719 07-Jun-11 06:00:19 651 64.4Elapsed: 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.30Logical reads: 187,227.45 2,479.88Block changes: 4,078.58 54.02Physical reads: 29.63 0.39Physical writes: 79.30 1.05User calls: 2,638.29 34.94Parses: 1200.23 5.81Hard parses: 52.84 0.70Sorts: 230.95 3.06Logons: 0.91 0.01Executes: 601.64 7.97Transactions: 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.00Buffer Hit %: 99.99 In-memory Sort %: 100.00Library Hit %: 91.75 Soft Parse %: 87.95Execute to Parse %: 27.13 Latch Hit %: 99.97Parse 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 ConcurrencyCPU time 11,675 39.7log file sync 193,236 1,109 6 3.8 Commitlog file parallel write 224,479 795 4 2.7 System I/Odb 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 didn’t have to be reparsed and your session didn’t 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 swhere a.statistic# = b.statistic# and s.sid=a.sidand 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 pwhere a.statistic# = b.statistic# and s.sid=a.sidand 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=FORCESESSION_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 that’s 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
I’ve 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 Oracle’s 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 Oracle’s 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/O’s (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
Oracle’s 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/O’s coming from the higher level. In particular, I have seen Red Hat 5.6 native multipathing breaking 64K or
128K I/O’s into multiple 4K I/O’s. Still don’t 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 ASM’s mirroring (ASM “normal redundancy” setting)
capabilities as a poor man’s 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 QUESTIONSTop 10 ASM QuestionsASM Architecture
Top 10 ASM QuestionsQ.1) What init.ora parameters does a user need toconfigure for ASM instances?A. The default parameter settings work perfectly forASM. The only parameters needed for 11g ASM:• PROCESSES*
• ASM_DISKSTRING*• ASM_DISKGROUPS• INSTANCE_TYPE•ASM is a very passive instance in that it doesn’t have a lot concurrent transactionsor 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 determinethe approp value:processes = 40 + (10 + [max number of concurrent database filecreations, and file extend operations possible])*nWhere 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 ASMinstance and how do I make ASM go faster?A. ASM is not in the I/O path so ASM does not impedethe database file access. Since the RDBMS instanceis 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 necessaryextents from extent map, all database IO going forward is processedthrough by the database processes, bypassing ASM. Thus we sayASM is not really in the IO path. So, the question how do we makeASM go faster…..you don’t have to.
RDBMS and ASM Instance InteractionServerOperating SystemDATABASE 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) Commit1A. Database issues open of a database file1B. ASM sends the extent map for the file to database instance. Startingwith 11g, the RDBMS only receives first 60 extents the remaining extentsin the extent map are paged in on demand, providing a faster open2A/2B. Database now reads directly from disk3A.RDBMS foreground initiates a create tablespace for example3B. ASM does the allocation for its essentially reserving the allocation units
for the file creation3C. Once allocation phase is done, the extent map is sent to the RDBMS3D. The RDBMS initialization phase kicks in. In this phase the initializes allthe reserved AUs3E. If file creation is successful, then the RDBMS commits the file creationGoing forward all I/Os are done by the RDBMS.
Q.3) Do I need to define the RDBMSFILESYSTEMIO_OPTIONS parameter when I use ASM?A. No. The RDBMS does I/O directly to the raw diskdevices, the FILESYSTEMIO_OPTIONS parameter isonly for filesystems.A. Review what the use of FILESYSTEMIO_OPTIONS parameter;essentially FILESYSTEMIO_OPTIONS is used for filesystem/blockstorage.This parameter controls which IO options are used. The value may be any ofthe following:*asynch - This allows asynchronous IO to be used where supported by theOS.*directIO - This allows directIO to be used where supported by the OS.Direct IO bypasses any Unix buffer cache. *setall - Enables bothASYNC and DIRECT IO. "none" - This disables ASYNC IO and DIRECTIO so that Oracle uses normal synchronous writes, without any direct iooptions.A. RDBMS does raw IO against the ASM disks, so need forFILESYSTEMIO_OPTIONS parameter. The only parameter that needs tobe set is disk_asyncio=true, which is true by default. If using ASMLIBthen even the disk_async does not need to be set.ASM is also supported for NFS files as ASM disks. In such cases, therequired NFS mount options eliminate the need to setFILESYSTEMIO_OPTIONS.
Q.4) I read in the ASM Best Practices paper that Oraclerecommends two diskgroups. Why?A. Oracle recommends two diskgroups to provide abalance of manageability, utilization, andperformance.To reduce the complexity of managing ASM and its diskgroups, Oracle recommends thatgenerally no more than two diskgroups be maintained and managed per RAC cluster orsingle ASM instanceoDatabase 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. Thislocation is indicated by DB_CREATE_FILE_DEST.oFlash recovery area: Where recovery-related files are created, such as multiplexed copiesof the current control file and online redo logs, archived redo logs, backup sets, andflashback 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 obviatesthe 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 ITdirector very happy. If more storage capacity or IO capacity is needed, just add an ASMdisk….all online activities.You have to ensure that this storage pool container houses enough spindles toaccommodate the IO rate of all the database objectsBottom line, one container == one pool manage, monitor, and trackNote however, that additional diskgroups may be added to support tiered storage classes inInformation Lifecycle Management (ILM) or Hierarchical Storage Management (HSM)
deployments
Q.5) We have a 16 TB database. I’m curious about thenumber of disk groups we should use; e.g. 1 largedisk group, a couple of disk groups, or otherwise?A. For VLDBs you will probably end up with differentstorage tiers; e.g with some of our large customersthey have Tier1 (RAID10 FC), Tier2 (RAID5 FC), Tier3(SATA), etc. Each one of these is mapped to adiskgroup.These custs mapped certain tablespaces to specific tiers; eg, system/rollback/syauxand 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 spaceefficiency than for performance. The 16MB recommendation is only necessary if thediskgroup is going to be used by 10g databases. In 11g we introduced variable sizeextents 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 largestI/O that you wish to issue for sequential access (other parameters need to be set toincrease the I/O size issued by Oracle). For random small I/Os the AU size does notmatter very much as long as every file is broken into many more extents than there aredisks.15
Q.6) We have a new app and don’t know our accesspattern, but assuming mostly sequential access, whatsize would be a good AU fit?A. For 11g ASM/RDBMS it is recommended to use 4MBASM AU for disk groups.See Metalink Note 810484.1For all 11g ASM/DB users, it best to create a disk group using 4 MB ASM AU size. MetalinkNote 810484.1 covers this
Q.7) Would it be better to use BIGFILE tablespaces, orstandard tablespaces for ASM?A. The use of Bigfile tablespaces has no bearing on ASM(or vice versa). In fact most database object relateddecisions are transparent to ASM.Nevertheless, Bigfile tablespaces benefits:Fewer datafiles - which means faster database open (fewer files toopen),Faster checkpoints, as well fewer files to manage. But you'll needcareful consideration for backup/recovery of these large datafiles.
Q.8) What is the best LUN size for ASMA. There is no best size! In most cases the storageteam will dictate to you based on their standardizedLUN size. The ASM administrator merely has tocommunicate the ASM Best Practices and applicationcharacteristics 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 SLAUsing 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 sizeis. This is based on several factors,including RAID LUN set builds (concatenated, striped, hypers, etc..). Having toomany LUNs elongates boottime and is it very hard to manage On the flip side, having too few LUNs makes arraycache management difficult tocontrol and creates un-manageable large LUNs (which are difficult to expand).The ASM adminstrator merely has to communicate to SA/storage folks that you needequally sized/performance LUNs and what the capacity requirement is, say 10TB.Using this info, the workload characteristic (random r/w, sequential r/w), and theirstandards, the storage folks should build a nice LUN group set for youHaving 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 fromDBAs and create different users and groups. How dowe 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 bea member of ASM's OSDBA group.• Choose a different OSDBA group for ASM instance (asmdba) than forRDBMS instance (dba)• In 11g, ASM administrator has to be member of a separate SYSASM group toseparate ASM Admin and DBAs.Operating system authentication using membership in the group or groupsdesignatedas OSDBA, OSOPER, and OSASM is valid on all Oracle platforms.A typical deployment could be as follows:ASM administrator:User : asmGroup: oinstall, asmdba(OSDBA), asmadmin(OSASM)Database administrator:User : oracleGroup: oinstall, asmdba(OSDBA of ASM), dba(OSDBA)ASM disk ownership : asm:oinstallRemember that Database instance connects to ASM instance assysdba. The user id the database instance runs as needs to be theOSDBA group of the ASM instance.
A typical deployment could be as follows:ASM administrator:User : asmGroup: oinstall, asmdba(OSDBA), asmadmin(OSASM)Database administrator:User : oracleGroup: oinstall, asmdba(OSDBA of ASM), dba(OSDBA)A typical deployment could be as follows:ASM administrator:User : asmGroup: oinstall, asmdba(OSDBA), asmadmin(OSASM)Database administrator:User : oracleGroup: oinstall, asmdba(OSDBA of ASM), dba(OSDBA)
Q.10) Can my RDBMS and ASM instances run differentversions?A. Yes. ASM can be at a higher version or at lowerversion than its client databases. There’s twocomponents of compatiblity:• Software compatibility• Diskgroup compatibility attributes:• compatible.asm• compatible.rdbmsThis is a diskgroup level change and not an instance level change…norolling upgrade here!
Disk Group Compatibility Example• Start with 10g ASM and RDBMS• Upgrade ASM to 11g• Advance compatible.asm• ALTER DISKGROUP dataSET ATTRIBUTE‘compatible.asm’ = ’11.1.0.7.0’• 10g RDBMS instances are still supported• 10g ASM instance can no longer mount the diskgroup22Disk Group Compatibility Example• Upgrade RDBMS to 11g• In the RDBMS instance set initialization parameter• compatible = 11.0• Advance compatible.rdbms• ALTER DISKGROUP dataSET 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 group23Disk Group Compatibility Example• Compatibility may be set during disk group creation• CREATE DISKGROUP dataDISK ‘/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 cannotbe reversed
Q.11) Where do I run my database listener from; i.e., ASMHOME or DB HOME?A. It is recommended to run the listener from the ASMHOME. This is particularly important for RAC env,since the listener is a node-level resource. In thisconfig, you can create additional [user] listeners from
the database homes as needed.- Allows registering multiple databases on the node to register with thelistener without being tied to a specific database home- From configuration tool standpoint (netca), we promote best practiceof creating one listener per node with node name suffix (that isregistered with CRS) and subsequent tools that create/upgradedatabases will register instances to that listener. One can alwayscreate multiple listeners in different homes and use'em but that wouldcomplicate the configurationBackups for ASM:
Top 10 ASM QuestionsQ.1) How do I backup my ASM instance?A. Not applicable! ASM has no files to backupUnlike the database, ASM does require a controlfile type structure orany other external metadata to bootstrap itself. All the data ASM needsto startup is on on-disk structures (disk headers and other disk groupmetadata).A Disk Group is the fundamental object managed by ASM. It iscomposed of multiple ASM disks. Each Disk Group is self-describing,like a standard file system. All the metadata about the usage of thespace 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 tothe disk group without any additional metadata
Q.2)When should I use RMAN and when should I useASMCMD copy?A. RMAN is the recommended and most complete andflexible method to backup and transport database filesin 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 filesRMAN is the most complete and versatile means to backup databasesstored in ASM.However, many customers use BCV/split-mirrors as backups for ASMbased databases. Many combine BCV mirrors with RMAN backupof the mirrors. Why would you want to do that? RMAN ensures theintegrity of the database data blocks by running sanity checks as itbacks up the blocksNow most of you are wondering about the 11g asmcmd copycommand, and how that fits in here. asmcmd cp is not intended todo wholesale backups (plus you’ll have to put the database in hotbackup).In 10g the possible ways to migrate - DBMS_FILE_TRANSFER, rman (copy vs.backup), or XMLDB FTPIn 11g, we introduced the asmcmd copy command. Key point here is that copy filesout is great for:1. archive logs2. Controlfiles3. Datafiles for debugging4. Dumpsets (can be done across platforms)Copying files in:TTS
Copy in only supported files.28ASMCMD CopyASMCMD> ls+fra/dumpsets/expdp_5_5.datASMCMD> cp expdp_5_5.dat [email protected]:+DATA/dumpsets/expdp_5_5.datsource +fra/dumpsets/expdp_5_5.dattarget +DATA/dumpsets/expdp_5_5.datcopying file(s)...file, +DATA/dumpsets/expdp_5_5.dat,copy committed.
Top 10 ASM QuestionsMigration
Top 10 ASM QuestionsQ. I’m 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 LevelUse v$asm_operation31
Q. We are migrating to a new storage array. How do Imove my ASM database from storage A to storage B?A. Given that the new and old storage are both visible toASM, simply add the new disks to the ASM disk groupand drop the old disks. ASM rebalance will migratedata online. Note 428681.1 covers how to moveOCR/Voting disks to the new storage arrayIf this is a RAC environment, the Note 428681.1 covers how to moveOCR/Voting disks to the new storage array
ASM_SQL> alter diskgroup DATAdrop diskdata_legacy1, data_legacy2,data_legacy3add disk‘/dev/sddb1’, ‘/dev/sddc1’,‘/dev/sddd1’;
ASM Rebalancing• Automatic online rebalance wheneverstorage configuration changes• Only move data proportional to storageadded• No need for manual I/O tuningDisk Group DATA (legacy disks)
ASM Rebalancing• Automatic online rebalance wheneverstorage configuration changes• Online migration to new storage
Disk Group DATA
ASM Rebalancing• Automatic online rebalance wheneverstorage configuration changes• Online migration to new storageDisk Group DATA
ASM Rebalancing• Automatic online rebalance wheneverstorage configuration changes• Online migration to new storageDisk Group DATA
ASM Rebalancing• Automatic online rebalance wheneverstorage configuration changes• Online migration to new storageDisk Group DATA (new disks)
Top 10 ASM QuestionsQ. Is it possible to unplug an ASM disk group from oneplatform and plug into a server on another platform(for example, from Solaris to Linux)?A. No. Cross-platform disk group migration notsupported. To move datafiles between endian-nessplatforms, you need to use XTTS, Datapump orStreams.The first problem that you run into here is that Solaris and Linuxformat their disks differently. Solaris and Linux do not recognize eachother’s partitions, etc.ASM does track the endian-ness of its data. However, currently, theASM code does not handle disk groups whose endian-ness does notmatch that of the ASM binary.Experiments have been done to show that ASM disk groups can bemigrated from platforms that share a common format and endian-ness(i.e. Windows to Linux), but this functionality is not currently officiallysupported because is not regularly tested yet.The following links show how to migrate across platformshttp://downloadwest.oracle.com/docs/cd/B19306_01/server.102/b25159/outage.htm#CACFFIDDhttp://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_PlatformMigrationTTS.pdf
Top 10 ASM Questions3rd Party Software40Top 10 ASM QuestionsQ. How does ASM work with multipathing software?A. It works great! Multipathing software is at a layerlower than ASM, and thus is transparent.You may need to adjust ASM_DISKSTRING to specifyonly 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, orHBA.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 autofailbackcapabilities.oConfigure the multi-paths to maximize performance using various load balancingmethods; 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 pathname at the OS level; e.g.; /dev/rdsk/c3t19d1s4 and /dev/rdsk/c7t22d1s4 could be pointingto same disk device. ASM, however, can only tolerate the discovery of one unique devicepath per disk. For example, if the asm_diskstring is ‘/dev/rdsk/*’, then several paths to thesame 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 willgenerally produce a pseudo device that virtualizes the sub-paths. For example, in thecase of EMC’s 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 willintercept 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 shouldwork. Most all MP products are known to work w/ ASM. But remember ASM does notcertify MP products, though we have a list products that work w/ ASM, this is more ofa guide of what’s available by platform/OS.Examples of multi-pathing software include EMC PowerPath, Veritas DMP, Sun TrafficManager, Hitachi HDLM, and IBM SDDPCM. Linux 2.6 has a kernel based multipathing
ASM/RDBMS/dev/Multipath driver/dev/sda1 /dev/sdb1Controller ControllerCacheDiskIO cloud
Top 10 ASM QuestionsQ. Is ASM constantly rebalancing to manage “hotspots”?A. No…No…Nope!!Bad rumor. ASM provides even distribution of extents across all disksin a disk group. Since each disk will equal number of extents, nosingle disk will be hotter than another. Thus the answer NO, ASM doesnot dynamically move hot spots, because hot spots simply do notoccur in ASM configurations.Rebalance only occurs on storage configuration changes (e.g. add,drop, or resize disks).43I/O Distribution• ASM spreads file extents evenly across all disks in disk group• Since ASM distributes extents evenly, there are no hot spotsAverage IOPS per disk during OLTP workload050100150200
250300TotalDiskIOPSFG1: - cciss/c0d2FG1: - cciss/c0d3FG1: - cciss/c0d4FG1: - cciss/c0d5FG1: - cciss/c0d6FG2: - cciss/c0d2FG2: - cciss/c0d3FG2: - cciss/c0d4FG2: - cciss/c0d5FG2: - cciss/c0d6FG3: - cciss/c0d2FG3: - cciss/c0d3FG3: - cciss/c0d4FG3: - cciss/c0d5FG3: - cciss/c0d6FG4: - cciss/c0d2FG4: - cciss/c0d3FG4: - cciss/c0d4FG4: - cciss/c0d5FG4: - cciss/c0d6As indicated, ASM implements the policy of S.A.M.E. that stripes and mirrorsfiles across all the disks in a Disk Group. If the disks are highly reliable asthe case may be with a high-end array, mirroring can be optionally disabledfor a particular Disk Group. This policy of striping and mirroring across alldisks in a disk group greatly simplifies storage management and provides aconfiguration 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 allavailable 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 fees45
Summary:• ASM requires very few parameters to run• ASM based databases inherently leverage raw diskperformance• No additional database parameters needed to supportASM• Mixed ASM-database version support• Facilitates online storage changes• RMAN recommended for backing up ASM baseddatabases• Spreads I/O evenly across all disks to maximizeperformance and eliminates hot spotsASM provides filesystem and volume manager capabilities built into the Oracle database kernel. Withthis capability, ASM simplifies storage management tasks, such as creating/laying out databases anddisk space management. Since ASM allows disk management to be done using familiarcreate/alter/drop SQL statements, DBAs do not need to learn a new skill set or make crucial decisionson provisioning.The following are some key benefits of ASM:oASM spreads I/O evenly across all available disk drives to prevent hot spots and maximizeperformance.oASM eliminates the need for over provisioning and maximizes storage resource utilization facilitatingdatabase consolidation.oInherent large file support.oPerforms automatic online redistribution after the incremental addition or removal of storagecapacity.oMaintains redundant copies of data to provide high availability, or leverages 3rd party RAIDfunctionality.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 fileactivities.ASM reduces Oracle Database cost and complexity without compromising performance or availability46ASM Collateral and Contenthttp://www.oracle.com/technology/asm• ASM 11g New Features• ASM Best Practices• ASM vendor papers• ASM-RAC Customer Case Studies
Top 10 ASM QuestionsExtra credit questions
Top 10 ASM QuestionsQ. Is ASMLIB required on Linux systems and are thereany benefits to using it?A. ASMLIB is not required to run ASM, but it is certainlyrecommended.ASMLIB has following benefits:• Simplified disk discovery• Persistent disk names• Efficient use of system resourceso Reduced Overhead
ASMLIB provides the capability for a process (RBAL) to perform a global open/closeon the disks that are being dropped or closed.This reduces the number of open file descriptors on the system, thus reduces theprobability of running out of global file descriptors on the system. Also, the openand close operations are reduced, ensuring orderly cleanup of file descriptors whenstorage configurations changes occur.A side benefit of the aforementioned items is a faster startup of the database.o Disk Management and DiscoveryWith ASMLib the ASM disk name is automatically taken from the name given it by theadministrative tool. This simplifies adding disks and correlating OS names with ASMnames, as well as eliminates erroneous disk management activities since disks arealready pre-named.The default discovery string for ASM is NULL, however, if ASMLIB is used, theASMLIB default string replaces the NULL string, making disk discovery much morestraightforward. Note, disk discovery has been one of the big challenges foradministrators.The ASMLib permissions are persistent across reboot and in the event of major/minornumber changesIn 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 thedefault disk discovery string, and discovery is seamless.o No requirement to setup raw linksWith ASMLib, there is not a requirement to modify the initializations (e.g. “/etc/init.d”)
Top 10 ASM QuestionsQ. Is it possible to do rolling upgrades on ASMLIB in aRAC configurationA. ASMLIB is independent of Oracle Clusterware andOracle Database, and thus can be upgraded on itsownUpgrading ASMLIB one a given node will require that ASMLIB bedisabled/stop, will require the database and ASM to also beshutdown on that node. Once the ASMLIB is upgarded then the stack can berestarted.
