Funny "ORA-01017: invalid username/password; logon denied" during DataGuard switchover operation from DG broker

Recently one of my customers encountered a problem when they tried to perform a switchover from DataGuard broker command line interface.

$ dgmgrl /
DGMGRL for Linux: Version 12.1.0.2.0 - 64bit Production

Copyright (c) 2000, 2013, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected as SYSDG.
DGMGRL> show configuration;

Configuration - db12c

  Protection Mode: MaxPerformance
  Members:
  db12c  - Primary database
    sdb12c - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS   (status updated 26 seconds ago)

DGMGRL> validate database sdb12c;

  Database Role:     Physical standby database
  Primary Database:  db12c

  Ready for Switchover:  Yes
  Ready for Failover:    Yes (Primary Running)

  Flashback Database Status:
    db12c:   On
    sdb12c:  Off

DGMGRL> switchover to sdb12c;
Performing switchover NOW, please wait...
Operation requires a connection to instance "sdb12c" on database "sdb12c"
Connecting to instance "sdb12c"...
ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.

        connect to instance "sdb12c" of database "sdb12c"


This output is from the test environment where we could easily reproduce the problem.
The installation is using single-tenant fashion of 12.1 database with ASM and Oracle Restart. Therefore we must take into consideration also the fact, that the databases are started/stopped through Oracle Clusterware.

Investigation:

1.) Check of if password files on primary and standby are the same - shutdown the standby database and copy password file prom primary.

Checking what we see from V$PWFILE_USERS on primary database:

SQL> select * from v$pwfile_users;

USERNAME                       SYSDB SYSOP SYSAS SYSBA SYSDG SYSKM     CON_ID
------------------------------ ----- ----- ----- ----- ----- ----- ----------
SYS                            TRUE  TRUE  FALSE FALSE FALSE FALSE          0
SYSDG                          FALSE FALSE FALSE FALSE TRUE  FALSE          1
SYSBACKUP                      FALSE FALSE FALSE TRUE  FALSE FALSE          1
SYSKM                          FALSE FALSE FALSE FALSE FALSE TRUE           1
C##_ADM_JSENEGACNIK            FALSE TRUE  FALSE FALSE FALSE FALSE          1
C##_SYS                        TRUE  FALSE FALSE FALSE FALSE FALSE          0
JOC                            TRUE  FALSE FALSE FALSE FALSE FALSE          3


After restarting standby database only to MOUNT state with refreshed password file we get the following:

SQL> select * from v$pwfile_users;

USERNAME                       SYSDB SYSOP SYSAS SYSBA SYSDG SYSKM     CON_ID
------------------------------ ----- ----- ----- ----- ----- ----- ----------
SYS                            TRUE  TRUE  FALSE FALSE FALSE FALSE          1
SYSDG                          FALSE FALSE FALSE FALSE TRUE  FALSE          1
SYSBACKUP                      FALSE FALSE FALSE TRUE  FALSE FALSE          1
SYSKM                          FALSE FALSE FALSE FALSE FALSE TRUE           1
C##_ADM_JSENEGACNIK            FALSE TRUE  FALSE FALSE FALSE FALSE          1
C##_SYS                        TRUE  FALSE FALSE FALSE FALSE FALSE          1

The standby database represents the password file users slightly different.
Important to interpret here is the CON_ID column which per Oracle documentation has the following meaning:


    The ID of the container to which the data pertains. Possible values include:

        0: This value is used for rows containing data that pertain to the entire CDB. This value is also used for rows in non-CDBs.

        1: This value is used for rows containing data that pertain to only the root

        n: Where n is the applicable container ID for the rows containing data

As the standby database is only in MOUNT state the value 1 in CON_ID is normal because the database is not opened yet in read write mode and therefore no operations on pluggable databases can be performed.

The displayed message when error occurred was:

Operation requires a connection to instance "sdb12c" on database "sdb12c"
Connecting to instance "sdb12c"...
ORA-01017: invalid username/password; logon denied

Analyzing this text means that we have a connection problem when the DG broker tries to connect to standby database.
We are connected as SYSDG user with SYSDG privileges in DG broker on primary site and we get the error when DG broker tries to connect to standby (remote) instance. As we have high level of privileges and the parameter remote_login_passwordfile is set to EXCLUSIVE it means that obviously we have a problem how we connect to the DGMGRL.

