AFPASSWD Utility

AFPASSWD Utility
AFPASSWD is an enhanced version of FNDCPASS, and includes the following features:
• AFPASSWD only prompts for passwords required for the current operation,
allowing separation of duties between applications administrators and database
administrators. This also improves interoperability with Oracle Database Vault. In
contrast, the FNDCPASS utility currently requires specification of the APPS and the
SYSTEM usernames and corresponding passwords, preventing separation of duties
between applications administrators and database administrators.
• When changing a password with AFPASSWD, the user is prompted to enter the
new password twice to confirm.
• AFPASSWD can be run from the database tier as well as the application tier. In
contrast, FNDCPASS can only be run from the application tier.
FNDCPASS will continue to be shipped with Oracle E-Business Suite, and customers
can migrate to the AFPASSWD utility at their discretion.
Important: The FNDCPASS utility must still be used to migrate the
password hashing scheme, as described in My Oracle Support
Document 457166.1, FNDCPASS Utility New Feature: Enhance Security
With Non-Reversible Hash Password.
AFPASSWD Usage
The AFPASSWD command is used with the relevant command line options to perform
the desired action.
AFPASSWD [-c [@]] [-f ]
AFPASSWD [-c [@]] [-o ]
AFPASSWD [-c [@]] [-a]
AFPASSWD [-c [@]] [-l [] |
[]]
AFPASSWD [-c [@]] [-L [] | []]
AFPASSWD [-c [@]] [-s]
These options have the following functions:
• -c {APPSUSER}[@{TWO_TASK}] - Specifies the connection string to use, the
Applications user, and/or the value of TWO_TASK. This option can be use in
combination with others. If it is not specified, default values from the environment
will be used.
Note: The password will be prompted for, and is not to be
provided in the connection string.
• -f {FNDUSER} - Changes the password for an Applications user. A username that
contains spaces must be enclosed in double quotation marks; for example, "JOHN
SMITH".
• -o {DBUSER} - Changes the password for an Oracle E-Business Suite database user.
Note: This only applies to users listed in the
FND_ORACLE_USERID table, not database users in general.
• -a - Changes all Oracle (ALLORACLE) passwords (except the passwords of APPS,
APPLSYS, APPLSYSPUB) to the same password, in the same way as the
ALLORACLE mode does in FNDCPASS.
• -l - Locks individual {ORACLE_USER} users (except required schemas). {TRUE} =
LOCK, {FALSE} = UNLOCK.
• -L - Locks all Oracle (ALLORACLE) users (except required schemas). {TRUE} =
LOCK, {FALSE} = UNLOCK.
• -s {APPLSYS} - Changes the password for the APPLSYS user and the APPS user.
This requires the execution of AutoConfig on all tiers.
• -h - Displays help.

--------------
Source:-http://download.oracle.com/docs/cd/B53825_04/current/acrobat/121sacg.pdf
Chapter 11
--------------

Distributed AD

1)Distributed AD offers improved scalability, performance, and resource utilization by allowing workers of the same AD session to be started on additional middle tier systems.

2)AD has always utilized a Parallel Jobs System, where multiple AD workers start and are assigned jobs. Information for the Jobs System is stored in the database, and workers receive their assignments by monitoring certain tables in the database.

3) Distributed AD allows workers to be started on remote machines, where they can utilize the resources on the remote machines when completing their assigned jobs


Prerequistes
1) Shared APPL_TOP
2) AD.H


Working
On one of your shared APPL_TOP nodes, start your AutoPatch or AD Administration session with the following command line options:

localworkers= workers=
For example to run an AutoPatch session with 3 workers on the local node and 5 workers on a remote node:

adpatch localworkers=3 workers=8
On one or more of the additional shared APPL_TOP nodes, start an AD Controller session with the following command line option:

adctrl distributed=y

After providing basic information, AD Controller will prompt for the worker number(s) to be started. For example, enter "4 5 6 7 8" or "4-8" to start workers 4 through 8. If AD Controller is started prior to AutoPatch or AD Administration starting the Jobs System, AD Controller will ask if you want to wait. Choosing yes will cause AD Controller to wait until the Jobs system is started, at which point it will start the appropriate worker processes. If an AutoPatch session has already been started, AD Controller will wait automatically.



Example of a two node session with five workers:

Node 1) adpatch localworkers=30 workers=20

Node 2) adctrl distributed=y and choose Enter the worker range 21-30
-----------------
Source:-http://appsoracle.blogspot.com/2011/07/distributed-ad.html
-----------------

Oracle DBA: DBA_JOBS facts

