Question with Answer on Oracle database Patches

Patches are a small collection of files copied over to an existing installation. They are associated with
particular versions of Oracle products.
The discussion will especially help for those beginners who are preparing for interview and inexperienced
to apply the patches. In this article you will find all those things briefly with an example. For more details
please study the oracle documentation and try to search with separate topics on this blog.
What are different Types of Patches?
Regular Patcheset: To upgrade to higher version we use database patchset. Please do not confuse
between regular patchests and patch set updates (PSU). Consider the regular patchset is super set of
PSU. Regular Patchset contain major bug fixes. In comparison to regular patch PSU will not change the
version of oracle binaries such as sqlplus, import/export etc. The importance of PSU is automatically
minimized once a regular patchset is released for a given version. It is mainly divided into two types:
Security or Critical Patch Update (CPU): Critical patch update quarterly delivered by oracle to fix
security issues.
Patch set updated (PSU): It include CPU and bunch of other one-off patches. It is also quarterly
delivered by oracle.
Interim (one-off) Patch: It is also known as patchset exception or one-off patch or interim patch. This is
usually a single fix for single problem or enhancement. It released only when there is need of immediate
fix or enhancement that cannot wait until for next release of patchset or bundle patch. It is applied using
OPATCH utility and is not cumulative.
Bundle Patches: Bundle Patches includes both the quarterly security patches as well as recommended
fixes (for Windows and Exadata only). When you try to download this patch you will find bundle of patches
(different set of file) instead of single downloaded file (usually incase patchset).
Is Opatch (utility) is also another type of patch?
OPatch is utility from oracle corp. (Java based utility) that helps you in applying interim patches to
Oracle's software and rolling back interim patches from Oracle's software. Opatch also able to Report
already installed interim patch and can detect conflict when already interim patch has been applied. This
program requires Java to be available on your system and requires installation of OUI. Thus from the
above discussion coming to your question it is not ideal to say OPATCH is another patch.
When we applying single Patch, can you use OPATCH utility?
Yes, you can use Opatch incase of single patch. The only type of patch that cannot be used with OPatch
is a patchset
When you applying Patchsets, You can use OUI.
Yes, Patcheset uses OUI. A patch set contains a large number of merged patches, to change the version
of the product or introduce new functionality. Patch sets are cumulative bug fixes that fix all bugs and
consume all patches since the last base release. Patch sets and the Patch Set Assistant are usually
applied through OUI-based product specific installers.
Can you Apply OPATCH without downtime?
As you know for apply patch your database and listener must be down. When you apply OPTACH it will
update your current ORACLE_HOME. Thus coming to your question to the point in fact it is not possible
in case of single instance but in RAC you can Apply Opatch without downtime as there will be more
separate ORACLE_HOME and more separate instances (running once instance on each
ORACLE_HOME).
You have collection of patch (nearly 100 patches) or patchset. How can you apply only one patch
from patcheset or patch bundle at ORACLE_HOME?
With Napply itself (by providing patch location and specific patch id) you can apply only one patch from a

collection of extracted patch. For more information check the opatch util NApply help. It will give
you clear picture.
For Example:
opatch util napply <patch_location> -id 9 -skip_subset -skip_duplicate
This will apply only the patch id 9 from the patch location and will skip duplicate and subset of patch
installed in your ORACLE_HOME.
How can you get minimum/detail information from inventory about patches applied and
components installed?
You can try below command for minimum and detail information from inventory
C:\ORACLE_HOME\Opatch\opatch lsinventory invPtrLoc location of oraInst.loc
file
$ORACLE_HOME\OPatch\opatch lsinventory -detail -invPtrLoc location of
oraInst.loc file
Differentiate Patcheset, CPU and PSU patch? What kind of errors usually resolved from them?
Critical Patch Update (CPU) was the original quarterly patches that were released by oracle to target the
specific security fixes in various products. CPU is a subset of patchset updates (PSU). CPU are built on
the base patchset version where as PSU are built on the base of previous PSU
Patch Set Updates (PSUs) are also released quarterly along with CPU patches are a superset of CPU
patches in the term that PSU patch will include CPU patches and some other bug fixes released by
oracle. PSU contain fixes for bugs that contain wrong results, Data Corruption etc but it doe not contain
fixes for bugs that that may result in: Dictionary changes, Major Algorithm changes, Architectural changes,
Optimizer plan changes
Regular patchset: Please do not confuse between regular patchests and patch set updates (PSU).
Consider the regular patchset is super set of PSU. Regular Patchset contain major bug fixes. The
importance of PSU is minimizing once a regular patchset is released for a given version. In comparison to
regular patch PSU will not change the version of oracle binaries such as sqlplus, import/export etc.
If both CPU and PSU are available for given version which one, you will prefer to apply?
From the above discussion it is clear once you apply the PSU then the recommended way is to apply the
next PSU only. In fact, no need to apply CPU on the top of PSU as PSU contain CPU (If you apply CPU
over PSU will considered you are trying to rollback the PSU and will require more effort in fact). So if you
have not decided or applied any of the patches then, I will suggest you to go to use PSU patches. For
more details refer:Oracle Products [ID 1430923.1], ID 1446582.1
PSU is superset of CPU then why someone choose to apply a CPU rather than a PSU?
CPUs are smaller and more focused than PSU and mostly deal with security issues. It seems to be
theoretically more consecutive approach and can cause less trouble than PSU as it has less code
changing in it. Thus any one who is concerned only with security fixes and not functionality fixes, CPU
may be good approach.
How can you find the PSU installed version?
PSU references at 5th place in the oracle version number which makes it easier to track such as (e.g.
10.2.0.3.1). To determine the PSU version installed, use OPATCH utility:
OPATCH lsinv -bugs_fixed | grep -i PSU
To find from the database:
Select substr(action_time,1,30) action_time, substr(id,1,10) id,
substr(action,1,10) action,substr(version,1,8) version,
substr(BUNDLE_SERIES,1,6) bundle, substr(comments,1,20) comments from
registry$history;