Therefore let us try to connect with username and password remotely from DGMGRL utility on primary database using connection string (alias) from standby database:

$ dgmgrl
DGMGRL for Linux: Version 12.1.0.2.0 - 64bit Production

Copyright (c) 2000, 2013, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sysdg@sdb12c
Password:
ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.
 
Ooops, we get the same error. So when SYSDG user tries to connect to standby database via password file the username/password combination is wrong. We can connect as SYSDG user to DGMGRL utility using only "/" because we are authenticated via OSGROUP authorization. But for stopping/starting remote databases via Oracle Clusterware we need to be logged in via password file.

From the 12c manuals it looks like that the only way to change the password for SYSDG user in password file is by revoking and granting SYSDG privilege.


Find all users who have been granted the SYSDG privilege.

    SELECT USERNAME FROM V$PWFILE_USERS WHERE USERNAME != 'SYS' AND SYSDG='TRUE';

   

    Revoke and regrant the SYSDG privilege to these users.

    REVOKE SYSDG FROM non-SYS-user;
    GRANT SYSDG TO non-SYS-user;  


Actually it is enough that you change the password via "ALTER USER" command. The time  at the OS level of the password file will reflect this change so obviously the password file is updated with new password for SYSDG user.

SQL> alter user sysdg identified by Secret$124;


I have intentionally selected to put special character in password in order to show a problem when you try to use such password from the command line.


$ dgmgrl sys/Secret$124@db12c
DGMGRL for Linux: Version 12.1.0.2.0 - 64bit Production

Copyright (c) 2000, 2013, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.
DGMGRL>


Again we get error but this time due to "$" character in password. Escaping it does not resolve the problem either, also putting connection parameter into quotes.


$ dgmgrl "sys/Secret$124@db12c"
DGMGRL for Linux: Version 12.1.0.2.0 - 64bit Production

Copyright (c) 2000, 2013, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.


So the right way to test connection is:


$ dgmgrl
DGMGRL for Linux: Version 12.1.0.2.0 - 64bit Production

Copyright (c) 2000, 2013, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sysdg@sdb12c
Password:
Connected as SYSDG.
DGMGRL>
DGMGRL> connect sysdg@db12c
Password:
Connected as SYSDG.


Now let us perform switchover to standby and afterwards back to old primary:


$ dgmgrl
DGMGRL for Linux: Version 12.1.0.2.0 - 64bit Production

Copyright (c) 2000, 2013, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sysdg@db12c
Password:
Connected as SYSDG.
DGMGRL> validate database sdb12c;

  Database Role:     Physical standby database
  Primary Database:  db12c

  Ready for Switchover:  Yes
  Ready for Failover:    Yes (Primary Running)

  Flashback Database Status:
    db12c:   On
    sdb12c:  Off

DGMGRL> switchover to sdb12c;
Performing switchover NOW, please wait...
Operation requires a connection to instance "sdb12c" on database "sdb12c"
Connecting to instance "sdb12c"...
Connected as SYSDG.
New primary database "sdb12c" is opening...
Oracle Clusterware is restarting database "db12c" ...
Switchover succeeded, new primary is "sdb12c"


DGMGRL>  validate database db12c;

  Database Role:     Physical standby database
  Primary Database:  sdb12c

  Ready for Switchover:  Yes
  Ready for Failover:    Yes (Primary Running)

  Flashback Database Status:
    sdb12c:  Off
    db12c:   On

DGMGRL> switchover to db12c;
Performing switchover NOW, please wait...
Operation requires a connection to instance "db12c" on database "db12c"
Connecting to instance "db12c"...
Connected as SYSDG.
New primary database "db12c" is opening...
Oracle Clusterware is restarting database "sdb12c" ...
Switchover succeeded, new primary is "db12c"


On Oracle support site there are several notes regarding the ORA-1017 error. So it is a good idea to check them in case that your problem is not as described above.

It is mandatory to test also the static connection identifiers names "StaticConnectIdentifier" which are part of the DG configuration. Do this for primary and standby database.


DGMGRL> show database verbose db12c;

