ORACLE APPS LOG FILES

R12 Installation Logs

Database Tier Installation
RDBMS $ORACLE_HOME/appsutil/log/$CONTEXT_NAME/<MMDDHHMM>.logRDBMS $ORACLE_HOME/appsutil/log/$CONTEXT_NAME/ApplyDBTechStack_<MMDDHHMM>.logRDBMS
$ORACLE_HOME/appsutil/log/$CONTEXT_NAME/ohclone.logRDBMS $ORACLE_HOME/appsutil/log/$CONTEXT_NAME/make_<MMDDHHMM>.logRDBMS
$ORACLE_HOME/appsutil/log/$CONTEXT_NAME/installdbf.logRDBMS $ORACLE_HOME/appsutil/log/$CONTEXT_NAME/adcrdb_<SID>.log RDBMS
$ORACLE_HOME/appsutil/log/$CONTEXT_NAME/ApplyDatabase_<MMDDHHMM>.logRDBMS $ORACLE_HOME/appsutil/log/$CONTEXT_NAME/<MMDDHHMM>/adconfig.log    RDBMS
$ORACLE_HOME/appsutil/log/$CONTEXT_NAME/<MMDDHHMM>/NetServiceHandler.log

Application Tier Installation
$INST_TOP/logs/<MMDDHHMM>.log
$APPL_TOP/admin/$CONTEXT_NAME/log/ApplyAppsTechStack.log
$INST_TOP/logs/ora/10.1.2/install/make_<MMDDHHMM>.log
$INST_TOP/logs/ora/10.1.3/install/make_<MMDDHHMM>.log
$INST_TOP/admin/log/ApplyAppsTechStack.log
$INST_TOP/admin/log/ohclone.log
$APPL_TOP/admin/$CONTEXT_NAME/log/installAppl.log
$APPL_TOP/admin/$CONTEXT_NAME/log/ApplyAppltop_<MMDDHHMM>.log
$APPL_TOP/admin/$CONTEXT_NAME/log/<MMDDHHMM>/adconfig.log
$APPL_TOP/admin/$CONTEXT_NAME/log/<MMDDHHMM>/NetServiceHandler.log

Inventory Registration:
$Global Inventory/logs/cloneActions<timestamp>.log
$Global Inventory/logs/oraInstall<timestamp>.log
$Global Inventory/logs/silentInstall<timestamp>.log

Other log files in R12
1) Database Tier

     1.1) Relink Log files :
$ORACLE_HOME/appsutil/log/$CONTEXT_NAME /MMDDHHMM/ make_$MMDDHHMM.log

    1.2) Alert Log Files :
$ORACLE_HOME/admin/$CONTEXT_NAME/bdump/alert_$SID.log
 
   1.3) Network Logs :
$ORACLE_HOME/network/admin/$SID.log

   1.4) OUI Logs : OUI Inventory Logs :
$ORACLE_HOME/admin/oui/$CONTEXT_NAME/oraInventory/logs

2) Application Tier
$ORACLE_HOME/j2ee/DevSuite/log
$ORACLE_HOME/opmn/logs
$ORACLE_HOME/network/logs

Tech Stack Patch 10.1.3 (Web/HTTP Server)
$IAS_ORACLE_HOME/j2ee/forms/logs
$IAS_ORACLE_HOME/j2ee/oafm/logs
$IAS_ORACLE_HOME/j2ee/oacore/logs
$IAS_ORACLE_HOME/opmn/logs
$IAS_ORACLE_HOME/network/log
$INST_TOP/logs/ora/10.1.2
$INST_TOP/logs/ora/10.1.3
$INST_TOP/logs/appl/conc/log
$INST_TOP/logs/appl/admin/log


- Autoconfig log file:
Apps:
$INST_TOP/logs/appl/admin/log

Db:
$ORACLE_HOME/appsutil/log/$CONTEXT_NAME//adconfig.log $ORACLE_HOME/appsutil/log/$CONTEXT_NAME//NetServiceHandler.log