Note: You can find the details from the above query if you already executed the catbundle.sql
Click to Check Existing Oracle Database Patch Status

Will Patch Application affect System Performance?

Sometimes applying certain patch could affect Application performance of SQL statements. Thus it is
recommended to collect a set of performance statistics that can serve as a baseline before we make any
major changes like applying a patch to the system.
Can you stop applying a patch after applying it to a few nodes? What are the possible issues?
Yes, it is possible to stop applying a patch after applying it to a few nodes. There is a prompt that allows
you to stop applying the patch. But, Oracle recommends that you do not do this because you cannot
apply another patch until the process is restarted and all the nodes are patched or the partially applied
patch is rolled back.
How you know impact of patch before applying a patch?
OPATCH <option> -report
You can use the above command to know the impact of the patch before actually applying it.
How can you run patching in scripted mode?
opatch <option> -silent
You can use the above command to run the patches in scripted mode.
Can you use OPATCH 10.2 to apply 10.1 patches?
No, Opatch 10.2 is not backward compatible. You can use Opatch 10.2 only to apply 10.2 patches.
What you will do if you lost or corrupted your Central Inventory?
In that case when you lost or corrupted your Central Inventory and your ORACLE_HOME is safe, you just
need to execute the command with attachHomeflag, OUI automatically setup the Central Inventory
for attached home.
What you will do if you lost your Oracle home inventory (comps.xml)?
Oracle recommended backup your ORACLE_HOME before applying any patchset. In that case either you
can restore your ORACLE_HOME from the backup or perform the identical installation of the
ORACLE_HOME.
When I apply a patchset or an interim patch in RAC, the patch is not propagated to some of my
nodes. What do I do in that case?
In a RAC environment, the inventory contains a list of nodes associated with an Oracle home. It is
important that during the application of a patchset or an interim patch, the inventory is correctly populated
with the list of nodes. If the inventory is not correctly populated with values, the patch is propagated only
to some of the nodes in the cluster.
OUI allows you to update the inventory.xml with the nodes available in the cluster using the updateNodeList flag in Oracle Universal Installer.
When I apply a patch, getting the following errors:
"Opatch Session cannot load inventory for the given Oracle Home <Home_Location> Possible
causes are: No read or write permission to ORACLE_HOME/.patch_storage; Central Inventory is
locked by another OUI instance; No read permission to Central Inventory; The lock file exists in
ORACLE_HOME/.patch_storage; The Oracle Home does not exist in Central Inventory". What do I
do?
This error may occur because of any one or more of the following reasons:
The ORACLE_HOME/.patch_storage may not have read/write permissions. Ensure that you give
read/write permissions to this folder and apply the patch again.
There may be another OUI instance running. Stop it and try applying the patch again.
The Central Inventory may not have read permission. Ensure that you have given read permission
to the Central Inventory and apply the patch again.
The ORACLE_HOME/.patch_storage directory might be locked. If this directory is locked, you will find
a file named patch_locked inside this directory. This may be due to a previously failed installation of a

patch. To remove the lock, restore the Oracle home and remove thepatch_locked file from
the ORACLE_HOME/.patch_storage directory.
The Oracle home may not be present in the Central Inventory. This may be due to a corrupted or
lost inventory or the inventory may not be registered in the Central Inventory.
We should check for the latest security patches on the Oracle metalink
website http://metalink.oracle.com/ and we can find the regular security alert at the
location http://technet.oracle.com/deploy/security/alert.htm
Caution: It is not advisable to apply the patches directly into the production server. The ideal solution is
to apply or test the patches in test server before being moved into the production system.

About Patching in Oracle

Patches are a small collection of files copied over to an existing installation. They are associated with
particular versions of Oracle products.
The article is specially for beginners who don't know about patching, how to apply it, how to get
patches, what are the step or process when you need to apply patches and what are the precaution to be
considered while applying patching. Here in this article you will find all those things briefly with an
example. For more details please study the oracle documentation.
Types of Patches:
Database patches are various kinds but mainly categories into three parts:
1.
Patchset Exception (also known as PSE, one-off, interim patch)
2.

Patch bundle (also known as MLR patch or Patchset)

3.

Security Patches (also know as CPU and PSU)

4.

Patchset

PSE, one-off or interim patch: This is usually a single fix for single problem. Interim patches are bug
fixes given to the customers in critical need and are not cumulative, regressed or versioned. It is applied
via opatch. You can use opatch lsinventory command to see which one-off patch are installed on your
system.
MRL patch: This type of patch is created by putting several fixes into a single patch. It is also applied
using opatch.
Security Patches: Security Patches are mainly divided into two types
(i) CPU (Critical Patch Update): These patches are quarterly delivered by oracle to fix security issues. It is
also applied using opatch.
(ii) PSU (Patch Set Updates): Patchset updated also quarterly delivered by oracle. It includes CPU and a
bunch of other one-off patches. CPU and PSU are Cumulative but we can stop to apply CPU if not
required.
Patchset: Patchsets are applied via OUI (Oracle Universal Installer). It is usually applied to upgrade
oracle version. For Example if you want to upgrade oracle version from 9.2.0.1.0 to 9.2.0.7.0 then Apply
the patchset 4163445. you can find the stepwise details how to Apply patchset on my
blog: http://shahiddba.blogspot.com/
About Opatch:
OPatch is a Java-based utility that runs on all supported operating systems and requires installation of the
Oracle Universal Installer.
Types of Patches That can not be Used with OPatch
The only type of patch that cannot be used with OPatch is a patchset. A patchset contains a large
number of merged patches, is thoroughly tested, changes the version of the product it is applied to, can
sometimes introduce new functionality, and should be applied when suitable. Patch sets are cumulative

