Mandalika's scratchpad [ Work blog @Oracle | Stock Market Notes | My Music Compositions ]

Old Posts: 09.04  10.04  11.04  12.04  01.05  02.05  03.05  04.05  05.05  06.05  07.05  08.05  09.05  10.05  11.05  12.05  01.06  02.06  03.06  04.06  05.06  06.06  07.06  08.06  09.06  10.06  11.06  12.06  01.07  02.07  03.07  04.07  05.07  06.07  08.07  09.07  10.07  11.07  12.07  01.08  02.08  03.08  04.08  05.08  06.08  07.08  08.08  09.08  10.08  11.08  12.08  01.09  02.09  03.09  04.09  05.09  06.09  07.09  08.09  09.09  10.09  11.09  12.09  01.10  02.10  03.10  04.10  05.10  06.10  07.10  08.10  09.10  10.10  11.10  12.10  01.11  02.11  03.11  04.11  05.11  07.11  08.11  09.11  10.11  11.11  12.11  01.12  02.12  03.12  04.12  05.12  06.12  07.12  08.12  09.12  10.12  11.12  12.12  01.13  02.13  03.13  04.13  05.13  06.13  07.13  08.13  09.13  10.13  11.13  12.13  01.14  02.14  03.14  04.14  05.14  06.14  07.14  09.14  10.14 


Monday, March 26, 2007
 
Migrating Linux Applications to Solaris

If you are a developer looking for some guidance on porting Linux applications to Solaris operating system (running on x86/x64/SPARC architectures), here is a short but useful porting guide for you:

Porting to the Solaris™ OS: A guide for Linux developers

__________
Technorati tags:
| | |


Sunday, March 25, 2007
 
Upgrading Oracle E-Business Suite 11.5.10 to CU2

Some notes I collected from the exercise of upgrading Oracle E-Business Suite 11.5.10 to 11.5.10 CU2*, on Sun Solaris:
  1. [Middle-tier] Apply patch 4318672 on all application server nodes

    • Enable maintenance mode by running adadmin.

    • Apply patch 4318672 with the help of adpatch tool.

    • Carefully read README.txt of 4318672, and run Technology Stack Validation tool in both middle- and db-tiers.

      Note:

      • Set PARALLEL_MAX_SERVERS parameter to the default value returned by show parameter cpu_count. For example, if the database is running on a SunFire T2000 server, set PARALLEL_MAX_SERVERS to 32.

      • [DB-tier] When prompted for applications context file, supply the output of echo $CONTEXT_FILE environment variable.

      • After running Technology Stack Validation tool, the generated html reports from middle- and db-tiers should have an 'ALLPASS' status. Otherwise, fix the errors and re-run the TSV tool until it achieves ALLPASS status.

  2. [Middle-tier] Apply patch 4229931 on all application server nodes

    • Apply patch 4229931 with the help of adpatch tool.

      Location of adpatch log file: $APPL_TOP/admin/<DBInstanceName>/log/adrelink.log.

  3. [Concurrent Processing node] Apply patch 4297568

    • Enable maintenance mode by running adadmin tool, if concurrent managers are not running on the same machine where all application server processes are running; then apply patch 4297568 by following the special instructions posted in README.txt file.

      Note:
      • Do NOT use adpatch tool to apply this patch, 4297568. Read the instructions of README.txt.

      • Without this patch, 4297568, CU2 maintenance patch, 3480000, may fail with error messages like:
        ld: fatal: file  /ebiz/visappl/sht/11.5.0/lib/ilog/5.1/libcplex8.a: 
        open failed: No such file or directory
        ld: fatal: File processing errors. No output written to /ebiz/visappl/demoappl/mst/11.5.0/bin/MSTCPP
        See Metalink document 311635.1 for more.

      • Some executables need to be re-linked as part of this step. Re-linking can be done in two ways:

        1. Using adadmin tool.

          Navigation: Maintain Applications Files -> Relink Applications Programs. This step re-links all the executables of the application.

        2. To re-link one or more applications' executable programs, run adrelink from the operating system shell:

          Syntax:
          adrelink force=y "<product> <module>"

          eg., To re-link MSO: MSONEW, run:

          adrelink force=y "MSO MSONEW"

          Shutdown all concurrent managers before running adrelink.


    • Disable maintenance mode by running adadmin, if concurrent managers are not running on the same machine where all application server processes are running.

  4. [Middle-tier] Apply release 11.5.10.2 maintenance pack, 3480000

    • Apply patchset, 4712852, with the help of adpatch tool.

    • Apply release 11.5.10.2 maintenance pack, 3480000, with the help of adpatch tool. Spare some time to read Metalink document 316365.1, before applying the maintenance pack.

      Note:

      • Stop all application server services including concurrent managers before running adpatch on 3480000 (CU2 maintenance pack). Failure to do so may result in the following error(s):
        ATTENTION: All workers either have failed or are waiting:
                FAILED: file afcmgr.odf on worker 1
        ATTENTION: please fix the above failed worker(s) so the manager can continue
        When such an error occurs, do the following:

        • Open up another shell and shutdown all services by running adstpall stop apps/apps command.

        • Run: adctrl
          • Check: 1) Show Worker Status.
          • 2) Tell worker to restart a failed job

          After this step adpatch resumes automatically.

        • adworker log file(s) default location: $APPL_TOP/admin/<DBInstanceName>/log.

    • Troubleshooting:

      • ERROR: file azstrctall.ldt on worker 1

        Follow the instructions of Metalink document '331284.1 Applying 3480000 Patch --- azstrctall.ldt failed --- ORA-20001: The specified api_code does not exist'.

      • FAILED: file AsgRunInst.class on worker 1

        Follow the instructions of Metalink document 270156.1. In short, skip the failed thread with an hidden option {of adctrl} : 8) Skip & Restart for worker thread 1. Run the failed thread manually, later.


  5. [Middle-tier] Disable maintenance mode by running adadmin
