Oracle Fusion Application Installation brief overview

Background
Oracle Fusion Application is best feature mix of e-business suite, jd edwards and peoplesoft integrated with Fusion Middleware products.

Installation of Fusion Application would mean installation of Fusion application components and all the fmw products.

Oracle has simplified install and configure by means of automated installation and configuration along with install validation. Oracle call this automation as provisioning.

Installation process. 
So Provisioning basically means installing various oracle products, configuration them to work with each other using oracle supplied special software(framework/life cycle managment tools)

A Framework software executes the installation, configuration and validation of all the required software components.

All the required inputs for installation/configuration and gathered in step called "creating responce file", This is the first step after installation of framework/life cycle managment tools software installation.

you would invoke resonponce file creation step using provisiongWizard and supply inputs in interview phase, after which a responce file is created. This will will be supplied during Applicaiton provisioning phase.

Application provisiong phase runs in below order.

Preverify
Install
Preconfigure
Configure
Configure Secondary
Post Configure
Startup
Validation.

Regards
Manoj

Tuning Garbage Collection Outline

Tuning Garbage Collection Outline (Oracle Apps) 

This document is a summary or outline of Sun's document: Tuning Garbage collection with the 1.4.2 Hotspot JVM located here: http://java.sun.com/docs/hotspot/gc1.4.2/

1.0 Introduction

    * For many applications garbage collection performance is not significant
    * Default collector should be first choice

2.0 Generations

    * Most straightforward GC will just iterate over every object in the heap and determine if any other objects reference it.
          o This gets really slow as the number of objects in the heap increase
    * GC's therefor make assumptions about how your application runs.
    * Most common assumption is that an object is most likely to die shortly after it was created: called infant mortality
    * This assumes that an object that has been around for a while, will likely stay around for a while.
    * GC organizes objects into generations (young, tenured, and perm) This is important!

2.1 Performance Considerations

    * Ways to measure GC Performance
          o Throughput - % of time not spent in GC over a long period of time.
          o Pauses - app unresponsive because of GC
          o Footprint - overall memory a process takes to execute
          o Promptness - time between object death, and time when memory becomes available
    * There is no one right way to size generations, make the call based on your applications usage.

2.2 Measurement

    * Throughput and footprint are best measured using metrics particular to the application.
    * Command line argument -verbose:gc output
      [GC 325407K->83000K(776768K), 0.2300771 secs]
          o GC - Indicates that it was a minor collection (young generation). If it had said Full GC then that indicates that it was a major collection (tenured generation).
          o 325407K - The combined size of live objects before garbage collection.
          o 83000K - The combined size of live objects after garbage collection.
          o (776768K) - the total available space, not counting the space in the permanent generation, which is the total heap minus one of the survivor spaces.
          o 0.2300771 secs - time it took for garbage collection to occur.
    * You can get more detailed output using -XX:+PrintGCDetails and -XX:+PrintGCTimeStamps

3 Sizing the Generations

    * The -Xmx value determines the size of the heap to reserve at JVM initialization.
    * The -Xms value is the space in memory that is committed to the VM at init. The JVM can grow to the size of -Xmx.
    * The difference between -Xmx and -Xms is virtual memory (virtually committed)

3.1 Total Heap

    * Total available memory is the most important factor affecting GC performance
    * By default the JVM grows or shrinks the heap at each GC to keep the ratio of free space to live objects at each collection within a specified range.
          o -XX:MinHeapFreeRatio - when the percentage of free space in a generation falls below this value the generation will be expanded to meet this percentage. Default is 40
          o -XX:MaxHeapFreeRatio - when the percentage of free space in a generation exceeded this value the generation will shrink to meet this value. Default is 70
    * For server applications
          o Unless you have problems with pauses grant as much memory as possible to the JVM
          o Set -Xms and -Xmx close to each other or equal for a faster startup (removes constant resizing of JVM). But if you make a poor choice the JVM can't compensate for it.
          o Increase memory sa you increase # of processors because memory allocation can be parallelized.

3.2 The Young Generation

    * The bigger the young generation the less minor GC's, but this implies a smaller tenured generation which increases the frequency of major collections.
    * You need to look at your application and determine how long your objects live for to tune this.
    * -XX:NewRatio=3 - the young generation will occupy 1/4 the overall heap
    * -XX:NewSize - Size of the young generation at JVM init. Calculated automatically if you specify -XX:NewRatio
    * -XX:MaxNewSize - The largest size the young generation can grow to (unlimited if this value is not specified at command line)

3.2.1 Young Generation Guarantee

    * The -XX:SurvivorRatio option can be used to tune the number of survivor spaces.
    * Not often important for performance
          o -XX:SurvivorRatio=6 - each survivor space will be 1/8 the young generation
          o If survivor spaces are too small copying collection overflows directly into the tenured generation.
          o Survivor spaces too large uselessly empty
          o -XX:+PrintTenuringDistribution - shows the threshold chosen by JVM to keep survivors half full, and the ages of objects in the new generation.
    * Server Applications
          o First decide the total amount of memory you can afford to give the virtual machine. Then graph your own performance metric against young generation sizes to find the best setting.
          o Unless you find problems with excessive major collection or pause times, grant plenty of memory to the young generation.
          o Increasing the young generation becomes counterproductive at half the total heap or less (whenever the young generation guarantee cannot be met).
          o Be sure to increase the young generation as you increase the number of processors, since allocation can be parallelized.

4 Types of Collectors

    * Everything to this point talks about the default garbage collector, there are other GC's you can use
    * Throughput Collector - Uses a parallel version of the young generation collector
          o -XX:+UseParallelGC
          o Tenured collector is the same as in default
    * Concurrent Low Pause Collector
          o Collects tenured collection concurrently with the execution of the app.
          o The app is paused for short periods during collection
          o -XX:+UseConcMarkSweepGC
          o To enable a parallel young generation GC with the concurrent GC add -XX:+UseParNewGC to the startup. Don't add -XX:+UseParallelGC with this option.
    * Incremental Low Pause Collector
          o Sometimes called Train Collector
          o Collects a portion of the tenured generation at each minor collection.
          o Tries to minimize large pause of major collections
          o Slower than the default collector when considering overall throughput
          o Good for client apps (my observation)
          o -Xincgc
    * Don't mix these options, JVM may not behave as expected.

4.1 When to use Throughput Collector

    * Large number of processors
    * Reduces serial execution time of app, by using multiple threads for GC
    * App with lots of threads allocating objects should use this with a large young generation
    * Server Applications (my observation)

4.2 The Throughput collector

    * By default the throughput collector uses the number of CPU's as its value for number of GC threads.
    * On a computer with one CPU it will not perform as well as the default collector
    * Overhead from parallel execution (synchronization costs)
    * With 2 CPU's the throughput collector performs as well as the default garbage collector.
    * With more then 2 CPU's you can expect to see a reduction in minor GC pause times
    * You can control the number of threads with -XX:ParallelGCThreads=n
    * Fragmentation can occur
          o Reduce GC threads
          o Increase Tenured Generation size

4.2.1 Adaptive Sizing

    * Keeps stats about GC times, allocation rates, and free space then sizes young and tenured generation to best fit the app.
    * J2SE 1.4.1 and later
    * -XX:+UseAdaptiveSizePolicy (on by default)

4.2.2 Aggressive Heap

    * Attempts to make maximum use of physical memory for the heap
    * Inspects computer resources (memory, num processors) and sets params optimal for long running memory allocation intensive jobs.
    * Must have at least 256MB of RAM
    * For lots of CPU's and RAM, but 1.4.1+ has shown improvements on 4-Way machines.
    * -XX:+AggressiveHeap

4.3 When to use the Concurrent Low Pause Collector

    * Apps that benefit from shorter GC pauses, and can share resources with GC during execution.
    * Apps with large sets of long living data (tenured generation)
    * Two or more processors
    * Interactive apps with modest tenured generation size, and one CPU

4.4 The Concurrent Low Pause Collector

    * Uses a separate GC thread to do parts of the major collection concurrently with the app threads.
    * Pauses App threads in the beginning of a collection and toward the middle (longer pause in middle)
    * The rest of the GC is in a single thread that runs at the same time as the app

4.4.1 Overhead of Concurrency

    * Doesn't provide much of an advantage on single processor machines.
    * Fragmentation can occur.
    * Two processor machine eliminates pauses due to the GC thread.
    * The more CPU's the advantages of concurrent collector increase.

