Tuesday 28 August 2012

Automatic Diagnostic Repository Command Interpreter: ADRCI in Oracle 11g



 We go to bdump and access the alert.log file whenever we have to analyze an issue in the database.
However In 11g, RDBMS diagnostic data has been reorganized and is stored inside a common directory structure, the Automatic Diagnostic Repository (ADR). An ADR is a centralized directory structure where one can find trace files, alert messages, incident dumps, core files, etc. This parameter is set by DIAGNOSTIC_DEST initialization parameter.

You will find the following directories under ADR HOME -

Alert : The alert directory contains the XML alert log

Cdump : core dumps are stored in this directory

Trace : Process trace files and Alert.log are stored in the trace directory. 'Background_dump_dest' and 'user_dump_dest' are now ignored in 11g. Now all the trace files will be generated in 'trace' directory.

Incident : The incident directory stores dump files created when critical errors are encountered.
Each occurrence of a critical error( incident ) is given its own incident directory, with the incident ID used to form the directory name.

Metadata : The metadata directory stores a series of files that contain diagnostic metadata.

HM : The hm directory stores reports for health checks

Incpkg, ir, lck, sweep : These directories contain internal diagnosability framework state.


ADRCI is the command line utility using which ADR is accessed.



----  To view the alert log file:

Example

$ adrci

ADRCI: Release 11.2.0.2.0 - Production on Wed Aug 1 12:02

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

ADR base = “/d01/app/oracle”

ADRCI > show alert –tail –f


---- ADRCI can also be used to track a problem and an incident:

Example: Whenever there is a problem recorded in the alert log file, we also get a message stating: Use ADRCI or Support Workbench to package the incident. Adrci can be used to know more about the problem and the incident:

ADRCI > show problem

ADRCI > show incident

ADRCI > show incident -mode detail -p "incident_id="
 
 
 
---- ADRCI can also be used for :
 
-       Incident Packaging Service (IPS):  To send details of the problem to oracle support through a package or a zip file.
 
-       Purge trace files. Example: ADRCI> purge –age 1440 –type trace (1440 is minutes, ie, one day. So all trace files older than 1 day will be purged).

Sunday 5 August 2012

Issue: Concurrent request running from a very long time


.
Application version: 11.5.10.2 multi-node (4 nodes)
Database: 11g RAC


Scenario:

Business critical concurrent request is running from more than 2 hours which was supposed to complete within 1 hour.
The standard manager and the manager responsible to execute the critical concurrent request (custom manager) were overloaded with many requests. The server on which these managers run had very high server load and all CPU’s were utilized.

After diagnosis, we had to kill few requests which were running from more than 2 hours and were creating load on the server. These requests were in fact not performing anything and had gone zombie.

The server load came down and CPU’s available were set free to execute new requests/processes.

However the business critical request was still running and wasn’t moving ahead at all. The database session associated was also not executing anything.

Challenge:

Since this being a critical business request, we couldn’t terminate the request coz we had already lost few hours running it. At the same time the database session also wasn’t performing any execution and the whole request was not going anywhere even though it showed running normal status.

Trick:

Not recommended, however can be a life saver at times.

---- Forcibly change the status of the request to pending normal.
---- Kill the database session of the request.

Use the below scripts:

update applsys.fnd_concurrent_requests set phase_code = 'P',
                                           status_code = 'I',
                                           actual_start_date = null,
                                           crm_release_date = null,
                                           controlling_manager=null,
                                           logfile_name = null,
                                           logfile_node_name = null,
                                           outfile_name = null,
                                           outfile_node_name = null,
                                           crm_tstmp = null
where request_id in ('request-id');


             alter system kill session 'sid, serial#, @instance-id';


Hence a new database session will get created as soon as the old one is killed and the request starts running. Since the server on which the request is supposed to get processed also had no issues now, the request went through very fast without any issues ;)

Thursday 2 August 2012

Apache issue after installing EBS R12 on Linux x86


EBS R12 installed on a Red Hat Enterprise Linux AS release 4 (2.6.9-5.EL)

After the install, when trying to start up the http server, this happens:

$./adapcctl.sh start
.
You are running adapcctl.sh version 120.6
.
Starting OPMN managed Oracle HTTP Server (OHS) instance ...
.
adapcctl.sh: exiting with status 204 
.
adapcctl.sh: check the logfile
$INST_TOP/apps/CONTEXT_NAME/logs/appl/admin/log/adapcctl.txt for more information.

Workaround:

Remove the parameter -DSSL in the ohs_start() function as follows:
.
$/<?>ora/10.1.3/Apache/Apache/bin/apachectl:

$ diff apachectl.original apachectl.mine

129c129,130
> eval ohs_start -DSSL "$args"
---
> # eval ohs_start -DSSL "$args"
> eval ohs_start "$args"

Restart Apache.

This is however a temporary solution. The main problem is due to not Installing all the Linux RPMS as per the R12 installation document (Note.402310.1). This has to be implemented so as to have a permanent workaround.

Wednesday 1 August 2012

Very interesting changes in Oracle EBS 12.2


There are 3 interesting changes in Oracle EBS 12.2 version:


One : The 10g oc4j (oracle containers for java) is replaced with 11g web logic server.


The EBS 12.2 Internal technology stack will have Fusion middleware 11g components: web logic server, web logic JSP and UIX 11g.


Two: Oracle 11g release 2 (11gR2 database) Edition- Based redefinition supports online patching.


                                          The database component of the EBS application can be upgraded while all the Application services are up and running and   while those components are in use by the connected application users. This enables upgrade of the application component without a downtime.

The database objects/components to be upgraded are done so by copying it to a different location and when all looks fine it’s made available to the application users replacing the old ones.

Online Patching is done to the EBS 12.2 while the application is up and running and later  requiring a minimal downtime to complete the patching process.


Three:  Oracle Single sign-on will not be certified in EBS 12.2


Users on Oracle Single sign-on will have to migrate to Oracle access manager as EBS 12.2 will not be certified with Single sign-on.


Reference: Steven chan's Blog