Autoconfig

Autoconfig:

AutoConfig is a tool that simplifies and standardizes configuration management tasks in oracle e-business suite.

Application Context file/Configuration file/XML file:

Naming convention is

              $CONTEXT_NAME.xml

Where CONTEXT_NAME variable is set to $SID or $SID_<hostname>.

Location is

              $APPL_TOP/admin

Creating the context file:

./$AD_TOP/bin/adbldxml.sh

This script will evaluate your environment in order to generate the context file.

Modifying the Application Context File:

• Using editcontext: - which provides GUI interface.

export DISPLAY=<Domain name>:0.0

cd $COMMON_TOP/util/editcontext

./editcontext

• Using OAM(Oracle Application Manager) :-[Oracle recommend]

                                  It is user-friendly searchable interface.

                                  In front-end click on sitemap ==> Context File Parameters.

•  Using a standard text editor (like vi)

Advantages of context file:-

Simplifies overall management of an oracle e-business suite system.

• Allows easier Startup & Shutdown of the Application services.
• Name & Location of Database
• Permits services to be installed or de-installed independently of others.
• Integrates seamlessly with a shared application tier file system.
• Enables use of OAM for configuration management.
• Facilitates support for RAC.
• Information about application tier services controlled by Autoconfig.

Note: if you modify Context file must be take backup before modifying context file.

Database	s_dbport	1521
Reports	s_repsport	7000
Web Listener	s_webport	8000
Forms Listener	s_formsport	9000
OEM Web Utility	s_oemweb_port	10000
Servlet	s_servletport	8800
OACORE Servlet Range	s_oacore_servlet_portrange	16000-16009
Discoverer Server Range	s_disco_servlet_portrange	17000-17009
Forms servlet Range	s_forms_servlet_portrange	18000-18009s

How to check whether the port number is already used or not?

netstat  - a | grep <port number>

Note: /etc/services file on the server with all services that are required ports.

Identifying Nodes with Context Parameters:-

AD utilities will use these parameters to perform tasks such as creating control scripts or maintaining necessary files to support services.

s_isDB	Database node for autoconfig to create control scripts
s_isAdmin	Admin node                 “
s_isWeb	Web server node              “
s_isForms	Forms Node                     “
s_isConc	Concurrent Processing Node           “
s_isAdadmin	Identifies node’s APPL_TOP as being used to support the Oracle Application System
s_isAdweb	Identifies node’s APPL_TOP as being used to support web services
s_isAdForms	“
s_isAdConc	“

Location of the Context file:

DB Tier:

                    $ORACLE_HOME/appsutil/<CONTEXT_NAME>.xml

Apps Tier:

                   $APPL_TOP/admin/<CONTEXT_NAME>.xml       [11i]

                   $INST_TOP/appl/admin/<CONTEXT_NAME>.xml      [R12]

AutoConfig Scripts:

adautocfg.sh :- Automatically pass "context_name.xml" file.

               Apps Tier :- $INST_TOP/admin/scripts        ===>R12

                                 $OAD_TOP/admin/scripts/<context_name>      ===> 11i

               DB Tier :- $ORACLE_HOME/appsutil/scripts/<context_name>

adconfig.sh :- Asks context_name.xml location & call adconfig.pl

               Apps Tier :- $AD_TOP/bin

               DB Tier :- $ORACLE_HOME/appsutil/bin

adconfig.pl :- Calls the Java API to carry out the actual configuration tasks.

               Apps Tier :- $AD_TOP/bin

               DB Tier :- $ORACLE_HOME/appsutil/bin

adchkcfg.sh :- This utility generates report difference between existing configuration files and the new ones that autoconfig will generate.

                Apps Tier: $AD_TOP/bin

                DB Tier :-$ORACLE_HOME/appsutil/bin

Autoconfig create directories:

                  $INST_TOP/admin/install                   Install Scripts

                  $INST_TOP/admin/scripts                 Control Scripts

                  $INST_TOP/admin/log                       Log files.

Log file location is

            $APPL_TOP/appsutil/log/$CONTEXT_NAME/mmddhhmm/adconfig.log

CVM [Context Value Management]:

      It is a Autoconfig component that is used to manages the values of variables in the context file & automatically required updates to it. It supports updates to both Database & Application context files.

CVM Actions:

• Adding new variables to context file.
• Updating values of variables in an existing.
• Applying new versions of context file templates.
• Executing scripts on configuration tools that must complete before the autoconfig engine starts.
• CVM starts itself before starting Autoconfig engine.