Database - db12c

  Role:               PRIMARY
  Intended State:     TRANSPORT-ON
  Instance(s):
    db12c

  Properties:
    DGConnectIdentifier             = 'db12c'
    ObserverConnectIdentifier       = ''
    LogXptMode                      = 'ASYNC'
    RedoRoutes                      = ''
    DelayMins                       = '0'
    Binding                         = 'optional'
    MaxFailure                      = '0'
    MaxConnections                  = '1'
    ReopenSecs                      = '300'
    NetTimeout                      = '30'
    RedoCompression                 = 'DISABLE'
    LogShipping                     = 'ON'
    PreferredApplyInstance          = ''
    ApplyInstanceTimeout            = '0'
    ApplyLagThreshold               = '0'
    TransportLagThreshold           = '0'
    TransportDisconnectedThreshold  = '30'
    ApplyParallel                   = 'AUTO'
    StandbyFileManagement           = 'MANUAL'
    ArchiveLagTarget                = '0'
    LogArchiveMaxProcesses          = '4'
    LogArchiveMinSucceedDest        = '1'
    DbFileNameConvert               = ''
    LogFileNameConvert              = ''
    FastStartFailoverTarget         = ''
    InconsistentProperties          = '(monitor)'
    InconsistentLogXptProps         = '(monitor)'
    SendQEntries                    = '(monitor)'
    LogXptStatus                    = '(monitor)'
    RecvQEntries                    = '(monitor)'
    StaticConnectIdentifier         = '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.110)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=db12c_DGMGRL)(INSTANCE_NAME=db12c)(SERVER=DEDICATED)))'
    StandbyArchiveLocation          = 'USE_DB_RECOVERY_FILE_DEST'
    AlternateLocation               = ''
    LogArchiveTrace                 = '0'
    LogArchiveFormat                = '%t_%s_%r.dbf'
    TopWaitEvents                   = '(monitor)'

Database Status:
SUCCESS

DGMGRL> connect sysdg@'(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.110)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=db12c_DGMGRL)(INSTANCE_NAME=db12c)(SERVER=DEDICATED)))';
Password:
Connected as SYSDG.

DGMGRL> connect sysdg@"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.110)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=db12c_DGMGRL)(INSTANCE_NAME=db12c)(SERVER=DEDICATED)))"
Password:
Connected as SYSDG.


It is mandatory to put the value of StaticConnectIdentifier in single or double quotes.

Of course you can use SYS user to perform switchover operation. Again, connect via SQL*Net (as being remote) to be authenticated by password file. Needless to say that you have to have the right setup in litener.ora and tnsnames.ora for both databases. I found that the easiest way is to have static definition in listener.ora file:


LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = olinux)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = KEY1521))
    )
  )

SID_LIST_LISTENER =
 (SID_LIST =
  (SID_DESC =
    (GLOBAL_DBNAME = db12c_DGMGRL)
    (ORACLE_HOME = /u01/app/oracle/product/12.1.0/dbhome_1)
    (SID_NAME = db12c)
  )
  (SID_DESC =
    (GLOBAL_DBNAME = db12c)
    (ORACLE_HOME = /u01/app/oracle/product/12.1.0/dbhome_1)
    (SID_NAME = db12c)
  )
 )

Similar is for the standby database.

Conclusion:

Although one might think that the "validate database" command checks everything, it actually does not. Oracle could check also the connectivity during "validate database" command, but does not. So it is a big surprise when one encounters ORA-1017 error due to incomplete check performed by DG.


There is a document on Oracle support site "Oracle Data Guard Broker and Static Service Registration (Doc ID 1387859.1)" about configuring DGB and static connection identifiers.
As per this document the requirement for

Single Instance Database with Oracle Restart

Here there is no cluster, but clusterware has been installed to enable the Oracle Restart feature. The local listener LISTENER has its LISTENER.ORA located in the /network/admin directory of the Oracle Grid Infrastructure home. In this case the static service registration is:

SID_LIST_LISTENER=
  (SID_LIST=
    (SID_DESC=
     (GLOBAL_DBNAME=db_unique_name_DGMGRL.db_domain)
     (ORACLE_HOME=oracle_home)
     (SID_NAME=sid_name)
    )
  )

