Question with Answer on Oracle database PatchesPatches 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 forthose 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 patchsetWhen 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 opatchutil NApply help. It will give you clear picture.For Example:opatch util napply -id 9 -skip_subset -skip_duplicateThis 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 inventoryC:\ORACLE_HOME\Opatch\opatch lsinventory invPtrLoc location of oraInst.loc file$ORACLE_HOME\OPatch\opatch lsinventory -detail -invPtrLoc location of oraInst.loc fileDifferentiate 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. CPUis a subset of patchset updates (PSU). CPU are built on the base patchset version where as PSU are built on the base of previous PSUPatch 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 changesRegular 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.1PSU 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 5thplace in the oracle version number which makes it easier to track such as (e.g. 10.2.0.3.1). Todetermine the PSU version installed,use OPATCH utility:OPATCH lsinv -bugs_fixed | grep -i PSUTo 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 thecatbundle.sqlClick toCheck Existing Oracle Database Patch StatusWill 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 -reportYou 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 -silentYou 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 withattachHomeflag, 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 theinventory.xmlwith the nodes available in the cluster using the-updateNodeListflag in Oracle Universal Installer.When I apply a patch, getting the following errors:"Opatch Session cannot load inventory for the given Oracle Home 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:TheORACLE_HOME/.patch_storagemay 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.TheCentral Inventorymay not have read permission. Ensure that you have given read permission to the Central Inventory and apply the patch again.TheORACLE_HOME/.patch_storagedirectory might be locked. If this directory is locked, you will find a file namedpatch_lockedinside 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_lockedfile from theORACLE_HOME/.patch_storagedirectory.The Oracle home may not be present in theCentral Inventory. This may be due to a corrupted or lost inventory or the inventory may not be registered in theCentral Inventory.We should check for the latest security patches on the Oracle metalink websitehttp://metalink.oracle.com/and we can find the regular security alert at the locationhttp://technet.oracle.com/deploy/security/alert.htmCaution: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 OraclePatches 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 forbeginners 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 patchesandwhat are theprecaution 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. PatchsetPSE, 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 viaOUI (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 OPatchThe only type of patch that cannot be used with OPatch is apatchset. 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, enter224346.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 thePatch 6880880link which will take you to the screen where you can obtain the latest version of OPatch based on release versions and platforms.OPatch System RequirementsThe OPatch utility has the following requirements:TheORACLE_HOMEenvironment variable must point to a valid Oracle home directory and match the value used during installation of the Oracle home directory.If the-invPtrLoccommand-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.Thejava,ar,cp, andmakecommands must be available in one of the directories listed in thePATHenvironment 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 thePatches & Updateslink.(iii)Enter thePatch ID or Number, then clickSearch. 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 theDownloadbutton in the right-hand column.Backup and Recovery Considerations for PatchingIt is highly recommended that you back up theORACLE_HOMEbefore any patch operation. You can back up the ORACLE_HOMEusing your preferred method. You can use any method such aszip,cp -r,tar, andcpioto 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 SupportYou can contact to the oracle support representative and you can go to the MY Oracle Support:https://support.oracle.com/CSP/ui/flash.htmlStep 2: Check for Existing patchesIf 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 theopatch lsinventorycommand oropatch checkInstalledOneOffscommand.Example:D:\>cd %ORACLE_HOME%\opatchD:\oracle\ora92\OPatch>opatch lsinventoryNote: 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 PatchUpon 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 HomeOnce you obtain the patch, determine the Oracle home directory to which you are going to apply the patch.Step 5. Read the README FileRead 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 PatchAfter you determine the Oracle home to which you need to apply the patch, you should apply the patch with theopatch applycommandThe syntax for theapplycommand 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 theopatch startcommand 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 theopatch rollbackcommand to remove the patch from the Oracle home.The syntax for therollbackoption 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 ExamplePSUs(PatchSet Updates) orCPUs(Critical Patch Updates) are applied viaOpatchutility.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:Opatchis 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" tabb) In the "Patch Name or Number" field type 6880880c) In the "Platform" field select the relevant platformd) Click the Search button.e) Select the patch that corresponds to the Oracle release installed:6880880 Universal Installer: Patch OPatch 11.2f) Click the Download buttonOnce 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-HOMEC:\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 fileUsers_Guide.txt, opatch_history.txt.For Example:ToApply 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.htmlHow to Apply Critical Patch Update (CPU) on RACPatch Details: Patch CPUJULY2012CPU patch is released 4 times in a year JAN/APR/JUL/OCTVersion & Platform: 10.2.0.4 Database on LINUX