_________
* CU2 = Consolidated Update 2.

Reference Document:
Metalink document 316366.1 11.5.10 Oracle E-Business Suite Consolidated Update 2 (CU2).

Technorati tags:
| |


Wednesday, March 21, 2007
 
Oracle Apps on T2000: ORA-04020 during Autoinvoice

The goal of this brief blog post is to provide a quick solution to all Sun-Oracle customers who may run into a deadlock when a handful of threads are running Autoinvoice Master Program (RAXMTR) on SunFire CoolThreads server, T2000.

If you are not happy with Autoinvoice performance, or if you feel like the AI program is crawling* when multiple threads are handling the submitted jobs, check the trace files generated in udump directory for a pattern like 'ORA-04020: deadlock detected while trying to lock object ...'. If there is a deadlock, you may see something like:

*** ACTION NAME:(Concurrent Request) 2007-03-20 17:55:25.238
*** MODULE NAME:(RAXMTR) 2007-03-20 17:55:25.238
*** SERVICE NAME:(SYS$USERS) 2007-03-20 17:55:25.238
*** SESSION ID:(2469.90) 2007-03-20 17:55:25.238

A deadlock among DDL and parse locks is detected.
This deadlock is usually due to user errors in
the design of an application or from issuing a set
of concurrent statements which can cause a deadlock.
This should not be reported to Oracle Support.
The following information may aid in finding
the errors which cause the deadlock:

ORA-04020: deadlock detected while trying to lock object AR.RA_INTERFACE_LINES_ALL

--------------------------------------------------------
object waiting waiting blocking blocking
handle session lock mode session lock mode
-------- -------- -------- ---- -------- -------- ----
457bf9a78 479d813f0 46dddbd10 X 47fd9ce08 468973ee0 S
46561f560 47fd9ce08 46894f520 X 479d813f0 46dc4edf8 X
--------------------------------------------------------
...
...

Setting profile option AR: Autoinvoice Gather Statistics to Yes or leaving it to the default value of NULL is one of the reasons for this deadlock. When the profile option is set to either Yes or NULL, by default it runs Autoinvoice Gather Statistics every time Autoinvoice program is run.

Running Autoinvoice Gather Statistics process is too expensive; and it is not necessary to run this process as part of the Autoinvoice process. Hence Autoinvoice Gather Statistics can be safely turned off as part of a normal Autoinvoice processing exercise.

To implement this, simply set the profile option AR: Autoinvoice Gather Statistics to No. Navigation: System Administrator responsibility -> Profile -> System.

Perhaps this solution is applicable to all other platforms where this deadlock issue shows up with quite a few threads running Autoinvoice (RAXMTR). I'm not sure - I never tried it.
________

*Run the following SQL to get the list of Autoinvoice request IDs, request date along with the actual start and completion times.
SELECT REQUEST_ID,
TO_CHAR (REQUEST_DATE, 'yyyymmddhh24mi') "REQUEST DATE",
TO_CHAR (ACTUAL_START_DATE, 'yyyymmddhh24mi') "START DATE",
TO_CHAR (ACTUAL_COMPLETION_DATE, 'yyyymmddhh24mi') "COMPLETION DATE"
FROM FND_CONCURRENT_REQUESTS
WHERE REQUEST_ID IN
(SELECT REQUEST_ID
FROM APPLSYS.FND_CONCURRENT_REQUESTS FCR, APPLSYS.FND_CONCURRENT_PROGRAMS FCP
WHERE FCP.CONCURRENT_PROGRAM_ID = FCR.CONCURRENT_PROGRAM_ID
AND FCP.CONCURRENT_PROGRAM_NAME = 'RAXTRX'
AND ACTUAL_COMPLETION_DATE > <desired_date>);
________
| | | |



2004-2014 

This page is powered by Blogger. Isn't yours?