4.4.2 Young Generation Guarantee

    * There has to be enough contiguous space available in the tenured generation for all objects in the eden and one survivor space.
    * A larger heap is needed compared to the default collector.
    * Add the size of the young generation to the tenured generation.

4.4.3 Full Collections

    * If the concurrent collector is unable to finish collecting the tenured generation before the tenured generation fills up, the application is paused and the collection is completed.
    * When this happens you should make some adjustments to your GC params

4.4.4 Floating Garbage

    * Floating Garbage - Objects that die while the GC is running (after they have been checked).
    * Increase the tenured generation by 20% to reduce floating garbage.

4.4.5 Pauses

    * First Pause - marks live objects - initial marking
    * Second Pause - remarking phase - checks objects that were missed during the concurrent marking phase due to the concurrent execution of the app threads.

4.4.6 Concurrent Phases

    * Concurrent Marking phase occurs between initial mark and remarking phase.
    * Concurrent sweeping phase collects dead objects after the remarking phase.

4.4.7 Measurements with the Concurrent Collector

    * Use -verbose:gc with -XX:+PrintGCDetails
    * vCMS-initial-mark shows GC stats for the initial marking phase
    * CMS-concurrent-mark - shows GC stats for concurrent marking phase.
    * CMS-concurrent-sweep - shows stats for concurrent sweeping phase
    * CMS-concurrent-preclean - stats for determining work that can be done concurrently
    * CMS-remark - stats for the remarking phase.
    * CMS-concurrent-reset - concurrent stuff is done, ready for next collection.

4.4.8 Parallel Minor Collection Options with Concurrent Collector

    * -XX:+UseParNewGC - for multiprocessor machines, enables multi threaded young generation collection.
    * -XX:+CMSParallelRemarkEnabled - reduce remark pauses

4.5 When to use the Incremental Low Pause Collector

    * Use when you can afford to tradeoff longer and more frequent young generation GC pauses for shorter tenured generation pauses
    * You have a large tenured generation
    * Single Processor

4.6 The Incremental Low Pause Collector

    * Minor collections same as default collector.
    * Don't use try to use parallel GC with this collector
    * Incrementally Collects parts of the tenured generation at each young collection.
    * Tries to avoid long major collections by doing small chunks each minor collection.
    * Can cause fragmentation of the heap. Sometimes need to increase tenured generation size compared to the default.
    * There is some overhead required to maintain the position of the incremental collector. Less overhead than is required by the default collector.
    * First try the default collector, and adjust heap sizing. If major pauses are too long try incremental.
    * If the incremental collector can't collect the tenured generation fast enough you will run out of memory, try reducing the young generation.
    * If young generation collections do not free any space, could be because of fragmentation. Increase tenured generation size.

4.6.1 Measurements with the Incremental Collector

    * -verbose:gc and -XX:+PrintGCDetails
    * Look for the Train: to see the stats for the incremental collection.

5 Other Considerations

    * The permanent generation may be a factor on apps that dynamically generate and load many classes (JSP, CFM application servers)
    * You may need to increase the MaxPermSize, eg: -XX:MaxPermSize=128m
    * Apps that rely on finalization (finalize method, or finally clauses) will cause lag in garbage collection. This is a bad idea, use only for errorious situations.
    * Explicit garbage collection calls (System.gc()) force a major collection. You can measure the effectiveness of these calls by disabling them with -XX:+DisableExplicitGC
    * RMI garbage collection intervals can be controlled with
          o -Dsun.rmi.dgc.client.gcInteraval=3600000
          o -Dsun.rmi.dgc.server.gcInterval=3600000
    * On Solaris 8+ you can enable libthreads, lightweight thread processes, these may increase thread performance.
    * To enable add /usr/lib/lwp to LD_LIBRARY_PATH
    * Soft References cleared less aggressively in server.
    * -XX:SoftRefLRUPolicyMSPerMB=10000
    * Default value is 1000, or one second per MB

6 Conclusion

    * GC can be bottleneck in your app.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

There are some good notes on JVM tuning from Mike Shaw on Steven Chan’s blog  here , here and here and some good Metalink notes at end of this post.
                     Important thing missing from all these notes (for some one like me who is new to Java) is basics of Garbage Collection, Generation and how to read GC output.
In this post I’ll start with basics of JVM GC (Garbage Collection) and then in next post apply this theory for real time performance issues w.r.t. JVM (11i Java Virtual Machine) .

Garbage - Java object is considered garbage when it can no longer be reached from any pointer in the running program.

Generations - Memory in JVM is managed in terms of generation i.e. Young generation and tenured generation. Memory pool holding object of different ages like young, tenured. If a particular generation fills up, garbage collection occurs.

A. Young generation - Objects are initially allocated in Young generation (most of objects die here). When Young generation fills up, it causes Minor Garbage Collection. Any objects survived after Minor GC (Garbage Collection) are moved to Tenured Generation.  Minor Garbage collection is quick as compared to Full/Major GC.

B. Tenured generation - Surviving objects (from young generation) after minor garbage collection are moved to area called tenured generation, When tenured generation fills up it causes major collection (aka Full GC or Full Garbage Collection). Major collection is slow as it involves all live objects.

Garbage Collection (GC) - is program which clears garbage(dead java objects). Garbage Collection work on fundamental principle that majority of java objects die young (quickly after arriving in JVM). There are two kind of Garbage Collection Minor Garbage Collection and Major Garbage Collection (aka Full GC)

Example of Minor GC -  3824.164: [GC 196725K->141181K(209864K), 0.3295949 secs]
Example of Minor GC -  3841.051: [Full GC 150466K->87061K(217032K), 3.2626248 secs]

Pauses: is the time when application becomes unresponsive because garbage collection is occurring.

.

Understanding JVM parameter for 11i
Sizing the generation is very important in tuning JVM GC. Before jumping to Sizing generation (Young and Tenured) lets look at default 11i JVM parameters

In context file($APPL_TOP/ admin/ $CONTEXT_NAME.xml) default entry for JVM is like

<jvm_options oa_var=”s_jvm_options” osd=”Solaris”>-verbose:gc -Xmx512M -Xms128M -XX:MaxPermSize=128M -XX:NewRatio=2-XX:+PrintGCTimeStamps -XX:+UseTLAB </jvm_options>

1. Above line represents JVM (OACoreGroup) size in 11i
2. -Xms128M, means start with 128MB heap size
3. -Xmx512M, means grow JVM heap size upto max size of 512 MB
4. -XX:NewRatio=2 is to control young generation i.e. ratio between young and tenured generation is 1:2 (i.e. if size of young generation is 50 MB then size of tenured generation should be approx. 100MB)
5. -XX:MaxPermSize=128M limit the permanent generation to 128M (permanent generation is part/area in tenured generation)
6. -XX:+UseTLAB represents to use thread-local object allocation
7. There are two more parameters (11i JVM uses default values) -XX:MinHeapFreeRatio=<minimum> & -XX:MaxHeapFreeRatio=<maximum> with default value of 40 & 70 resp. (for Solaris)

If percentage of free space in generation falls below 40%, size of generation will expand and if percentage of free space exceeds 70%, the size of generation will shrunk.

.
Various type of Garbage Collector
From JDK 1.4.2 there are total 4 type of collectors (prior to 1.4.2 it was just one collector i.e. default collector)

1. Default Collector: JDK prior to 1.4.2 uses default collector. If you don’t specify any parameter with JVM default is default collector.

2. ThroughPut Collector : This collector uses parallel version of young generation collector but Tenrured generation is collected in normal way. To set throughput collector use -XX:+UseParallelGC  so change

<jvm_options oa_var=”s_jvm_options” osd=”Solaris”>-verbose:gc -Xmx512M -Xms128M -XX:MaxPermSize=128M -XX:NewRatio=2 -XX:+PrintGCTimeStamps -XX:+UseTLAB </jvm_options>
to
<jvm_options oa_var=”s_jvm_options” osd=”Solaris”>-verbose:gc -Xmx512M -Xms128M -XX:MaxPermSize=128M -XX:NewRatio=2 -XX:+PrintGCTimeStamps -XX:+UseTLAB -XX:+UseParallelGC</jvm_options>