Overview:ACritical 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 patchNote:Do not forget toread 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 Metalink2.Change the owner of the patch file to oracle user.# chown R oracle3. Set the PATH variable to locate the opatch utility.$ export PATH=$PATH: $ORACLE_HOME/OPatch4.unzip the patch and go the unzipped directory$unzip patchfile.zip5.Find and invoke the Opatch version$ opatch versionOPatch Version: 10.2.0.4.2$ opatch lsinventoryIf you want check the CPU patch is whether rolling support or not, go to the patch directoryCd /oracle/?? --patch directory[oracle@rac1 ??]$opatch query -all6.Backup the oraInventoryand Opatch directory$cp -R oraInventory old_oraInventory$cp -R opatch old_opatch7.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 rac18. Go to the Patch Directory and invoke opatch apply.$ cd ?? --patch directory$opatch apply or $opatch napply -skip_subset -skip_duplicate9. Verify Patches are applied$opatch lsinventory -detail -oh $ORACLE_HOME10. Now start the Node1 and repeat the same steps 7 to 9 for Node211. Verify Patches are applied$opatch lsinventory -detail -oh $ORACLE_HOME12. Startthe Instance/Asm/Nodeapps of node2$srvctl start instance d racdb i racdb2$srvctl start asm n rac2$srvctl start nodeapps n rac2$crs_stat tPost 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 thecatbundle.sqlscript:On node1/node2:cd $ORACLE_HOME/rdbms/adminsqlplus /nologSQL> CONNECT / AS SYSDBASQL> STARTUPSQL> @catbundle.sql cpu applySQL> @utlrp.sqlThecatbundle.sqlexecution is reflected in thedba_registry_historyview by a row associated with bundle series CPU. Check the following log files for any errors:catbundle_CPU__APPLY_.log, catbundle_CPU__GENERATE_.logon the path$ORACLE_HOME/cfgtoollogs/catbundleRecompiling Views in the DatabaseIf 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_recompilesqlplus /nologSQL> CONNECT / AS SYSDBASQL> @recompile_precheck_jan2010cpu.sqlNote: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_recompilesqlplus /nologSQL> CONNECT / AS SYSDBASQL> SHUTDOWN IMMEDIATE;SQL> STARTUP UPGRADE;SQL> @view_recompile_jan2010cpu.sqlSQL> SHUTDOWN;SQL> STARTUP;2. Stop all instances except the one where the view recompilation is being executed.cd $ORACLE_HOME/cpu/view_recompilesqlplus /nologSQL> CONNECT / AS SYSDBASQL> STARTUP NOMOUNT;SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=spfile;SQL> SHUTDOWN;SQL> STARTUP UPGRADE;SQL> @?/cpu/view_recompile/view_recompile_jan2008cpu.sqlSQL> 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> QUITcd $CRS_HOME/binsrvctl start database -d racdbIf any invalid objects were reported, run theutlrp.sqlscript:cd $ORACLE_HOME/rdbms/adminsqlplus /nologSQL> CONNECT / AS SYSDBASQL> @utlrp.sqlThen, 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 stepTake RMAN backup on the production system diskRman target sys/****@sadhan catalog/catalog@rmanRMAN> BACKUP database plus archivelog;Create standby controlfile on Primary databaseRMAN> 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 ServerYou 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\sadstby\control01.ctl'core_dump_dest='D:\oracle\sadstby\cdump'DB_UNIQUE_NAME= SADSTBYdb_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=10Startup the standby database in nomount phasesqlplus / as sysdbaSQL>startup nomount pfile=D:\ORABACK\sadstby.sql;Connected to an idle instance.SQL> Create spfile frompfile=D:\ORABACK\sadstby.sql;SQL> shutdown immediate;SQL> startup nomount;Duplicate the database by connecting to target, auxiliary and catalog.connect target /connect catalogcatalog/catalog@rmanconnect auxiliarysys/****@sadstbyconnected to target database: SADHAN (DBID=63198018)connected to recovery catalog databaseconnected to auxiliary database: SADHAN (not mounted)RMAN> run {# Set the last log sequence numberset 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>exitOnce 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#)-------------- 58SQL> alter system switch logfile;System altered.SQL> /System altered.SQL> select max(sequence#) from v$archived_log;MAX(SEQUENCE#)-------------- 60SQL> select name,open_mode,log_mode from v$database;NAME OPEN_MODE LOG_MODE--------- ---------- ------------SADHAN MOUNTED ARCHIVELOGSQL> select recovery_mode from v$archive_dest_status;

