This documentation is a start Oracle Applications automatically when the machine is rebooted.
Refer to Doc ID: Note: 61333.1 (Subject: AUTOMATIC STARTUP AND SHUTDOWN OF ORACLE DATABASE INSTANCES)
Can modify /etc/oratab script. This did not start database listener or application services.
Can also put startup script in /etc/rc.local. Must be edited as root user.
su applmgr -c /u2/oracle/scripts/startVIS2.sh su applmgr -c /u3/oracle/scripts/startVIS4.sh
Problem: Unable to get application to launch.
Solution: Try the following:
Step 1: Check the hosts file (either /etc/hosts or C:WINDOWSSYSTEM32 DRIVERSETCHOSTS) and ensure that the IP address and host is in the file.
Step 2: Ensure that the local addresses are bypassed in the browser.
Step 3: Ensure that the instance is started on the server.
Problem: When accessing any menu that launches core forms, get this error:
load: class oracle/apps/fnd/formsClient/FormsLauncher.class not found
Solution: Check the proxy server settings in the browser and ensure that addresses to bypass are correct.
Use the ‘hostname*’ format in the proxy server settings.
From Metalink article Doc ID: Note:291698 (Subject: FormsLauncher.class Not Found Error When Attempting to Access Forms in Applications)
Steps for resolution:
See also: Doc ID: Note:373736.1 (Subject: Load: Class Oracle/Apps/Fnd/ Formsclient/Formslauncher.Class Not Found)
Problem: In Oracle Applications Manager, in Applications Dashboard, on the database is appearing up. The remaining servers are shown as down.
Solution:
Executing service control script:
/emca/PROD/prodcomn/admin/scripts/PROD_linux-blade/adrepctl.sh stop
script returned:
**************************************************** You are running adrepctl.sh version 115.29 Reports Server for PROD is already stopped. adrepctl.sh: exiting with status 2 .end std out. .end err out. **************************************************** Executing service control script: /emca/PROD/prodcomn/admin/scripts/PROD_linux-blade/adfmcctl.sh stop script returned: **************************************************** You are running adfmcctl.sh version 115.16 forms load balancing client for PROD already stopped. adfmcctl.sh: exiting with status 2 .end std out. .end err out. **************************************************** Executing service control script: /emca/PROD/prodcomn/admin/scripts/PROD_linux-blade/adfmsctl.sh stop script returned: ****************************************************
Subject: Summary of Possible Reasons and Solutions for the Problem Where All Concurrent Requests Stuck in Pending Phase Doc ID: Note:182154.1
2. When shutting down the concurrent manager are there any FNDLIBR processes still running at the OS level? If so, do a kill -9 on them. Then restart the concurrent manager.
Tried this, but CM stopped successfully with no need to kill FNDLIBR.
3. Rebuild the concurrent manager views. As applmgr run the following from the OS:
This is non-destructive.
Concurrent Manager views can be rebuild by running the following command at the command line:
Ensure that concurrent manager is shutdown.
FNDLIBR FND FNDCPBWV apps/apps SYSADMIN 'System Administrator' SYSADMIN
Restart the concurrent manager.
Executed the above, but no change.
Executed the code:
update fnd_concurrent_queues set control_code = 'A' where concurrent_queue_name = 'FNDCRM'; commit; SQL> update fnd_concurrent_queues 2 set control_code = 'A' 3 where control_code = 'N' 4 / SQL> select control_code, target_node, concurrent_queue_name 2 from fnd_concurrent_queues 3 where control_code = 'N' 4 / C TARGET_NODE CONCURRENT_QUEUE_NAME - ------------------------------ ------------------------------ N FNDCRM N FNDSCH N STANDARD N PODAMGR N RCVOLTM N PASMGR N INVMGR N INVTMRPM N IEU_SH_CS N IEU_WL_CS N OAMCOLMGR C TARGET_NODE CONCURRENT_QUEUE_NAME - ------------------------------ ------------------------------ N OAMGCS_LINUX-BLADE
updated /etc/hosts file:
[applmgr@linux-blade etc]$ cat /etc/hosts # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost 128.x.x.x linux-blade.domainname linux-blade SQL> create table fnd_concurrent_queues_vseeram 2 as select * from fnd_concurrent_queues;
The XML template that is being updated is located in the Public folder (project_folder) on x.x.x.x. If you cannot log on to this server, use applmgr/applmgr as the username and password.
Navigate to the ARSetupXML folder. The report that is being modified is the Transaction Detail Report.rtf. This file was copied to TDR1 VS.rtf, which is being modified.
To register the RTF file as an XML template in Oracle Applications (OA), you must set up a Data Definition and then a Template. To set up a Data Definition:
| Name | Enter any name you choose |
| Application | Receivables |
| Code | Any name you choose |
| Start Date | Today’s Date |
Next, a template must be set up. To create a new template, follow these steps:
| Name | Enter any name you choose |
| Application | Receivables |
| Type | RTF |
| Code | Any name you choose |
| Data Definition | The name of the data definition enter in the above steps |
| Start Date | Today’s Date |
| File | Click the Browse button and choose ARSetupXML TDR1 VS.rtf from the Public folder |
| Language | English |
| Territory | United States |
To disable a template, set the End Date to a date (such as the Start Date). To restore the template, list all template where ACTIVE = NO. Then remove the End Date.
When the report was submitted, it completed with a warning. The message in the log stated:
+————- 1) PUBLISH ————-+
Beginning post-processing of request 264770 on node ERPTEST at 29-MAY-2006 10:34:20.
Post-processing of request 264770 failed at 29-MAY-2006 10:34:20 with the error message:
One or more post-processing actions failed. Consult the OPP service log for details.
+————————————–+
To view the OPP service log, OPP must be accessed from the Oracle Applications Manager.
This is the OPP service log. The following was noted:
Caused by: oracle.xdo.parser.v2.XPathException: Unknown expression at EOF: .//for each:G_LINES.
at oracle.xdo.parser.v2.XSLProcessor.reportException(XSLProcessor.java:782)
at oracle.xdo.parser.v2.XSLProcessor.newXSLStylesheet(XSLProcessor.java:564)
… 15 more
From this log, there was an error with G_LINES. It should have been for‑each:G_LINES. Therefore, this would be the starting point to resolve this problem.
To fix this file, a working XML template file, “Revised UTT Invoice V3 (file 1).rtf”, was opened and compared to the “TDR1 VS.rtf” file (file 2). The tags were meticulously compared, together with the XML source, “XML Transaction Detail Report.xml”.
Refer to the Oracle® XML Publisher User’s Guide, which is located in the Public folder, under the “User Manualsxml” folder in the file XML Publisher.pdf.
On Test environment:
Prerequisites to Using the Reconciliation Open Interface
To enable the Use Reconciliation Open Interface checkbox:
Most likely, the CE_999_INTERFACE_V view already exists within the system. However, the CE_999_INTERFACE table does NOT exist. It must be created as follows:
CREATE TABLE CE.CE_999_INTERFACE AS SELECT * FROM APPS.CE_999_INTERFACE_V; CREATE VIEW CE.CE_999_INTERFACE_V AS SELECT * FROM CE.CE_999_INTERFACE; CREATE SYNONYM APPS.CE_999_INTERFACE FOR CE.CE_999_INTERFACE; CREATE SYNONYM APPS.CE_999_INTERFACE_V FOR CE.CE_999_INTERFACE_V;
Then grant privileges on the table CE_999_INTERFACE:
Grant select, insert, update, delete, index, references, alter on CE_999_INTERFACE to public; col grantee format a8 col grantor format a8 select * from dba_tab_privs where table_name = 'CE_999_INTERFACE';
You may be required to rename OR delete the view in APPS with the same name:
RENAME CE_999_INTERFACE_V TO CE_999_INTERFACE_VS; DROP VIEW APPS.CE_999_INTERFACE_V;
To validate views with status ‘INVALID’:
ALTER VIEW CE_999_RECONCILED_V COMPILE; ALTER VIEW CE_999_REVERSAL_V COMPILE;
In order to recreate the original view APPS.CE_999_INTERFACE_V, see the file $CE_TOP/admin/odf/cevw.odf. You may be required to reconstruct the SQL code from that given in this file.
The CE_999_INTERFACE table seems to have been deleted. The script that was used to create the table must be rerun. To find this table, check the Stage11510 folder to locate the file:
mkdir ~/ce for i in `find /emcb/Stage11510/oraApps/ -iname 'ce*'`; do cp $i ~/ce/; done
On Production:
The CE_999_INTERFACE_V view should already have been created in the database when the database was set up.
To see the contents of the DBA_OBJECTS view:
Col owner format a6 Col object_name format a30 SELECT OWNER, OBJECT_NAME, OBJECT_TYPE, CREATED, STATUS FROM DBA_OBJECTS WHERE OBJECT_NAME LIKE ‘CE_999%’ ;
To see the contents of the DBA_SYNONYMS view:
SET LINESIZE 150 SELECT OWNER, SYNONYM_NAME, TABLE_OWNER, TABLE_NAME FROM DBA_SYNONYMS WHERE SYNONYM_NAME LIKE ‘CE_999%’ ;
To see the contents of the DBA_VIEWS view:
SET LONG 800 SET LINESIZE 800 SET LONGCHUNKSIZE 800 SET WRAP OFF SELECT OWNER, VIEW_NAME, TEXT FROM DBA_VIEWS WHERE VIEW_NAME = ‘CE_999_INTERFACE_V’ ;
To troubleshoot any problems viewing data in the application, the CE_999_TRANSACTIONS_V view must be analyzed. Specifically, the WHERE clause must be examined to determine if all criteria are met.
One of the views in the FROM clause is the AP_BANK_ACCOUNTS. The AP_BANK_ACCOUNTS view needs the CLIENT_INFO variable set in SQL*Plus to view the data in this view. To view the value of this variable, enter:
SELECT USERENV (‘CLIENT_INFO’) FROM DUAL;
OR
SELECT SYS_CONTEXT ('USERENV', 'CLIENT_INFO') FROM DUAL;
To set this parameter, use the DBMS_APPLICATION_INFO package:
EXEC DBMS_APPLICATION_INFO.SET_CLIENT_INFO (‘102’);
By removing all lines from the WHERE clause of then gradually adding them back one at a time in a SQL query, it was determined where the problem occurred. The last line of the WHERE clause was with the Transaction Date and only when this line was added was no rows returned.
This document briefly outlines the procedure for cloning an 11i multi node instance to a single node instance.
Assumptions
1. SOURCE Instance is split on 2 NODES:
SOURCE DB NODE – Both APPS and DB services installed on 1st Server
Application tier services are shut down
SOURCE APPS NODE – Both APPS and DB services installed on 2nd Server
Application tier services are started
2. TARGET instance is to be a single node (may be a new machine or one of the above)
Summary
Shut down the apps server
Start all services on db server
Run autoconfig to convert to instance to a single node
Run the preclone perl scripts
Copy files to new location
Convert source to 2 nodes by running autoconfig
Run clone scripts on Target
Cloning SOURCE Instance
1. Refer to the latest version of the cloning documentation on Metalink (Metalink Doc ID: 230672.1) to determine which patches to apply before cloning.
2. Shutdown the application server by running the adstpall.sh script:
cd /oraprod/oracle/prodcomn/admin/scripts/PROD_finsvr/
./adstpall.sh apps/apps
Log off source APPS node
Log on source DB node
Make multi node a single node to begin cloning.
1. cd /oraprod/oracle/prodcomn/admin/scripts/PROD_finsvr
2. Start all application services on database Source DB Node using adstrtal.sh:
cd /oraprod/oracle/prodcomn/admin/scripts/PROD_finsvr
./adstrtal.sh apps/apps
Even though the listener and concurrent manager are the only services started on PROD, you will need to ensure that you start ALL services. Verify that the Concurrent Manager is up.
3. Run autoconfig:
cd /oraprod/oracle/prodcomn/admin/scripts/PROD_finsvr
./adautocfg.sh
Read prompt carefully, choosing default responses where possible.
Migrating to AutoConfig on the Source DB Node (necessary only if a new rapid clone patch is applied).
4. cd /oraprod/oracle/prodappl/ad/11.5.0/bin (that is, $AD_TOP/bin)
Create appsutil.zip file:
perl admkappsutil.pl
appsutil.zip created in $APPL_TOP/admin/out
On the database tier (finmgr), copy or FTP the appsutil.zip file to the RDBMS_ORACLE_HOME.
5. Copy file appsutil.zip to /oraprod/oracle/proddb/9.2.0/*
unzip -o appsutil.zip
Generate and Apply AutoConfig Configuration files
This step performs the conversion to AutoConfig. Once completed, the previous configuration will not be available. The database server and the database listener must remain available during the AutoConfig run. All other database tier services should be shut down.
Warning: Running AutoConfig on the database node will update the RDBMS network listener file. Save the listener file before you run autoconfig.
7. Change directory to RDBMS_ORACLE_HOME/appsutil/bin
cd /oraprod/oracle/proddb/9.2.0/appsutil/bin
adconfig.sh contextfile=PROD_finmgr.xml appspass=apps*
8. Prepare the source system database tier for cloning
cd /oraprod/oracle/proddb/9.2.0/appsutil/scripts/PROD_finmgr (that is, $RBDMS_ORACLE_HOME/appsutil/scripts/$CONTEXT_NAME
perl adpreclone.pl db Tier
9. Prepare the source system application tier for cloning
cd /oraprod/oracle/prodcomn/admin/scripts/PROD_finmgr (that is, $COMMON_TOP/admin/scripts/$CONTEXT_NAME)
perl adpreclone appsTier
10. Stop all services (DB and APPS)
cd /oraprod/oracle/prodcomn/admin/scripts/PROD_finmgr/
./adstpall.sh apps/apps
Shutdown database listener (addlnctl.sh stop apps/apps)
Shutdown database (addbctl.sh stop apps/apps)
Or run the stopDB script in /oraprod/scripts (doing so will attempt to shut the services again)
11. Copy files
Create the respective folders on target node:
clondb
clondata
clonora
clonappl
cloncomn
Copy the files from Source DB Node to Target Node. As root user, mount source node on target Node by editing /etc/exports on target node and adding the line where the source files are located (i.e. /oraprod/oracle).
Then restart NFS on the target server by entering the following command at the command prompt (as root user):
service nfs restart
12. On the target node (that is, where the clone is being created), do the following:
a. su – applmgr
b. cd /orapatch (new clone top directory)
c. mkdir prodfiles (where we want the files copied to)
d. su – root
e. Mount SOURCE directory onto TARGET directory
f. Copy the files using the operating system utilities
May need to ensure that the owner name and group of target directories are applmgr and dba respectively and not nfsmount.
To convert from single node to multi node:
Run autoconfig on Source Apps Node to make Source Instance 2 Node.
When a report is run on the target instance we get an error: “File server could not verify its initialization parameters when viewing output”. Patch 4244610 was applied, but this did not resolve the issue.
Removed spaces from listener.ora file in /orapatch/oracle/clonora/8.0.6/network/admin/clon_newtest/listener.ora. Removed all spaces near the APPLFSTT parameter. Removed everything and left reference to database alone. Bounce listener.
To change color and name, go to SysAdmin/ Security/Profile/System, under profile %Site%, change Site Name to new name. To change color, navigate to profile %Color% JavaColorScheme and Service:Visual Attributes for Settings where the colour can also be changed.
Step 1. Shutdown the TEST instance:
./oratest/scripts/stopTEST.sh
Step 2. Backup the directory /oratest/oracle and all it subdirectories.
Step 3. Rename the directory /oratest/oracle to /oratest/oracle_backup
Step 4. Restore from backup /oratest/oracle
Step 5. Verify Recovery by Comparing file sizes between oracle and oracle_backup
Step 6. Start the TEST instance:
./oratest/scripts/startTEST.sh
Step 7. Log on to TEST instance and TEST functionality.
Step 8. Remove directory /oratest/oracle_backup
Recent Comments