Sunday 26 February 2012

Autoconfig basics

Oracle AutoConfig in Oracle Applications

AutoConfig is the tool, which is used to configure oracle application systems. AutoConfig uses a file called context file, which is used to configure changes. Context file is a XML file having all the parameters of application system.These parameters are part of some configuration file for some services or it may be a part of some environment file. Each configuration file has one corresponding template file (provided by autoconfig patches, stored in $PROD_TOP/admin/template directory).Profile options and other instance specific information in the database is maintained by many sql scripts, called from wrapper shell/perl scripts. These scripts also have corresponding template files (also provided by autoconfig patches, `in $PROD_TOP/admin/templates). In these template files all the environment specific values are replaced by placeholders (like %s_webhost%). Environment specific values for this placeholder is stored in an environment specific xml file (called application context file) stored in $APPL_TOP/admin.

Eg,

Following entry in httpd.conf

Timeout 300 is replaced by following in its template $FND_TOP/admin/template/httpd_ux_ias1022.conf

Timeout %s_ohstimeout%

For the above placeholder the value stored in the xml file is:

<ohstimeout oa_var=”s_ohstimeout”>300</ohstimeout>

Each placeholder has a corresponding xml node in the context file. The placeholder name is the value for the “oa_var” attribute of the xml node, the placeholder name without the prefix “s_” (generally) is the node name for the xml node and the value is stored as a child text node. These xml nodes are termed as context variables by Oracle documentation and each node primarily is identified by its oa_var attribute value. So effectively we can say that in the above case we replace “300″ by context variable “ohstimeout” whose oa_var value is “s_ohstimeout”. Configuration files can be easily created from the template file by just replacing all the placeholders with the corresponding values from the context file. This process is termed as “instantiating the template” in Oracle documentation.

Driver files (stored in $PROD_TOP/admin/driver) store information about what to do with each template (e.g. instantiate it and replace the existing configuration file with it, instantiate it and run it). These files are named as <PROD_TOP>tmpl.drv (e.g. adtmpl.drv, fndtmpl.drv etc.) They contain one line for each template they manage.

When autoconfig (adconfig.pl or adconfig.sh) runs it just processes the driver file for each product, line by line doing what the driver file instructs it to do. The order of execution of each line is not sequential.

Sunday 19 February 2012

Compile Form,Pll with compile_all in Oracle R12

frmcmp_batch userid=apps/apps module=$AU_TOP/forms/US/FORM_name.fmb  output_file=$PRODUCT_TOP/forms/US/FORM_name.fmx
module_type=form compile_all=special



frmcmp_batch userid=apps/apps module=<Name_of_pll_file> output_file=<Name_of_plx_file>
module_type=library compile_all=special




Why compile forms with compile_all=special

compile_all=special was originally introduced as a workaround for a bug that was fixed some time ago.

The main reason it is still recommended for Oracle Applications is due to the way attached libraries are inherited from other attached libraries, and the difficulties in subsequently removing them if added by mistake.

For example, if a new library is attached to CUSTOM.pll, that library also becomes directly attached to every form or library that has CUSTOM.pll attached, once the higher level object has been re-compiled.

With compile_all=yes, the new library would end up attached to both the source and generated objects, and removing it would be extremely difficult: as well as removing it from CUSTOM.pll, you would have to remove it from every library or form that had CUSTOM.pll attached.

With compile_all=special, the source is not updated, and only the generated files (.plx and .fmx) have the new library attached.

In the case where someone has mistakenly attached a library to CUSTOM.pll, (for example when they do not follow Oracle customization standards, and attach an Applications product library), you simply need to delete it from CUSTOM.pll, regenerate all the forms and libraries, and it will be gone.

If you never customize, or if you follow the standards documented in the Oracle Applications Developer's Guide, the use of compile_all=yes should never cause this kind of problem, but Oracle still recommends that you use compile_all=special.

If you open and save a form or library in the builder, it will inherit any new library attachments from its sub-libraries in the same way as if it was generated with compile_all=yes.

Wednesday 1 February 2012

SMON_SCN_TO_TIME_AUX - CLUSTER

How to Reorg the object SMON_SCN_TO_TIME_AUX . The object type is CLUSTER.

Please test the steps on test environment first.

Take Backup
export ORACLE_SID=dev
export ORACLE_HOME=/ora_DEV/app/oracle/product/11.2.0/prodclone/dbhome_1
rman target /
run {
allocate channel ch1 device type disk;
allocate channel ch2 device type disk;
crosscheck archivelog all;
crosscheck backup of database;
delete expired backup of database ;
backup full tag full_db_bkp_dev format '/ora_DEV/PROD_STAGE/RMAN_DBF_%d_%T_%s_%p_%u.bkp' (database);
sql 'alter system archive log current';
backup format '/ora_DEV/PROD_STAGE/RMAN_ARCH_%d_%T_%s_%p_%u.bkp' archivelog all;
backup format '/ora_DEV/PROD_STAGE/RMAN_CTL_%d_%T_%s_%p_%u.bkp' current controlfile;
release channel ch1;
release channel ch2;
}

shutdown immediate

startup restrict

# Enable event 12500. Setting the 12500 event at system level should stop SMON from updating the SMON_SCN_TIME table.

alter system set events '12500 trace name context forever, level 10';

# Truncate the cluster SMON_SCN_TO_TIME

truncate cluster SMON_SCN_TO_TIME_AUX;

Rebuild the indexes
alter index SMON_SCN_TO_TIME_IDX rebuild;
alter index SMON_SCN_TO_TIME_AUX_IDX rebuild;
alter index SMON_SCN_TIME_TIM_IDX rebuild;
alter index SMON_SCN_TIME_SCN_IDX rebuild;

# Analyze the table to confirm it is clean

analyze table SMON_SCN_TIME validate structure cascade;

# Disable the event 12500 so SMON can resume updating the SMON_SCN_TIME table.

alter system set events '12500 trace name context off';

# Disable restricted session:

alter system disable restricted session;

shutdown immediate

startup