Query to see the jobs running through dba_jobs

select /*+ rule */ * from dba_jobs_running;

or

select /*+ ordered */ * from dba_jobs_running;

Common Reason why jobs don't execute automatically and as scheduled
1) select instance_name,logins from v$instance;
If the logins=RESTRICTED, then:
alter system disable restricted session;

2) check the JOB_QUEUE_PROCESSES
show parameter JOB_QUEUE_PROCESSES
It should greater then 0

3)Is the job BROKEN?
select job,broken from dba_jobs where job=;
If broken, then check the alert log and trace files to diagnose the issue

4) _SYSTEM_TRIG_ENABLED=FALSE
Check if _system_enabled_trigger=false
col parameter format a25
col value format a15
select a.ksppinm parameter,b.ksppstvl value from x$ksppi a,x$ksppcv b
Where a.indx=b.indx and ksppinm=’_system_trig_enabled’;
-----------------
Source:-http://appsoracle.blogspot.com/2011/04/oracle-dba-dbajobs-facts.html
-----------------

Oracle apps: Output post Processor(OPP)

BlogThis!Share to TwitterShare to Facebook
The Output Post Processor (OPP) is an enhancement to Concurrent Processing and is designed to support XML Publisher as post-processing action for concurrent requests. If a request is submitted with an XML Publisher template specified as a layout for the concurrent request output, then after the concurrent manager finishes running the concurrent program, it will contact the OPP to apply the XML Publisher template and create the final output.

The Output Post Processor makes use of the Oracle Streams Advanced Queuing (AQ) database feature. Every OPP service instance monitors the FND_CP_GSM_OPP_AQ queue for new messages and this queue has been created with no value specified for primary_instance (link). This implies that the queue monitor scheduling and propagation is done in any available instance. In other words, ANY OPP service instance may pick up an incomming message independent of the node on which the concurrent request ran.


Maximum Memory Usage Per Process:

The maximum amount of memory or maximum Java heap size a single OPP process can use is by default set to 512MB. This value is seeded by the Loader Data File: $FND_TOP/patch/115/import/US/afoppsrv.ldt which specifies that the DEVELOPER_PARAMETERS is "J:oracle.apps.fnd.cp.gsf.GSMServiceController:-mx512m". At the time of writing (Sep 2007), there's no user interface available which allows this value to be altered (Bug 4247067). The alternative is to alter the value using SQL*Plus

Determine the current maximum Java heap size:

SELECT service_id, service_handle, developer_parameters
FROM fnd_cp_services
WHERE service_id = (SELECT manager_type
FROM fnd_concurrent_queues
WHERE concurrent_queue_name = 'FNDCPOPP');

SERVICE_ID SERVICE_HANDLE DEVELOPER_PARAMETERS
---------- -------------- --------------------------------------------------------
1091 FNDOPP J:oracle.apps.fnd.cp.gsf.GSMServiceController:-mx512m

Increase the maximum Java heap size for the OPP to 1024MB (1GB):

UPDATE fnd_cp_services
SET developer_parameters =
'J:oracle.apps.fnd.cp.gsf.GSMServiceController:-mx1024m'
WHERE service_id = (SELECT manager_type
FROM fnd_concurrent_queues
WHERE concurrent_queue_name = 'FNDCPOPP');

The OPP queue can be Recreated the using $FND_TOP/patch/115/sql/afopp002.sql file as 'APPLSYS' user. On running the script you will be prompted for username and password.

There are 2 new profiles options that can be used to control the timeouts

Profile Option : Concurrent:OPP Response Timeout
Internal Name : CONC_PP_RESPONSE_TIMEOUT
Description : Specifies the amount of time a manager waits for OPP to respond to its request for post processing.

Profile Option : Concurrent:OPP Process Timeout
Internal Name : CONC_PP_PROCESS_TIMEOUT
Description : Specifies the amount of time the manager waits for the OPP to actually process the request.
----------------------
Source:-http://appsoracle.blogspot.com/2011/05/oracle-apps-output-post-processoropp.html
----------------------

Oracle apps:FNDFS working

1) The user selects ‘Request Output’, ‘Request Log’, or ‘Manager Log’

2) The file name and nodename are selected from the database.
Reports:
SELECT outfile_name, outfile_node_name FROM fnd_concurrent_requests
WHERE request_id = :id;
Logfiles:
SELECT logfile_name, logfile_node_name FROM fnd_concurrent_requests
WHERE request_id = :id;
Manager logs:
SELECT logfile_name, node_name FROM fnd_concurrent_processes
WHERE concurrent_process_id = :process_id;