bug fixes that fix all bugs and consume all patches since the last base release. Patchset are usually
applied through OUI-based product specific installers.
How to Get Opatch:
(i)
Access and log into My Oracle Support at the following location: http://support.oracle.com/
(ii)
In the Search Knowledge Base field, enter 224346.1. This is the ID of the document that describes how
to obtain the latest version of OPatch.
(iii) In the search results, click on the link corresponding to document ID 224346.1.
(iv) In the document, click on the Patch 6880880 link which will take you to the screen where you can obtain
the latest version of OPatch based on release versions and platforms.
OPatch System Requirements
The OPatch utility has the following requirements:

The ORACLE_HOME environment variable must point to a valid Oracle home directory and match the
value used during installation of the Oracle home directory.

If the -invPtrLoc command-line argument was used during installation, and then it must be used when
using the OPatch utility. Oracle recommends the use of the default central inventory for a platform.

The java, ar, cp, and make commands must be available in one of the directories listed in
the PATH environment variable. The commands are not available for all platforms.
Getting Patches:
(i)
Access and log into My Oracle Support at the following location: http://support.oracle.com/
(ii)
Click the Patches & Updates link.
(iii) Enter the Patch ID or Number, then click Search. A Patch Search Results table appears.
(iv) Using the Release and Platform columns, find the desired patch, then click the associated Patch ID.
(v)
In the page that now appears, click the Download button in the right-hand column.
Backup and Recovery Considerations for Patching
It is highly recommended that you back up the ORACLE_HOME before any patch operation. You can
back up the ORACLE_HOME using your preferred method. You can use any method such as zip, cp
-r, tar, and cpio to compress the ORACLE_HOME.
Steps and Process when you need to apply patches:
First, determine the patch you have to apply, if you are applying a patchset (e.g., 10.2.0.1 to 10.2.0.3) or a
one-off patch or CPU patch. These are applied in different ways. Applying a patchset usually requires the
use of the Oracle Universal Installer (OUI) and then running a script inside each database using that
ORACLE_HOME. When you download the patchset, it will be accompanied by a detailed, step-by-step
guide for how to apply the patchset.
Step 1: Contact Oracle Support
You can contact to the oracle support representative and you can go to the MY Oracle
Support: https://support.oracle.com/CSP/ui/flash.html
Step 2: Check for Existing patches
If Oracle Support is not able to resolve the issue, they may ask to see if you have any patches already
installed on your system. To determine this information, you should run the opatch lsinventory command
or opatch checkInstalledOneOffs command.
Example:
D:\>cd %ORACLE_HOME%\opatch
D:\oracle\ora92\OPatch>opatch lsinventory
Note: Opatch does not list the patch applied on Database. It list only the interim patch applied on oracle
binaries. You can list patch applied on database with the help of below query in 10g R2.
SQL>Select * from sys.registry$history;
Step 3. Obtain OPatch and the Necessary Patch

Upon determining that you are in need of a new patch and it has not already been installed on your
system, you should do the above steps: Getting Patches:
Step 4. Determine the Oracle Home
Once you obtain the patch, determine the Oracle home directory to which you are going to apply the
patch.
Step 5. Read the README File
Read the README file that accompanies the patch. This file contains important information and
instructions that must be followed prior to applying your patch.
Step 6. Apply the Patch
After you determine the Oracle home to which you need to apply the patch, you should apply the patch
with the opatch apply command
The syntax for the apply command is shown below:
opatch apply
[-auto [-domain domain_name]]
[-mw_home MW_HOME]
[-oh ORACLE_HOME]
[-property_file path_to_property_file]
[-report]]

After Applying the Patch...

In most cases, after you apply the patch the instructions in the README file will tell you to run the opatch
start command to re-start your servers.
After the patching is complete and your servers are restarted, you should check your product software to
verify that the issue has been resolved.
If for some reason the result is not satisfactory, you can use the opatch rollback command to remove the
patch from the Oracle home.
The syntax for the rollback option is shown below:
opatch rollback -id patch_id
[-auto [-domain domain_name]]
[-mw_home MW_HOME]
[-oh ORACLE_HOME]
[-property_file path_to_property_file
[-report]]

How to apply Patchset updates or Critical Patch Updates with Example

PSUs (PatchSet Updates) or CPUs(Critical Patch Updates) are applied via Opatch utility.
Opatch is an interim utility for applying Database interim patches which will fix the bug in the release. For
making use of the opatch utility you have to download the opatch recent version and apply as follow:
Opatch is very useful for applying the database patches to fix various bugs and it is essential to have the
latest version.
1) Download the latest OPatch version from My Oracle Support.
a) Click on the "Patches & Updates" tab
b) In the "Patch Name or Number" field type 6880880
c) In the "Platform" field select the relevant platform
d) Click the Search button.
e) Select the patch that corresponds to the Oracle release installed:
6880880 Universal Installer: Patch OPatch 11.2
f) Click the Download button
Once the above task is done copy the patch to $ORACLE_HOME directory and move the previous
OPatch directory to separate directory in OS. We can use winscp or ftp for copying this patch from MOS
to windows and than windows to linux Box.
g) Now, unzip this patch zip file and apply it.
How to apply patch:

C:\ CD oracle1\Opatch
-- C:\ORACLE1 is the ORACLE-HOME
C:\oracle1\Optach\opatch> apply D:\Patch_dir -- D:\Patch_dir is the path where you have downloaded
or kept the patch.
Note: Before going to apply the patch you must search or check these file Users_Guide.txt,
opatch_history.txt.
For Example:
To Apply patches on 9.2.0.1.0 to upgrade 9.2.0.7.0 check the below
link: http://shahiddba.blogspot.com/2012/03/upgrade-database-version-fron-92010-to.html