SQL> select max(sequence#) from v$log_history;MAX(SEQUENCE#)-------------- 58SQL> alter database recover managed standby database disconnect;Database altered.Creating Physical Standby DB through RMAN Restore & RecoveryHere in below example we will see step by step procedure how to create standby database without using Recovery ManagerDUPLICATE TARGET DATABASE command.Steps:1. Backup the database with all Archivelogs and controlfile for standby2. 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 site5. Put the Standby DB in Recovery Managed Mode.Take a full valid backup of Primary databaseC:\> 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 databaseC:\>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-13using target database control file instead of recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: sid=158 devtype=DISKchannel ORA_DISK_1: starting full datafile backupsetchannel ORA_DISK_1: specifying datafile(s) in backupsetincluding standby control file in backupsetchannel ORA_DISK_1: starting piece 1 at 25-FEB-13channel ORA_DISK_1: finished piece 1 at 25-FEB-13piece handle=H:\oraback\sadstbycontrol.ctl tag=TAG20130225T020241 comment=NONEchannel ORA_DISK_1: backup set complete, elapsed time: 00:00:02Finished backup at 25-FEB-13Move the Backup to the Standby ServerYou 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 = 63198018executing command: SET DBIDRMAN> restore controlfile from H:\oraback\sadstbycontrol.ctl --for 9iRMAN> restore standby controlfile from 'H:\oraback\sadstbycontrol.ctl'; --for 10g onwardsRMAN> 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 RMANDUPLICATE 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 redologs2. Enable database force logging.3. Create Pfile or use ALTER SYSTEM to add standby parameter for primary database4. Enable Archiving (if not)5. Create Pfile for Standby database (optional)6. ConfigureListener.oraandtnsname.orafor 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 RememberPrimary ServerStandby Server

Host Namedbserverdbserver1

DB_NameSadhanSadhan

DB_Unique_NameSadhanSadstby

Net_service_NameSadhanSadstby

Oracle database version: 10.2.0.1.0 and Platform: Windows 2003 Server

Create Standby Redo logsSQL> select GROUP#,THREAD#,MEMBERS,BYTES FROM V$LOG;GROUP# THREAD# MEMBERS BYTES------- -------- -------- --------- 1 1 1 52428800 2 1 1 52428800 3 1 1 52428800SQL> 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.logSQL> SELECT GROUP#, BYTES FROM V$STANDBY_LOG;no rows selectedSQL> 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 52428800Force 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 ARCHIVELOGSQL>SELECT INSTANCE_NAME, HOST_NAME FROM V$INSTANCE;INSTANCE_NAME HOST_NAME---------------- --------------Sadhan dbserverSQL> SELECT name, value FROM V$PARAMETER where name = 'service_names';NAME VALUE---------- -----------service_names SADHAN.WORLDNote:Create password file for primary database (if not exist) using orapwd.Create Pfile or use ALTER SYSTEM to add the following parametersSQL> CREATE PFILE = D:\SADHAN.SQL FROM SPFILE;service_names=SADHANdb_unique_name=SADHANlog_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=enablelog_archive_dest_state_2=enableREMOTE_LOGIN_PASSWORDFILE=EXCLUSIVELOG_ARCHIVE_FORMAT=%t_%s_%r.arcLOG_ARCHIVE_MAX_PROCESSES=30FAL_SERVER='SADSTBY'FAL_CLIENT='SADHAN'db_file_name_convert=D:\ORACLE\ORADATA\SADHAN,D:\ORACLE\ORADATA\SADSTBYlog_file_name_convert=D:\ORACLE\ORADATA\SADHAN,D:\ORACLE\ORADATA\SADSTBYstandby_file_management=auto-or- you can use later system to dynamically modify the below parametersSQL> 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 structureSQL> 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 structureSQL> 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 standbycompatible='10.2.0.1.0'control_files='d:\oracle\oradata\sadstby\control01.ctl,D:\oracle\oradata\sadstby\control02.ctldb_name=sadhanservice_names=SADSTBYdb_unique_name=sadstbylog_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.arclog_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=enablelog_archive_dest_state_2=enableREMOTE_LOGIN_PASSWORDFILE=EXCLUSIVEdb_file_name_convert=D:\ORACLE\ORADATA\SADHAN,D:\ORACLE\ORADATA\SADSTBYlog_file_name_convert=D:\ORACLE\ORADATA\SADHAN,D:\ORACLE\ORADATA\SADSTBYstandby_file_management=autoCreate service for Standby DB and Configure Listener for both Primary and Standbyoradim -NEW -SID sadstby -INTPWD password -STARTMODE manualTIPS: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 InstanceSTANDBY =(DESCRIPTION =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.14.222)(PORT = 1521)))(CONNECT_DATA =(SERVICE_NAME = SADSTBY)))Add the below line inSQLNET.ORA (Standby DB)to broken connection detection on primary file systemSQLNET.EXPIRE_TIME=2Finally check connection between two databases:C:\>tnsping SadhanAttempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.14.17) (PORT = 1521))) (CONNECT_DATA = (SID = sadhan)))OK (70 msec)C:\>tnsping sadstbyAttempting 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 recoverySQL> Alter system switch logfile;SQL> Select max(sequence#) from v$archived_log;MAX(SEQUENCE#)--------------450Take a full backup of Primary database and copy the all backup to standby hostRMAN>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-13using target database control file instead of recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: sid=158 devtype=DISKchannel ORA_DISK_1: starting full datafile backupsetchannel ORA_DISK_1: specifying datafile(s) in backupsetincluding standby control file in backupsetchannel ORA_DISK_1: starting piece 1 at 25-FEB-13channel ORA_DISK_1: finished piece 1 at 25-FEB-13piece handle=H:\oraback\sadstbycontrol.ctl tag=TAG20130225T020241 comment=NONEchannel ORA_DISK_1: backup set complete, elapsed time: 00:00:02Finished backup at 25-FEB-13Restart both the instance with modified Pfileand create Spfile from PfileSQL> conn sys/****@sadhan as sysdbaSQL> shutdown immediate;SQL> startup PFILE=D:\SADHAN.SQL FROM SPFILESQL> CREATE SPFILE FROM PFILE =D:\SADHAN_NEW.SQL;SQL> shutdown immediate:SQL> startup;On standby server:SQL> conn sys/****@sadstby as sysdbaConnected 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 spfileSQL> show parameter log_archive_dest_1NAME TYPE VALUE--------------------- --------- -----------------------log_archive_dest_1 string service=Sadhan valid_for=(online logfiles, primary_role) db_unique name = sadhanlog_archive_dest_10 stringSQL> shut immediate;SQL> startup nomount;Now Connect RMAN and configure parameter for Standby serverCONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO H:\oraback\%F;CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT H:\oraback\%U.bak MAX PIECESIZE 4 G;CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT H:\oraback\%U.bak MAX PIECESIZE 4 G;CMD> rman target sys/****@sadhanRMAN > connect auxiliary sys/****@sadstbyRecovery Manager: Release 10.2.0.1.0 - Production on Fri Feb 25 02:30:20 2013Copyright (c) 1982, 2005, Oracle. All rights reserved.connected to target database: SADHAN (DBID=63198018)auxiliary database Password:connected to auxiliary database: SADSTBY (not mounted)Use RMAN DUPLICATE TARGET DATABASE to create standby databaseRMAN> run {# Set the last log sequence numberset 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>exitNow you have successfully created standby database using RMAN. Try to check both the database is synchronizing.C:\sqlplus /as sysdba --connect with primarySQL> archive log list;Database log mode Archive ModeAutomatic archival EnabledArchive destination E:\oracle\ArchivelogOldest online log sequence 56Next log sequence to archive 58Current log sequence 58SQL> exitC:\>sqlplus sys/***@sadstby as sysdbaSQL> archive log list;Database log mode Archive ModeAutomatic archival EnabledArchive destination E:\oracle\ArchivelogOldest online log sequence 56Next log sequence to archive 58Current log sequence 58SQL> exitTake 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#)-------------- 58SQL> alter system switch logfile;System altered.SQL> /System altered.SQL> select max(sequence#) from v$archived_log;MAX(SEQUENCE#)-------------- 60SQL> select name,open_mode,log_mode from v$database;NAME OPEN_MODE LOG_MODE--------- ---------- ------------SADHAN MOUNTED ARCHIVELOGSQL> select recovery_mode from v$archive_dest_status;

SQL> select max(sequence#) from v$log_history;MAX(SEQUENCE#)-------------- 58SQL> 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-----------------------MANAGEDMANAGEDMANAGEDMANAGEDMANAGEDMANAGED5 rows selected.SQL> select max(sequence#) from v$log_history;

MAX(SEQUENCE#)-------------- 60Once 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.