4. The client takes the nodename that was returned and adds FNDFS_ to the
beginning of it. For example, if xprod_ser1 was returned as the node name, the
client would construct the string: FNDFS_xprod_ser1

5. The client takes this string and attempts to use it as a SQL*Net connect
descriptor. SQL*Net will attempt to resolve this descriptor into a host and SID
using a local tnsnames.ora file or Oracle Names.
6. If successfully resolved, a connection is made to the given host. The listener on
this host receives the connection request, and resolves the SID using its
listener.ora file. If it finds a PROGRAM parameter listed for this SID, it will
launch this program. (which should be $FND_TOP/bin/FNDFS)

7. The FNDFS executable runs. The client sends RPC commands to it to return the
requested file.

Common error
An error occurred while attempting to establish an application file server
connection with the node There may be a network connection
problem or the listener on node may not be running.

-This can indicate a multitude of problems, and unfortunately, it does not display anymore helpful messages.

-This most commonly indicates a problem with the local tnsnames.ora file or the
listener.ora file on the server. Check that the customer added an FNDFS entry to the
tnsnames.ora file.

-Check that the hostname and port are correct. Make sure that the entry is named
FNDFS_hostname. Also, if the customer has edited the file himself, he may have
inadvertently corrupted the file. SQL*Net is very picky about the syntax of this file.

-An extra space or carriage return could cause RRA to fail. The only supported
method of editing this file is to use Network Manager. Have the customer backup the
old file, then create a new one with Network Manager if you suspect that this file
may be bad.

-Once you are sure the tnsnames.ora file is correct, you should be able to use TNSPing to ping the listener. (Be sure to ping the FNDFS alias) It should return an OK result.

-Errors here may indicate that the listener is not properly set up.

-Make sure that you are using the exact name of the server (check this with: uname -n) If you have the wrong name in the tnsnames file entry, the tnsping will work, but
RRA will not. For example, suppose the server’s real name is XPROD_SER1, and you
create a tnsnames entry called: FNDFS_DBSERV because you have a DNS alias for
this server. You can ping the server normally, because DNS will resolve this name for
you. You can run TNSPing with FNDFS_DBSERV and it will resolve this connect
string and it will ping the server and return an OK result. This would lead you to
believe that everything is OK on the client side. However, RRA still does not work.
This is because RRA is using the real server name, and it is trying to resolve the
connect string FNDFS_XPROD_SER1, and this entry does not exist. A client-side trace
would discover this error.
----------
Source:-http://appsoracle.blogspot.com/2011/05/oracle-appsfndfs-working.html
----------

Staged APPL_TOP in R12

A staged Applications system represents an exact copy of your Production system, including all APPL_TOPs as well as a copy of the Production database. Patches are applied to this staged system, while your Production system remains up. When all patches have been successfully applied to the test system, the reduced downtime for the Production system can begin. The staged APPL_TOP is used both to run the database update into the Production database as well as synchronizing the production APPL_TOP.

Pre steps
1.Compare Topologies

A staged Applications system must duplicate the topology of your Production system. For example, each physical APPL_TOP of your Production system must exist in your staged system.
2.Verify Snapshot

Prior to copying the Production Applications system, ensure that the snapshot of the system is up-to-date. While the current snapshot should automatically be managed by AutoPatch, verification can be done by running the Maintain Current Snapshot task in AD Administration. This should be done for each APPL_TOP in your Applications system. Having the snapshot of your Production Applications system current will ensure proper patch prerequisite checking when patches are applied.
3.Create the Staged System

Create a clone of your Production database and of each APPL_TOP of your Production Applications system. Production and Staged should have the same APPL_TOP names, as this will ensure the patching history for your staged APPL_TOP will be correct in the Production system. Historical information is stored in the context of an APPL_TOP, and when patch history data is imported into Production it needs to have the same APPL_TOP names. The database of your staged APPL_TOP should have a different ORACLE_SID to avoid accidental connections to Production. Passwords, ports and any process or service related parameters may be changed as well to further reduce risks.

. You must have different Applications system names for staged and Production. AutoPatch will correct the historical information. Your staged APPL_TOP name should be the same as your Production APPL_TOP name for the database driver to update the patch history information correctly.
Apply Patches to the Staged System
The staged system is patched the same way as any Oracle Applications system using AutoPatch to apply the patch drivers.

Update the Production System

1.Update the Production Database
Once patching the staged environment is complete, you are ready to update your Production system. Ensure you are able to connect to your Production database from your staged systems. You may need to create a tnsnames file in your staged system with entries for Production. You can use the s_ifile AutoConfig variable for this purpose. Refer to Appendix C of OracleMetaLink Note 387859.1, Using AutoConfig to Manage System Configurations in Oracle E-Business Suite Release 12.