Apps Tier: 

      $AD_TOP/bin/adcvm.sh         ---> Main CVM script

      $AD_TOP/admin/template/adcvmat.xml      ---> Stores CVM related data for apps tier

DB Tier :

       $ORACLE_HOME/appsutil/bin/adcvm.sh       ---> CVM script

       $ORACLE_HOME/appsutil/template/adcvmat.xml     ----> store CVM related data for the DB Tier.

Autoconfig Files:

Template files: Evaluates the context variables in a template file, determines the actual values required and creates a configuration file with these values substituted.(is called instantiation)

            Apps Tier: <product_top>/admin/template

                                                   /driver

            DB Tier : $ORACLE_HOME/appsutil/template

 Driver files: These are used to list the corresponding template files and locations and specifying the commands to be executed.

                  Apps Tier: <product_top>/admin/driver

                  DB Tier : $ORACLE_HOME/appsutil/driver

Note:

Each configuration file having one template file ( like httpd_ux.conf ) 

Driver files list the names & locations of the files that need to have context variables replaced( like adtmpl.drv,fndtmpl.drv..).

Phases of AutoConfig:-

INSTE8: Find the location of template and Driver files.

INSTE8_SETUP: update the setup files

INSTE8_PRF: This was profile phase, it will execute scripts that will update the profile values.

INSTE8_APPLY: This was final phase. It will update the Database Objects.

BINCPY:

New features of Autoconfig in R12:

There are 2 new options are added. These are introduced from 12.1 onwards.They are 

1. Profile
2. Parallel

 Profile :-

[applprod@ravi prod_ravi]$ adautocfg.sh Enter the APPS user password: AutoConfig is configuring the Applications environment... AutoConfig will consider the custom templates if present.         Using APPL_TOP location     : /apps01/applprod/prodappl         Classpath                   : /apps01/applprod/prodcomn/util/java/1.4/j2sdk1.4.2_04/jre/lib/rt.jar:/apps01/applprod/prodcomn/util/java/1.4/j2sdk1.4.2_04/lib/dt.jar: /apps01/applprod/prodcomn/util/java/1.4/j2sdk1.4.2_04/lib/tools.jar:/apps01/applprod/prodcomn/java/appsborg2.zip:/apps01/applprod/prodcomn/java         Using Context file          : /apps01/applprod/prodappl/admin/prod_ravi.xml Context Value Management will now update the Context file Context Value Management has found new variables that must be defined to update the context file and continue with system configuration Variable : s_ohs_serveradmin Details  : This parameter sets the e-mail address that the OHS            includes in any error messages it returns to the client.            It may be worth setting up a dedicated address for this purpose. Enter the Oracle HTTP Server Administrator email address [applprod@apps.com]:         Updating Context file...COMPLETED         Attempting upload of Context file and templates to database...COMPLETED Configuring templates from all of the product tops...         Configuring AD_TOP........COMPLETED         Configuring FND_TOP.......COMPLETED         Configuring ICX_TOP.......COMPLETED         Configuring IEO_TOP.......COMPLETED         Configuring ABM_TOP.......COMPLETED         Configuring ECX_TOP.......COMPLETED         Configuring BIS_TOP.......COMPLETED         Configuring GL_TOP........COMPLETED         Configuring AMS_TOP.......COMPLETED         Configuring CCT_TOP.......COMPLETED         Configuring WSH_TOP.......COMPLETED         Configuring CLN_TOP.......COMPLETED         Configuring OKE_TOP.......COMPLETED         Configuring OKL_TOP.......COMPLETED         Configuring OKS_TOP.......COMPLETED         Configuring CSF_TOP.......COMPLETED         Configuring XNC_TOP.......COMPLETED         Configuring IGS_TOP.......COMPLETED         Configuring IBY_TOP.......COMPLETED         Configuring PA_TOP........COMPLETED         Configuring JTF_TOP.......COMPLETED         Configuring MWA_TOP.......COMPLETED         Configuring CN_TOP........COMPLETED         Configuring CSI_TOP.......COMPLETED         Configuring WIP_TOP.......COMPLETED         Configuring CSE_TOP.......COMPLETED         Configuring EAM_TOP.......COMPLETED         Configuring IMT_TOP.......COMPLETED         Configuring FTE_TOP.......COMPLETED         Configuring ONT_TOP.......COMPLETED         Configuring AR_TOP........COMPLETED         Configuring AHL_TOP.......COMPLETED         Configuring OZF_TOP.......COMPLETED         Configuring IES_TOP.......COMPLETED         Configuring CSD_TOP.......COMPLETED         Configuring IGC_TOP.......COMPLETED AutoConfig completed successfully. The log file for this session is located at: /apps01/applprod/prodappl/admin/prod_ravi/log/10131401/adconfig.log [applprod@ravi prod_ravi]$

