Enable ReconfigProcessingEnable for Rac one-node

We’ve had issues with RAC one-node and OEM for a very long time.  One really vexing issue has to do with incorrect instance status after a relocation.

EM12c: Scan Listener Shows Down Status In EM Console After Relocation (Doc ID 1932744.1) has instructions for fixing the issue.  It boils down to this:

There is an OMS parameter called oracle.sysman.db.rac.ReconfigProcessingEnable that is not set under normal circumstances for Real Application Clusters because a OEM doesn’t need to keep track of which instance number is running on which host.  For R1 it’s a big deal.

The process boiled down to this:

On the OMS server, execute:

emctl set property -name oracle.sysman.db.rac.ReconfigProcessingEnable -value true

emctl get property -name oracle.sysman.db.rac.ReconfigProcessingEnable

Bounce the OMS server to pick up the configuration change.

If some of the systems still look like they’re having the instance-awareness problem run a clearstate on the remote host

emctl stop agent
emctl clearstate agent
emctl start agent
emctl upload agent
Posted in emctl | Tagged , , | Leave a comment

Your Oracle Home GUID may be wrong! Part 2

Thanks to Sean Connolly at Oracle for sharing this solution

My last post about the Oracle Home GUID emphasized the importance of changing the OH GUID prior to host discovery and EM agent installation.

What if it’s already done?

You can update specific values for individual OEM targets using emctl.

emctl control agent runCollection ${OHOME_NAME}:oracle_home oracle_home_config

In this case we need to update the repository value for oracle_home_config for target $OH_NAME of target type oracle_home.  Use emctl to get the correct name for that target.

> emctl config agent listtargets | grep [o]racle_home 
        | grep -v agent | grep -v sbin

[Ora11g_gridinfrahome1_2_myhost, oracle_home]
[OraDb11g_home1_1_myhost, oracle_home]

PROCEDURE

1. Run this query on the repository database and filter it for your host_name

SELECT target_name,
       host_name,
       oui_home_name,
       oui_home_guid
FROM  mgmt$oh_home_info
WHERE target_name NOT LIKE 'agent%'
AND    target_name NOT LIKE 'sbin%'
AND    host_name='&host_name'
ORDER BY target_name;

2. Change the Oracle Home GUID using the process outlined in the last post

3. Update the agent with the emctl command

emctl control agent runCollection ${OHOME_NAME}:oracle_home 
      oracle_home_config

4. Run the SQL query again and notice that the OUI_HOME_GUID has changed!

Posted in emctl, OEM 12c, Oracle Inventory | Tagged , , , | Leave a comment

Your Oracle Home GUID may be wrong!

Each database and clusterware Oracle Home has an inventory directory, and within that directory you’ll find a ContentsXML directory, just like you have in your Central Inventory.

Within ContentsXML directory is an interesting file named oraclehomeproperties.xml.

<GUID>12345678#.987653210</GUID>
 <HOME CRS="T"/>
 <ARU_PLATFORM_INFO>
 <ARU_ID>46</ARU_ID>
 <ARU_ID_DESCRIPTION>Linux x86
 </ARU_ID_DESCRIPTION>
 </ARU_PLATFORM_INFO>
 <CLUSTER_INFO>
 <LOCAL_NODE NAME="Ora123demo"/>
 <NODE_LIST>
 <NODE NAME="Ora123demo"/>
 <NODE NAME="Ora987demo"/>
 </NODE_LIST>
 </CLUSTER_INFO>

If you preinstall and patch your Oracle binaries on a VM template and then use a copy of that template as a starting place to build a new database server the Oracle Home GUID remains unchanged.  It creates a situation very much like failing to run nid after creating a cloned database:  Oracle tools that rely on those unique identifiers become confused.  Automation dies.

Oracle Enterprise Manager relies on the Oracle Home GUID as a unique identifier for the oracle_home target types.  Each of those targets must be uniquely identified by Oracle Home GUID for automated patching through OEM.

You can reset the Oracle Home GUID only be recreating the inventory entries for the Oracle Home in inventory.xml using the OUI runInstaller tool.  The home must be detached and then reattached using the generateGUID option.

This script attached (when modified for your environment) captures each Oracle Home entry in the inventory.xml for the database binary home and the clusterware home.

CAUTION:  You must change the Oracle Home GUIDs before host discovery in OEM.

If you’ve tried to work with the editor tool for blogs you’ll appreciate why I chose to insert the shell script as a file:

update_orainventory

Posted in OEM 12c, Oracle Inventory | Tagged , , , | Leave a comment

Attention to Detail – OEM R4 Agent Listing