As with Single Instance databases, the SID_NAME value sid_name will default to the db_unique_name.



Updated on Jan 23nd 2017.

"ORA-16047 - DGID mismatch between destination setting and target database" while configuring dataguard.

While setting up dataguard configuration you may encounter ORA-16047 - DGID mismatch between destination setting and target database.

From alert.log on primary database:

******************************************************************
LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
******************************************************************
Sat Dec 31 08:29:30 2016
FAL[server, ARC3]: Error 16047 creating remote archivelog file 'sauxmes'
FAL[server, ARC3]: FAL archive failed, see trace file.
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance auxmes - Archival Error. Archiver continuing.
Error 16047 for archive log file 2 to 'sauxmes'
Errors in file /u01/app/xxxxx/diag/rdbms/auxmes/auxmes/trace/auxmes_nsa2_9525.trc:
ORA-16047: DGID mismatch between destination setting and target database
Sat Dec 31 08:30:12 2016
PING[ARC1]: Heartbeat failed to connect to standby 'sauxmes'. Error is 16047.
Sat Dec 31 08:33:39 2016
PING[ARC1]: Heartbeat failed to connect to standby 'sauxmes'. Error is 16047.
Sat Dec 31 08:37:12 2016
PING[ARC1]: Heartbeat failed to connect to standby 'sauxmes'. Error is 16047.


Solution:
Check the configuration on STANDBY side in parameter log_archive_config:

SQL> show parameter log_archive_config  

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_config                   string
 
Most likely it will not be set. Therefore set it to appropriate value like:

alter system set LOG_ARCHIVE_CONFIG='DG_CONFIG=(auxmes,sauxmes)';

This will resolve the problem and the redo transport will start working.

Another possibility for getting this kind of error is if you didn't set parameter DB_UNIQUE_NAME on standby database (must be different from the name on primary site):

alter system set DB_UNIQUE_NAME="sauxmes" scope=spfile;  

and then you need to restart the standby database as this parameter can't be dynamically set.

Maintaining Tempfile in TEMP Tablespace of PDB$SEED in Oracle 12c (12.1.0.2)

During testing recovery procedures for one of the ongoing projects I wanted to test the "complete disaster" recovery scenario. In this scenario I had to recreate also all ASM disks and restore everything from backup.
Actually full backup with RMAN and subsequent restore of a pluggable 12c single-tenant database  was the solution. I will not talk about that as the main point of this post is quite different.

So the recovery was successful but after restoring  the CDB$ROOT and PDB database I found in the alert log the following message:


Errors in file /u01/app/oracle/diag/rdbms/mydb/mydb/trace/mydb_dbw0_28973.trc:
ORA-01157: cannot identify/lock data file 202 - see DBWR trace file
ORA-01110: data file 202: '+DATA/MYDB/FD9AC20F64D244D7E043B6A9E80A2F2F/DATAFILE/pdbseed_temp012015-01-03_12-22-30-pm.dbf'
ORA-17503: ksfdopn:2 Failed to open file +DATA/MYDB/FD9AC20F64D244D7E043B6A9E80A2F2F/DATAFILE/pdbseed_temp012015-01-03_12-22-30-pm.dbf
ORA-15173: entry 'FD9AC20F64D244D7E043B6A9E80A2F2F' does not exist in directory 'MYDB'
Thu Feb 05 09:12:52 2015
Errors in file /u01/app/oracle/diag/rdbms/mydb/mydb/trace/mydb_dbw0_28973.trc:
ORA-01186: file 202 failed verification tests
ORA-01157: cannot identify/lock data file 202 - see DBWR trace file
ORA-01110: data file 202: '+DATA/MYDB/FD9AC20F64D244D7E043B6A9E80A2F2F/DATAFILE/pdbseed_temp012015-01-03_12-22-30-pm.dbf'


The problem was the temp file of the temporary tablespace TEMP in PDB$SEED which is used for creation of pluggable databases. The tempfiles are not part of RMAN backup as they can always be recreated. Although I could live with this error messages as this is single-tennat database with only one pluggable database I wanted to deliver a "clean solution" to the client. Besides I wanted to know how I can solve such problem.

So here is the solution:

$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on Thu Feb 5 09:35:11 2015

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


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Advanced Analytics
and Real Application Testing options

SQL> alter session set container=pdb$seed;

Session altered.

SQL> select open_mode from v$database;

OPEN_MODE
--------------------
READ ONLY


SQL> select name from v$tempfile;

NAME
---------------------------------------------------------------------------------------------------
+DATA/MYDB/FD9AC20F64D244D7E043B6A9E80A2F2F/DATAFILE/pdbseed_temp012015-01-03_12-22-30-pm.dbf


SQL> alter pluggable database pdb$seed close;
alter pluggable database pdb$seed close
*
ERROR at line 1:
ORA-65017: seed pluggable database may not be dropped or altered


SQL> alter session set "_oracle_script"=TRUE;

Session altered.

SQL> alter pluggable database pdb$seed close;

Pluggable database altered.

SQL> alter pluggable database pdb$seed open read write;

Pluggable database altered.

SQL> alter tablespace temp add tempfile '+DATA';

Tablespace altered.
SQL> column name format a100
SQL> select name from v$tempfile;

NAME
-------------------------------------------------------------------------------------------------
+DATA/MYDB/FD9AC20F64D244D7E043B6A9E80A2F2F/DATAFILE/pdbseed_temp012015-01-03_12-22-30-pm.dbf
+DATA/MYDB/0BBEAC43B4250445E0530A0C6D0AEC65/TEMPFILE/temp.299.870860375

SQL>  alter tablespace temp drop tempfile '+DATA/MYDB/FD9AC20F64D244D7E043B6A9E80A2F2F/DATAFILE/pdbseed_temp012015-01-03_12-22-30-pm.dbf';


Tablespace altered.

SQL>  select name from v$tempfile;

NAME
----------------------------------------------------------------------------
+DATA/MYDB/0BBEAC43B4250445E0530A0C6D0AEC65/TEMPFILE/temp.299.870860375



After performed change there were no more error messages during database startup.

The secrete sauce for changing the state of PDB$SEED was setting "alter session set "_oracle_script"=TRUE;". The idea came from this post about changing the open mode of the PDB$SEED database.
Hope this short post will help somebody to resolve his problem with dropping and creating new tempfile in PDB$SEED faster.

Finding Oracle VM Manager Core Management Port After OVM Manager Installation

Recently I was working on integration of OVM Manager with Oracle EM Cloud Control 12cR4 and I had to enter the "Oracle VM Manager URL" a.k.a. as "Core management port" which is reported at the end of OVM Manager installation. The default value for this port is 54321. As I was not in position to get this post-installation report because the installation was performed by another company, I had to find out the right port. The definition should be entered in the form: tcp://:.

EM Cloud Control and OVM Manager Integration Screen

OVM Manager Installation report sample

One of the the first ideas was to check local firewall configuration and see if there is anything for port 54321.

# iptables -L | grep 5432
ACCEPT     tcp  --  anywhere  anywhere   state NEW tcp dpt:54322

Search showed opened port 54322 which could also be one of the possibilities.
Searching with netstat revealed no acctivity on port 54322

# netstat -vatn | grep 54322

However, a lot of rows was returned when searching for port 54321:

# netstat -vatn | grep 54321
tcp        0      0 ::ffff:127.0.0.1:54321      :::*                        LISTEN
tcp        0      0 ::ffff:127.0.0.1:36797      ::ffff:127.0.0.1:54321      ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:51828      ::ffff:127.0.0.1:54321      ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:53096      ::ffff:127.0.0.1:54321      ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:55461      ::ffff:127.0.0.1:54321      ESTABLISHED
tcp        0      0 ::ffff:127.0.0.1:53017      ::ffff:127.0.0.1:54321      ESTABLISHED


But I was still not 100% sure, if the iptables showed the right port. So further digging through the documentation revealed the right port. The definition of the "Core management port"  is hidden in .config file under the name COREPORT in OVM Manager home directory /u01/app/oracle/ovm-manager-3/.config

The contents of this file in my case was:

# cat  /u01/app/oracle/ovm-manager-3/.config