Errors & Solutions:


Starting AutoConfig at Thu Sep  3 19:41:59 2015
Using adconfig.pl version 120.26.12010000.5

        Classpath                   : /data1/OBAAPPS/apps/apps_st/comn/java/lib/appsborg2.zip:/data1/OBAAPPS/apps/apps_st/comn/java/classes

===========================================================================
Starting Utility to Report Version Conflicts at Thu Sep 03 19:42:10 IST 2015
Using VersionConflictListGenerator.java version 120.3


[ INFO_REPORT ]


[ AD_TOP ]

[ VERSION CONFLICTS INFORMATION ]
Template shipped by oracle is having a version different than the template lying in custom directory.
Template shipped by Oracle : /data1/OBAAPPS/apps/apps_st/appl/ad/12.0.0/admin/template/APPLSYS_ux.env(version: 120.29.12010000.7)
Custom template            : /data1/OBAAPPS/apps/apps_st/appl/ad/12.0.0/admin/template/custom/APPLSYS_ux.env(version: 120.29.12010000.3)
Please resolve the differences between the two templates or refer to Metalink Note 387859.1 for further details.

All driver files processed.
===========================================================================
Version Conflicts among development maintained and customized templates encountered; aborting AutoConfig run.

The logfile for this session is located at: /data1/OBAAPPS/inst/apps/OBA_our12-test/admin/log/09031941/adconfig.log


Solution:

cp -rp /data1/OBAAPPS/apps/apps_st/appl/ad/12.0.0/admin/template/APPLSYS_ux.env /data1/OBAAPPS/apps/apps_st/appl/ad/12.0.0/admin/template/custom/APPLSYS_ux.env

AutoConfig Fails With Error: Version Conflicts Among Development Maintained and Customized Templates Encountered; aborting AutoConfig Run (Doc ID 1100113.1)

Data Guard

DATA GUARD:

Data Guard was introduced from 9i onwards (before it was called as Standby Server).

Data Protection modes:

Maximum Protection	No Data loss	Synchronous redo shipping
Maximum Availability	No Data loss	Synchronous redo shipping
Maximum Performance	0 – few seconds Data loss	Asynchronous redo shipping

Maximum Protection Mode:

-          Highest level of data protection

-          Enforce protection of every transaction.

-          If last standby is unavailable processing stop  at primary DB.

-          Good for Financial systems where no data loss is acceptable

Maximize Availability:

-          Enforces protection of every transaction.

-          If last standby is unavailable, processing continues at primary DB.

-          When it is re-available, synchronization is automatic.

Maximum Performance:

-          Highest level of performance

-          Protects from failure of any single component.

-          Least impact on primary/production DB.

-          Useful for applications that can tolerate some data loss.

There are 2 types of standby databases. They  are

1.      Local

2.      Remote

1)      Local Standby database:

Ø  Appropriate for highest data protection mode.

Ø  LAN links are cheap, reliable, have high bandwidth and low latency.

Ø  Switch over operations are very fast.

2)      Remote Standby database:

Ø  Best solution for Disaster Recovery.

Ø  WAN links are generally more expensive, less reliable, have lower bandwidth and higher latency.

Ø  Suitable for highest performance asynchronous data protection mode.

Primary database name: dg

Standby Database name: stdby

STEP 1: Create the same structure in standby database like primary database.

Ex:

Primary: /u01/dg/oradata

Standby:/u01/stdby/oradata

STEP 2: prepare primary database.

1.      Check FORCE_LOGGING is enabled or not by using V$DATABASE.

Enable Force Logging

SQL>STARTUP

SQL>SELECT NAME,

CONTROLFILE_TYPE,

FORCE_LOGGING,

OPEN_MODE

 FROM V$DATABASE;

SQL> ALTER DATABASE FORCE LOGGING;

STEP 3: create standby controlfile.

ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/././..’;

STEP 4: Primary Database parameters:

db_name=dg

db_block_size=4096

sga_target=500M

db_create_file_dest='/u01/dg/oradata'

undo_management=auto

