CCMCONNSTRING Registry Value Encryption - Password Change Scenario

Oracle has introduced encryption of the apps password in the registry value CCMCONNSTRING. I do not know exactly which patch introduces this change - FND.H / ATG.H / ATG.H RUP 4/ AD.I.4. Earlier the value used to be stored in an unencrypted fashion and once the apps password was changed, the DBA could manually go and update this value in plain text. This registry value is used by the concurrent managers at startup.

Of course, FNDCPASS would be used to change the 'APPS', 'APPLSYS' and 'APPS_MRC' passwords. However, in a multinode environment, some oracle documentation pointed out, that autoconfig needs to be run on each mid-tier, after changing the apps password using FNDCPASS on the database tier (this would require APPL_TOP to be available on db tier). The autoconfig would take care of apps password update in wdbsvr.app file and ccmconnstring registry value on the midtiers.

Autoconfig is time consuming, especially when you have more nodes and customized configuration files. So, I wanted to find an alternative to running autoconfig. After researching this problem for a little while, I came up with the following approach:

- Use CCMSETUP to update the ccmconnstring registry value.
- Manually update the wdbsvr.app file under $IAS_ORACLE_HOME/...

One can enter the password in plain text in CCMSETUP and save the changes which would in turn be saved in an encrypted format in the registry value by the CCMSETUP.

Troubleshooting Hints:

- Capture the value of ccmconnstring registry value before any change.
- In a multi-node environment, logon to a non-concurrent processing node and run the FNDCPASS.
- Capture the value of ccmconnstring registry value after the password change.
- No change in the encrypted values points to the fact that FNDCPASS does not update the ccmconnstring registry value.
- On the concurrent manager box, invoke ccmsetup and update the values and save. You will see the change in the encrypted value for ccmconnstring
- Bring up the concurrent managers and this works fine.

Thus, we achieved our goal of not running autoconfig and not recreating the concurrent manager service.

- Aravind Kamath

The system has not been taken off maintenance mode completely

A problem was reported by the users stating they are seeing the following warning message:

"The system has not been taken off maintenance mode completely"

When I started working on this issue, I made the following observations:

- Users with profile option "Self Service Personal Home Page mode" set to "Framework Only" saw this warning message when they logged in.
- Users with profile option ""Self Service Personal Home Page mode" set to "Personal Home Page" did not see this warning message.
- Not all users who have the "Self Service Personal Home Page Mode" set to "Framework Only" experienced this issue. About a third of users were not seeing this message.
- A patch was applied in our environment previously.
- A quick check from "adadmin" revealed that maintenance mode had been disabled.

As I continued to work on this issue, I found that the reason for this problem was that the apps services on mid-tiers were started after patching without disabling the maintenance mode. The Maintenance Mode was later disabled and the services on third mid-tier brought up. This was the reason users were experiencing the warning message.

Corrective Action: Bounce of online midtier services which were started before disabling the maintenance mode.

Troubleshooting tips:

A comparison of apache/jserv startup time stamp on each online box with the maintenance mode disabled time stamp in adadmin log would reveal whether or not apache/jserv was started before disabling maintenance mode. The corrective action will need to be applied to only those online midtiers where services were started before maintenance mode was disabled.

- Aravind Kamath

Maximum Dump File Size

In this post, I will share with you something related to the max_dump_file_size parameter that i came across sometime earlier...



There was a requirement from our IT team to increase the maximum allowed user trace file size from 50 MB (the trace files would max out at 50MB) to 500 MB. I took up the request from the developer and started working on this. Interestingly, I observed the max_dump_file_size was set to 102400. As a matter of fact, I was not part of the original team that set up the databases/instances I am currently maintaining, so i am not too sure about the history of why this parameter was set as 102400 in our environment.



Now, when the size is not described with a suffix eg., K (KB) or M (MB), the size is considered as maximum size in operating system blocks. I wanted to find out the operating system block size in our windows environment (though reverse engineering from the maxed out trace file would reveal 512 ). A quick check on the windows operating system revealed the logical size (cluster size) as 4K (4096 Bytes). However, the database files in our environment are on a mounted volume which is raw partition and hence it appears that oracle is using the physical block size - 512 bytes to calculate the max size. A select on the lebsz column of sys.x$kccle revealed the size of 512 bytes, which is also the size that oracle database is picking up.



So, in our environment the max trace file size was being calculated as follows, despite the windows cluster size being at 4K:



102400*512=52428800 bytes.



This would translate to 50MB.



- Aravind Kamath

About me and my upcoming posts

Hi,

This first post of mine is not apps dba tech stuff. Instead, I would like to add a couple of lines about myself. I have been in the IT industry for more than 6 years now and I have spent most of it as an Oracle Apps DBA. I have worked extensively with oracle applications, starting with version 11.5.3 all the way upto to 11.5.10. I also had a chance to explore 11.0.3, but quite frankly, i dont remember much of that now. I have dirtied my hands in maintaining oracle applications on various flavours of unix and red hat linux. In the last two years plus, I have been managing Oracle Applications on Windows platform, something that is not too common (Atleast I presume so).

What i intend to share with you is my experiences as an Apps DBA on Windows platform - some of the issues i have faced, solutions and troubleshooting. I am not assuming any level of proficiency in the audience of my blogs. Some of the things i write may feel very rudimentory to some of the readers but may be just the solution for some other reader. I will start publishing technical articles soon.. Watch out this space for my Apps DBA tech experiences.

Aravind Kamath Posral