- Startup/Shutdown AD SCRIPTS Log files:
$INST_TOP/logs/appl/admin/log

- Apache, OC4J and OPMN:

$LOG_HOME : - /u01/app/prod/inst/apps/PROD_oracle/logs
$INST_TOP :-      /u01/app/prod/inst/apps/PROD_oracle

$LOG_HOME/ora/10.1.3/Apache       or    $INST_TOP/log/ora/10.1.3/Apache/

$LOG_HOME/ora/10.1.3/j2ee            or    $INST_TOP/log/ora/10.1.3/j2ee/oacore/    # OC4J logfile (Text)
                                                         or    $INST_TOP/log/ora/10.1.3/j2ee/oacore/log/oacore_default_group_1/oc4j         # OC4J logfile ODL

$LOG_HOME/ora/10.1.3/opmn          or    $INST_TOP/log/ora/10.1.3/opmn

- Patch log:
$APPL_TOP/admin/$SID/log/

- Concurrent Manager log:
$INST_TOP/apps/$CONTEXT_NAME/logs/appl/conc/log
or
$INST_TOP/logs/appl/conc/log

AD tools log files:
$APPL_CONFIG_HOME/admin/$TWO_TASK/log



Log files related to cloning in R12
Preclone log files in source instance 
    i) Database Tier – /$ORACLE_HOME/appsutil/log/$CONTEXT_NAME/(StageDBTier_MMDDHHMM.log)
    ii) Application Tier – $INST_TOP/apps/$CONTEXT_NAME/admin/log/ (StageAppsTier_MMDDHHMM.log)

Clone log files in target instance
Database Tier - $ORACLE_HOME/appsutil/log/$CONTEXT_NAME/ApplyDBTier_<time>.log
Apps Tier  – $INST_TOP/apps/$CONTEXT_NAME/admin/log/ApplyAppsTier_<time>.log


—–
If your clone on DB Tier fails while running txkConfigDBOcm.pl  (Check metalink note – 415020.1)
During clone step on DB Tier it prompts for “Target System base directory for source homes” and during this you have to give like /base_install_dir like ../../r12 and not oracle home like ../../r12/db/tech_st_10.2.0
—–

R12 Apache login issue common error

If Login Page (AppsLocalLogin.jsp ) doesn’t work
a. Stop Application Services
b. Clear $COMMON_TOP/_pages directory
c. cd $FND_TOP/patch/115/bin ./ojspCompile.pl --compile --flush -p 10
d. If error something like this

Caused by: oracle.apps.jtf.base.resources.FrameworkException:

ORA-01578: ORACLE data block corrupted (file # 25, block # 228173)
ORA-01110: data file 25: 'apps_ts_tx_data.290.743539659'
ORA-26040: Data block was loaded using the NOLOGGING option


---run below as apps user

begin
apps.wf_local_synch.BULKSYNCHRONIZATION(P_ORIG_SYSTEM=>'ALL',
P_PARALLEL_PROCESSES=>2,
P_LOGGING=>'LOGGING',
P_RAISEERRORS=>TRUE,
P_TEMPTABLESPACE=>'APPS_TS_TX_DATA');
END;

txkWfClone.sh INSTALL_SETUP 1 (Autocongif completed with errors)

When Runing adconfig.sh on apps tier after clone some time this error.

[AutoConfig Error Report]
The following report lists errors AutoConfig encountered during each
phase of its execution. Errors are grouped by directory and phase.
The report format is:
<filename> <phase> <return code where appropriate>

[SETUP PHASE]
AutoConfig could not successfully execute the following scripts:
Directory: /f11/app/applp032/inst/apps/P032_tgpora3/admin/install
txkWfClone.sh INSTALL_SETUP -1
AutoConfig is exiting with status 1

RC-50014: Fatal: Execution of AutoConfig was failed
Raised by oracle.apps.ad.clone.ApplyApplTop
ERROR: AutoConfig completed with errors. Check logfile at /f11/app/applp032/inst/apps/P032_tgpora3/admin/log/ApplyAppsTier_07180828.log for details.
ApplyApplTop Completed Successfully

REASON :

1. Received the following error running Autoconfig:
[AutoConfig Error Report]
The following report lists errors AutoConfig encountered during each
phase of its execution.  Errors are grouped  by directory and phase.
The report format is:
      <filename>  <phase>  <return code where appropriate>
  [SETUP PHASE]
  AutoConfig could not successfully execute the following scripts:
    Directory: /apps/ifswmisc/common/admin/install/MISC_findvcl2
      txkWfClone.sh           INSTE8_SETUP       1

2. The adconfig.log shows txkWfClone.sh errors with the following:
ERROR at line 1:
ORA-06550: line 10, column 7:
PLS-00201: identifier 'WF_CLONE.DETERMINECLONE' must be declared
ORA-06550: line 10, column 3:
PL/SQL: Statement ignored


CAUSE:

This error means one of the following:
(a) WF_CLONE pkg and/or pkg body doesn't exist in the db or is invalid
or
(b) The DETERMINECLONE method/procedure doesn't exist within WF_CLONE pkg/pkg body.
(c) Some time Permission issue

Solution

1. Please verify if WF_CLONE is valid in the database. If it is not, please
recompile it.
2. If the actions in #1 do not resolve the issue, then do the following:
a. Run the following SQL query:

SQL> select text
2 from all_source
3 where name = 'WF_CLONE' and line < 7;

b. Go to the $FND_TOP/patch/115/sql directory and obtain the version of wfclones.pls
and wfcloneb.pls.
c. Compare the two versions. If they are different, then go to the
$FND_TOP/patch/115/sql directory and recreate the spec/body by running:

- sqlplus apps/<passwd> @WFCLONES.pls
- sqlplus apps/<passwd> @WFCLONEB.pls

3. Rerun AutoConfig.
  

Reinstating a Failed Primary Database (After Failover to swith the PRIMARY TO STANDBY) in DGMGRL

If your primary database had been configured with Flashback Database, you can easily reinstate the failed primary database as a standby database of the new primary database.
The failed primary database will be reinstated as a standby type that matches the old standby database. For example, if you failed over to a physical standby database,
 the old primary will be reinstated as a physical standby database.

To reinstate the failed primary database, start it to the mounted state. Then run DGMGRL, connect to the new primary database and reinstate the old primary database.


Step 1   Restart the Old Primary Database.

% sqlplus sys as sysdba
Enter password: password

SQL> STARTUP MOUNT;
ORACLE instance started.
Total System Global Area  234364928 bytes
Fixed Size                  1296352 bytes
Variable Size             209717280 bytes
Database Buffers           16777216 bytes
Redo Buffers                6574080 bytes
Database mounted.


Step 2   Reinstate the old primary database.

% dgmgrl connect sys
Password: password
Connected.

DGMGRL> REINSTATE DATABASE 'North_Sales';
Reinstating database "North_Sales", please wait...
Operation requires shutdown of instance "sales1" on database "North_Sales"
Shutting down instance "sales1"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "sales1" on database "North_Sales"
Starting instance "sales1"...
ORACLE instance started.
Database mounted.
Continuing to reinstate database "North_Sales" ...
Reinstatement of database "North_Sales" succeeded


After the primary has been reinstated, issue the SHOW CONFIGURATION and SHOW DATABASE commands to confirm that the old primary has been successfully reinstated.


Step 3   Show the Configuration and Databases.

DGMGRL> SHOW CONFIGURATION; 
Configuration
 Name:                DRSolution
 Enabled:             YES
 Protection Mode:     MaxAvailability
 Databases:
 DR_Sales     - Primary database
 North_Sales  - Physical standby database

Fast-Start Failover: DISABLED

Current status for "DRSolution":
SUCCESS

DGMGRL> SHOW DATABASE 'DR_Sales';
 Database
 Name:            DR_Sales
 Role:            PRIMARY
 Enabled:         YES
 Intended State:  TRANSPORT-ON
 Instance(s):
 dr_sales1
 Current status for "DR_Sales":
SUCCESS

DGMGRL> SHOW DATABASE 'North_Sales'; 
Database
 Name:            North_Sales
 Role:            PHYSICAL STANDBY
 Enabled:         YES
 Intended State:  APPLY-ON
 Instance(s):
 sales1
 Current status for "North_Sales":
SUCCESS

Performing a Manual Failover Operation without DGMGRL

You invoke a failover operation in response to an emergency situation, usually when the primary database cannot be accessed or is unavailable.

See before you fail over to decide which standby database should be the target of the failover. The following scenario describes a failover to the remote database called DR_Sales.

Note:

If fast-start failover is enabled, you can perform a manual failover only to the standby database that was specified as the target of a fast-start failover and only when the observer is running.

If you want to perform a manual failover to a standby database that is not the fast-start failover target standby database, you must first disable fast-start failover using the FORCE option on the standby database you want to fail over. See Section 5.5.5, "Disabling Fast-Start Failover" for more information about the FORCE option.

Step 1   Connect to the target standby database.

To perform the failover operation, you must connect to the standby database to which you want to fail over to as a user that has the SYSDBA privilege. For example:

DGMGRL> CONNECT sys@DR_Sales.foo.com;

Password: password

Connected.

Step 2   Issue the failover command.

Now you can issue the failover command to make the target standby database the new primary database for the configuration. Note that after the failover completes, the original primary database cannot be used as a standby database of the new primary database unless it is reenabled (as described in Section 5.4.3).

Step 3   Show the configuration.

Issue the SHOW CONFIGURATION command to verify the failover.

DGMGRL> SHOW CONFIGURATION;

Configuration

 Name:                DRSolution

 Enabled:             YES

 Protection Mode:     MaxAvailability

 Databases:

   DR_Sales     - Primary database

   North_Sales  - Physical standby database (disabled)

Fast-Start Failover: DISABLED

Current status for "DRSolution":

Warning: ORA-16608: one or more databases have warnings

Note that in this example, the configuration was operating in maximum availability mode. The protection mode was preserved after the failover. The configuration also has a warning status. If you show the StatusReport monitorable database property of the new primary, you will see that the warning is the result of not having an enabled physical standby database. As a result, the warning status indicates that the protection level of the configuration is not the same as the configured mode.

Step 4   Show StatusReport property of the new primary database.

DGMGRL> SHOW DATABASE 'DR_Sales' StatusReport;

STATUS REPORT

      INSTANCE_NAME   SEVERITY ERROR_TEXT

                  *    WARNING ORA-16629: database reports a different protection level from the protection mode

Step 5   Show the database.

Issue the SHOW DATABASE command to see that the former (failed) primary database was disabled by the broker as a consequence of the failover. It must be reenabled (as described in Section 5.4.3).

DGMGRL> SHOW DATABASE 'North_Sales';

Database

 Name:            North_Sales

 Role:            PHYSICAL STANDBY

 Enabled:         NO

 Intended State:  APPLY-ON

 Instance(s):

   sales1

Current status for "North_Sales":

Error: ORA-16661: the standby database needs to be reinstated

Enabling Fast-Start Failover and Starting the Observer With DGMGRL

Step 1   Ensure standby redo logs are configured on the primary and target standby databases.

Standby redo logs must be configured on the primary and standby databases. You must stop log apply services prior to configuring standby redo logs.

Step 2   Ensure the LogXptMode Property is set to SYNC.

The LogXptMode configurable database property must be set to SYNC on the primary and target standby databases.

To set the redo transport service that corresponds to the protection mode you plan to set, use the EDIT DATABASE (property) command on the primary and target standby databases.

For example, if the protection mode to be set is MAXAVAILABILITY, you must set the LogXptMode property to SYNC on the primary database and on the target standby database, as shown in the following examples:

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'LogXptMode'='SYNC';

Property "LogXptMode" updated

DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY 'LogXptMode'='SYNC';

Property "LogXptMode" updated

The broker does not allow these commands to succeed unless the databases are configured with standby redo log files.

Step 3   Set the FastStartFailoverTarget configuration property.

If you have two or more standby databases, set up the FastStartFailoverTarget configuration property on the primary database to indicate the desired target standby database. For example:

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY FastStartFailoverTarget='DR_Sales';

Property "FastStartFailoverTarget" updated

Step 4   Upgrade the protection mode to MAXAVAILABILITY, if necessary.

If it is necessary to upgrade the protection mode, use the following DGMGRL EDIT CONFIGURATION command. For example:

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

Step 5   Enable Flashback Database on the primary and target standby databases, if necessary.

If it is not already enabled on the primary and standby databases, enable Flashback Database by issuing the following statements on each database:

ALTER SYSTEM SET UNDO_RETENTION=3600 SCOPE=SPFILE;

ALTER SYSTEM SET UNDO_MANAGEMENT='AUTO' SCOPE=SPFILE;

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

SHOW PARAMETER UNDO;

ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320 SCOPE=BOTH;

ALTER DATABASE ARCHIVELOG;

ALTER DATABASE FLASHBACK ON;

ALTER DATABASE OPEN;

Ensure the UNDO_RETENTION and DB_FLASHBACK_RETENTION_TARGET initialization parameters are set to sufficiently large values so that reinstatement is still possible after a prolonged outage.

Step 6   Start the observer.

Start the observer by logging into the observer computer and running DGMGRL. Connect to the configuration as SYS and then issue the START OBSERVER command. Note that the command does not return; that is you will not get DGMGRL prompt after issuing the command.

DGMGRL> CONNECT sys@North_Sales.foo.com;

Password: password

Connected.

DGMGRL> START OBSERVER;

Observer started

When starting the observer interactively, Oracle recommends that connection credentials be supplied as a command parameter to the DGMGRL CONNECT command, as shown in the example, rather than as a command line parameter to the DGMGRL command. This practice prevents other users on the system from using a utility (for example, the UNIX ps utility) to display the connection credentials.

When starting the observer from a script, Oracle recommends that you use a method that supports 'connect /', so that database connection credentials do not have to be embedded within the script. If you choose to use a client-side Oracle Wallet as a secure external password store (see Oracle Database Advanced Security Administrator's Guide), be sure to add credentials for both the primary and fast-start failover target standby databases. The database connect string that you specify when adding the credentials for each database must match the ObserverConnectIdentifer or DGConnectIdentifier configurable database property.

Step 7   Enable fast start failover.

You can enable fast-start failover while connected to any database system in the broker configuration. For example:

DGMGRL> ENABLE FAST_START FAILOVER;

Enabled.

Step 8   Verify the fast-start failover configuration.

Use the SHOW FAST_START FAILOVER command to display the fast-start failover settings:

DGMGRL> SHOW FAST_START FAILOVER;

Fast-Start Failover: ENABLED

 Threshold:           30 seconds

 Target:              DR_Sales

 Observer:            observer.foo.com

 Lag Limit:           30 seconds (not in use)

 Shutdown Primary:    TRUE

 Auto-reinstate:      TRUE

Configurable Failover Conditions

 Health Conditions:

   Corrupted Controlfile          YES

   Corrupted Dictionary           YES

   Inaccessible Logfile            NO

   Stuck Archiver                  NO

   Datafile Offline               YES

 Oracle Error Conditions:

   (none)

Configuration Protection Mode with DGMGRL

Step 1   Configure standby redo log files, if necessary.
Because you will be setting the protection mode to the MAXAVAILABILITY mode, it is important to ensure that sufficient standby redo log files are configured on the standby database.

Step 2   Set the LogXptMode configurable database property appropriately.
Use the EDIT DATABASE (property) command on the standby database to set the redo transport service that corresponds to the protection mode you plan to set. If the protection mode to be set is MAXAVAILABILITY, it is required that the redo transport service of at least one standby database is set to SYNC. For example:

DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY 'LogXptMode'='SYNC';
Property "LogXptMode" updated

The broker will not allow this command to succeed unless the standby database is configured with standby redo log files in the configuration.

Step 3   Change the overall protection mode for the configuration.
Use the EDIT CONFIGURATION command to upgrade the broker configuration to the MAXAVAILABILITY protection mode:

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
Succeeded.
If the configuration is disabled when you enter this command, the actual protection mode change is not applied until you enable the configuration with the ENABLE CONFIGURATION command. The broker will not allow you to enable the configuration if it does not find a standby database in the configuration that can support the requirements of the protection mode.

Step 4   Verify the protection mode was changed.
Use the SHOW CONFIGURATION command to display the current protection mode for the configuration:

DGMGRL> SHOW CONFIGURATION;

Configuration
 Name:                DRSolution
 Enabled:             YES
 Protection Mode:     MaxAvailability      
 Databases:
   North_Sales  - Primary database
   DR_Sales     - Physical standby database

Fast-Start Failover: DISABLED

Current status for "DRSolution":
SUCCESS

Converting a Physical Standby to a Snapshot Standby With DGMGRL

If you have a physical standby database that the Flashback Database feature enabled and you would like to create a temporary, updatable snapshot of that database, use the DGMGRL CONVERT DATABASE command. Note that redo data will be received by the database while it is operating as a snapshot standby database but will not be applied until it is converted back into a physical standby database.

DGMGRL> CONVERT DATABASE 'DR_Sales' to SNAPSHOT STANDBY;
Converting database "DR_Sales" to a Snapshot Standby database, please wait...
Database "DR_Sales" converted successfully

DGMGRL> SHOW CONFIGURATION;
Configuration
Name: DRSolution
Enabled: YES
Protection Mode: MaxPerformance
Databases:
North_Sales - Primary database
DR_Sales - Snapshot standby database
Fast-Start Failover: DISABLED
Current status for "DRSolution":
SUCCESS
When you are ready to revert the database back to a physical standby database, use the DGMGRL CONVERT DATABASE command again as follows. Any updates made to the database while it was operating as a snapshot standby database will be discarded. All accumulated redo data will be applied by Redo Apply services after the database is converted back to a physical standby database.

DGMGRL> CONVERT DATABASE 'DR_Sales' to PHYSICAL STANDBY;

Converting database "DR_Sales" to a Physical Standby database, please wait...
Operation requires shutdown of instance "dr_sales1" on database "DR_Sales"
Shutting down instance "dr_sales1"...
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "dr_sales1" on database "DR_Sales"
Starting instance "dr_sales1"...
ORACLE instance started.
Database mounted.
Continuing to convert database "DR_Sales" ...
Operation requires shutdown of instance "dr_sales1" on database "DR_Sales"
Shutting down instance "dr_sales1"...
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "dr_sales1" on database "DR_Sales"
Starting instance "dr_sales1"...
ORACLE instance started.
Database mounted.
Database "DR_Sales" converted successfully

Applying CPU/PSU/Opatch with DGMGRL in Oracle 10g..

============================
PART SECOND ON STANDBY SIDE
============================

1.Disable Log Shipping From Primary To Standby

----DGMGRL
connect sys/oracle@PRIMARY

edit database PRIMARY set property LogShipping='OFF';      // IF hang then first clean shutdown the database and restart server then after try;
show database verbose PRIMARY;
show database verbose STANDBY;

2.Shutdown All The Standby Database Services

alter database recover managed standby database cancel;
shutdown immediate
lsnrctl stop

3.Apply PSU patch to Standby Database


A) .Ensure that your Oracle Database installation is the same release for which you are applying this patch. In other words, only apply the Release 10.2.0.1 CPUJul2006 patch to an Oracle Database Release 10.2.0.1.


B) .Review Section 4, "Known Issues" before proceeding with this installation.