undo_tablespace=undotbs

db_unique_name=dg

control_files='/u01/dg/oradata/control01.ctl','/u01/dg/oradata/control02.ctl'

#log_archive_dest=/u01/dg/admin/arch

log_archive_format=arch_%s_%t_%r_%d.arc

db_domain=apps.com

background_dump_dest=/u01/dg/admin/bdump

user_dump_dest=/u01/dg/admin/udump

core_dump_dest=/u01/dg/admin/cdump

dg_broker_start=true

remote_login_passwordfile='EXCLUSIVE'

log_archive_dest_1='LOCATION=/u01/dg/admin/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=dg'

log_archive_config='DG_CONFIG=(dg,stdby)'

log_archive_dest_2='SERVICE=stdby VALID_FOR=(ALL_LOGFILES,PRIMARY_ROLE) LGWR ASYNC REOPEN=10 DB_UNIQUE_NAME=stdby'

FAL_CLIENT=dg

FAL_SERVER=stdby

standby_file_management=auto

STEP 5: Standby database parameters:

db_name=dg

db_block_size=4096

sga_target=500M

db_unique_name=stdby

undo_management=auto

undo_tablespace=undotbs

control_files=/u01/stdby/oradata/stdby01.ctl

#log_archive_dest=/u01/stdby/admin/arch

log_archive_format=arch_%s_%t_%r_%d.arc

db_domain=apps.com

background_dump_dest=/u01/stdby/admin/bdump

user_dump_dest=/u01/stdby/admin/udump

core_dump_dest=/u01/stdby/admin/cdump

standby_file_management=auto

dg_broker_start=true:

log_archive_dest_1='LOCATION=/u01/stdby/admin/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=stdby'

log_archive_config='DG_CONFIG=(dg,stdby)'

log_archive_dest_2='SERVICE=dg VALID_FOR=(ALL_LOGFILES,PRIMARY_ROLE) LGWR ASYNC REOPEN=10 DB_UNIQUE_NAME=dg'

log_archive_dest_state_1='ENABLE'

log_archive_dest_state_2='ENABLE'

FAL_CLIENT=stdby

FAL_SERVER=dg

standby_archive_dest='/u01/stdby/admin/arch' (this parameter is deprecated in 11g onwards)

remote_login_passwordfile='EXCLUSIVE'

db_file_name_convert= 'dg','stdby'

log_file_name_convert= 'dg','stdby'

STEP 6: Network configuration

Primary listener.ora file

dg = (DESCRIPTION =

      (ADDRESS = (HOST=192.168.1.99)(PROTOCOL = TCP) (PORT = 1533)))

SID_LIST_dg= (SID_LIST =

               (SID_DESC =

                (ORACLE_HOME=/u01/oraravi/db/tech_st/10.2.0)

                      (SID_NAME = dg )))

Primary tnsnames.ora file:

dg =   (DESCRIPTION =

         ( ADDRESS = (PROTOCOL = TCP) (PORT =1533) (HOST =192.168.1.99))

          (CONNECT_DATA =

            (SERVICE_NAME = dg)))

stdby = (DESCRIPTION =

         ( ADDRESS = (PROTOCOL = TCP) (PORT =1533) (HOST =192.168.1.77))

          (CONNECT_DATA =

            (SERVICE_NAME = stdby)))

Standby listener.ora

stdby = (DESCRIPTION =

         (ADDRESS = (HOST=192.168.1.77)(PROTOCOL = TCP) (PORT = 1533)))

SID_LIST_stdby = (SID_LIST =

                (SID_DESC =

                 (ORACLE_HOME=/u01/oraprod/proddb/10.2.0)

                      (SID_NAME = stdby )))

Standby tnsnames.ora

dg =   (DESCRIPTION =

         ( ADDRESS = (PROTOCOL = TCP) (PORT =1533) (HOST =192.168.1.99))

          (CONNECT_DATA =

            (SERVICE_NAME = dg)))

STEP 7: create standby log files in primary for standby database.

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP <number>  ‘/../../../../’ SIZE <same as online redo log sizes>;

STEP 8: create password files for both primary and standby.

$orapwd file=orapw<sid> password=<XXXXX>  ignorecase=y

STEP 9: Take a backup and copy data files, log files, standby control file, Password file and archives from primary database to standby database.

STEP 10: start the standby database.

SQL> STARTUP NOMOUNT;

SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

SQL> SELECT database_role FROM v$database;

DATABASE_ROLE

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

