Apps DBA Questions

Apps DBA Questions 

1. What is a snapshot? In which table we get Information?
2. How will check Apache is working in Front-end and Back End
3. Write down the methods to identify whether the application is in maintenance mode or not
4. What is the result of unsetting APPLCSF
5. How are the AOL Developers Environment variables set
6. How do we get access to the initial sigon to application?
7. From where are the Report files picked up for execution
8. Where are the Reports plsql files located
9. Which ORACLE HOME is used by ad utilities
10. Which file contains the product dependencies information
11. When apps password is given wrong for adstpall.sh, what is the effect on the services
12. What are the Various Statuses of Workers
13. How do you restart a failed patch process
14. What are the table/tables created when workers are initiated and in which schema
15. Create defaults file for "Compile Apps Schema"
16. Execute "Compile Apps Schema" in noninteractive mode
17. Where are the custom files placed
18. Difference between ad_bugs and ad_applied patches
19. What happened Relink adslpice and adpatch?
20. What are Oracle Apps DBA Important Tables we use in daily activities?
21. What is .lct and .ldt files in Patch Directory?
22. What are the tables updated when you apply application patch?
23. Can you apply Opatch without inventory? If there is no inventory, how do you apply Opatch?
24. What are the tables get created during Apps Patching?
25. How do you hide apps password during adpatching? (adpatch flags=hidepw)
26. What is interoperability patch
27. How do you compile jsp files?
28. Types of profile options?
29. Opatch log file location?
30. How do you clone a context file or how do you change existing port pool?
31. How do you run autoconfig in test mode?
32. What are mandatory users in oracle apps?
33. What is the location of apache and plsql cache?
34. What is adlicmgr ?
35. When do you relinking?
36. What is DAD?
37. How do you compile a schema?
38. What is the utility to clean the concurrent manager tables?
39. How do you stage the 11.5.10 Apps software?
40. ADPATCH has failed and it indicated there was an error with a worker. What steps can be taken to investigate this problem?
41. How can I check to see if a concurrent manager is running?
42. Where do concurrent request or manager logfiles and output files go?
43. What is the function of the 'Conflict Resolution Manager'?
44. Unable to Bring Up Concurrent Manager after Running Autoconfig.
45. When should I run AutoConfig?
46. Which files / profile options get changed when I run AutoConfig?
47. What is cloning?
48. How do I determine if my system is Rapid Clone enabled?
49. Can I clone from one operating system version to another?
50. Can I change the database dbf files layout while cloning?
51. What is the difference between Concurrent Requests, Programs, and Processes
52. What is iAS Patch?
53. Why does a worker fails in Oracle Apps Patch and few scenarios in which it failed for you?
54. When you apply C driver patch does it require database to be Up & Why?
55. What are the important options to reduce patch down time?
56. Can you apply patch without putting Applications 11i in Maintenance mode?
57. What is difference between adpatch & opatch? Can you use both adpatch & opatch in Apps?
58. Why do I have invalid objects? What causes them? How you identify them ?
59. Is there a file that lists all of the patches that have been applied to the application?
60. What is the difference between apps listener & web listener?
61. Why only for Concurrent Manager, we specify apps/apps password & not for other?
62. What’s the significance of batch size? What r the effects when we increase r decrease the batch size it defaults to 1000.
63. What is the purpose of using the option Phtofile in adpatch?
64. How do I configure AutoConfig for a multi-node system?
65. How do you identify the No. of nodes in Middle tier and db Tier
66. What is a Shared APPL_TOP? How do you identify whether it is a shared appl_TOP or not?
67. What is a Jinitiator? (Jinitiator is the Oracle JVM used to run the applet instead of using browsers own JVM)
68. Where would i find .rf9 file, and what exactly it dose?
69. What is .dbc file, where its stored , what’s use of .dbc file ?
70. What is the use of adident utility ?
71. What is adsplice utility ?
72. How can you licence a product after installation ?
73. What is access_log in apache , what entries are recored in access_log ? Where is default location of this file ?
74. How to determine Oracle Apps 11i Version ?
75. What is PCP is Oracle Applications 11i ?
76. How to convert pll to pld file or pld file to pll ?
77. Where are the Application usrs details stored?
78. How to find plsql version?
79. When do you use startmgr.sh script? Where its locate?
80. What is the yellow Bar Issues? 