How to Apply Critical Patch Update (CPU) on RAC

Patch Details: Patch CPUJULY2012
CPU patch is released 4 times in a year JAN/APR/JUL/OCT
Version & Platform: 10.2.0.4 Database on LINUX

Overview: A Critical patch update (CPU) is a collection of patches for multiple security vulnerabilities.
CPU patch are usually cumulative, which means fixes from previous Oracle security alerts and critical
patch updates are included in current patch. However each advisory describes only the security fixes
added since the critical patch update advisory. Thus it is not required to have previous security patches
applied before applying the latest patches. However, you must be on the stated patch set level for a given
product home before applying the latest patches for that release:Information about latest CPU patch
Note: Do not forget to read the README file from the patch before start the actual work.
If this is a RAC environment, select one of the patch installation methods provided by OPatch (rolling, all
node, or minimum downtime), and shutdown instances and listeners as appropriate for the installation
method selected. This CPU patch is rolling RAC installable.
If this is not a RAC environment, shut down all instances and listeners associated with the Oracle home
that you are updating.
Repeat the Steps for each node of RAC
Shutdown the Oracle instances and services or listener on node 1
Apply the patch to the on node 1
Start the Oracle instance of node 1
Now Shutdown the Oracle instance on node 2
Apply the patch to on node 2
Start the Oracle instance of node 2
Repeat this process as per the number of node.
1. Download the CPU required patchset from Metalink
2. Change the owner of the patch file to oracle user.
# chown R oracle
3. Set the PATH variable to locate the opatch utility.
$ export PATH=$PATH: $ORACLE_HOME/OPatch
4. unzip the patch and go the unzipped directory
$unzip patchfile.zip
5. Find and invoke the Opatch version
$ opatch version
OPatch Version: 10.2.0.4.2
$ opatch lsinventory
If you want check the CPU patch is whether rolling support or not, go to the patch directory
Cd /oracle/?? --patch directory
[oracle@rac1 ??]$ opatch query -all

6. Backup the oraInventory and Opatch directory

$cp -R oraInventory old_oraInventory
$cp -R opatch old_opatch
7. If you are Applying on RAC: Stop Instance/asm/nodeapps of node1
$ srvctl stop instance -d racdb i racdb1
$ srvctl stop asm -n rac1
$ srvctl stop nodeapps -n rac1
8. Go to the Patch Directory and invoke opatch apply.
$ cd ?? --patch directory
$opatch apply or $opatch napply -skip_subset -skip_duplicate
9. Verify Patches are applied
$opatch lsinventory -detail -oh $ORACLE_HOME
10. Now start the Node1 and repeat the same steps 7 to 9 for Node2
11. Verify Patches are applied
$opatch lsinventory -detail -oh $ORACLE_HOME
12. Start the Instance/Asm/Nodeapps of node2
$srvctl start instance d racdb i racdb2
$srvctl start asm n rac2
$srvctl start nodeapps n rac2
$crs_stat t
Post CPU Patch Steps:
For each database instance running on the Oracle home being patched, connect to the database using
SQL*Plus on each node. Connect as SYSDBA and run the catbundle.sql script:
On node1/node2:
cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> @catbundle.sql cpu apply
SQL> @utlrp.sql
The catbundle.sql execution is reflected in the dba_registry_history view by a row associated
with bundle series CPU. Check the following log files for any errors:
catbundle_CPU__APPLY_.log, catbundle_CPU__GENERATE_.log on the
path $ORACLE_HOME/cfgtoollogs/catbundle
Recompiling Views in the Database
If you already applied this during previous CPU installation then you can skip this section. To check
whether view recompilation has already been performed:
SELECT * FROM registry$history where ID = '6452863';
If the view recompilation has been performed, this statement returns one or more rows. If the view
recompilation has not been performed, this statement returns no rows.
If no rows returns then go the following steps for RAC environment:
1. Run the pre-check script, which reports the maximum number of views and objects that may be
recompiled:
cd $ORACLE_HOME/cpu/view_recompile
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> @recompile_precheck_jan2010cpu.sql

Note: If the database is in RAC environment then perform both the steps otherwise (single instance db),
perform only step1 skip the step 2.
cd $ORACLE_HOME/cpu/view_recompile
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP UPGRADE;
SQL> @view_recompile_jan2010cpu.sql
SQL> SHUTDOWN;
SQL> STARTUP;
2. Stop all instances except the one where the view recompilation is being executed.
cd $ORACLE_HOME/cpu/view_recompile
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP NOMOUNT;
SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=spfile;
SQL> SHUTDOWN;
SQL> STARTUP UPGRADE;
SQL> @?/ cpu/view_recompile /view_recompile_jan2008cpu.sql
SQL> SHUTDOWN;
SQL> STARTUP NOMOUNT;
Set the CLUSTER_DATABASE initialization parameter to TRUE:
SQL> ALTER SYSTEM SET CLUSTER_DATABASE=TRUE SCOPE=spfile;
Restart the database:
SQL> QUIT
cd $CRS_HOME/bin
srvctl start database -d racdb
If any invalid objects were reported, run the utlrp.sql script:
cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> @utlrp.sql
Then, manually recompile any invalid objects:
SQL> alter package schemaname.packagename compile;
Verify Patches are applied.
$opatch lsinventory -detail -oh $CRS_HOME #if you have CRS_HOME
$opatch lsinventory -detail -oh $ORACLE_HOME #if you have both ORACLE_HOME

