Patch DN1F is mutually exclusive and cannot coexist with patch(es): CIH8

Patch DN1F is mutually exclusive and cannot coexist with patch(es): CIH8

While applying a patch on WLS, we encounter the error:

Patch DN1F is mutually exclusive and cannot coexist with patch(es): CIH8


Solution:

Remove the conflicting patch using below command:

[applmgr@oel7 bsu]$ ./bsu.sh -prod_dir=/u01/apps/TEST/fs1/FMW_Home/wlserver_10.3 -patchlist=CIH8 -verbose -remove
Checking for conflicts........
No conflict(s) detected

Starting removal of Patch ID: CIH8
Removing /u01/apps/TEST/fs1/FMW_Home/patch_wls1036/patch_jars/AppsAdapter.jar
Removing /u01/apps/TEST/fs1/FMW_Home/patch_wls1036/patch_jars/bpm-infra.jar
Removing /u01/apps/TEST/fs1/FMW_Home/patch_wls1036/patch_jars/DBAdapter.jar
Removing /u01/apps/TEST/fs1/FMW_Home/patch_wls1036/patch_jars/dbws.jar
Removing /u01/apps/TEST/fs1/FMW_Home/patch_wls1036/patch_jars/jca-binding-api.jar
Updating /u01/apps/TEST/fs1/FMW_Home/patch_wls1036/profiles/default/sys_manifest_classpath/weblogic_patch.jar
Old manifest value: Class-Path= ../../../patch_jars/BUG16684205_1036.jar ../../../patch_jars/BUG13964737_1036.jar ../../../patch_jars/BUG13729611_103607.jar ../../../patch_jars/BUG11781879_103607.jar ../../../patch_jars/BUG19687084_103607.jar ../../../patch_jars/BUG20474010_1036.jar ../../../patch_jars/BUG17319481_103607.jar ../../../patch_jars/BUG13337000_103607.jar ../../../patch_jars/BUG17572726_103607.jar ../../../patch_jars/com.bea.core.stax2_2.0.0.0_3-0-3.jar ../../../patch_jars/glassfish.jaxb.xjc_1.2.0.0_2-1-14.jar ../../../patch_jars/glassfish.jaxb_1.2.0.0_2-1-14.jar ../../../patch_jars/glassfish.jaxp_1.4.5.0.jar ../../../patch_jars/glassfish.jaxws.mimepull_1.1.0.0_1-3-8.jar ../../../patch_jars/AppsAdapter.jar ../../../patch_jars/bpm-infra.jar ../../../patch_jars/DBAdapter.jar ../../../patch_jars/dbws.jar ../../../patch_jars/jca-binding-api.jar ../../../patch_jars/com.bea.core.management.core_2.9.0.1.jar ../../../patch_jars/BUG14272383_1036.jar ../../../patch_jars/BUG13845626_1036.jar
New manifest value: Class-Path= ../../../patch_jars/BUG16684205_1036.jar ../../../patch_jars/BUG13964737_1036.jar ../../../patch_jars/BUG13729611_103607.jar ../../../patch_jars/BUG11781879_103607.jar ../../../patch_jars/BUG19687084_103607.jar ../../../patch_jars/BUG20474010_1036.jar ../../../patch_jars/BUG17319481_103607.jar ../../../patch_jars/BUG13337000_103607.jar ../../../patch_jars/BUG17572726_103607.jar ../../../patch_jars/com.bea.core.stax2_2.0.0.0_3-0-3.jar ../../../patch_jars/glassfish.jaxb.xjc_1.2.0.0_2-1-14.jar ../../../patch_jars/glassfish.jaxb_1.2.0.0_2-1-14.jar ../../../patch_jars/glassfish.jaxp_1.4.5.0.jar ../../../patch_jars/glassfish.jaxws.mimepull_1.1.0.0_1-3-8.jar ../../../patch_jars/AppsAdapter.jar ../../../patch_jars/bpm-infra.jar ../../../patch_jars/DBAdapter.jar ../../../patch_jars/dbws.jar ../../../patch_jars/jca-binding-api.jar ../../../patch_jars/com.bea.core.management.core_2.9.0.1.jar ../../../patch_jars/BUG14272383_1036.jar ../../../patch_jars/BUG13845626_1036.jar
Result: Success

Then Apply the patch 

CLEARING an ADOP patching session

In some case adop prepare phase fails due to some issues and if you wish to apply any patch in hotpatch mode, it will fail with below errors

[STATEMENT] There is already a session which is incomplete. Details are:
[STATEMENT]     Session Id: 2
[STATEMENT]     Prepare phase status: R
[STATEMENT]     Apply phase status: N
[STATEMENT]     Cutover  phase status: N
[STATEMENT]     Abort phase status: N