Migrating an Oracle Database From Solaris to Linux


There has been a general move over the last couple of years for a number of our clients to migrate their Oracle environments off Solaris/SPARC and onto Linux/x86, normally Red Hat Linux. The reasons typically given are cost savings and performance improvements. I had assumed that the takeover of Sun by Oracle would slow these migrations down as people waited to see the roadmap from Oracle but so far there's been no indication of that.

The migration process is reasonably well described in the Oracle documentation (Transporting Tablespaces Between Databases), but I'll give a summary of the process here so you can see what's involved, we're using the 'power of RMAN' (I think I may need to trademark that!) to do the heavy lifting.

1: Check that platforms are compatible, run this query on the database you want to migrate from and it will list the platforms you can migrate to:

select * from V$TRANSPORTABLE_PLATFORM;

check the value of ENDIAN_FORMAT, if you are migrating from one format to another you are going to need to convert your database files, so for example going from Solaris to Linux you will need to convert.

2: You can only migrate tablespaces to a database which uses the same character set and national charcter set, so check if you are migrating to an existing database or make sure to use the same values if you are building a new database

3: Assuming you are good to go you need to determine which tablespaces hold the data you want to transport and then double check that the list is self-contained, execute this PL/SQL procedure to check the tablespaces you plan to migrate:

execute DBMS_TTS.TRANSPORT_SET_CHECK('tspace1','tspace2', true);

Then query the output table:

select * from TRANSPORT_SET_VIOLATIONS;

Ideally this will come up with no rows, in which case your list of tablespaces is self-contained and you are ready to proceeed, if not then the quuery results will show problems you have, for example:

VIOLATIONS
--------------------------------------------------------------------------------
Index TESTUSER.INDEX1 in tablespace TSPACE1 points to table TESTUSER.Table2 in tablespace TSPACE3

In this case you could move that table from TSPACE3 into one of the tablespaces you are migrating, include TSPACE3 in your tablespace list, drop or move the index, whichever action is most appropriate. Re-run the PL/SQL and recheck the results - rinse and repeat until you are clean to go:

exec DBMS_TTS.TRANSPORT_SET_CHECK('tspace1','tspace2', true);

select * from TRANSPORT_SET_VIOLATIONS;

no rows selected

4: Generate the transportable tablespace set; you need to export the metadata and then copy the datafiles and if you want the views, PL/SQL etc. for the schemas that are included in the tablespaces then you will need to export those too:

alter tablespace TSPACE1 read only;
alter tablespace TSPACE2 read only;



exp file=tts.dmp transport_tablespace=Y tablespaces=TSPACE1,TSPACE2

cp /data/tspace1_01.dbf /migrate

cp /data/tspace1_02.dbf /migrate

cp /data/tspace2_01.dbf /migrate

cp /data/tspace2_02.dbf /migrate

exp file=testuser.dmp log=testuser.log rows=N owner=TESTUSER



alter tablespace TSPACE1 read write;
alter tablespace TSPACE2 read write;



5: copy the metadata export, datafiles and any schema exports to the new host

6: convert the datafiles to new platform format using RMAN, in this example we will put the converted datafiles into an ASM instance:

rman
connect target /
convert datafile
'/migrate/tspace1_01.dbf',
'/migrate/tspace1_02.dbf',

'/migrate/tspace2_01.dbf',

'/migrate/tspace2_02.dbf'

from platform 'Solaris[tm] OE (64-bit)'
format '+DATA1'
parallelism 4;

7: plug the tablespace into the target database, check the ASM instance to get the names of the converted datafiles:



imp file=tts.dmp log=tts.log transport_tablespace=Y datafiles= \
'+DATA1/db1_server1/datafile/TSPACE1.279.699544583',\
'+DATA1/db1_server1/datafile/TSPACE1.299.699544581',\
'+DATA1/db1_server1/datafile/TSPACE2.300.699544581',\
'+DATA1/db1_server1/datafile/TSPACE2.301.699544581'



8: set the imported tablespaces to read write:

alter tablespace TSPACE1 read write;
alter tablespace TSPACE2 read write;



9: import procs, triggers etc

imp file=testuser.dmp log=testuser.log rows=N ignore=Y full=Y

10: unlock the schema object statistics as they will all be 'locked' after the migration - this caught me out the first time!:


exec DBMS_STATS.UNLOCK_SCHEMA_STATS('testuser');


11: Take a backup of your newly migrated tablespaces

Oracle Database Platform Migration From CentOS (RHEL) Linux 4.5 to Solaris 10
Contents

Pre-migration Steps
Verify TDB support for target platform
Target system software version
Identify external files and directories
Start the database in READ ONLY mode
Verify the database is ready for migration
Prepare database on target server
Migration Steps
Run RMAN CONVERT DATABASE on Target
Move necessary files to target system
Complete the migration
Post Migration Steps

Pre-migration Steps
Verify TDB support for target platform

Before attempting a platform migration with TDB, verify the target platform is supported for TDB by your source platform. Query the view V$DB_TRANSPORTABLE_PLATFORM for the target platform name. Here is example output from a database on ‘Linux IA (32-bit)’ platform.
Logon to source database
SQL> connect / as sysdba
SQL> select platform_name from v$db_transportable_platform;
PLATFORM_NAME
---------------------------------------------
Microsoft Windows IA (32-bit)
Linux IA (32-bit)
HP Tru64 UNIX
Linux IA (64-bit)
HP Open VMS
Microsoft Windows IA (64-bit)
Linux 64-bit for AMD
Microsoft Windows 64-bit for AMD
Solaris Operating System (x86)
9 rows selected.
If the target platform does not appear in the output from V$DB_TRANSPORTABLE_PLATFORM, then the database cannot be migrated using TDB.

Target system software version

The target system must have the same Oracle software version and patches installed as the source system. This includes the same patch set version, critical patch updates, and patch set exceptions. The software should be used to create a sample database to ensure it is operational. Refer to Oracle Universal Installer and OPatch User’s Guide [4], for details on using the OPatch utility to determine the currently installed versions and patches.

Identify external files and directories

Identify directories external to the source database that will need to be created on the target system, and external table files and BFILEs that will need to be moved to the target system.
The PL/SQL function CHECK_EXTERNAL identifies external tables, directories, and BFILEs that need to be moved during the migration so the target database is complete when the process is finished.
SQL> set serveroutput on
SQL> declare x boolean;
begin x := dbms_tdb.check_external; end;
The following directories exist in the database:
SYS.DATA_PUMP_DIR, SYS.ADMIN_DIR, SYS.WORK_DIR, SYS.DEV_UIMAGES,
SYS.STAG_UIMAGES, SYS.PROD_UIMAGES, SYS.PRJ_KEY, SYS.testuser2_UPLOADS
PL/SQL procedure successfully completed.

    Directory objects must be created on the target system. Query DBA_DIRECTORIES on the source database to determine the filesystem locations that must exist on the target system for the directory objects to be usable.

SQL> select directory_path from dba_directories;
DIRECTORY_PATH
--------------------------------------------------------------------------------
/ade/aime_10.2_lnx_push/oracle/md/admin
/u02/oracle/apexdb/admin/apex/dpdump/
/var/www/testuser.appshosting.com/web/budevser.com/UIMAGES
/ade/aime_10.2_lnx_push/oracle/work
/var/www/testuser.appshosting.com/web/bustagser.com/UIMAGES
/var/www/testuser.appshosting.com/web/testuser.com/UIMAGES
/usr/bin/
/var/www/testuser2.appshosting.com/web/uploads
8 rows selected.
Ensure that each directory listed in the view DBA_DIRECTORIES points to a valid filesystem directory, or ASM disk group or directory on the target system. Accomplish this by either creating each directory on the target system, or altering the DIRECTORY_PATH to a valid directory when the target database is open after the migration process. For example:
$ mkdir –p /extdata/orcl $ mkdir –p /u01/app/oracle/admin/orcl/tts $ mkdir –p /u01/app/oracle/admin/orcl/dpdump/
• Identify external table files that will need to be transferred to the target system when indicated in a later step. Do not add additional external tables to the source database until the platform migration is complete.
To identify external table files, run the following query
SQL> select directory_path||‘/’||location External_file_path from dba_directories a, dba_external_locations b where a.directory_name=b.directory_name;

Identify BFILE files that will need to be transferred to the target system when indicated in a later step. Do not initialize additional BFILEs in the source database until the platform migration is complete. To identify directories that contain BFILEs, run the following SQL script from the appendix:
SQL> @tdb_get_bfile_dirs.sql
The following directories contain external files for BFILE columns
Copy the files within these directories to the same path on the target system
If it is necessary to list all BFILE external files, then run the script tdb_get_bfiles.sql script from the appendix.

Start the database in READ ONLY mode

TDB requires that the source database be opened in READ ONLY mode. The source database will be unavailable from this step forward.
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database open read only;

Verify the database is ready for migration

To ensure the database is ready for migration, run the DBMS_TDB.CHECK_DB function to verify that the database can be migrated to the target platform and that the database is in the proper state to be migrated.
SQL> set serveroutput on
SQL> declare
retcode boolean;
begin
retcode := dbms_tdb.check_db(‘Solaris Operating System (x86)', dbms_tdb.skip_none);
end;
PL/SQL procedure successfully completed.

Any condition reported by CHECK_DB must be resolved before TDB can proceed. For details of the checks performed by DBMS_TDB.CHECK_DB,

Prepare database on target server

# groupadd dba
# groupadd oinstall
# Useradd -g oinstall oracle
# mkdir /d01
# mkdir /export/home/oracle
# chown oracle:oinstall /export/home/oracle
Modify /etc/auto_home to add a new entry 'oraapex localhost:/export/home/oraapex'
Set password for oraapex to '0raapex!'
Set shell in /etc/passwd file to /usr/bin/bash
# vi /etc/group
  Add oraapex user to dba group

Install RDBMS 10.2.0.1 into /d01/oracle/apexdb/10.2.0
Run root scripts
$ vi $HOME/testdb.env
   Add environment variables for testdb database on ahweb
$ cd
$ . testdb.env
$ mkdir $ORACLE_HOME/admin $ORACLE_HOME/admin/testdb
$ cd $ORACLE_HOME/admin/testdb
$ mkdir bdump udump cdump adump

Add listener and tns entry
$ $ORACLE_HOME/bin/netca
  Add LSNR1 listener and testdb tns entry

Migration Steps
Run RMAN CONVERT DATABASE on Target

When performing a target system conversion, RMAN creates an RMAN script to be used on the target system to convert all datafiles.
Login to source server
# mkdir /tmp/convertdb
# chmod 777 /tmp/convertdb
# su – oraapex
$ . testdb.env
$ rman
RMAN> connect target /
RMAN> configure device type disk parallelism 1;
RMAN> show all;
RMAN> convert database on target platform
convert script ‘/tmp/convertdb/convert_testdb.rman’
transport script '/tmp/convertdb/transport_testdb.sql'
new database 'testdb'
format '/tmp/convertdb/testdb%U'
db_file_name_convert '/u02/oracle/apexdata/apex','/d01/oracle/apexdata';
RMAN> exit
$ sqlplus /nolog
SQL> connect / as sysdba
SQL> shutdown;

Run SQL script /tmp/convertdb/transport_testdb.sql on the target platform to create database
Edit init.ora file /tmp/convertdb/init_testdb00j60sqd_1_0.ora. This PFILE will be used to create the database on the target platform
Run RMAN script /tmp/convertdb/convert_testdb.rman on target platform to convert datafiles
To recompile all PL/SQL modules, run utlirp.sql and utlrp.sql on the target platform
To change the internal database identifier, use DBNEWID Utility
Finished backup at 13-JAN-08

The CONVERT DATABASE command specified in the example will create a convert script named /tmp/convert_mydb.rman, a transport script named /tmp/transport_mydb.sql, and a PFILE named /tmp/init_mydb.ora. See the appendix for example target system conversion output.

Move necessary files to target system

Once the CONVERT DATABASE command is complete transfer /tmp/convertdb directory and files to the target system using operating system utilities (e.g. ftp, scp).
Login to target ahweb.appshosting.com as oraapex
$ scp -pr root@targetserver.appshosting.com:/tmp/convertdb $HOME/
In addition to the common files listed above, if performing a target system conversion, the following files must be transferred to the target system:

    Unconverted datafiles – should be placed in a staging area. The convert RMAN script will read datafiles from this location and write the converted datafiles to their final location.

Login to target server ahweb.appshosting.com as oraapex
$ mkdir /d01/oracle /d01/oracle/apexdata
$ scp –pr root@targetserver.appshosting.com:/u02/oracle/apexdata/apex /export/home/oraapex/apexdata/

To reduce overall outage time, instead of transferring the unconverted datafiles using a command like FTP, NFS mount the source system’s datafile location on the target system. During the conversion process, this will allow the datafiles to be read from their original source location and written in the converted format to their final target location. See step 6 for details on modifying the convert RMAN script.
# mount source:/u01/oradata/PROD/datafile /mnt/mydb
• Convert RMAN script

Complete the migration

The final steps required to complete the migration differ slightly depending on the type of conversion chosen – source system or target system.
Review the PFILE
For all migrations, the PFILE created on the source system and transferred to the target system must be reviewed to ensure that directory paths and file locations are accurate for the target system. The parameters that need to be changed are grouped together at the top of the PFILE.
$ cp $HOME/convertdb/*.ora $ORACLE_HOME/dbs/
$ cd $ORACLE_HOME/dbs
$ mv init_testdb00j60sqd_1_0.ora inittestdb.ora
$ vi inittestdb.ora
   To modify parameters for target database on ahweb.appshosting.com
Target system conversion only – review and run the Convert RMAN script
When performing a target system conversion, the datafiles are moved to the target system in the source system format. The convert RMAN script must be reviewed to ensure the file locations are accurate. The following should be reviewed and changed as necessary:

    The filename specified for CONVERT FILENAME should be the unconverted datafile that was transferred from the source system. If instead of transferring the unconverted datafiles the source datafile
    location was NFS mounted to the target system, then specify the location of the NFS mount.
    The FORMAT spec should indicate the final location of the converted datafile. This final location must match the location specified in the transport SQL script. See the next section for more detail.

$ su – oraapex
$ vi $HOME/convertdb/convert_testdb.rman
   Replace ‘/u02/oracle/apexdata/apex’ to ‘/export/home/oraapex/apexdata’
$ sqlplus /nolog
SQL> connect / as sysdba
SQL> startup mount;
After the convert RMAN script is reviewed and edited as necessary, run the script:
RMAN> connect target /
RMAN> @convert_testdb.rman
RMAN> exit
SQL> shutdown
Review and run the Transport SQL script
For all migrations, the final step to complete is to run the transport SQL script that was created by RMAN’s CONVERT DATABASE command. The script must first be edited on the target system to ensure that locations for all referenced files are correct. The following sections should be reviewed for accuracy and changed as necessary:

    Ensure that the PFILE referenced in the STARTUP command in the transport script point to the location where the PFILE was placed when it was transferred from the source system.
    Ensure the DATAFILE locations in the CREATE CONTROLFILE statement refer to the final location of the converted datafiles on the target system. If it is a target system, conversion, then the DATAFILE locations should match where the CONVERT DATAFILE placed its output.
    Ensure that the LOGFILE locations in the CREATE CONTROLFILE statement refer to the desired location of the online logfiles on the target system. If no location is specified then Oracle-Managed Files will be used to name and place the files.
    Ensure the TEMPFILE location(s), if specified, are accurate for new tempfiles being created for temporary tablespaces.

After the transport SQL script has been reviewed and edited as necessary, run the script:
SQL> connect / as sysdba;
SQL> @transport_testdb.sql
When the transport SQL script is complete, review the output for errors.

Post Migration Steps

Directory objects must be created on the target system. Query DBA_DIRECTORIES on the target database to determine the filesystem locations that must exist for the directory objects to be usable.
$ mkdir $ORACLE_HOME/admin/dpdump
SQL> select directory_path from dba_directories;
DIRECTORY_PATH
--------------------------------------------------------------------------------
/ade/aime_10.2_lnx_push/oracle/md/admin
/u02/oracle/apexdb/admin/apex/dpdump/
/var/www/testuser.appshosting.com/web/budevser.com/UIMAGES
/ade/aime_10.2_lnx_push/oracle/work
/var/www/testuser.appshosting.com/web/bustagser.com/UIMAGES
/var/www/testuser.appshosting.com/web/testuser.com/UIMAGES
/usr/bin/
/var/www/testuser2.appshosting.com/web/uploads
8 rows selected.
SQL> update dba_directories set directory_path=’/d01/oracle/apexdb/admin/testdb/dpdump’
           where directory_path=’/u02/oracle/apexdb/admin/apex/dpdump’;

Copy web upload directories from source to target server
# cp -pr root@<sourceServer>:/var/www/*/web/uploads  /var/www/*/web/

AutoConfig@R12Apps

AutoConfig is a tool that supports automated configuration of an Oracle E-Business Suite Release 12 instance. All the information required for configuring an Applications instance is collected into two local repositories, called the Applications context file and the database context file.

When AutoConfig runs on the application tier, it uses information from the Applications context file to generate all configuration files and update database profiles. When AutoConfig runs on the database tier, it uses information from the database context file to generate all configuration files used on the database tier.

AutoConfig provides several major benefits, including:

• Configuration Support: AutoConfig configures the APPL_TOP, the ORACLE_HOMEs, and the supporting technology stack.
• Configuration Management: AutoConfig centralizes the configuration and re-configuration of an Applications instance.
• Configuration Delivery and Patching: The uptake of new technology is simplified, as new configurations and configuration changes can be provided in the form of a patch.

Run AutoConfig on the Database Tier:
1.Log-in to the Oracle User
2.Source the Environment file
3.Run the autoconfig script.
sh <RDBMS_ORACLE_HOME>/appsutil/scripts/
<CONTEXT_NAME>/adautocfg.sh

Run AutoConfig on the Application Tier:

1.Log-in to the Apps User
2.Source the Environment file
3.Run the autoconfig script.

Run AutoConfig on all application tier nodes and execute the following command to run AutoConfig.

sh <INST_TOP>/admin/scripts/adautocfg.sh

How to Enable Maintance Mode In R12 APPS? 

During a patch application the recommended option is to Enable Maintenance node.When adsetmmd.sql runs, it sets the Profile Option ‘Applications Maintenance Mode’ (APPS_MAINTENANCE_MODE) to ‘MAINT’ to Enable ‘Maintenance Mode’ and to ‘NORMAL’ to Disable it.When you Enable or Disable ‘Maintenance Mode’, adadmin will execute the script.

sqlplus -S  apps/*****
@$AD_TOP/patch/115/sql/adsetmmd.sql DISABLE

sqlplus -S  apps/*****
@$AD_TOP/patch/115/sql/adsetmmd.sql ENABLE

Determining if Maintenance Mode is Running:

A quick way to verify if the Environment is on Maintenance Mode or not, is by checking the value of this Profile Option as follows:

sqlplus apps/apps
SQL>select fnd_profile.value('APPS_MAINTENANCE_MODE')
from dual;

If the query returns ‘MAINT’, then Maintenance Mode has been Enabled and the Users will not be able to Login. If the query returns ‘NORMAL’ then Maintenance Mode has been De-Activated and the Users will be able to use the application.

Found dead process in ICM log file 

There is an issue occurred on my E-Business Suite.Many concurrent mangers are not started after restarted the concurrent manger server.The Internal Manager log file shows that the following information.

Found dead process: spid=(12099), cpid=(1125806),
ORA pid=(123), manager=(0/15293)

Found dead process: spid=(12053), cpid=(1125722),
ORA pid=(104), manager=(0/14293)

This was happened due to the controlling manager was not brought down gracefully.Gracefully meaning that it was brought down when and only when, all concurrent processes are completed.I have applied the following solution to resolve this issue.

Solution:

Step1. Stop all middle tier services including the concurrent managers and verify that all APPS-Tier processes are down :

ps -fu<APPS User> | grep FND
                OR
ps -fu<APPS User> | grep FND | wc -l

The command will show all processes on OS level, which are running for the Concurrent Managers. It can take some minutes until all CCM processes are stopped.

Step2. Stop the Database and verify, that all Database processes are down.

Step3. Start the database.

Step4. Execute the CMCLEAN.SQL script from the referenced note below (don’t forget to commit).

For details, please see NOTE:134007.1 – ‘CMCLEAN.SQL – Non Destructive Script to Clean Concurrent Manager Tables’.

Step5. Start the Middle Tier Services including your Concurrent Manager.

Step6. Verify the issue .

Here  Second step and Third Steps are optional.Normally it s not necessary to stop the database for run the cmclean.sql.In my case the cmclean script is hanged when i do run it and its needed to restart the database.

How To Clear The Cache Using Functional Administrator

In R12 we use the following steps to clear the cache and also when we do this activity make sure that the  users shouldn’t connect the applications.

Step1: Log in and choose the Functional Administrator responsibility – then choose Home.

Step2:Choose the Core Services Tab – then the Caching Framework Sub-Menu .

Step3:Click Global Configuration’ from the left hand side menu that appears  and  – In the far right choose ‘Clear all Cache’ button

Step4: A screen prompts and confirms that the action will clear all cache on the middle tier server – choose Yes.

Step5: A confirmation message is displayed, confirming that all cache has been cleared across middle tiers.

Clearing the OA Framework cache in a PRODUCTION instance can cause data issues if multiple users are engaged and transacting data in the application at the time cache is cleared. Please only utilize this in Production if advised by Oracle Support Services or Oracle Development.

How To Clear Apache/iAS Cache in 11i and R12? 

The following steps provides how to clear cache of Apache on Oracle E-Business Suite 11i and 12.
Whenever you bounce the apache server, you need to clear the server side cache, so that those cached pages will not be used again.

On 11i Versions:

Step1:Stop the apache listener

$COMMON_TOP/admin/scripts/adapcctl.sh stop

Step2:Clear Cache

cd $COMMON_TOP/_pages/

rm -rf *

Step3:Start the apache listener

$COMMON_TOP/admin/scripts/adapcctl.sh start .

On R12 Versions:

In R12 we have two methods to clear the cache.

Method1: We can clear the cache by using Functional Administrator.Please check the this Link How To Clear The Cache Using Functional Administrator.

Method2:If you cleared the _pages as above method as used in 11i accidentally, .run ojspcompile.pl.The ojspcompile.pl perl script to perform a manual pre-compilation of the JSP pages. The following command will compile all the JSP pages and build up the JSP cache again.

cd $FND_TOP/patch/115/bin

perl ojspCompile.pl --compile --flush -p 2

It is always better to go for method1 for clearing the cache.If you are having any issues with calling JSP pages results in a hanging ‘blank’ screen,you can use the 2nd method.

How to cancel a concurrent request from db level? 

• The following query returns sid” and “serial#” once you have provided “request_id” of a Concurrent Program which is currently running.
• Take the values “sid” and “serial#” and kill the sessions at the database level.

Step1:Connect to SQLPLUS as the APPS user:

SQL> SELECT ses.sid,

 ses.serial#

 FROM v$session ses,

 v$process pro

 WHERE ses.paddr = pro.addr

 AND pro.spid IN (SELECT oracle_process_id

 FROM fnd_concurrent_requests

 WHERE request_id = &request_id);

Enter value for request_id:

Step2:Connect to SQLPLUS as the SYSTEM user:

SQL> ALTER SYSTEM KILL SESSION '&sid,&serial#'IMMEDIATE;

Enter value for sid:

Enter value for serial:

Error running SQL and EXEC commands in parallel 

This issue has occurred when we do applying the patches on the Application Tier.
The cause of this is auto patch previous sessions are still exists in the server and failing the ad workers with the following error.
 Error

11 workers have quit.  Waiting for 9 more.

12 workers have quit.  Waiting for 8 more.

 All workers have quit.

 Completed: file apgtxlat.sql on worker  1 for product ap  username AP.

 Time is: Sat May 26 2012 21:31:09

 Error running SQL and EXEC commands in parallel

 You should check the file

/applprod2/uat3/appluat3/admin/DEV/log/u7023348.drv2.log  for errors.

Solution:

Kill the ad patch sessions and try to apply the patch again.

1.Mydb>ps -eaf | grep adpatch
           OR
  Mydb>ps -efa | grep adworker

2.Mydb>kill -9 <pid>

RW-50016: Error: – {0} was not created:-Log in Page Error 
The cause of the bellow issue is incorrect settings in the /etc/hosts file.Rapidwiz fails during post installation checks as per part of the application installation.

RW-50016: Error: – {0} was not created: 
File = {1}

The hosts file is a computer file used to store information on where to find a node on a computer network.It contains a list of IP addresses, hostnames and hostname aliases.

Solution:

I applied the following solution for resolving this issue

    Stop the Apache Server
    Open the /etc/hosts file and check the configuration setttings correctly
    Start the Apache Server
    Click to Retry option for performing post installation checks again.

Upgrade of Oracle Applications Version R12.1.1 to R12.1.3

After Installation of Oracle Applications R12.1.1,I have upgraded to R12.1.3 Successfully in my Servers.
The following patches are required and download from the Oracle Support as per their environment.
In this Note I have added some more patches for avoiding the feature errors and for avoiding  invalid objects.
Before going to proceed please check the metal ink Note Oracle E-Business Suite Release 12.1.3 Readme [ID 1080973.1].



Required patches:
p9239089_R12.AD.B_R12_LINUX.zip
p10349415_R12.AD.B_R12_GENERIC.zip (Optional)
p9239090_R12_LINUX_1of6.zip
p9239090_R12_LINUX_2of6.zip
p9239090_R12_LINUX_3of6.zip
p9239090_R12_LINUX_4of6.zip
p9239090_R12_LINUX_5of6.zip
p9239090_R12_LINUX_6of6.zip
p9239095_R12_GENERIC.zip
p9822544_R12.MSC.B_R12_GENERIC.zip(Optional)


Post update patches are :
p9966055_R12.FND.B_R12_GENERIC.zip
p9817770_R12.ATG_PF.B_R12_LINUX.zip


The following information will provide upgradation process for Ooracle Applications R12.1.1 to R12.1.3.


Step1: Run adadmin and put Maintenance Mode


Step2: Apply Prerequisite R12.AD.B.DELTA.3 Patch 9239089
Do the following Tasks before going to apply the Patch R12.AD.B.DELTA.3 Patch 9239089


Run the adgrants.sql script as a user that can connect as SYSDBA to grant privileges to selected SYS objects and create PL/SQL profiler objects.


Usage:
1.Create $ORACLE_HOME/appsutil/admin on the database server.


2.Copy adgrants.sql (UNIX) from this patch directory to $ORACLE_HOME/appsutil/admin.Or, copy adgrants_nt.sql (Windows) from this patch directory to %ORACLE_HOME%\appsutil\admin.


3.Set the environment to point to ORACLE_HOME on the database server.


4.Use SQL*Plus to run the script:


UNIX:
$ sqlplus /nolog
SQL> @$ORACLE_HOME/appsutil/admin/adgrants.sql <APPS schema name>


Step3: Apply R12.AD.B_R12_GENERIC.zip Patch 10349415


Step4: Apply Oracle E-Business Suite Release 12.1.3 Patch 9239090


Step5:. Apply Oracle E-Business Suite Online Help for 12.1.3 Release Update Pack patch 9239095


Step6:.Apply Patch 9822544 for Advanced Supply Chain Planning. (Optional).This patch fixes the issue of collecting resource requirements of OPM batches WIP warehouse does not belong to resource warehouse.


Step7: Apply post Update Patches:


–Apply mandatory Patch 9817770 (9817770:R12.ATG_PF.B [POST-R12.ATG_PF.B.DELTA.3 CONSOLIDATEDPATCH].)


–Apply mandatory Patch 9966055 (9966055:R12.FND.B [TRANSLATED VERSION OF FNDSCSGN NOT LAUNCHED].)


After you have upgraded to Oracle E-Business Suite Release 12.1.3, perform the following post-update steps to update all database tier nodes with the code level, provided by Oracle E-Business Suite Release 12.1.3.



Step8: Run Application  and Database Environment files.


@Application Tier:


    Run AutoConfig on the APPL_TOP.
    Run the admkappsutil.pl utility to create the file appsutil.zip in the <INST_TOP>/admin/out directory.


perl <AD_TOP>/bin/admkappsutil.pl


@Database Tier:


Copy or FTP the appsutil.zip file to the <RDBMS ORACLE_HOME>. Uncompress appsutil.zip under the <RDBMS ORACLE_HOME>.


    cd <ORACLE_HOME>
    unzip -o appsutil.zip
    Run AutoConfig on the <RDBMS ORACLE_HOME>.


Step9:. Run adpreclone.pl on the database tier and the application tier


    perl adpreclone.pl dbTier
    perl adpreclone.pl appsTier


Step10: Disable Maintenance Mode using adadmin and check the version using following sql statement.


SQL> select release_name from fnd_product_groups;
RELEASE_NAME
--------------------------------------------------
12.1.3