Creating Physical Standby DB using RMAN (without

shutting down the prod DB)
Here we are going to create standby database from RMAN backup without shutting down the production
database.
Steps:
(1) Take RMAN FULL backup of Primary database
(2) Create standby controlfile on primary site.
(3) Move the Backup and Standby control file to standby site

(4) Create or copy PFILE to standby DB and modify it accordingly

(5) Configure tns and listerner for both primary and standby database.
(6) Start the standby database in NOMOUNT then perform the next step
Take RMAN backup on the production system disk
Rman target sys/****@sadhan catalog/catalog@rman
RMAN> BACKUP database plus archivelog;
Create standby controlfile on Primary database
RMAN> backup current controlfile for standby format
H:\oraback\sadstby_cfile.ctl;
RMAN> SQL ALTER SYSTEM ARCHIVE LOG CURRENT;
RMAN> BACKUP ARCHIVELOG ALL NOT BACKED UP 1 TIMES;
Move the Backup to the Standby Server
You can move the backup from primary site to standby site by using any of the below method:

You can move the backup exactly the same location on standby as they were created on primary
database.

You can use CATALOG BACKUPIECE command (on 10g onwards) if you are moving the backup to a
different location.

If the backup are on NFS then mount the NFS on standby server with the same name as you mounted
on primary database.

Use FTP or SCP to move the backup.

If you taken the backup on tape then you must do proper changes on standby server to restore the
backup using tape.
Perform log switches on primary and record the last log sequence number.
SQL> alter system switch logfile;
SQL> alter system switch logfile;
Note: Do not forget to make same folder structures in the destination server.
Create Pfile in primary server after making necessary change transfer to standby site:
SQL> connect target /
SQL> create pfile=D:\ORABACK\sadstby.sql from spfile;
background_dump_dest='D:\oracle\admin\sadstby\bdump'
control_files='D:\oracle\oradata\sadstby\control01.ctl','D:\oracle\oradata\sad
stby\control01.ctl'
core_dump_dest='D:\oracle\sadstby\cdump'
DB_UNIQUE_NAME= SADSTBY
db_name='SADHAN'
instance_name='sadstby'
log_archive_format='%t_%s_%r.dbf'
log_archive_dest_2='SERVICE=SADHAN VALID_FOR=(ONLINE_LOGFILES, ALL_ROLES)
DB_UNIQUE_NAME=SADHAN'
log_archive_dest_state_2='DEFER'
log_archive_dest_1='LOCATION=E:\ORACLE\SADSTBY\ARCHIVE'
remote_archive_enable='true'
fal_server='SADHAN'
fal_client='SADSTBY'
log_file_name_convert=('D:\oracle\oradata\sadhan',
'D:\oracle\oradata\sadstby')
db_file_name_convert=('D:\oracle\oradata\sadhan', 'D:\oracle\oradata\sadstby')
Configure Network File for standby

#Assume Primary database is already configure. You have to do necessary addition for standby
database.
#Update Listener.ora in standby server:
(SID_DESC =
(GLOBAL_DBNAME = SADSTBY)
(ORACLE_HOME = d:\oracle)
(SID_NAME = SADSTBY)
)
#Update tnsnames.ora on primary node:
SADSTBY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.14.222)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = SADSTBY)
)
)

Create the password file for standby database.

orapwd file=orapwSADSTBY password=oracle entries=10
Startup the standby database in nomount phase
sqlplus / as sysdba
SQL> startup nomount pfile=D:\ORABACK\sadstby.sql;
Connected to an idle instance.
SQL> Create spfile from pfile=D:\ORABACK\sadstby.sql;
SQL> shutdown immediate;
SQL> startup nomount;
Duplicate the database by connecting to target, auxiliary and catalog.
connect target /
connect catalog catalog/catalog@rman
connect auxiliary sys/****@sadstby
connected to target database: SADHAN (DBID=63198018)
connected to recovery catalog database
connected to auxiliary database: SADHAN (not mounted)
RMAN> run {
# Set the last log sequence number
set until sequence = 450 thread = 1;
allocate auxiliary channel ch1 type disk;
allocate auxiliary channel ch2 type disk;
duplicate target database for standby dorecover nofilenamecheck;
}
RMAN> exit
Once the standby database is created, RMAN can back up the standby database and archived redo logs
as part of your backup strategy. These standby backups are fully interchangeable with primary backups.
In other words, you can restore a backup of a standby datafile to the primary database, and vice versa.
Take the Standby in Managed recovery Mode and check sync the logs from primary are shipped
over to standby archive destination.
SQL> Select max(sequence#) from v$archive_log;

MAX(SEQUENCE#)
-------------58
SQL> alter system switch logfile;
System altered.
SQL> /
System altered.
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
-------------60
SQL> select name,open_mode,log_mode from v$database;
NAME
OPEN_MODE LOG_MODE
--------- ---------- -----------SADHAN
MOUNTED
ARCHIVELOG
SQL> select recovery_mode from v$archive_dest_status;
SQL> select max(sequence#) from v$log_history;
MAX(SEQUENCE#)
-------------58
SQL> alter database recover managed standby database disconnect;
Database altered.

Creating Physical Standby DB through RMAN Restore &

Recovery
Here in below example we will see step by step procedure how to create standby database without using
Recovery Manager DUPLICATE TARGET DATABASE command.
Steps:
1.
Backup the database with all Archivelogs and controlfile for standby
2.

Move all your backup and standby controlfile to the standby server.

3.

Make proper changes in Pfile of both primary and standby server.

4.

Perform Restore & Recovery on Standby site

5.

Put the Standby DB in Recovery Managed Mode.

Take a full valid backup of Primary database

C:\> rman target /
connected to target database: SADHAN (DBID=63198018)
RMAN>run
{
allocate channel ch1 type disk;
allocate channel ch2 type disk;
backup incremental level 0 format 'H:\ORABACK\i001_%T_%u_s%s_p%p' database;
backup format 'E:\ORABACK\i001_arch_%T_%u_s%s_p%p' archivelog all;
backup current controlfile for standby format'E:\ORABACK\i001_CF_%T_%u_s%s_p
%p' ;
}
Create Standby Control file on Primary database

C:\>RMAN TARGET /
connected to target database: SADHAN (DBID=63198018)
RMAN> backup current controlfile for standby format=H:\oraback\sadstby_CFile.
%U;
Starting backup at 25-FEB-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=158 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including standby control file in backupset
channel ORA_DISK_1: starting piece 1 at 25-FEB-13
channel ORA_DISK_1: finished piece 1 at 25-FEB-13
piece handle=H:\oraback\sadstbycontrol.ctl tag=TAG20130225T020241 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 25-FEB-13

Move the Backup to the Standby Server

You can move the backup from primary site to standby site by using any of the below method:
You can move the backup exactly the same location on standby as they were created on primary
database.
You can use CATALOG BACKUPIECE command (on 10g onwards) if you are moving the backup to a
different location.
If the backup are on NFS then mount the NFS on standby server with the same name as you mounted
on primary database.
Use FTP or SCP to move the backup.
If you taken the backup on tape then you must do proper changes on standby server to restore the
backup using tape.
Make proper changes in Pfile for both primary and standby server:
Copy the Primary Database PFILE to Standby site and make necessary change. Consider you have
already primary database pfile required changing.
log_archive_dest_2='SERVICE=SADSTBY'
db_unique_name='sadstby'
instance_name='sadstby'
db_file_name_convert='D:\oracle\oradata\sadhan','D:\oracle\oradata\sadstby'
log_file_name_convert='D:\oracle\oradata\sadhan','D:\oracle\oradata\sadstby'
standby_archive_dest='E:\oracle\sadstby\Archive'
Note: Do not forget to create service for standby database and make sure to tns network connectivity for
primary as well as standby database.
Perform the Restore & Recovery on Standby site:
C:\> rman target /
connected to target database (not started)
RMAN> startup nomount;
RMAN> SET DBID = 63198018
executing command: SET DBID
RMAN> restore controlfile from H:\oraback\sadstbycontrol.ctl --for 9i
RMAN> restore standby controlfile from 'H:\oraback\sadstbycontrol.ctl'; --for
10g onwards
RMAN> sql 'alter database mount standby database';

RMAN> restore database;

Now try to list all the archivelogs which are backed up and from this list identify the maximum sequence
for recovery.
RMAN> list backup of archivelog all;
RMAN> recover database until sequence 58;
Note: Do not be panic if you find any error indicating file was not restored sufficiently with old backup.
You can safely ignore that error and move for next step.
Put the Standby DB in Recovery Managed Mode:
SQL> alter database recover managed standby database disconnect from session;
Database altered.
Now try to generate some log and check the sync the log from primary are shipped over to standby
archive destination.

Creating Physical Standby DB using (RMAN DUPLICATE

TARGET)
Here in below example we will see step by step procedure how to create standby database by using
RMAN DUPLICATE TARGET DATABASE command. While creating standby database, RMAN automate
the following steps of the creation procedure.
1.
Restores the standby control file.
2.

Restores the primary datafile backups and copies.

3.
Recovers the standby database (optional) after the control file has been mounted up to the
specified time or to the latest archived redo log generated.
4.

Finally RMAN leave the standby DB mounted, So we can start MRP manually (if needed)

Note: According to oracle documentation, RMAN cannot full automate for create standby database, there
are some manual process require.
Steps:
Primary server side Preparation:
1.
Create Standby redologs
2.

Enable database force logging.

3.

Create Pfile or use ALTER SYSTEM to add standby parameter for primary database

4.

Enable Archiving (if not)

5.

Create Pfile for Standby database (optional)

6.

Configure Listener.ora and tnsname.ora for primary (if not)

7.

Copy Pfile and Password file to standby server.

8.

Take a full backup of Primary system and copy it to standby server.

9.

Create standby control file for primary database system and copy to standby server.

Standby server side Preparation:

1.
Create password file for standby (if not copied)
2.

Create directory structure similar to primary server.

3.

Modify the Pfile accordingly for standby.

4.

Finally verify connectivity between two server.

Consider the following point in mind before starting the actual process:
Point to Remember
Primary Server
Standby Server
Host Name
dbserver
dbserver1

DB_Name
DB_Unique_Name
Net_service_Name

Sadhan
Sadhan
Sadhan

Sadhan
Sadstby
Sadstby

Oracle database version: 10.2.0.1.0 and Platform: Windows 2003 Server

Create Standby Redo logs

SQL> select GROUP#,THREAD#,MEMBERS,BYTES FROM V$LOG;
GROUP#
THREAD#
MEMBERS
BYTES
--------------------- --------1
1
1
52428800
2
1
1
52428800
3
1
1
52428800
SQL> select group#,member from v$logfile;
GROUP# MEMBER ORDER BY group#;
1 D:\oracle\oradata\sadhan\redo01.log
2 D:\oracle\oradata\sadhan\redo02.log
3 D:\oracle\oradata\sadhan\redo03.log
SQL> SELECT GROUP#, BYTES FROM V$STANDBY_LOG;
no rows selected
SQL> ALTER DATABASE ADD STANDBY LOGFILE
('D:\oracle\oradata\sadhan\stby_redo01.log') SIZE 52428800;
Database altered.
SQL> ALTER DATABASE ADD STANDBY LOGFILE
('D:\oracle\oradata\sadhan\stby_redo02.log') SIZE 52428800;
Database altered.
SQL> ALTER DATABASE ADD STANDBY LOGFILE
('D:\oracle\oradata\sadhan\stby_redo03.log') SIZE 52428800;
Database altered.
SQL> SELECT GROUP#, BYTES FROM V$STANDBY_LOG;
GROUP#
BYTES
-------------4
52428800
5
52428800
6
52428800
Force Logging to the primary DB and put your DB in Archive mode (if not)
In primary database we need to enable force logging and define some initialization parameters, which
controls redo transport services while the database is in primary role.
SQL> Select FORCE_LOGGING FROM V$DATABASE;
SQL> Alter database FORCE_LOGGING;
SQL> Select name, open_mode, log_mode from V$database;
NAME
OPEN_MODE LOG_MODE
--------- ---------- -----------SADHAN
READ WRITE ARCHIVELOG
SQL> SELECT INSTANCE_NAME, HOST_NAME FROM V$INSTANCE;
INSTANCE_NAME
HOST_NAME
---------------- -------------Sadhan
dbserver
SQL> SELECT name, value FROM V$PARAMETER
where name = 'service_names';

NAME
VALUE
-------------------service_names
SADHAN.WORLD
Note: Create password file for primary database (if not exist) using orapwd.
Create Pfile or use ALTER SYSTEM to add the following parameters
SQL> CREATE PFILE = D:\SADHAN.SQL FROM SPFILE;
service_names=SADHAN
db_unique_name=SADHAN
log_archive_config='dg_config=(sadhan, sadstby)'
log_archive_dest_1='LOCATION=E:\ORACLE\SADHAN\ARCHIVE valid_for=(ALL_LOGFILES, ALL_ROLE)
db_unique_name=SADSTBY'
log_archive_dest_2='service=SADSTBY ASYNC valid_for=(ONLINE_LOGFILES, PRIMARY_ROLE)
db_unique_name=SADSTBY'
log_archive_dest_state_1=enable
log_archive_dest_state_2=enable
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
LOG_ARCHIVE_MAX_PROCESSES=30
FAL_SERVER='SADSTBY'
FAL_CLIENT='SADHAN'
db_file_name_convert=D:\ORACLE\ORADATA\SADHAN,D:\ORACLE\ORADATA\SADSTBY
log_file_name_convert=D:\ORACLE\ORADATA\SADHAN,D:\ORACLE\ORADATA\SADSTBY
standby_file_management=auto

-or- you can use later system to dynamically modify the below parameters
SQL> alter system set log_archive_config = 'dg_config = (sadhan,sadstby)' scope=spfile;
System altered.
SQL> alter system set LOG_ARCHIVE_DEST_1= 'LOCATION=E:\oracle\Sadhan\Archive
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=SADHAN';
System altered.
SQL> alter system set LOG_ARCHIVE_DEST_2= 'service=sadstby LGWR ASYN
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLES) DB_UNIQUE_NAME=SADSTBY';
SQL> alter system set log_archive_dest_state_1=enable;
System altered.
SQL> alter system set log_archive_dest_state_2=enable;
System altered.
SQL> alter system set remote_login_passwordfile = exclusive scope=spfile;
System altered.
SQL>alter system set log_archive_max_processes=30 scope=spfile;
System altered.
#DATAGAURD PARAMTERS#
SQL> alter system set fal_server = sadstby;
System altered.
SQL> alter system set fal_client = sadhan;
System altered.
# db_file_name_convert: do not need for same directory structure
SQL> alter system set db_file_name_convert =
'D:\oracle\oradata\sadhan', 'D:\oracle\oradata\sadstby' scope=spfile;
System altered.

# log_file_name_convert: do not need for same directory structure

SQL> alter system set log_file_name_convert =
D:\oracle\oradata\sadhan', D:\oracle\oradata\sadstby' scope=spfile;
System altered.
SQL> alter system set standby_file_management = auto scope=spfile;
System altered.

Note: Create password file in your primary database (if already exist no need) using orapwd.
Copy the Pfile and Password file to Standby server and modify this Pfile for standby
compatible='10.2.0.1.0'
control_files='d:\oracle\oradata\sadstby\control01.ctl,D:\oracle\oradata\sadstby\control02.ctl
db_name=sadhan
service_names=SADSTBY
db_unique_name=sadstby
log_archive_config='dg_config=(sadhan, sadstby)'
log_archive_dest_1='LOCATION=E:\ORACLE\SADSTBY\ARCHIVE valid_for=(ALL_LOGFILES, ALL_ROLE)
db_unique_name=SADSTBY'
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
log_archive_dest_2='service=sadhan ASYNC valid_for=(ONLINE_LOGFILES, PRIMARY_ROLE)
db_unique_name=SADHAN'
FAL_SERVER='SADHAN'
FAL_CLIENT='SADSTBY'
log_archive_dest_state_1=enable
log_archive_dest_state_2=enable
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
db_file_name_convert=D:\ORACLE\ORADATA\SADHAN,D:\ORACLE\ORADATA\SADSTBY
log_file_name_convert=D:\ORACLE\ORADATA\SADHAN,D:\ORACLE\ORADATA\SADSTBY
standby_file_management=auto

Create service for Standby DB and Configure Listener for both Primary and Standby
oradim -NEW -SID sadstby -INTPWD password -STARTMODE manual
TIPS: Assume Listener already configured on primary node. You should try to Create Listener (Standby)
by using Net Configuration Assistant on Standby Server.
#Connection string for Primary Instance.
SADHAN =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.14.17)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = SADHAN)
)
)
#Connecting string for Standby Instance
STANDBY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.14.222)(PORT = 1521))
)
(CONNECT_DATA =

(SERVICE_NAME = SADSTBY)
)
)

Add the below line in SQLNET.ORA (Standby DB) to broken connection detection on primary file system
SQLNET.EXPIRE_TIME=2
Finally check connection between two databases:
C:\>tnsping Sadhan
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = 192.168.14.17) (PORT = 1521))) (CONNECT_DATA = (SID = sadhan)))
OK (70 msec)
C:\>tnsping sadstby
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = 192.168.14.222) (PORT = 1521))) (CONNECT_DATA = (SID = sadstby)))
OK (60 msec)

Make a note of log Sequence Number for RMAN until recovery

SQL> Alter system switch logfile;
SQL> Select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
-------------450

Take a full backup of Primary database and copy the all backup to standby host
RMAN>run
{
allocate channel ch1 type disk;
allocate channel ch2 type disk;
backup incremental level 0 format 'H:\oraback\Weekly_%T_FULL_%d-%s_%p.db'
database;
backup format 'H:\oraback\Weekly_%T_FULL_%d-%s_%p.db' archivelog all;
backup current controlfile for standby format'H:\oraback\Weekly_%T_FULL_%d-%s_
%p.db' ;
}
Note: Manage the same directory Structure on both machines. Copy the backup to standby on the same
location as you are taking backup on primary site.
Create Standby Control file on Primary database and Copy to Standby site.
C:\>RMAN TARGET /
connected to target database: SADHAN (DBID=63198018)

RMAN> backup current controlfile for standby format=H:\oraback\sadstby_CFile.

%U;
Starting backup at 25-FEB-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=158 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including standby control file in backupset
channel ORA_DISK_1: starting piece 1 at 25-FEB-13
channel ORA_DISK_1: finished piece 1 at 25-FEB-13
piece handle=H:\oraback\sadstbycontrol.ctl tag=TAG20130225T020241 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02

Finished backup at 25-FEB-13

Restart both the instance with modified Pfile and create Spfile from Pfile
SQL> conn sys/****@sadhan as sysdba
SQL> shutdown immediate;
SQL> startup PFILE=D:\SADHAN.SQL FROM SPFILE
SQL> CREATE SPFILE FROM PFILE =D:\SADHAN_NEW.SQL;
SQL> shutdown immediate:
SQL> startup;

On standby server:
SQL> conn sys/****@sadstby as sysdba
Connected to an idle instance.
SQL> startup nomount pfile='D:\sadstby.sql';
ORACLE instance started.
SQL> create spfile from pfile='D:\sadstby.sql';
File created.
Now bounce back the database to activate with spfile
SQL> show parameter log_archive_dest_1
NAME

TYPE

VALUE

---------------------

---------

-----------------------

log_archive_dest_1

string

service=Sadhan valid_for=(online logfiles, primary_role)

db_unique name = sadhan

log_archive_dest_10

string

SQL> shut immediate;

SQL> startup nomount;
Now Connect RMAN and configure parameter for Standby server
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT H:\oraback\%U.bak
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT H:\oraback\%U.bak
CMD> rman target sys/****@sadhan
RMAN > connect auxiliary sys/****@sadstby
Recovery Manager: Release 10.2.0.1.0 - Production on Fri Feb 25
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database: SADHAN (DBID=63198018)
auxiliary database Password:
connected to auxiliary database: SADSTBY (not mounted)

H:\oraback\%F;
MAX PIECESIZE 4 G;
MAX PIECESIZE 4 G;

02:30:20 2013

Use RMAN DUPLICATE TARGET DATABASE to create standby database

RMAN> run {
# Set the last log sequence number
set until sequence = 450 thread = 1;
allocate auxiliary channel ch1 type disk;
allocate auxiliary channel ch2 type disk;
duplicate target database for standby dorecover nofilenamecheck;
}
RMAN> exit
Now you have successfully created standby database using RMAN. Try to check both the database is
synchronizing.
C:\sqlplus /as sysdba --connect with primary

SQL> archive log list;

Database log mode
Archive Mode
Automatic archival
Enabled
Archive destination
E:\oracle\Archivelog
Oldest online log sequence
56
Next log sequence to archive
58
Current log sequence
58
SQL> exit
C:\>sqlplus sys/***@sadstby as sysdba
SQL> archive log list;
Database log mode
Archive Mode
Automatic archival
Enabled
Archive destination
E:\oracle\Archivelog
Oldest online log sequence
56
Next log sequence to archive
58
Current log sequence
58
SQL> exit
Take the Standby in Managed recovery Mode and check sync the logs from primary are shipped
over to standby archive destination.
SQL> Select max(sequence#) from v$archive_log;
MAX(SEQUENCE#)
-------------58
SQL> alter system switch logfile;
System altered.
SQL> /
System altered.
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
-------------60
SQL> select name,open_mode,log_mode from v$database;
NAME
OPEN_MODE LOG_MODE
--------- ---------- -----------SADHAN
MOUNTED
ARCHIVELOG
SQL> select recovery_mode from v$archive_dest_status;
SQL> select max(sequence#) from v$log_history;
MAX(SEQUENCE#)
-------------58
SQL> alter database recover managed standby database disconnect;
Database altered.
Note: This statement include the DISCONNECT FROM SESSION option so that Redo Apply runs in a
background session. If you find the Error: RMAN-06059: expected archived log not found, lost of archived
log compromises recoverability then try to user RMAN> change archivelog all crosscheck;
SQL> select recovery_mode from v$archive_dest_status;
RECOVERY_MODE

----------------------MANAGED
MANAGED
MANAGED
MANAGED
MANAGED
MANAGED
5 rows selected.
SQL> select max(sequence#) from v$log_history;
MAX(SEQUENCE#)
-------------60
Once the standby database is created, RMAN can back up the standby database and archived redo logs
as part of your backup strategy. These standby backups are fully interchangeable with primary backups.
In other words, you can restore a backup of a standby datafile to the primary database, and vice versa.