C) .Shut down all instances and listeners associated with the Oracle home that you are updating. For more information, see Oracle Database Administrator's Guide.


D) .Ensure that the $PATH has the following executables: make, ar, ld, and nm.

which make
which ar
which ld
which nm


E) .Check whether the java and jar executables are present in your Oracle home.

In a standard Oracle installation, java is available in $ORACLE_BASE/jre/JDK version/bin directory and jar is available in $ORACLE_HOME/jdk/bin directory. By default, the OPatch utility uses the executables from these locations. However, if they are located elsewhere, you can use the opatch apply command with the -jdk flag, and then specify the full path to the JDK to be used. For more information, refer to OPatch User's Guide, which is available with the OPatch utility distribution.


$ export PATH=$PATH:$HOME:$ORACLE_HOME/OPatch:/bin

$ opatch napply -skip_subset -skip_duplicate



F) .Set your current directory to the directory where the patch is located and then run the OPatch utility by entering the following command:
cd  5225798
opatch apply



----startup mount
4.Mount The Standby Database and lsnrctl start


============================
PART SECOND ON PRIMARY SIDE
============================
5 .Stop Primary Database Services stop listener
6 .Apply CPU Patch To Primary Database
7 .Start Primary Database
8 .Re-Enable Log Shipping
9 .Put Standby Database In Recovery Mode
10.Verify The CPU Patch Application.