PHYSICAL STANDBY

STEP 11: recover standby archives by using the following statement.

 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Switch over or Fail over case:

Altered at run time without loss of data or resetting of redo logs.

Primary to Standby:-

SQL> select DATABASE_ROLE,GUARD_STATUS,SWITCHOVER_STATUS,DATAGUARD_BROKER from v $database;

DATABASE_ROLE    GUARD_S SWITCHOVER_STATUS    DATAGUAR

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

PRIMARY          NONE    TO STANDBY           DISABLED

SQL> select protection_mode from v$database;

PROTECTION_MODE

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

MAXIMUM PERFORMANCE

SQL> alter database commit to switchover to standby;

Database altered.

SQL> shut immediate;

ORA-01507: database not mounted

ORACLE instance shut down.

SQL> startup nomount;

ORACLE instance started.

Total System Global Area  523108352 bytes

Fixed Size                  1337632 bytes

Variable Size             314574560 bytes

Database Buffers          201326592 bytes

Redo Buffers                5869568 bytes

SQL> alter database mount standby database;

Database altered.

Standby to primary:-

SQL> alter database recover managed standby database;

Database altered.

SQL> alter database open;

Database altered.

SQL> alter database commit to switchover to primary;

Database altered.

SQL> shut

ORA-01109: database not open

Database dismounted.

ORACLE instance shut down.

SQL> startup

ORACLE instance started.

Total System Global Area  523108352 bytes

Fixed Size                  1337632 bytes

Variable Size             314574560 bytes

Database Buffers          201326592 bytes

Redo Buffers                5869568 bytes

Database mounted.

Database opened.

SQL> alter system switch logfile;

System altered.

Change  DATA Protection modes:-

 Go to primary database.

SQL> shut immediate;

SQL> startup mount;

SQL> alter database standby database set to maximize [protection / availability / performance];

SQL> alter database open;

Data Guard Broker:

-          Distributed management framework that automates & centralizes the creation, maintenance, and monitoring of Data Guard configuration.

-          Management operations can be performed locally or remotely through the broker’s easy to use interfaces

Ø  GUI based oracle data guard manager.

Ø  Data Guard command-line Interface.

Errors :

Archives not transferred from primary to standby?

Errors in file /u01/prod/oracle/product/diag/rdbms/stdby/stdby/trace/stdby_arc3_ 18736.trc:

ORA-16191: Primary log shipping client not logged on standby

FAL[server, ARC3]: Error 16191 creating remote archivelog file 'primary'

FAL[server, ARC3]: FAL archive failed, see trace file.

Errors in file /u01/prod/oracle/product/diag/rdbms/stdby/stdby/trace/stdby_arc3_ 18736.trc:

ORA-16055: FAL request rejected

ARCH: FAL archive failed. Archiver continuing

ORACLE Instance stdby - Archival Error. Archiver continuing.

Thu May 09 07:17:33 2013

Error 1017 received logging on to the standby

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

Check that the primary and standby are using a password file

and remote_login_passwordfile is set to SHARED or EXCLUSIVE,

and that the SYS password is same in the password files.

      returning error ORA-16191

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

Solution:

Check password file and re-define the password file.

orapwd file=orapwstdby password=welcome ignorecase=y

In 11g set the parameter  “sec_case_sensitive_logon=false”

Error:-

SQL> startup

ORACLE instance started.

Total System Global Area  523108352 bytes

Fixed Size                  1337632 bytes

Variable Size             314574560 bytes

Database Buffers          201326592 bytes

Redo Buffers                5869568 bytes

Database mounted.

ORA-03113: end-of-file on communication channel

Process ID: 22464

Session ID: 1 Serial number: 7

In alert log file error shoes:

ORA-16072: a minimum of one standby database destination is required

Errors in file /u01/prod/oracle/product/diag/rdbms/stdby/stdby/trace/stdby_lgwr_22385.trc:

Solution:

SQL> startup mount

ORACLE instance started.

Total System Global Area  523108352 bytes

Fixed Size                  1337632 bytes

Variable Size             314574560 bytes

Database Buffers          201326592 bytes

Redo Buffers                5869568 bytes

Database mounted.

SQL> alter database set standby database to maximize {AVAILABILITY/PERFORMANCE/PROTECTION};

Database altered.

SQL> alter database open;

Database altered.

**********************************************************
*********************************************

Physical versus Logical Standby database:

Physical: It is kept synchronized with the primary database by recovering the redo data received from the primary database. The recovery operation applies changes block-for-block using the physical row ID