Once your environment is set correctly, and all services on the Production system have been disabled, run AutoPatch for the database portion of the patch you wish to apply, by specifying options=nocopyportion, nogenerateportion on the AutoPatch command line. Ensure the database name prompted by AutoPatch is correct.

If you applied multiple patches to the staged system, you will need to run the database update for each patch you applied to stage, in the same order. To reduce downtime further in such a case, you should consider merging patches prior to staging.
2.Update the Production APPL_TOP
The Production APPL_TOP needs to be synchronized with the staged APPL_TOP. To minimize downtime, you can complete this while the Production database is being updated. There are many ways to accomplish this task, ranging from a simple copy command to utilities such as rdist. Some storage providers offer hardware solutions as well. If your topology includes multiple APPL_TOPs, each APPL_TOP needs to be copied over to the Production system. If you share a single APPL_TOP, you only need to synchronize one system. The $COMMON_TOP directory, which on some systems may reside outside the APPL_TOP, also needs to be updated for each APPL_TOP in the Applications system.

Certain configuration files, log directories and environment scripts are specific to an APPL_TOP. These files and directories must be excluded when copying. (if using the rdist utility, you can use a distfile to exclude them)

Post steps
1) Synchronizing Patch Histories
The staged applications system strategy fragments your patch history. At this point in the process, the copy and generate portions of the patch history for patches applied using a staged applications system are stored in your staged database, and the database portion of the patch history for these patches is stored in both your staged database and in your production database. It is important that the patch history of your production system be complete. To accomplish this, you must now load the copy and generate portions of all patches applied using a staged applications system into your production database.
Use the adphmigr.pl utility located in the bin directory to export the patch history for the copy and generate portions of patches applied using a staged applications system from your staged database, then use AutoPatch to import the extracted patch history data into your production database. For each patch applied using a staged applications system, you must export patch history for each APPL_TOP in the staged applications system and import it for the corresponding APPL_TOP in the production applications system. Both exporting patch history data from the staged database and importing patch history data into the production database can be done with users on the production system. To ensure correct results, you should finish consolidating patch history for the production system before applying additional patches to it or using patch-related Oracle Applications Manager features on it.

a) Export Patch History
Use the adphmigr.pl utility. adphmigr.pl is located in the bin directory under AD_TOP. Enter adphmigr.pl -help to see all valid options for adphmigr.pl. We recommend that you export patch history for each APPL_TOP separately, as you will need to import it for each APPL_TOP separately.
Ensure you specify nodatabaseportion=Y on the adphmigr.pl command line. This ensures that the patch history data for the database portion of patches applied against the staged applications system is not exported. This data should not be imported into the production database, because the database portion of each patch has already been applied directly to the production database.
Export example:
$ perl $AD_TOP/bin/adphmigr.pl userid=apps/apps \
startdate='2007/10/10 00:00:00' enddate='2007/14/10 00:00:00' \
appsystemname=stage appltopname=tafnw1 nodatabaseportion=Y
This command will generate two data files for each run of AutoPatch on the staged APPL_TOP, one for java updates and one for all other patch actions. Check adphmigr.log to ensure the data files represent the patch runs you wish to export, and that the start and end times specified did not include any unwanted AutoPatch runs.
b) Import Patch History
You should have extracted a separate set of data files for each APPL_TOP in your staged applications system. For each APPL_TOP in your production applications system, copy the data files extracted for the corresponding staged APPL_TOP to the $APPL_TOP/admin/ directory. AutoPatch will automatically upload these data files the next time it runs in this APPL_TOP. To load the data files immediately, start AutoPatch in interactive mode, answer the prompts until prompted for the name of the patch driver file, then exit AutoPatch by entering "abort" at the patch driver file prompt.

----------------
Source:-http://appsoracle.blogspot.com/2011/07/staged-appltop-in-r12.html
----------------

Huge Events*.log files in $APPLCSF/$APPLLOG?

The other day I received an automated email alert that a partition was running low on available space. Its the partition which contains $APPLCSF/$APPLLOG (ie. $COMMON_TOP/admin/log/). This directory stores concurrent manager logs, concurrent request logs, etc.

I noticed one file, Events01.log was 7GB in size. I should add that this environment is pretty static, so there aren’t log of changes and it doesn’t get restarted often.