Post Installation Instructions for a Non-RAC Environment

Follow these steps:

A) .Start all database instances running from the Oracle home that you are patching.


B) .For each database instance running of the Oracle home being patched, connect to the database using SQL*Plus. Connect as SYSDBA and run the catcpu.sql script as follows:

(Due to changes in the installation scripts, it is no longer a requirement to startup the database in MIGRATE mode.)
cd $ORACLE_HOME/cpu/CPUJul2006
sqlplus /nolog
SQL> CONNECT /AS SYSDBA
SQL> STARTUP
SQL> @catcpu.sql
SQL> QUIT


C) .Check the log file for any errors. If there are errors, refer to Section 4, "Known Issues".


D) .If catcpu.sql reports any Invalid Objects, run the following commands:



Note: For large numbers of objects, this compilation step can take some time. If you are applying this patch through the Enterprise Manager console,
you will be prompted to run this compilation script.


You can check for any invalid objects by executing following statement:
SQL> SELECT OBJECT_NAME FROM DBA_OBJECTS WHERE STATUS= 'INVALID';


 cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT /AS SYSDBA
SQL> STARTUP
SQL> @utlrp.sql


You can check for any invalid objects by executing following statement:
SQL> SELECT OBJECT_NAME FROM DBA_OBJECTS WHERE STATUS= 'INVALID';




