What is AFPASSWD in Oracle R12 ?

EBS passwords are changed by the utility called FNDCPASS. 


In R12.1.2 Oracle has come up with another Utility AFPASSWD for the same purpose

Advantage is that you can run AFPASSWD utility from DB tier or from Midtier where as FNDCPASS can only be run from midtier side.

It prompts only the required passwords .

AFPASSWD [-c APPSUSER[@TWO_TASK]] [-f FNDUSER]
AFPASSWD [-c APPSUSER[@TWO_TASK]] [-o DBUSER]
AFPASSWD [-c APPSUSER[@TWO_TASK]] [-a]
AFPASSWD [-c APPSUSER[@TWO_TASK]] [-l ORACLEUSER [TRUE] |
[FALSE]]
AFPASSWD [-c APPSUSER[@TWO_TASK]] [-L [TRUE] | [FALSE]]
AFPASSWD [-c APPSUSER[@TWO_TASK]] [-s] APPLSYS

Oracle R12 and OC4J

OC4J expands to Oracle Containers For Java. Originally based on the IronFlare Orion Application Server, has developed solely under Oracle's control since Oracle Corporation acquired the source.( this is the reason why you see config files are named as orion-web.xml, orion-application.xml etc.,)

In R12 we have 3 groups of OC4J's. OC4J replaces Jserv(Java servlet containers) which came with earlier 11i techstack.

oacore OC4J - Supports framework based applications
forms OC4J - Supports forms based applications
oafm OC4J - expands to Oracle Application Fusion Middleware - for mapviewer, webservices, ascontrol

Number of OC4J instances for each group will be determined by corresponding nprocs context variable ( s_oacore_nprocs, s_forms_nprocs/s_frmsrv_nprocs, s_oafm_nprocs).

-bash-2.05b$ ./adopmnctl.sh status

You are running adopmnctl.sh version 120.4

Checking status of OPMN managed processes...

Processes in Instance: r12test_ap6155rt.ap6155rt.us.oracle.com
-------------------+--------------------+---------+---------
ias-component | process-type | pid | status
-------------------+--------------------+---------+---------
OC4J | oafm | 27133 | Alive

OC4J | forms | 27064 | Alive

OC4J | oacore | 26775 | Alive
HTTP_Server | HTTP_Server | 26718 | Alive

ASG | ASG | N/A | Down

adopmnctl.sh: exiting with status 0

adopmnctl.sh: check the logfile /slot01/appmgr/R12/inst/apps/r12test_ap6155rt/logs/appl/admin/log/adopmnctl.txt for more information ...

-bash-2.05b$

To be more precise, forms.ear application is deployed in forms OC4J to server forms based applications. ( $IAS_ORACLE-HOME/j2ee/forms/applications/forms.ear)

oafm.ear, mapviewer.ear, ascontrol.ear applications (can be found at $IAS_ORACLE-HOME/j2ee/oafm/applications/) are deployed under oafm OC4J container.

But remember, even if one file change in ear file, will leads to creation of new ear file and redeployment, which is time consuming. hence the dummy ear file is used and config files are tweaked to support adpatching in ebiz R12.

User-Managed Recovery Scenario - Recovering Through an Added Datafile with a Backup Control File

If database recovery with a backup control file rolls forward through a CREATE TABLESPACE or an ALTER TABLESPACE ADD DATAFILE operation, then the database stops recovery when applying the redo record for the added files and lets you confirm the filenames.

For example, suppose the following sequence of events occurs:

You back up the database

You create a new tablespace containing two datafiles: /oracle/oradata/trgt/test01.dbf and /oracle/oradata/trgt/test02.dbf.

You later restore a backup control file and perform media recovery through the CREATE TABLESPACE operation.

You may see the following error when applying the CREATE TABLESPACE redo data:

ORA-00283: recovery session canceled due to errors
ORA-01244: unnamed datafile(s) added to controlfile by media recovery
ORA-01110: data file 11: '/oracle/oradata/trgt/test02.dbf'
ORA-01110: data file 10: '/oracle/oradata/trgt/test01.dbf'

To recover through an ADD DATAFILE operation:

View the files added by selecting from V$DATAFILE.

For example:


SELECT FILE#,NAME
FROM V$DATAFILE;

FILE#           NAME
--------------- ----------------------
1               /oracle/oradata/trgt/system01.dbf
.
.
.
10               /oracle/oradata/trgt/UNNAMED00001
11               /oracle/oradata/trgt/UNNAMED00002

If multiple unnamed files exist, then determine which unnamed file corresponds to which datafile by using one of these methods:
Open the alert_SID.log, which contains messages about the original file location for each unnamed file.
Derive the original file location of each unnamed file from the error message and V$DATAFILE: each unnamed file corresponds to the file in the error message with the same file number.


Issue the ALTER DATABASE RENAME FILE statement to rename the datafiles. For example, enter:


ALTER DATABASE RENAME FILE '/db/UNNAMED00001' TO
                           '/oracle/oradata/trgt/test01.dbf';


ALTER DATABASE RENAME FILE '/db/UNNAMED00002' TO
                           '/oracle/oradata/trgt/test02.dbf';

Continue recovery by issuing the previous recovery statement.

For example:

RECOVER AUTOMATIC DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL