A new FNDCPASS Utility feature introduced in 11.5.10 RUP 3

A new FNDCPASS Utility feature introduced in 11.5.10 RUP 3 allows us to change



ORACLE EBS base product schema passwords with a single command line invocation.



We can have this feature if we are on 11i.ATG_PF.H Rollup 3 or higher or if we have applied



Oracle Critical Patch Update - January 2006.







Usage FNDCPASS [logon] 0 Y [system/password] ALLORACLE [new_password]



where



logon : The Oracle apps username/password.



system/password : The username and password for the SYSTEM DBA account.



new_password : The new password.



For example,



FNDCPASS apps/apps 0 Y system/manager ALLORACLE MYPW0RD







This change the passwords of all Oracle Application products schema's to MYPW0RD

To Find out the Workflow Mailer component status

To Find out the Workflow Mailer component status from DATABASE using sqlplus



select COMPONENT_NAME , STARTUP_MODE, COMPONENT_STATUS

from fnd_svc_components where concurrent_queue_id in (select concurrent_queue_id from fnd_concurrent_queues where concurrent_queue_name like 'WF%')

order by COMPONENT_TYPE, COMPONENT_ID

Few things ORACLE Application Patching

Few things ORACLE Application Patching

xxx===========xxxxxxxxx===============xxx



Structure of ORACLE Applications (EBSO ) patches

In Applications patches there are usually three patch drivers.

> c[patch number].drv - which drives the copy actions for the patch and links executables.

> d[patch number].drv - this drives the database changes, by sql scripts and programs that change the data or objects of the database.

This driver is optional and will be included only if there is some change to the database objects.

> g[patch number].drv - is the generate driver which generates forms/reports/message files

This driver is optional and will be included only if there is some change to forms/reports/message files



Most the "next-generation" patches are coming out with three-in-one drivers or called as unified drivers.



>u[patch number].drv - no changes but performs functions of all the three drivers



:) a great help in patch automations.



Patching Utilities

xxx===========xxxxxxxxx===============xxx

In ORACLE Apps patches are applied by using few utilities designed specifically for that purpose.

Couple of them are run from the command line, and few Web-based.

Currently i wish to discuss few utilities. Will try to put in more descriptions in coming posts.



Command Line Utilities

AutoPatch (adpatch)

When we have to apply patches to ORACLE Applications, the first word we remember is adpatch,

this is a utility that automates most of the patching tasks for ORACLE Applications.

and it used to apply patches to the Oracle Applications file system or database.



But Its never used to apply any patches on Technology Components for e.g. ORACLE RDBMS Software, iAS, or Developer Suite tools.

that's done another utility opatch - (will discuss later. )



One biggest advantage of adpatch is that its version checking capability .

It ensure that the file with the latest version is used, determined by comparing what is present on file system and what the new patch contains.

A record of the applied patches are stored in database tables.

If there are multiple languages installed, then autopatch notifies we to apply the nls patch also .

adpatch can check for pre-requisites patches , whether they are applied or not.





Some of the options that can be used to change the standard behavior of adpatch



hotpatch = apply the patch without setting it in Maintenance mode , kind of online patching.

noprereq = will not check for pre-reqs (as of AD.I.4, by default, patching will not check for pre-reqs,

need to run OAM patching wizard for prereqs)

nodatabaseportion = not to run the DB portion

nocopyportion= not to execute the copy driver portion

nogenerateportion=not to execute the generate driver portion

nocompiledb= when we wish not to compile the invalid objects after the patch application

noautoconfig = specify autopatch that we do not wish to run autoconfig as a part of the patch application

nocheckfile= to skip check for already executed exec, SQL, and execution commands (can cause performance overheads )

nocompilejsp= when we wish not to compile the the java server pages (jsp) after the patch application

nohidepw = not to hide the passwords from the log file, use this only when you need to debug, and never in prod env.





Running a patch in different modes