The Manage Cloud Control | Agents page was always useful but for quickly identifying EM agent status.  Prior to Release 4 this page had static icons indicating problems with specific agents.  The page contained no hints about why the agents were in trouble, I’d highlight the broken agent’s row and then push the Unblock icon.  There was 50-50 chance that the agent was actually blocked but, as often as not, Resecuring the agent would fix the issue.  Haphazard?  Sure.  Effective?  Most times.

Starting in Release 4 those little trouble icons have some intelligence built into them!

R4AgentProblems

Each trouble indicator has two parts.  The little broken route icon on the left gives you the nature of the problem but, and this is the part I really like, if you press the billboard-carrying-robin icon,  genuine troubleshooting analysis kicks off.

R4AgentProblems_02R4AgentProblems_02detail

First it tells you what may be wrong and then it checks to see if its hunch was correct.  In this case the agent is unreachable because of a Block Counter mismatch between the agent and the OMS.  OEM has also verified that the problem isn’t with the agent’s upd-wn status. Need proof, OMS says, here’s what I checked and what I found.

In terms of size this is an awfully small physical change in the console, but it reduces the time to resolution significantly by performing the next two steps for you. That’s what automation is supposed to do.  Right?

The next example isn’t as colorful but it’s just as useful for when upload problems exist.

R4AgentProblems_03

R4AgentProblems_03detail

Posted in Uncategorized | Leave a comment

Update OEM Harvester after 12.1.0.4 Upgrade

After we upgraded our OMS environment we realized that our Harvester wasn’t uploading data to MOS anymore.  Of course, you say, you just replaced your former ORACLE_HOME with a new home for 12.1.0.4.

Procedure:

1. Download p5567658_120030_Linux-x86-64.zip or the latest OCM installer for your environment.  You’ll find a tab for downloading OCM on your front page in MOS.  While you are there you should also download the Quick Start guide.

2. Unzip that file in your OMS home, typically …Middleware/oms

3. cd into ccr/bin

4. Run setupCCR with your CSI number and the same email address you used to configure MOS connectivity in the OEM console

setupCCR -s 12345678 my_mos_user@somewhere.com

Uploads will now begin in the wee hours of tomorrow morning.  You can find the Harvester Job Status in the Job Activity page in OEM.

Update your environment variables that were set if you previously has Harvester working (ORACLE_HOME and ORACLE_CONFIG_HOME).  All prerequisites and a troubleshooting section are included in the OCM Installation and Administration Guide Doc #E48361-02.

Posted in Uncategorized | Leave a comment

Repair OID Server Properties Page

You can set and review your Oracke Identity Server setting in the 11g Enterprise Manager console for ODSM by opening the EM console for a server and clicking through to the Identity and Access Server oid1.  Once you’re on the EM page for the Oracle Identity Manager, click on Oracle Internet Directory drop-down, then select Administration, then Server Properties.  If all is well, you change things like anonymous binds and the LDAP ports.  When it’s broken the console will complain about null values that it won’t let you change.  

If you encounter that, log into the host as the ODSM binary owner and move into your $ORACLE_INSTANCE/bin directory – the location of your opmnctl executable.

You’ll need to use this syntax, adjusted for your world:

opmnctl updatecomponentregistration
-adminHost hostname
-adminPort weblogic_port
-adminUsername weblogic_admin
-componentType OID
-componentName compName
-Port non-sslport
-Sport sslport

You’ll end up with a giant string that looks something like this:

opmnctl updatecomponentregistration -adminHost <full-qualified hostname> -adminPort 7001 -adminUsername weblogic -componentType OID -componentName oid1 -port 49200 -sport 49201

When it completes it burps out “Command succeeded”.

Restart your Admin Server and OID processes (opmnctl stopall, opmnctl startall) to pick up the change.

Posted in LDAP, ODSM Oracle Directory Services Manager, opmnctl, updatecomponentregistration | Leave a comment

Edit ldifwrite output

You can export an LDAP tree for ODSM using the ldifwrite utility with this syntax:

ldifwrite basedn=”dc=oracle,dc=com” ldiffile=$HOME/ldifprod.lst connect=orcl verbose=true

 

Careful: Lines that start with a space are concatenated into the line before during ldif import.  Resist the temptation to unwrap those lines to make your file easier for people to read.

For instance, let’s say this appears in your ldifwrite file:

dn: cn=orcla,cn=OracleContext,dc=oracle,dc=com
orclnetdescstring: (DESCRIPTION=(ADDRESS_LIST=(address=(protocol=tcp)(port=152
 1)(host=demohost)))(CONNECT_DATA=(SID=orcla)))
objectclass: orclNetService
objectclass: top
orclnetdescname: 000:cn=DESCRIPTION_0
cn: orcla

The LDAP import tool will concatenate the third line (starting with ” 1)(host=”) onto the end of the second line during import.

Your formatting help, dear human, will break it.

 

 

Posted in LDAP, ODSM Oracle Directory Services Manager | Leave a comment