----DGMGRL
connect sys/oracle@PRIMARY

edit database PRIMARY set property LogShipping='ON';      // IF hang then first clean shutdown the database and restart server then after try;
show database verbose PRIMARY;
show database verbose STANDBY;

Warning: You are no longer connected to ORACLE" while converting database using DGMGRL.

As part of my OCM Exam preparation while practicing the Data Guard scenarios such as converting the database from physical standby tosnapshot standby and from snapshot standby to physical standbyusing Data Guard Broker, the following warning messages were generated:

Unable to connect to database
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

Failed.
Warning: You are no longer connected to ORACLE.

Please complete the following steps and reissue the CONVERT command:
        start up and mount instance "stby" of database "stby"

Here is how, I was testing:

DGMGRL> connect sys@PRIMARY
Password: <enter the password here>
Connected.

Show the configuration:

DGMGRL> show configuration;

Configuration - DGConfig01

  Protection Mode: MaxPerformance
  Databases:
    PRIMARY - Primary database
    stby - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

Convert the Physical Standby Database to Snapshot Standby Database:


DGMGRL> convert database 'stby' to snapshot standby;
Converting database "stby" to a Snapshot Standby database, please wait...
Database "stby" converted successfully

Note: Converting the database from Physical Standby to Snapshot Standby database was succeeded, but it failed while reverting from Snapshot Standby to Physical Standby.