3. Concurrent Low Pause Collector : Concurrent Collector is used to collect tenured generation collection concurrently with execution of application. Parallel version of collector is used for young generation. To set Concurrent Low Pause Collector use -XX:+UseConcMarkSweepGC
like
<jvm_options oa_var=”s_jvm_options” osd=”Solaris”>-verbose:gc -Xmx512M -Xms128M -XX:MaxPermSize=128M -XX:NewRatio=2 -XX:+PrintGCTimeStamps -XX:+UseTLAB -XX:+UseConcMarkSweepGC</jvm_options>

4. Incremental low pause collector : This collector collects just portion of tenured generation at each minor garbage collection. To use Incremental low pause collector use
-Xincgc

If you are on JDK 1.4.2 with multi CPU try setting Concurrent Low Pause Collectoras Garbage Collector.

Thumb rule for Grabage Collection/ JVM tuning w.r.t. 11i
1.Stay on latest JVM/JDK version where ever possible (latest certified with 11i is JRE 6, you should be at-least 1.4.2 and higher)
2. For OACoreGroup consider no more than 100 active users per JVM
3. There should NOT be more than 1 active JVM per CPU
4. Try to reduce GC (Garbage Collection) frequency (specially Major/Full GC). Play with various JVM parameters like (-Xmx, -Xms, -XX:MaxPermSize, -XX:NewRatio, -XX:+UseParallelGC/ -XX:+UseConcMarkSweepGC)
5. If you are on JDK 1.4.2 with multiple CPU middle tier, use Concurrent Low Pause Garbage Collector  by setting -XX:+UseConcMarkSweepGC with JVM
6. If you are using Oracle Configurator, assign dedicated JVM for configurator requests
7. Try setting JVM max size NOTgreater than 1 GB, (use multiple JVM’s of 512MB or 1024 MB), this is to reduce GC time (more heap size means more time in GC)
8. Minor GC should be occurring at interval long enough to allow many objects to die young (i.e. lot of objects should die between two minor GC).
9. Throughput (which is time NOT spent on GC) is inversely proportion to amount of memory. Higher the memory for JVM, more time for GC meaning low throughput.
10. Unless you have problems with pauses (time when application becomes unresponsive because garbage collection is occurring), try granting as much memory as possible to VM (128 to 512 is good start and fine tune as per load testing results)
.

How to find JDK version used by Apache/Jserv (JVM) in 11i ?

In context file search for parameter like s_jdktop

<JDK_TOP oa_var=”s_jdktop”>/oracle/apps/11i/vis11icomn/util/java/1.4/j2sdk1.4.2_04</JDK_TOP>

Where is JVM log location in 11i ?
$IAS_ORACLE_HOME/ Apache/ Jserv/ logs/ jvm/ OACoreGroup.0.stdout  (GC output)
$IAS_ORACLE_HOME/ Apache/ Jserv/ logs/ jvm/ OACoreGroup.0.stderr  (JVM Error)

.

How to read GC (JVM stdout) file ?

Example of JVM out file to understand Garbage Collection in 11i

3824.164: [GC 196725K->141181K(209864K), 0.3295949 secs]
3840.734: [GC 207741K->150466K(217032K), 0.3168890 secs]
3841.051: [Full GC 150466K->87061K(217032K), 3.2626248 secs]
3854.717: [GC 155413K->97857K(215568K), 0.2732267 secs]
3874.714: [GC 166209K->109946K(215568K), 0.3498301 secs]

1. Line 1,2 4 and 5 are example of Minor Collection
2. Line 3 (Full GC) is example of Major Collection
3. First entry in each line is time in seconds since JVM started, To find out time between two GC (Garbage Collection) just subtract second entry from first i.e. (3840.734 - 3824.164 = 16.57 seconds)
4. 196725K->141181K in first line indicates combined size of live objects before and after Garbage Collection (GC)
5. (209864K) in first line in parenthesis, represents object after minor collection that aren’t necessarily alive but can’t be reclaimed, either because they are directly alive, or because they are referenced from objects in tenured generation.
6. 0.3295949 secs in first line represents time taken to run minor collection.
7. Full GC in line three represents Full Garbage Collection or Major Collection

References

• 362851.1  Guidelines to setup the JVM in Apps E-Business Suite 11i and R12
• 370583.1  Basic troubleshooting of JVM consuming cpu or too many JDBC connections in Apps 11i
• 567647.1  Using Various Garbage Collection Methods For JVM Tuning
• 390031.1  Performance Tuning Forms Listener Servlet In Oracle Applications

Regards

Manoj

Categories of Java HotSpot VM Options

Categories of Java HotSpot VM Options (E-business suite, Apache, 10G AS)

Standard options recognized by the Java HotSpot VM are described on the Java Application Launcher reference pages for Windows, Solaris and Linux. This document deals exclusively with non-standard options recognized by the Java HotSpot VM:

    * Options that begin with -X are non-standard (not guaranteed to be supported on all VM implementations), and are subject to change without notice in subsequent releases of the JDK.
    * Options that are specified with -XX are not stable and are not recommended for casual use. These options are subject to change without notice.


Some Useful -XX Options


Default values are listed for Java SE 6 for Solaris Sparc with -server. Some options may vary per architecture/OS/JVM version. Platforms with a differing default value are listed in the description.

    * Boolean options are turned on with -XX:+<option> and turned off with -XX:-<option>.
    * Numeric options are set with -XX:<option>=<number>. Numbers can include 'm' or 'M' for megabytes, 'k' or 'K' for kilobytes, and 'g' or 'G' for gigabytes (for example, 32k is the same as 32768).
    * String options are set with -XX:<option>=<string>, are usually used to specify a file, a path, or a list of commands

Flags marked as manageable are dynamically writeable through the JDK management interface (com.sun.management.HotSpotDiagnosticMXBean API) and also through JConsole. In Monitoring and Managing Java SE 6 Platform Applications, Figure 3 shows an example. The manageable flags can also be set through jinfo -flag.

The options below are loosely grouped into three categories.

    * Behavioral options change the basic behavior of the VM.
    * Performance tuning options are knobs which can be used to tune VM performance.
    * Debugging options generally enable tracing, printing, or output of VM information.


Behavioral Options

Option and Default Value
Description
-XX:-AllowUserSignalHandlers Do not complain if the application installs signal handlers. (Relevant to Solaris and Linux only.)

-XX:AltStackSize=16384 Alternate signal stack size (in Kbytes). (Relevant to Solaris only, removed from 5.0.)

-XX:-DisableExplicitGC Disable calls to System.gc(), JVM still performs garbage collection when necessary.

-XX:+FailOverToOldVerifier Fail over to old verifier when the new type checker fails. (Introduced in 6.)

-XX:+HandlePromotionFailure The youngest generation collection does not require a guarantee of full promotion of all live objects. (Introduced in 1.4.2 update 11) [5.0 and earlier: false.]

-XX:+MaxFDLimit Bump the number of file descriptors to max. (Relevant  to Solaris only.)

-XX:PreBlockSpin=10 Spin count variable for use with -XX:+UseSpinning. Controls the maximum spin iterations allowed before entering operating system thread synchronization code. (Introduced in 1.4.2.)

-XX:-RelaxAccessControlCheck Relax the access control checks in the verifier. (Introduced in 6.)

-XX:+ScavengeBeforeFullGC Do young generation GC prior to a full GC. (Introduced in 1.4.1.)

-XX:+UseAltSigs Use alternate signals instead of SIGUSR1 and SIGUSR2 for VM internal signals. (Introduced in 1.3.1 update 9, 1.4.1. Relevant to Solaris only.)

-XX:+UseBoundThreads Bind user level threads to kernel threads. (Relevant to Solaris only.)

-XX:-UseConcMarkSweepGC Use concurrent mark-sweep collection for the old generation. (Introduced in 1.4.1)

-XX:+UseGCOverheadLimit Use a policy that limits the proportion of the VM's time that is spent in GC before an OutOfMemory error is thrown. (Introduced in 6.)

-XX:+UseLWPSynchronization Use LWP-based instead of thread based synchronization. (Introduced in 1.4.0. Relevant to Solaris only.)

-XX:-UseParallelGC Use parallel garbage collection for scavenges. (Introduced in 1.4.1)

-XX:-UseParallelOldGC Use parallel garbage collection for the full collections. Enabling this option automatically sets -XX:+UseParallelGC. (Introduced in 5.0 update 6.)

-XX:-UseSerialGC Use serial garbage collection. (Introduced in 5.0.)