• A physically identical copy of the primary database on a block-for-block basis.
•  To Synch with primary through Redo Apply.
• Read only access, but only in an Exclusive Mode (no redo apply at the same time).
• Can be used to offload Backups.
• Redo apply is faster and most efficient approach to apply to changes.

Logical: It is kept synchronized with the primary database by transforming the data in the redo logs received from primary database into SQL statements and then executing the SQL statements on the standby database.

• Contains the same logical information as the production database, although a physical organization and structure of the data can be different.
• To Synch with primary through SQL Apply.
• Read only access can be queried for reports while logs are being applied  via SQL.
• Can create additional indexes and Materialized views for better query performance.

Limitations of Logical:

1. Uses more resources than physical.
2. Has some restrictions on datatypes. type of tables, DDL and DML.

Note: we can create Temporary Tablespace with different Name and Size on Standby Database.

Shutting down/Stop the Physical Standby:

deffer the archive log destination 2 and perform a log switch on primary database.( it is not possible in the maximum protection mode the primary database have to be shutdown first).

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=defer;

Find out if the standby database is performing managed recovery (SEC):

SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;

PROCESS STATUS

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

ARCH    CLOSING

ARCH    CLOSING

RFS     WRITING

MRP0    WAIT_FOR_LOG

RFS     RECEIVING

RFS     RECEIVING

4. Cancel managed recovery operations (SEC)

SQL> ALTER DATABASE RECOVER MANAGE STANDBY DATABASE CANCEL;

5. Shut down the standby database (SEC)

SQL> SHUTDOWN IMMEDIATE;

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

Switching between the Read-Only Access and Managed-Recovery Mode

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

1. Cancel log apply services

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

2. Open the database for read-only access

SQL> ALTER DATABASE OPEN READ ONLY;

Return back to managed-recovery mode:

3. Terminate all active user sessions on the standby database.

4. Restart log apply services:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

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

Role Management – Switchover

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

1. Verify that it is possible to perform a switchover operation (PRI)

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS

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

SESSIONS ACTIVE

2. Convert the primary database to the new standby (PRI)

SQL> alter database commit to switchover to physical standby with session shutdown;

3. Shutdown the former primary and mount as a standby database (PRI)

SQL> shutdown immediate

SQL> startup nomount

SQL> alter database mount standby database;

at this point both databases are configured as standby <=

4. Defer the remote archive destination on the old primary (OLD PRI)

SQL> alter system set log_archive_dest_state_2=defer;

5. Verify that the physical standby can be converted to the new primary (SEC)

SQL> select switchover_status from v$database;

6. Convert the physical standby to the new primary (SEC)

SQL> alter database commit to switchover to primary with session shutdown;

7. Shutdown and startup the new primary (NEW PRI)

SQL> shutdown immediate

SQL> startup

8. Initiate Log Apply Services (NEW SEC)

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

9. Enable Archiving to the Physical Standby Database (NEW PRI)

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=enable;

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

Role Management – Failover

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

0. Consider if it would be faster to repair the primary database than to perform a role transition.

1. Identify and resolve any archived redo log gaps.

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

 THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#

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

         1            13             14

2. In order to determine if there are any missing archived redo logs

you have to query the V$ARCHIVED_LOG view on all available databases in the configuration to obtain the highest sequence number for each thread.

SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;

3. Register any copied archive log

SQL>  ALTER DATABASE REGISTER PHYSICAL LOGFILE '/ORA/dbs02/oracle/admin/arch/arch_0001_0000000015.dbf';

4. Initiate the failover operation on the target physical standby database.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH SKIP STANDBY LOGFILE;

5. Convert the physical standby database to the primary role.

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

6. Shut down and restart the new primary database.

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP;

7.  Enable the archiving destination on the new primary

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

Queries:

 Primary:

SQL> select TYPE,DEST_NAME,status,error from v$archive_dest;

TYPE    DEST_NAME                 STATUS    ERROR

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

PUBLIC  LOG_ARCHIVE_DEST_1        VALID

PUBLIC  LOG_ARCHIVE_DEST_2        ERROR     ORA-16191: Primary log shipping client not logged on standby

Standby:

SQL> select status,process from v$managed_standby;

STATUS       PROCESS

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

CONNECTED    ARCH

CONNECTED    ARCH

CONNECTED    ARCH

CONNECTED    ARCH

WAIT_FOR_LOG MRP0