DBTYPE=MySQL
DBHOST=localhost
SID=ovs
LSNR=49500
OVSSCHEMA=ovs
APEX=8080
WLSADMIN=weblogic
OVSADMIN=admin
COREPORT=54321
UUID=0004fb000001000075e54bae74172d82
BUILDID=3.3.1.1065


The explanation for the configuration items can be found in chapter "5.1 Backing up and Restoring Oracle VM Manager"  and obviously in my case the port used was actually the default one 54321.
The .config file should be part of the backup.

Hope this post will shorten search time for this kind of information to my readers.

Using Hyphen In OS Username Or ORACLE_HOME Path in Oracle 12c Database Installation Will Make You Cry

Recently I was involved in an upgrade project on Linux platforms to Oracle 12c (12.1.0.2) and the customer wanted to name the owners of the Oracle SW distribution according to their company standard. So instead of using "grid"  and "oracle" OS account names they wanted to have the names which would start with "svc-" and continue with unique non Oracle standard name for either grid infrastructure or database software. Besides using this names as owners of grid and database software we used them also in the names of the GRID_HOME and ORACLE_HOME directories according to Oracle OFA suggestion.

So no problems with those names during installation and database creation. However, when  we wanted to patch the grid infrastructure and Oracle home with latest patches, the Opatch utility returned with an error that it can't parse the path to Oracle grid infrastructure. I immediately recognized the problem and the only remedy was to uninstall both grid and database SW. And then bang, another surprise, the Oracle 12c deinstallation procedures crashed as well. This time the reason was in checking the ownership of the distribution (grid or oracle).

The regular expression used to find the owner of the distribution in the script is /.*?\((\w+)\).*/
String returned by "id" command is:

uid=211(svc-xxxyyy) gid=201(oinstall) groups=201(oinstall), 200(dba), 205(asmadmin), 206(asmdba), 207(asmoper), 110000513(domain users) 

The $1 returned variable gets value "oinstall" instead of svc-xxxyyy and this causes deinstalltion script to fail.  The right expression would be /.*?\((\w+\-\w+)\).*/


So how one can manually deinstall database home and grid infrastructure home? For ORACLE_HOME deinstallation one can follow Doc.ID 1624580.1 and run:

cd $ORACLE_HOME/oui/bin
./runInstaller -silent -detachHome ORACLE_HOME="/u01/app/svc-xxxyyy/product/12.1.0/dbhome_1" ORACLE_HOME_NAME="OraDB12Home1"

This operation succeeded without any problems. Deinstalling GRID_HOME was slightly more complicated and actually at the moment of writing this post there is no document on MOS relevant for manual deinstallation of grid infrastructure with configured Oracle Restart. The suggestion from Oracle support was to follow "How to Deinstall Oracle Clusterware Home Manually ( Doc ID 1364419.1 )" which was relevant for 11gR2 but not 12c. Actually I have performed the deinstalltion in two steps:

# roothas.sh -deconfig -force
$ runInstaller -detachHome -silent -local ORACLE_HOME=$ORACLE_HOME

The $ORACLE_HOME in this case was actually pointing to GRID_HOME.

Why I said in the title that this will make you cry - because you have to start it all over again and the Oracle Installer doesn't warn you about the problematic hyphen  during the installation process when all prerequisites are run.

So after being working so many years with Oracle products I was really angry with myself that I was caught on such stupid mistake.

Internet Explorer Can Not Access Database Console Page - Certficate Error

Microsoft recently launched a security patch for Internet Explorer which requires a 1024 bits long key. Originally when the EM Database Control (DB Console) was installed  the self generated key  length is 512 bits.

The IE therefore reports a problem with the web site (EM) certificate.

Oracle has recently published a note on My Oracle Support (MOS) under ID 1498203.1

"Log In To Grid Control Console 10g or DB Control 10g and 11g within Internet Explorer 7, 8 or 9 fails with "Internet Explorer cannot display this page" or with Security Certificate Error".

Actually one has to patch the EM in order to be able to increase the key length to 1024 bits. The command which should be used is:

emctl secure dbconsole -key_strength 1024 -reset

However, without first applying the Patch 14503114 one will get error that the parameter -key_strength is not supported. So in order to resolve the problem patch has to be applied.

The other possible workaround is to use another browser which is satisfied with 512 bits long key. Google Chrome and Firefox work just perfectly.