[STATEMENT]     Session status: F

[ERROR]     Cannot apply hotpatch as another online patching cycle is going on

[ERROR]     Unrecoverable error occured. Exiting the current session.

[STATEMENT] [START 2019/10/22 16:13:00] Unlocking sessions table

[STATEMENT] [END   2019/10/22 16:13:00] Unlocking sessions table

[STATEMENT] Log file: /adop_20191022_161221.log

[STATEMENT] [START 2019/10/22 16:13:02] Unlocking sessions table

[STATEMENT] [END   2019/10/22 16:13:03] Unlocking sessions table

Can't call method "close" on an undefined value at /u01/apps/TEST/fs1/EBSapps/appl/au/12.0.0/perl/ADOP/Phase.pm line 239.

Now, if you try to cleanup the previous session using below

$ adop phase=cleanup

  [ERROR]     Error: Pending session of prepare/apply/cutover exists

  [ERROR]     Hint: Before trying cleanup complete the pending session

  [STATEMENT] [START 2019/10/22 16:18:36] Unlocking sessions table

  [STATEMENT] [END   2019/10/22 16:18:36] Unlocking sessions table

  [STATEMENT] Log file: /u01/apps/TEST/fs_ne/EBSapps/log/adop/2/adop_20191022_161746.log

adop exiting with status = 2 (Fail)

The solution is to abort the patching cycle as shown below:

Type Y when prompted 

$ adop phase=abort

...

[STATEMENT]           one patch is already applied for the session id

The above session would be aborted/rolled back. Do you want to continue [Y/N]? Y

[STATEMENT] adop phase=abort - Completed Successfully

$ adop -status

Node Name       Node Type       Phase       Status          Started                        Finished                       Elapsed

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

oel7            master          PREPARE     SESSION ABORTED 22-OCT-19 02:33:06 +03:00      22-OCT-19 02:54:06 +03:00      0:20:00

                                APPLY       SESSION ABORTED

                                CUTOVER     SESSION ABORTED

                                CLEANUP     SESSION ABORTED

File System Synchronization Used in this Patching Cycle: None

For more information, see the full ADOP Status Report.

Generating full ADOP Status Report at location: /u01/apps/TEST/fs_ne/EBSapps/log/status_20191022_162759/adzdshowstatus.out

Please wait...

Done...!

adop exiting with status = 0 (Success)

Connecting to Oracle Cloud VM from putty

There is a very nice explanation of how to connect to an Oracle Cloud VM using putty. 

Connect to a Cloud VM on Windows with PuTTY

https://www.oracle.com/webfolder/technetwork/tutorials/obe/cloud/ggcs/Connect_to_a_cloud_VM_on_Windows_with_Putty/connect_to_a_cloud_VM_using_Putty.html#summary




PS: Instead of using the auto-login (oracle) user name use (opc). It worked for me. 

Enjoy ur VM

resyncing from database with DB_UNIQUE_NAME RMAN-03014: implicit resync of recovery catalog failed

There has been a structural changes on the primary DB ( like adding of data files,etc) and during the time, tried to connect from standby database using rman as below

rman target / catalog rman/rman@dbcat

Recovery Manager: Release 11.2.0.4.0 - Production on Mon Oct 21 13:30:38 2019

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: SPROD (DBID=1981104798)
connected to recovery catalog database


RMAN> show all;

2> ;

ORA-20079: full resync from primary database is not done

doing automatic resync from primary
resyncing from database with DB_UNIQUE_NAME SPROD
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of show command at 10/21/2019 11:00:29
RMAN-03014: implicit resync of recovery catalog failed
RMAN-03009: failure of partial resync command on default channel at 10/21/2019 11:00:29
ORA-17629: Cannot connect to the remote database server
ORA-17627: ORA-01017: invalid username/password; logon denied

ORA-17629: Cannot connect to the remote database server

rman tries to resync the standby from primary using db_unique_name.

However, RMAN is unable to connect to the primary because no connect string was used when connecting to the standby - 

in order to resync from another host in a Data Guard configuration , the connection to target must be made with a username, password and alias.  

This is documentation Bug 13774434: ORA-17629, ORA-17628 DURING RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;

SoLUTION

Use a TNS connect string when connecting to the standby eg

rman target sys/sys123@primary_db catalog rman/rman@dbcat


RMAN> show all;

RMAN configuration parameters for database with db_unique_name SPRODSMU are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;

CONFIGURE CONTROLFILE AUTOBACKUP ON;