DGMGRL> convert database 'stby' to physical standby;
Converting database "stby" to a Physical Standby database, please wait...
Operation requires shutdown of instance "stby" on database "stby"
Shutting down instance "stby"...
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "stby" on database "stby"
Starting instance "stby"...
Unable to connect to database
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

Failed.
Warning: You are no longer connected to ORACLE.

Please complete the following steps and reissue the CONVERT command:
        start up and mount instance "stby" of database "stby"

Solution A:

First of all this is just a warning message, all you need to do is startup mount the database as instructed in the above warning message to resolve the issue.

But, the issue is that the Data Guard Broker was attempting to connect to a service called < db_unique_name>_DGMGRL i.e.stby_DGMGRL. On the server, the service name stby_DGMGRL.standbydb in the listener.ora file was configured as follows

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = stby_DGMGRL.standbydb)
      (ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1)
      (SID_NAME = stby)
    )

To overcome from this warning message being generated and to fix the issue permanently,  add a static registration for stby_DGMGRL to your $ORACLE_HOME/network/admin/listener.ora. Below is an example.

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = stby_DGMGRL)
      (ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1)
      (SID_NAME = stby)
    )
  )

Or Solution B:

Check the value of StaticConnectIdentifier property for stby database:


DGMGRL> show database 'stby' 'StaticConnectIdentifier';
  StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=standby.mydomain)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=stby_DGMGRL)(INSTANCE_NAME=stby)(SERVER=DEDICATED)))'