The issue is described in Note:601375.1, which says the culprit is the Fulfillment Server having a high level of debugging enabled. The fix is to change the parameter s_jto_debug_string = OFF in your context file. (Don’t edit this manually, use OAM.) However, to enable this change you’ll need to execute autoconfig.

If your not able to run autoconfig at this time (I prefer to bundle these types of changes with patches so that users will do a quick sanity check of the environment), you can manually edit the file $COMMON_TOP/admin/scripts//jtffmctl.sh and remove the references to:

-Dengine.LogLevel=9

-Ddebug=full

Once that change is made you need to stop apache (adapcctl.sh), the fulfillment server (jtffmctl.sh) and restart them. You can now remove that huge Events log file.

Note: If you remove an active file while a process is still pointing to it, the space will not be released. I’ve been asked by people many times why they removed a file but did not see the available space increase.

----------------
Source:-http://newappsdba.blogspot.com/search/label/E-Business%20Suite
----------------

Stuck Concurrent Requests

Stuck Concurrent Requests
Every now and then users call us with a concurrent request that is running longer than normal and/or blocking other batch jobs because of incompatibilities. Upon investigation we'll see that there is no database session for the request. Since there isn't a database session users may not be unable to cancel the request themselves. The cancel button will be grayed out. The solution is to clean the fnd_concurrent_requests table.

Background: Concurrent programs may be incompatible with other programs which means they cannot execute at the same time. If the stuck concurrent request has such rules defined, then programs it is incompatible with will not run until the problem is solved.

There are 2 ways to do this, update the table manually or run the Oracle provided cmclean.sql script. Depending on the method you choose, you'll need the request id. This can be provided by the user or you can look at the running requests via Oracle Applications Manager (OAM). To navigate there click on Site Map on the top left hand corner of the page. Under Concurrent requests click on Running.




Once your in the Running requests screen you'll see which programs are currently being executed. With the help of your users, find the request id in question and make note of it. The recommended approach from Oracle will be:

1. Kill the database sessions for the requests. (In our case there weren't any.)
2. Shutdown the concurrent managers.
3. Run the cmclean.sql script Note: 134007.1
4. Start your concurrent managers.

The other method is to update the bad rows in the fnd_concurrent_requests table manually.

update fnd_concurrent_requests set STATUS_CODE='D',phase_code='C' where request_id=

STATUS_CODE of D means Cancelled and a phase_code of C is completed.

For a list of status, phase_codes and what they mean, refer to Note: 297909.1.

The benefit to updating the fnd_concurrent_requests table manually is that no downtime is required. If you are using cmclean.sql remember to shutdown the concurrent managers first!

--------------------------
Source:--http://newappsdba.blogspot.com/search/label/EBS%20Concurrent%20Processing
--------------------------

Correcting invalid spfile parameters

Correcting invalid spfile parameters
tnsManager - Distribute tnsnames the easy way and for free!



Consider the following situation. An alteration is made to the spfile which results in the instance being unable to start. Because the instance will not start, the mistake can not be corrected:



SQL> show parameter sga_max_size
sga_max_size big integer 537989896

SQL> alter system set sga_max_size=99999999999 scope=spfile;
System altered.

SQL> shut immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup
ORA-27102: out of memory

SQL> startup nomount
ORA-27102: out of memory

SQL> alter system set sga_max_size=537989896 scope=spfile;
alter system set sga_max_size=537989896 scope=spfile
*
ERROR at line 1:
ORA-01034: ORACLE not available
How annoying! The usual way to fix this problem (apart from being more careful in the first place) is to:
•create pfile from spfile
•edit the pfile
•startup nomount
•create spfile from pfile
•shutdown
•startup
•remove the pfile
There is another way however - and one that I prefer. It relies on the fact that a database can have a spfile and a pfile at the same time, and furthermore parameters specified in the pfile override those in the spfile! The spfile location must be specified in the pfile for this to work. Check out the following trace:

SQL> !
oracle@bloo$ vi $ORACLE_HOME/dbs/init${ORACLE_SID}.ora

spfile=/u02/oradata/scr9/spfilescr9.ora
sga_max_size=537989896
:wq
oracle@bloo$ exit

SQL> startup
ORACLE instance started.

Total System Global Area 554767132 bytes
Fixed Size 451356 bytes
Variable Size 402653184 bytes
Database Buffers 150994944 bytes
Redo Buffers 667648 bytes
Database mounted.
Database opened.

SQL> alter system set sga_max_size=537989896 scope=spfile;
System altered.



SQL> !rm $ORACLE_HOME/dbs/init${ORACLE_SID}.ora
SQL>





------------------------------------------------------------------------------------------------


Source :-