we can apply a patch in TEST mode using adpatch.

when we use test mode it does not do any changes, but generates a log file with all the actions it would have performed in actual execution.

$adpatch apply=n



Pre-install Mode

we can also apply a patch in pre install mode, normally during an upgrade or consolidated update.

used only when we need to upgrade the files be for actual update, it checks for files versions, file copy (copies all files to APPL_TOP), relink fnd and ad executables,

saves the patch history info to the file system.



$adpatch preinstall=y





A Sample command (UNIX) would be





adpatch driver=u*******.drv logfile=u*******_`echo $TWO_TASK`_`date '+%d%B%Y_%H_%M_%S'`.log options=hotpatch, noprereq,novalidate,nodatabaseportion



You can use default file also to make application of multiple patches easier.

Will discuss this at a later point of time.





xxx===========xxxxxxxxx===============xxx



AD Merge Patch (admrgpch)

When we apply many patches separately, we must perform patching tasks multiple

times. For example, for every individual patch there may be same generate or autoconfig processes.

AD Merge Patch merges multiple patches into a single patch so that the required patching tasks

and processes are performed only once, and if two multiple patches contains different version of the same file admrgpch

will ensure that only the latest version is included in the new file.



Usage :- admrgpch



> Merge patches without unzipping the automated release updates (ARUs)

admgrpch -s -d -merge_name -manifest



The admrgpch supports both split patch driver files and unified patch driver files.

If all the source patches have split driver files, the merged patch has split driver files.

If any of the source patches has a unified driver file, the merged patch has a unified driver file.

The admrgpch copies the latest versions of the files required by the merged patches into the destination directory from target.

When merging patches, the source and destination directories cannot be child or parent directories of each other.

It is recommended to run admrgpch from the parent directory of the source directory, and the destination directory should also be located in the same parent directory.





xxx===========xxxxxxxxx===============xxx







Patch Application Assistant (admsi.pl)

There can be manual steps during patching, though most of them are automated with adpatch.

Oracle Patch Application Assistant (PAA) helps users to track and perform these manual steps during patching,

and brings consistency in the format of manual steps. Readme contains manual steps as generic instructions for all systems.

For instructions specific to our system, the readme file instructs we to use PAA.



For merged patches, PAA automatically merges the contents of all the patches readme files,

and then generates a custom set of instructions, specific to our installation, that consolidates,

and displays the relevant manual steps for all the patches we want to apply.



After successfully performing each manual step, we can record that step as completed.

When applying patches in the future, refer to this record to see which manual steps we have already completed.

Unless specified otherwise, we do not have to repeat the manual steps we have previously completed.



xxx===========xxxxxxxxx===============xxx





Web-based Patching Utilities

Utilities are based on Oracle Applications Manager (OAM).



Applied Patches

The Applied Patches utility enables us to query the patch history database for a list of patches that have been applied to our system.

From the Applied Patches interface, we can view patch information such as patch number and type, driver file name, platform and version,

location of applied patch, patch content and language, files changed or copied, bug fixes in each driver file, whether patch application was

successful, and timing information.



File History

The File History utility enables the viewing of files that have been updated by a patch. we can view file history information such as:

APPL_TOP on which the file resides, directory in which the file resides, product family that owns the file, name of the file,

version of the file, date on which the file was changed, patch details report, and action summary report for the updates to the file.





Patch Wizard

An important job for APPS DBA is to keep knowledge of new patches that are recommended, and analyze their effects before we actually apply them.

With Patch Wizard utility, we can determine patches that have not been applied to our system, but that are recommended for our system,

and also gives us a preview about the effects of applying a patch on our system.





Timing Reports

Use the Timing Reports utility to monitor a job that is running or to view statistics of completed AutoPatch and AD Administration maintenance sessions.

we can view information such as task name, time taken to complete the task, start time and end time.

Mainly used to calculate the downtime required for production.