Here the SERVICE_NAME is stby_DGMGRL (by default it was set like this when Data Guard Broker configured).

Change the SERVICE_NAME from stby_DGMGRL to stby_DGMGRL.standbydb using Data Guard Broker 


DGMGRL> connect sys@stby
Password: <enter the password here>
Connected.

Show the current value for StaticConnectIdentifier property


DGMGRL> show database 'stby' 'StaticConnectIdentifier';
  StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=standby.mydomain)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=stby_DGMGRL)(INSTANCE_NAME=stby)(SERVER=DEDICATED)))'

Edit the value for StaticConnectIdentifier property

DGMGRL> edit database 'stby' set property 'StaticConnectIdentifier'='(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=standby.mydomain)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=stby_DGMGRL.standbydb)(INSTANCE_NAME=stby)(SERVER=DEDICATED)))';
Property "StaticConnectIdentifier" updated

Note: Above is a one line command


DGMGRL> show database 'stby' 'StaticConnectIdentifier';
  StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=standby.mydomain)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=stby_DGMGRL.standbydb)(INSTANCE_NAME=stby)(SERVER=DEDICATED)))'


Now start conversion:

DGMGRL> convert database 'stby' to physical standby;
Converting database "stby" to a Physical Standby database, please wait...
Error: ORA-16541: database is not enabled

Failed.
Failed to convert database "stby"

Note: Here we have to first start the standby database in mount mode. Then try the 'convert database' command.

[oracle@ocm01 ~]$ export ORACLE_SID=stby

[oracle@ocm01 ~]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on Wed Apr 10 23:34:47 2013

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

SQL> connect /as sysdba
Connected to an idle instance.

SQL> startup mount;
ORACLE instance started.

Total System Global Area  680607744 bytes
Fixed Size                  2216464 bytes
Variable Size             406851056 bytes
Database Buffers          264241152 bytes
Redo Buffers                7299072 bytes
Database mounted.

Now start conversion:


DGMGRL> connect sys@stby
Password: <enter the password here>
Connected.

DGMGRL> convert database 'stby' to physical standby;
Converting database "stby" to a Physical Standby database, please wait...
Operation requires shutdown of instance "stby" on database "stby"
Shutting down instance "stby"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "stby" on database "stby"
Starting instance "stby"...
ORACLE instance started.
Database mounted.
Database "stby" converted successfully