-XX:-UseSpinning Enable naive spinning on Java monitor before entering operating system thread synchronizaton code. (Relevant to 1.4.2 and 5.0 only.) [1.4.2, multi-processor Windows platforms: true]

-XX:+UseTLAB Use thread-local object allocation (Introduced in 1.4.0, known as UseTLE prior to that.) [1.4.2 and earlier, x86 or with -client: false]

-XX:+UseSplitVerifier Use the new type checker with StackMapTable attributes. (Introduced in 5.0.)[5.0: false]

-XX:+UseThreadPriorities Use native thread priorities.

-XX:+UseVMInterruptibleIO Thread interrupt before or with EINTR for I/O operations results in OS_INTRPT. (Introduced in 6. Relevant to Solaris only.)


Back to Options

Performance Options

Option and Default Value
Description
-XX:+AggressiveOpts Turn on point performance compiler optimizations that are expected to be default in upcoming releases. (Introduced in 5.0 update 6.)

-XX:CompileThreshold=10000 Number of method invocations/branches before compiling [-client: 1,500]

-XX:LargePageSizeInBytes=4m Sets the large page size used for the Java heap. (Introduced in 1.4.0 update 1.) [amd64: 2m.]

-XX:MaxHeapFreeRatio=70 Maximum percentage of heap free after GC to avoid shrinking.

-XX:MaxNewSize=size Maximum size of new generation (in bytes). Since 1.4, MaxNewSize is computed as a function of NewRatio. [1.3.1 Sparc: 32m; 1.3.1 x86: 2.5m.]

-XX:MaxPermSize=64m Size of the Permanent Generation.  [5.0 and newer: 64 bit VMs are scaled 30% larger; 1.4 amd64: 96m; 1.3.1 -client: 32m.]

-XX:MinHeapFreeRatio=40 Minimum percentage of heap free after GC to avoid expansion.

-XX:NewRatio=2 Ratio of new/old generation sizes. [Sparc -client: 8; x86 -server: 8; x86 -client: 12.]-client: 4 (1.3) 8 (1.3.1+), x86: 12]

-XX:NewSize=2.125m Default size of new generation (in bytes) [5.0 and newer: 64 bit VMs are scaled 30% larger; x86: 1m; x86, 5.0 and older: 640k]

-XX:ReservedCodeCacheSize=32m Reserved code cache size (in bytes) - maximum code cache size. [Solaris 64-bit, amd64, and -server x86: 48m; in 1.5.0_06 and earlier, Solaris 64-bit and and64: 1024m.]

-XX:SurvivorRatio=8 Ratio of eden/survivor space size [Solaris amd64: 6; Sparc in 1.3.1: 25; other Solaris platforms in 5.0 and earlier: 32]

-XX:TargetSurvivorRatio=50 Desired percentage of survivor space used after scavenge.

-XX:ThreadStackSize=512 Thread Stack Size (in Kbytes). (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]

-XX:+UseBiasedLocking Enable biased locking. For more details, see this tuning example. (Introduced in 5.0 update 6.) [5.0: false]

-XX:+UseFastAccessorMethods Use optimized versions of Get<Primitive>Field.

-XX:-UseISM Use Intimate Shared Memory. [Not accepted for non-Solaris platforms.] For details, see Intimate Shared Memory.

-XX:+UseLargePages Use large page memory. (Introduced in 5.0 update 5.) For details, see Java Support for Large Memory Pages.

-XX:+UseMPSS Use Multiple Page Size Support w/4mb pages for the heap. Do not use with ISM as this replaces the need for ISM. (Introduced in 1.4.0 update 1, Relevant to Solaris 9 and newer.) [1.4.1 and earlier: false]

-XX:+StringCache Enables caching of commonly allocated strings.

-XX:AllocatePrefetchLines=1 Number of cache lines to load after the last object allocation using prefetch instructions generated in JIT compiled code. Default values are 1 if the last allocated object was an instance and 3 if it was an array.

-XX:AllocatePrefetchStyle=1 Generated code style for prefetch instructions.
0 - no prefetch instructions are generate*d*,
1 - execute prefetch instructions after each allocation,
2 - use TLAB allocation watermark pointer to gate when prefetch instructions are executed.


Back to Options

Debugging Options

Option and Default Value
Description
-XX:-CITime Prints time spent in JIT Compiler. (Introduced in 1.4.0.)

-XX:ErrorFile=./hs_err_pid<pid>.log If an error occurs, save the error data to this file. (Introduced in 6.)

-XX:-ExtendedDTraceProbes Enable performance-impacting dtrace probes. (Introduced in 6. Relevant to Solaris only.)

-XX:HeapDumpPath=./java_pid<pid>.hprof Path to directory or filename for heap dump. Manageable. (Introduced in 1.4.2 update 12, 5.0 update 7.)

-XX:-HeapDumpOnOutOfMemoryError Dump heap to file when java.lang.OutOfMemoryError is thrown. Manageable. (Introduced in 1.4.2 update 12, 5.0 update 7.)

-XX:OnError="<cmd args>;<cmd args>" Run user-defined commands on fatal error. (Introduced in 1.4.2 update 9.)

-XX:OnOutOfMemoryError="<cmd args>;
<cmd args>" Run user-defined commands when an OutOfMemoryError is first thrown. (Introduced in 1.4.2 update 12, 6)

-XX:-PrintClassHistogram Print a histogram of class instances on Ctrl-Break. Manageable. (Introduced in 1.4.2.) The jmap -histo command provides equivalent functionality.

-XX:-PrintConcurrentLocks Print java.util.concurrent locks in Ctrl-Break thread dump. Manageable. (Introduced in 6.) The jstack -l command provides equivalent functionality.

-XX:-PrintCommandLineFlags Print flags that appeared on the command line. (Introduced in 5.0.)

-XX:-PrintCompilation Print message when a method is compiled.

-XX:-PrintGC Print messages at garbage collection. Manageable.

-XX:-PrintGCDetails Print more details at garbage collection. Manageable. (Introduced in 1.4.0.)

-XX:-PrintGCTimeStamps Print timestamps at garbage collection. Manageable (Introduced in 1.4.0.)

-XX:-PrintTenuringDistribution Print tenuring age information.

-XX:-TraceClassLoading Trace loading of classes.

-XX:-TraceClassLoadingPreorder Trace all classes loaded in order referenced (not loaded). (Introduced in 1.4.2.)

-XX:-TraceClassResolution Trace constant pool resolutions. (Introduced in 1.4.2.)

-XX:-TraceClassUnloading Trace unloading of classes.

-XX:-TraceLoaderConstraints Trace recording of loader constraints. (Introduced in 6.)

Regards
Manoj





Source :
http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp#largepages

FORMS

FND:ENABLE_CANCEL_QUERY
-----------------------
Oracle E-Business Suite Release 11i provides the ability for end users to cancel certain long-running queries, such as retrieving data in a block or List of Values. When these operations exceed a time threshold, this feature will allow the user to cancel the query.

If you are using Oracle Applications 11i Release 7 (11.5.7) or later, or are using FND mini-pack D or later you must set the profile option FND:ENABLE_CANCEL_QUERY to Yes in order to enable this feature. This can be set at site, application, responsibility or user leve



FORMS_CATCHTERM
---------------
The Parameter FORMS_CATCHTERM is related to the unix stack trace. The top two functions siehjmpterm() and sigacthandler() are the signal handling code - these functions will often be present in the stack trace. To see the function the program was in when the error occurred you need to read further down the stack.

If you set FORMS_CATCHTERM=0 the two functions do not show up in the dump file. The stack trace is displayed without the crash handling symbols.

That parameter will not limit the customer number of sessions at all, will only work as a back-end modification, handling the signals between functions.

BOUNCING THE MOBILE APPLICATION SERVER IN E-BUSINESS SUITE

Mobile Application Server - Version: 11.5.9 to 12.0.5

BOUNCING THE MOBILE APPLICATION SERVER FOR INDUSTRIAL APPLICATIONS


It is advisable to bounce the Mobile Application Server(s) at predefined intervals, so that active database sessions can be refreshed, and possible defects that might occur due to caching can be avoided.
Solution

Mobile Application Server for Industrial Applications can be used in conjunction with a software/hardware dispatcher for load balancing purposes. In this case, multiple servers are active and bouncing should take care of maintaining continuity of active user sessions; users who are logged in should not loose their connection. Steps required in bouncing can be summarized as follows:

. Start new servers on ports different than currently running servers using the mwactl utility, i.e. "mwactl.sh start port"

. Register new servers with the dispatcher

· Notify the dispatcher to stop accepting new connections for servers that are to be stopped

· Send graceful stop command to each of the servers that are to be stopped using the mwactl utility, i.e. "mwactl.sh -login mfg/welcome -stop port". (Refer to the Installation Guide for more information about shutting down servers gracefully)

When the Mobile Application Server is stopped gracefully, server process does not terminate until current users logout (or zombie sessions timeout). Hence, on a system that has to be up 24x7, Mobile Application Server should be stopped gracefully to provide a transparent transition for active users. As explained in the steps above, dispatcher should be aware of this process, and it should not send new sessions to servers that are being shutdown.

The Mobile Application Server Dispatcher has features to provide smooth transitioning for bouncing. First of all, every Mobile Application Server process that is brought up knows how to find the dispatcher (using mwa.cfg) and registers itself with the dispatcher after a successful start. Likewise, each server notifies the dispatcher as they get a graceful stop signal, which prevents the dispatcher from sending new sessions to these servers. Therefore, bouncing steps can be accomplished by a script, which would start the new servers first, and then stop the old ones gracefully. Since servers that are started should have different port numbers than servers that are in the process of shutting down, this script should also take care of alternating between two sets of port numbers. Please note that the Mobile Applications Server reserves two ports in case of a successful start; specified port (n), and n+1, i.e. if the server is started on port 10252, Mobile Application Server also reserves 10253 for administration purposes (Server Manager Listener is using this extra port), so you can not start another server on 10253. Running this script as a cron job (at specified intervals by the crontab file) would achieve the task of bouncing Mobile Application Servers on a regular basis.

In case of using a hardware dispatcher, each of these steps has to be executed manually. As explained above, after starting the new server, you should add these servers to the dispatcher routing table (Please consult your Dispatcher manual for instructions on how to modify your routing table). Dispatcher routing table should also be modified not to send new sessions to servers that are to be stopped. Finally, you should send graceful stop signals to servers that should be stopped. Once again, these steps can be accomplished by a script, which will run as a cron job.

To give an example, say your business runs 3 concurrent Mobile Application Servers, and you want to bounce these servers everyday at 6:00 a.m. (GMT). In this case you will have to allocate 12 ports ( 2 sets of 6 ports) for the Mobile Application Server. At least 6 of these ports will be active at any time 3 for Mobile Application Servers, 3 for Server Manager Listeners), and all of them will be used at bounce time. Assume the following sets are used: (10252, 10253, 10254, 10255, 10256, 10257) and (10258, 10259, 10260, 10261, 10262, 10263). The first time servers are started, bouncing script can use the first set, so you should be executing mwactl.sh 3 times with the following syntax:

mwactl.sh start 10252
mwactl.sh start 10254
mwactl.sh start 10256

Once again, please note that, 10253, 10255, 10257 will be allocated by these servers! The next morning, you should complete the following steps:

· Start new servers on the inactive set (which is the second set) using the following:
o mwactl.sh start 10258
o mwactl.sh start 10260
o mwactl.sh start 10262
· If you are using the hardware dispatcher, modify the routing tables to register these servers (running on ports 10258, 10260, 10262) with the dispatcher. Remember that, this step is not required if you are using
the the Mobile Application Server Dispatcher.
· If you are using the hardware dispatcher, modify the routing table so that the dispatcher won't accept new connections on the set that is to be stopped (running on ports 10252, 10254, 10256). Remember that, this step is not required if you are using the the Mobile Application Server Dispatcher.
· Stop the servers that need to be stopped gracefully (running on ports 10252,10254, 10256) using the following:
o mwactl.sh -login appsuser/appspassword stop 10252
o mwactl.sh -login appsuser/appspassword stop 10254
o mwactl.sh -login appsuser/appspassword stop 10256

If you want to implement this in a shell script, you can cycle between the port sets by creating a dummy file as follows:

· Check if foo.1 exists, if so remove foo.1, create foo.2 and use port set 2.
· Check if foo.2 exists, if so remove foo.2, create foo.1 and use port set 1
· If both of them do not exist, default to use port set 1

The following sample script illustrates how this can be done.

Note : This script does not check for all possible failures and is forcefully stopping the MWA Servers so logged in users would be disconnected. This should normally be scheduled to run during inactive hours like midnight or on holidays when there wouldn't be active users on the system. TMPDIR can be set to any temporary writable directory location

#!/bin/ksh
export TMPDIR=/usr/tmp
ulimit -n 1024

if [ -f $TMPDIR/foo.1 ]
then

rm -f $TMPDIR/foo.1
touch $TMPDIR/foo.2

#activate servers with port set 2
nohup $MWA_TOP/bin/mwactl.sh start 10258 >> /dev/null 2>&1 &
echo "Starting 10258 server"
nohup $MWA_TOP/bin/mwactl.sh start 10260 >> /dev/null 2>&1 &
echo "Starting 10260 server"
nohup $MWA_TOP/bin/mwactl.sh start 10262 >> /dev/null 2>&1 &
echo "Starting 10262 server"

#stop existing servers
nohup $MWA_TOP/bin/mwactl.sh -login mfg/welcome stop_force 10252 >> /dev/null 2>&1 &
echo "Stopping 10252 server"
nohup $MWA_TOP/bin/mwactl.sh -login mfg/welcome stop_force 10254 >> /dev/null 2>&1 &
echo "Stopping 10254 server"
nohup $MWA_TOP/bin/mwactl.sh -login mfg/welcome stop_force 10256 >> /dev/null 2>&1 &
echo "Stopping 10256 server"

else
if [ -f $TMPDIR/foo.2 ]
then

rm -f $TMPDIR/foo.2
touch $TMPDIR/foo.1

#activate servers with port set 1
nohup $MWA_TOP/bin/mwactl.sh start 10252 >> /dev/null 2>&1 &
echo "Starting 10252 server"
nohup $MWA_TOP/bin/mwactl.sh start 10254 >> /dev/null 2>&1 &
echo "Starting 10254 server"
nohup $MWA_TOP/bin/mwactl.sh start 10256 >> /dev/null 2>&1 &
echo "Starting 10256 server"

#stop existing servers
nohup $MWA_TOP/bin/mwactl.sh -login mfg/welcome stop_force 10258 >> /dev/null 2>&1 &
echo "Stopping 10258 server"
nohup $MWA_TOP/bin/mwactl.sh -login mfg/welcome stop_force 10260 >> /dev/null 2>&1 &
echo "Stopping 10260 server"
nohup $MWA_TOP/bin/mwactl.sh -login mfg/welcome stop_force 10262 >> /dev/null 2>&1 &
echo "Stopping 10262 server"
fi

fi

exit

Regards
Manoj

Source: NOTE:198543.1    



Title:              How To Rebounce the Mobile Application Server for
                    Industrial Applications v1.0.8

1. Responsibilities Listing
2. Menus Listing
3. Submenu and Function Listing
4. User and Assigned Responsibility Listing
5. Responsibility and assigned request group listing
6. Profile option with modification date and user
7. Forms personalization Listing
8. Patch Level Listing
9. Request attached to responsibility listing
10. Request listing application wise
11. Count Module Wise Reports
12. Request Status Listing
13. User and responsibility listing
14. Applied Patch Listing




//*
1. Responsibilities Listing
Purpose/Description:
Retrieve a list of all responsibilities.
Parameters
None
*//

SELECT
    (SELECT application_short_name
        FROM fnd_application fa
        WHERE fa.application_id = frt.application_id)
    application
,   frt.responsibility_id
,   frt.responsibility_name
FROM apps.fnd_responsibility_tl frt;



//*
2. Menus Listing
Purpose/Description:
To see the Menus associated with a given responsibility
Parameters
responsibility_id that you can retrieve from query nr 1 (Responsibilities Listing)
*//

SELECT DISTINCT
    a.responsibility_name
,   c.user_menu_name
FROM
    apps.fnd_responsibility_tl a
,   apps.fnd_responsibility b
,   apps.fnd_menus_tl c
,   apps.fnd_menus d
,   apps.fnd_application_tl e
,   apps.fnd_application f
WHERE
    a.responsibility_id(+) = b.responsibility_id
AND a.responsibility_id = 50103
AND b.menu_id = c.menu_id
AND b.menu_id = d.menu_id
AND e.application_id = f.application_id
AND f.application_id = b.application_id
AND a.LANGUAGE = ‘US’;



