While installing VM Manager 2.1.5 today an error occurred during the install. I’m using an existing database instead of Oracle XE and its version 11.2.0.1.
Deploying Oracle VM Manager application to OC4J container.
Creating connection pool … Failed
Please see /var/log/ovm-manager/oc4j.log for more information.
From the oc4j.log:
2011-03-30 15:01:36.381 WARNING J2EE DS-00001 Exception occurred testing connection. Exception: java.sql.SQLException: ORA-01017: invalid username/password; logon denied
Nothing turned up on Metalink. It didn’t make much sense to me until I remember that passwords by default in 11g are case sensitive. I disabled the feature by issuing:
SQL> alter system set SEC_CASE_SENSITIVE_LOGON=false scope=spfile;
and restarted the database. When I tried to install VM Manager again it was successful. I plan to upgrade it to the latest version, 2.2.1 and will check to see if that version supports case insensitivity.
Tuesday
Weblogic–Patching with the Smart Update utility
We currently use Grid Control 10g to monitor some of our environments. Its running on a server that needs to be decommissioned so I decided to go ahead and install 11g and migrate the setup.
Grid Control 11g requires Weblogic, which I have installed many times and while going through the install guide for Grid Control 11g I noticed that you need to apply patch ID WDJ7.
I’ve never patched a weblogic environment before (although its on my list to do since I need to apply security patches to some other environments). My initial thought was “Oh great”, expecting it not to be a simple straightforward process or to encounter issues during the install. My background is as an e-Business Suite DBA. The EBS dba’s out there can certainly understand where I’m coming from. (Although I have to say, even EBS has improved over the years.)
Anyways, long story short, I expected patching Weblogic to be complicated but I was pleasantly surprised to find that its very simple. My environment is 64bit linux. The first step is to launch the Smart Update utility by executing $BEA_HOME/utils/bsu/bsu.sh.
Note: This is an X based application, so you’ll need to make sure your DISPLAY environment variable is set appropriately. After you login with your Metalink account information, the first screen you’ll see is:
Click on the Get Patches tab:
As you can see above I selected the patch required WDJ7 as well as the latest CPU Advisory. Once you click on the Download Selected button you’ll be presented with a few screens before the download actually happens.
Once the download has finished you’ll be brought back to the Smart Update utilities main screen.
Notice that even tho only two updates were selected to be downloaded, there are quite a few listed. Click on the Manage Patches tab:
Click on the Apply button to the right of the patch you’d like to install. Before you do that notice the icons next to the Patch ID and Description columns. The Smart Update utility seems to break apart the patches to show the individual bugs addressed. If you click on the apply button next to 4D53 for example, you’ll be prompted with:
So 4D53 is part of WDJ7 and could be applied separately if you wanted to. Notice that the icon to the left of WDJ7 is layered which means it’s a patch set. If you click on the apply button next to WDJ7, all the patches included in the patch set will be applied at the same time. In the case of WDJ7 that includes 4D53, NIXN and XLXA.
I’ve tried removing just a single patch included with WDJ7 and reapplying it with no issues. That’s pretty cool. Potentially if you hit an issue with a particular patch breaking something you can easily remove it.
Once all the patches are applied:
That’s it.
Grid Control 11g requires Weblogic, which I have installed many times and while going through the install guide for Grid Control 11g I noticed that you need to apply patch ID WDJ7.
I’ve never patched a weblogic environment before (although its on my list to do since I need to apply security patches to some other environments). My initial thought was “Oh great”, expecting it not to be a simple straightforward process or to encounter issues during the install. My background is as an e-Business Suite DBA. The EBS dba’s out there can certainly understand where I’m coming from. (Although I have to say, even EBS has improved over the years.)
Anyways, long story short, I expected patching Weblogic to be complicated but I was pleasantly surprised to find that its very simple. My environment is 64bit linux. The first step is to launch the Smart Update utility by executing $BEA_HOME/utils/bsu/bsu.sh.
Note: This is an X based application, so you’ll need to make sure your DISPLAY environment variable is set appropriately. After you login with your Metalink account information, the first screen you’ll see is:
Click on the Get Patches tab:
As you can see above I selected the patch required WDJ7 as well as the latest CPU Advisory. Once you click on the Download Selected button you’ll be presented with a few screens before the download actually happens.
Once the download has finished you’ll be brought back to the Smart Update utilities main screen.
Notice that even tho only two updates were selected to be downloaded, there are quite a few listed. Click on the Manage Patches tab:
Click on the Apply button to the right of the patch you’d like to install. Before you do that notice the icons next to the Patch ID and Description columns. The Smart Update utility seems to break apart the patches to show the individual bugs addressed. If you click on the apply button next to 4D53 for example, you’ll be prompted with:
So 4D53 is part of WDJ7 and could be applied separately if you wanted to. Notice that the icon to the left of WDJ7 is layered which means it’s a patch set. If you click on the apply button next to WDJ7, all the patches included in the patch set will be applied at the same time. In the case of WDJ7 that includes 4D53, NIXN and XLXA.
I’ve tried removing just a single patch included with WDJ7 and reapplying it with no issues. That’s pretty cool. Potentially if you hit an issue with a particular patch breaking something you can easily remove it.
Once all the patches are applied:
That’s it.
Friday
How to deregister the appsTier or dbTier.
During my upgrade from 32bit to 64bit, as described in my last post, I hit an unexpected issue. After migrating, the environment wouldn’t start up successfully. By successfully, I mean all services being available.
As part of my upgrade to 32bit I migrated the application to new servers, thus new server names, etc. I quickly noticed in FND_NODES, FND_DATABASES, tnsnames files, etc that there were still references to the old servers as well as the new. Since I already migrated the database I couldn’t use the standard way to deregister a tier.
Example, to deregister an application tier it is:
perl $AD_TOP/bin/adgentns.pl appspass=<APPSpwd> \
contextfile=<CONTEXT> –removeserver
So the question is, how do I deregister a tier if I’ve already moved it? Manually using the FND_NET_SERVICES package.
First execute the following query:
select NAME, SERVER_TYPE from FND_APP_SERVERS, FND_NODES where FND_APP_SERVERS.NODE_ID = FND_NODES.NODE_ID and SERVER_TYPE in ('DB',’APPS"’) and FND_NODES.NODE_NAME=upper('hostname');
Substitute hostname with the name of your old servers. Sample output:
NAME SERVER_TYPE
---------------------- ------------------------------
myserver_VIS_APPS APPS
myserver_VIS_DB DB
The next step is to call FND_NET_SERVICES.remove_server(SYSTEM_NAME, SERVER_NAME); to remove them. Example:
begin
FND_NET_SERVICES.remove_server( 'VIS', 'myserver_VIS_DB');
end;
begin
FND_NET_SERVICES.remove_server('VIS', ‘myserver_VIS_APPS');
end;
The last step is to run autoconfig on both the dbTier and appsTier.
Once I hit that issue, in my first development pass, I could have modified my steps to deregister the tiers. However, I didn’t want to modify the original environment in any way. Worst case scenario, if some issues were encountered during the migration or testing phase, I could rollback to the original environment.
Subscribe to:
Posts (Atom)