//*
3. Submenu And Function Listing
Purpose/Description:
By using this query you can check function and submenus attached to a specific menu
Parameters
User_menu_name that you can get by running query 2 (Menu Listing)
*//

SELECT
    c.prompt
,   c.description
FROM
    apps.fnd_menus_tl a
,   fnd_menu_entries_tl c
WHERE
    a.menu_id = c.menu_id
AND a.user_menu_name = ‘Navigator Menu - System Administrator GUI’;



//*
4.User and Assigned Responsibility Listing
Purpose/Description:
You can use this query to check responsibilities assigned to users.
Parameters
None
*//
   
SELECT UNIQUE
    u.user_id
,   SUBSTR (u.user_name, 1, 30) user_name
,   SUBSTR (r.responsibility_name, 1, 60) responsiblity
,   SUBSTR (a.application_name, 1, 50) application
FROM
    fnd_user u
,   fnd_user_resp_groups g
,   fnd_application_tl a
,   fnd_responsibility_tl r
WHERE
    g.user_id(+) = u.user_id
AND g.responsibility_application_id = a.application_id
AND a.application_id = r.application_id
AND g.responsibility_id = r.responsibility_id
ORDER BY
    SUBSTR (user_name, 1, 30)
,   SUBSTR (a.application_name, 1, 50)
,   SUBSTR (r.responsibility_name, 1, 60);



//*
5. Responsibility and assigned request group listing
Purpose/Description:
To find responsibility and assigned request groups.
Every responsibility contains a request group (The request group is basis of submitting requests)
Parameters
None
*//

SELECT
    responsibility_name responsibility
,   request_group_name
,   frg.description
FROM
    fnd_request_groups frg
,   fnd_responsibility_vl frv
WHERE
    frv.request_group_id = frg.request_group_id
ORDER BY responsibility_name



//*
6. Profile option with modification date and user
Purpose/Description:
Query that can be used to audit profile options.
Parameters
None
*//

SELECT
    t.user_profile_option_name
,   profile_option_value
,   v.creation_date
,   v.last_update_date
,   v.creation_date - v.last_update_date "Change Date"
,   (SELECT UNIQUE user_name
        FROM fnd_user
        WHERE user_id = v.created_by) "Created By"
,   (SELECT user_name
        FROM fnd_user
        WHERE user_id = v.last_updated_by) "Last Update By"
FROM
    fnd_profile_options o
,  fnd_profile_option_values v
,   fnd_profile_options_tl t
    WHERE
        o.profile_option_id = v.profile_option_id
    AND o.application_id = v.application_id
    AND start_date_active <= SYSDATE
    AND NVL (end_date_active, SYSDATE) >= SYSDATE
    AND o.profile_option_name = t.profile_option_name
    AND level_id = 10001
    AND t.LANGUAGE IN (SELECT language_code
    FROM fnd_languages
WHERE installed_flag = ‘B’
UNION
    SELECT nls_language
    FROM fnd_languages
    WHERE installed_flag = ‘B’)
ORDER BY user_profile_option_name;



//*
7. Forms personalization Listing
Purpose/Description:
To get modified profile options.
Personalization is a feature available in 11.5.10.X.
Parameters
None
*//

SELECT
    ffft.user_function_name "User Form Name"
,   ffcr.SEQUENCE
,   ffcr.description
,   ffcr.rule_type
,   ffcr.enabled
,   ffcr.trigger_event
,   ffcr.trigger_object
,   ffcr.condition
,   ffcr.fire_in_enter_query
,   (SELECT user_name
        FROM fnd_user fu
        WHERE fu.user_id = ffcr.created_by) "Created By”
FROM
    fnd_form_custom_rules ffcr
,   fnd_form_functions_vl ffft
WHERE ffcr.ID = ffft.function_id
ORDER BY 1;



//*
8. Patch Level Listing
Purpose/Description:
Query that can be used to view the patch level status of all modules
Parameters
None
*//

SELECT
    a.application_name
,   DECODE (b.status, ‘I’, ‘Installed’, ‘S’, ‘Shared’, ‘N/A’) status
,   patch_level
FROM
    apps.fnd_application_vl a
,   apps.fnd_product_installations b
WHERE
    a.application_id = b.application_id;
 



//*
9. Request attached to responsibility listing
Purpose/Description:
To see all requests attached to a responsibility
Parameters
None
*//

SELECT
    responsibility_name
,   frg.request_group_name
,   fcpv.user_concurrent_program_name
,  fcpv.description
FROM
    fnd_request_groups frg
,   fnd_request_group_units frgu
,   fnd_concurrent_programs_vl fcpv
,   fnd_responsibility_vl frv
WHERE
    frgu.request_unit_type = ‘P’
AND frgu.request_group_id = frg.request_group_id
AND frgu.request_unit_id = fcpv.concurrent_program_id
AND frv.request_group_id = frg.request_group_id
ORDER BY responsibility_name;



//*
10. Request listing application wise
Purpose/Description:
View all request types application wise
Parameters
None
*//

SELECT
    fa.application_short_name
,   fcpv.user_concurrent_program_name
,   description
,   DECODE (fcpv.execution_method_code
            ,’B', ‘Request Set Stage Function’
            ,’Q', ‘SQL*Plus’
            ,’H', ‘Host’
            ,’L', ‘SQL*Loader’
            ,’A', ‘Spawned’
            ,’I', ‘PL/SQL Stored Procedure’
            ,’P', ‘Oracle Reports’
            ,’S', ‘Immediate’
            ,fcpv.execution_method_code) exe_method
,   output_file_type
,   program_type
,   printer_name
,   minimum_width
,   minimum_length
,   concurrent_program_name
,   concurrent_program_id
FROM
    fnd_concurrent_programs_vl fcpv
,   fnd_application fa
WHERE
    fcpv.application_id = fa.application_id
ORDER BY description



//*
11. Count Reports per module
Purpose/Description:
To Count Reports
Parameters
None
*//

SELECT
    fa.application_short_name
,   DECODE (fcpv.execution_method_code
    ,’B', ‘Request Set Stage Function’
    ,’Q', ‘SQL*Plus’
    ,’H', ‘Host’
    ,’L', ‘SQL*Loader’
    ,’A', ‘Spawned’
    ,’I', ‘PL/SQL Stored Procedure’
    ,’P', ‘Oracle Reports’
    ,’S', ‘Immediate’
    ,fcpv.execution_method_code) exe_method
,   COUNT (concurrent_program_id) COUNT
FROM
    fnd_concurrent_programs_vl fcpv
,   fnd_application fa
WHERE
    fcpv.application_id = fa.application_id
GROUP BY
    fa.application_short_name
,   fcpv.execution_method_code
ORDER BY 1;



//*
12. Request Status Listing
Purpose/Description:
This query returns report/request processing time
Parameters
None
*//

SELECT
    f.request_id
,   pt.user_concurrent_program_name user_concurrent_program_name
,   f.actual_start_date actual_start_date
,   f.actual_completion_date actual_completion_date
,   floor(((f.actual_completion_date-f.actual_start_date)*24*60*60)/3600)
    || ‘ HOURS ‘ ||
    floor((((f.actual_completion_date-f.actual_start_date)*24*60*60) -
    floor(((f.actual_completion_date-f.actual_start_date)*24*60*60)/3600)*3600)/60)
    || ‘ MINUTES ‘ ||
    round((((f.actual_completion_date-f.actual_start_date)*24*60*60) -
    floor(((f.actual_completion_date-f.actual_start_date)*24*60*60)/3600)*3600 -
    (floor((((f.actual_completion_date-f.actual_start_date)*24*60*60) -
    floor(((f.actual_completion_date-f.actual_start_date)*24*60*60)/3600)*3600)/60)*60) ))
    || ‘ SECS ‘ time_difference
,   DECODE(p.concurrent_program_name
    ,’ALECDC’
    ,p.concurrent_program_name||’['||
     f.description||']‘
    ,p.concurrent_program_name) concurrent_program_name
,   decode(f.phase_code
    ,’R',’Running’
    ,’C',’Complete’
    ,f.phase_code) Phase
, f.status_code
FROM
    apps.fnd_concurrent_programs p
,   apps.fnd_concurrent_programs_tl pt
,   apps.fnd_concurrent_requests f
WHERE
    f.concurrent_program_id = p.concurrent_program_id
AND f.program_application_id = p.application_id
AND f.concurrent_program_id = pt.concurrent_program_id
AND f.program_application_id = pt.application_id
AND pt.language = USERENV(’Lang’)
AND f.actual_start_date is not null
ORDER by f.actual_completion_date-f.actual_start_date desc;



//*
13. User and responsibility listing
Purpose/Description:
Check responsibilities assigned to users
Parameters
None
*//

SELECT UNIQUE
    u.user_id
,   SUBSTR (u.user_name, 1, 30) user_name
,   SUBSTR (r.responsibility_name, 1, 60) responsiblity
,   SUBSTR (a.application_name, 1, 50) application
FROM
    fnd_user u
,   fnd_user_resp_groups g
,   fnd_application_tl a
,   fnd_responsibility_tl r
WHERE g.user_id(+) = u.user_id
AND g.responsibility_application_id = a.application_id
AND a.application_id = r.application_id
AND g.responsibility_id = r.responsibility_id
–AND a.application_name like ‘%Order Man%’
ORDER BY SUBSTR (user_name, 1, 30),
SUBSTR (a.application_name, 1, 50),
SUBSTR (r.responsibility_name, 1, 60)



//*
14. Applied Patch Listing
Purpose/Description:
Check Current Applied Patches
Parameters
None
*//

SELECT
    patch_name
,   patch_type
,   maint_pack_level
,   creation_date
FROM applsys.ad_applied_patches
ORDER BY creation_date DESC



=================================
CM: jvm size of concurrent queues
=================================
select DEVELOPER_PARAMETERS from FND_CP_SERVICES
where SERVICE_ID = (select MANAGER_TYPE from FND_CONCURRENT_QUEUES
where CONCURRENT_QUEUE_NAME = 'FNDCPOPP');
============
to increase
============
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');



===========================================
Workflow: To see failed, open notifications
===========================================
SELECT message_type, COUNT(1)
FROM apps.wf_notifications
WHERE 1 = 1 AND mail_status = 'FAILED' AND status = 'OPEN'
GROUP BY message_type;


================
SQL: patch level
================
set linesize 155;
set pagesize 200;
set verify off;
select b.bug_number bug, b.creation_date credate, b.last_update_date ldate,
decode(bug_number,
2728236, 'OWF.G',
3031977, 'POST OWF.G ROLLUP 1 - 11.5.9.1',
3061871, 'POST OWF.G ROLLUP 2 - 11.5.9.2',
3124460, 'POST OWF.G ROLLUP 3 - 11.5.9.3',
3316333, 'POST OWF.G ROLLUP 4 - 11.5.9.4.1',
3314376, 'POST OWF.G ROLLUP 5 - 11.5.9.5',
3409889, 'POST OWF.G ROLLUP 5 Consolidated Fixes',
3492743, 'POST OWF.G ROLLUP 6 - 11.5.9.6',
3672076, 'POST OWF.G ROLLUP 6.1',
3868138, 'POST OWF.G ROLLUP 7',
3258819, 'OWF.H',
3262159, 'FND.H',
3140000, '11.5.10',
3240000, '11.5.10 CU1',
4017300, '11.5.10 Consolidated Update (CU1) for ATG Product Family',
3460000, '11.5.10 CU2',
4125550, '11.5.10 Consolidated Update (CU2) for ATG Product Family',
4605136, 'WFDS 4.5 rollup FOR 11.5.10, 11.5.10.1, 11.5.10.2',
4645579, 'WFDS 4.5 v2 (replaces 4605136) FOR FND.H',
4684377, 'ONE OFF MISSING RESPONSIBILITIES PATCH',
4334965, '11.5.10 Consolidated Update (CU3) for ATG Product Family') Patch
from APPS.AD_BUGS b
where b.BUG_NUMBER in
('2728236','3031977','3061871','3124460','3316333',
'3314376','3409889','3492743','3672076','3868138',
'3258819','3262159','3140000','3240000','4017300',
'3460000','4125550','4605136','4645579','4684377',
'4334965')
order by bug_number desc;

=================
Workflow: version
=================
$FND_TOP/sql/wfver.sql


========================
Enable low level logging
========================
How to turn on the debugging:
Set the following profiles:
 FND: Debug Log Enabled = YES
 FND: Debug Log Filename = NULL
 FND: Debug Log Level = STATEMENT (most detailed log)
 FND: Debug Log Module = % or ar% or even ar.arp_auto_rule%

If you have applied Patch 3140000 - 11.5.10 MAINTENANCE PACK, the profile names have changed:
'FND: Debug Log Enabled' been replaced by 'FND: Log Enabled'
and 'FND: Debug Log Level' has been replaced by 'FND: Log Level

If FND: Debug Log Enabled profile is not set, then rest of the others won't matter.


============================================
To check the what is installed on what nodes
===========================================
select node_name, status,  support_cp "cp", support_web "web", support_forms "frm", support_db "db" from apps.fnd_nodes;

============================================
Summary of how many users -- 10g As oacore
============================================

REM
    REM        START OF SQL
    REM
    set feedback on
    set timing on
    set echo on
    set feedback on
    set pagesize 132
    set linesize 80
    col user_name format a15
    col first_connect format a18
    col last_connect format a18
    col How_many_user_sessions format 9999999999
    col How_many_sessions format 9999999999
    REM
    REM SQL 1
    REM Summary of how many users
    REM
    select 'Number of user sessions : ' || count( distinct session_id) How_many_user_sessions
    from icx_sessions icx
    where last_connect > sysdate - 1
    and disabled_flag != 'Y'
    and PSEUDO_FLAG = 'N'


===========================================
check JOC patch's
===========================================
select bug_number, last_update_date from ad_bugs where bug_number in ('5726582','5639951','5455628','5468797','5215394');


=====================
Check current sysdate
=====================
SELECT TO_CHAR(SYSDATE,'MM/DD/YYYY HH:MM:SS AM')
       "Today's Date and Time" from DUAL;

===============================
Enable Apache and Jserv logging
===============================


Jserv
 Modify $ORACLE_HOME/Apache/Jserv/etc/jserv.properties
 Make sure the log switch is set to true. Can also specify the location
 of the jserv log file if so desired:

      log=true
      log.timestamp=true
      log.file=<path to jserv log file>/jserv.log
      log.channel.servletException=true
      log.channel.jservException=true
      log.channel.warning=true
      log.channel.servletLog=true
      log.channel.critical=true

Apache
# LogLevel: Control the number of messages logged to the error_log.
   # Possible values: debug,info,notice,warn,error,crit,alert,emerg
     Loglevel warn


=================================================================
Session info: high cpu consumption spid session info
=================================================================
set verify off
set echo off
set head off
set pages 1000
PROMPT Enter SPID :
ACCEPT 1
  select 'SID............ : ' || a.sid
|| chr(10) ||
         'SERIAL#........ : ' || a.serial#
|| chr(10) ||
         'USERNAME....... : ' || a.username
|| chr(10) ||
         'COMMAND........ : ' || a.command
|| chr(10) ||
         'STATUS......... : ' || a.status
|| chr(10) ||
         'Machine........ : ' || a.machine
|| chr(10) ||
         'Terminal....... : ' || a.terminal
|| chr(10) ||
         'Program........ : ' || a.program
|| chr(10) ||
         'Module........ : ' || a.module
|| chr(10) ||
         'SQL Hash Value. : ' || a.sql_hash_value
|| chr(10) ||
         'Logon Time..... : ' || to_char(a.logon_time,'DD-Mon-YYYY HH:MI:SS')
|| chr(10) ||
         'Last Call Et... : ' || a.last_call_et
|| chr(10) ||
         'Process ID..... : ' || a.process
|| chr(10) ||
         'SPID........... : ' || b.spid
  from   v$session a, v$process b
  where  a.paddr=b.addr     and b.spid='&1';
  PROMPT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  PROMPT  Process ID is  process col. in v$session table.
  PROMPT  SPID       is  spid    col. in v$process table.
  PROMPT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  select 'Session Waiting for event...: ' || event
  from    v$session_wait
  where   sid=(select sid from v$session a, v$process b where  a.paddr=b.addr
  and b.spid='&1');
  PROMPT  SQL STATEMENT :
  PROMPT  ===============
  select sql_text
  from   v$sqltext
  where  hash_value=(select sql_hash_value from v$session a, v$process b where
a.paddr=b.addr  and b.spid='&1')
  order  by piece;
==============================================

XXX Is not a valid responsibility for the current user

There are multiple fixes for the error, some are listed below

This error is displayed because of the caching framework of apache, workflow components in oracle apps are suppose to sync the cache. When workflow events fail to trigger/function due to some XYZ reason, this issue occurs. Make sure workflow components are working optimally for permanent fix for temporary fix clear cache.

1. Clear cache

Go to > Functional Administrator responsibility

Click on Core services tab (the tab at the top right)

Click on Caching Framework Tab (blue tab under main tab)

Click on Global configuration

Click on Clear All Cache

A warning message related to performance will come , say yes

2. Bounce Apache by clearing cache

 

 

Regards

Manoj

Check India Localization patchset level
How to check the current India Localization Patchset Level installed on an Instance

India Localization Patchset is IN60107(Patch Number = 5498551)
If the Patch Number 5498551 is applied, your current India Localization patchset is IN60107.
This can be verified by running the below select
select * from JAI_APPLIED_PATCHES where Patch_number = 5498551;

If the Patch Number 5498551 is not applied, the India Localization Patchset should be IN60106 or below.
This can be checked by running the below statement:-
select * from JA_IN_INSTALL_CHECK_INFO where name like '601%';


source: Metalink ID: 752704.1

Regards
Manoj

Compiling forms in Oracle apps (e-business suite) 11i

Compiling forms in Oracle apps (e-business suite) 11i

All module fmb are located in $AU_TOP
-Change directory to $AU_TOP/forms/US
Take backup of existing fmx

f60gen module=<formname>.fmb userid=apps/<apps_pwd> output_file=<required_module_top>/forms/US/<formname>.fmx

Regards

Manoj

How to Find out available (current & old) log file names of concurrent Manager.

How to Find out available (current & old) log file names of concurrent Manager.

Script provided by oracle

afcmcreq.sql
Displays the concurrent manager and the name of its log file that processed a request.



Tables:

fnd_concurrent_processes (LOGFILE_NAME --> logfile name)
fnd_concurrent_queues (CONCURRENT_QUEUE_NAME --> short name of manager)
fnd_concurrent_queues_tl (USER_CONCURRENT_QUEUE_NAME --> Name of manager, as seen on front end screen)

Foreign Key: CONCURRENT_QUEUE_ID.

Query
-----

set linesize 350
set pagesize 100
col Name for a30
col "Short Name" for a10
col Host for a13
col "Log File" for a40

select b.USER_CONCURRENT_QUEUE_NAME "Name", b.CONCURRENT_QUEUE_NAME "Short Name", a.PROCESS_START_DATE "Start Date", a.NODE_NAME "Host", a.LOGFILE_NAME "Log File" from fnd_concurrent_processes a, fnd_concurrent_queues_tl b where a.CONCURRENT_QUEUE_ID = b.CONCURRENT_QUEUE_ID and b.CONCURRENT_QUEUE_NAME like '%&Short_Name%';

Note: Change b.CONCURRENT_QUEUE_NAME to b.USER_CONCURRENT_QUEUE_NAME if you want to query through concurrent manager name. CONCURRENT_QUEUE_NAME is manager short name

Regards
Manoj

Check Versions of Oracle Applications

1. Application release version

select release_name from apps.fnd_product_groups;

2. Latest ATG RUP level

select creation_date, bug_id, decode(bug_number,
4334965, '11i.ATG_PF.H RUP3',
4676589, '11i.ATG_PF.H RUP4',
5473858, '11i.ATG_PF.H RUP5',
5903765, '11i.ATG_PF.H RUP6',
6241631, '11i.ATG_PF.H.RUP.7')
from apps.ad_bugs where bug_number in('4334965','4676589','5473858','5903765','6241631');

3.jdbc driver version

select bug_number, decode(bug_number,
'3043762','JDBC drivers 8.1.7.3',
'2969248','JDBC drivers 9.2.0.2',
'3080729','JDBC drivers 9.2.0.4 (OCT-2003)',
'3423613','JDBC drivers 9.2.0.4 (MAR-2004)',
'3585217','JDBC drivers 9.2.0.4 (MAY-2004)',
'3882116','JDBC drivers 9.2.0.5 (OCT-2004)',
'3966003','JDBC drivers 9.2.0.5 (OCT-2004)',
'3981178','JDBC drivers 9.2.0.5 (NOV-2004)',
'4090504','JDBC drivers 9.2.0.5 (JAN-2005)',
'4201222','JDBC drivers 9.2.0.6 (MAY-2005)') Patch_description
from ad_bugs
where bug_number in
(
'3043762',
'2969248',
'3080729',
'3423613',
'3585217',
'3882116',
'3966003',
'3981178',
'4090504',
'4201222'
)
order by 2;

Oracle workflow notification mailer sql's

Oracle workflow notification mailer sql's
=========================================

1. Workflow: version
2. check workflow status.
3. check if workflow is used by only one instance
4. check if processor_read_timeout_close is set to 'Y'
5. check for bad e-mail address
6. How to know mail sent to a user with details:
7. How to know whether it is set to correct url from porfile options:
8. How to know reqid, process id, sid..
9. workflow patches
10. Workflow: To see failed, open notifications
11. To check if email address, notification preference, display_name
12. How to know workflow responsibility from backend:
13. Steps to drop and recreate WF_CONTROL queue:


=================
1. Workflow: version
=================
$FND_TOP/sql/wfver.sql

----------------------------------------------------
2. check workflow status.
----------------------------------------------------
set linesize 120
set pagesize 50
column COMPONENT_NAME format a45
column STARTUP_MODE format a15
column COMPONENT_STATUS format a15
select fsc.COMPONENT_NAME,fsc.STARTUP_MODE,fsc.COMPONENT_STATUS,fcq.last_update_date
from APPS.FND_CONCURRENT_QUEUES_VL fcq, fnd_svc_components fsc
where fsc.concurrent_queue_id = fcq.concurrent_queue_id(+)
order by COMPONENT_STATUS , STARTUP_MODE , COMPONENT_NAME;

Classification of Technologies used in Oracle E-business suite

Classification of Technologies used in Oracle E-business suite

• Oracle Application Object Library (AOL)
• Java Technology Foundation (JTF)

AOL applications are Oracle Forms developed using Oracle Developer and are usually
referred to as Forms-based applications. JTF applications are Java Server Pages (JSPs)
developed using Oracle JDeveloper and are usually referred to as HTML-based
applications. Each type of application accesses the same database and can share
information with the other.

The product interfaces are accessed by providing the Uniform Resource Locator (URL)
for the environment in an Oracle Applications 12-compliant Web browser and
navigating to the hyperlink for the login page for the specific technology stack. You can
also provide the URL for the specific login page. This URL is referred to as your login
URL.

Oracle Applications URL
Use this URL to navigate to the Personal Home Page URL or the CRM Home page URL.
http://:/
* To navigate to the Personal Home Page URL, choose Apps Logon Links >Personal
Home Page.
* To navigate to the CRM Home Page URL, choose Apps Logon Links >CRM Home
Page.

CRM Home Page URL
This URL is sometimes referred to as the Apache or JTF login URL. Use this URL to
open the login page for HTML-based applications.
http://:/OA_HTML/jtflogin.jsp

Personal Home Page URL
This URL is sometimes referred to as the Self-Service Web Applications or SSWA login
URL. Use this URL to open the login window for Oracle Applications via the Personal
Home Page. You can access Forms-based or HTML-based applications from the
Personal Home Page.
http://:/OA_HTML/US/ICXINDEX.htm

Forms URL
Use this URL to open the login page for Forms-based applications. This login URL is
Dependencies and Integration Points 2-11
typically used by system administrators, not end users.
http://:/dev60cgi/f60cgi

User Accounts
An application user is an authorized user of Oracle Applications and is uniquely
identified by a username. After the user account has been defined, the application user
can sign on to Oracle Applications at the CRM Home Page, Personal Home Page, or
Forms login.
Note: Oracle Applications is installed with a system defined username
and password.
* Username: sysadmin
* Password: sysadmin

An application user enters a username along with a password to sign on to Oracle
Applications. The password assigned by the system administrator is temporary. When
signing on for the first time, the application user will be prompted to change the
password. Access to specific functionality and data will be determined by the
responsibilities assigned to your user account.

Regards
Manoj