Explanation of Various Parameters for Workflow Background Process Engine
ITEM TYPE:
Specify an item type to restrict this engine to activities associated with that item type. If you do not specify an item type, the engine processes any deferred activity regardless of its item type.
MINIMUM THRESHOLD:
Specify the minimum cost that an activity must have for this background engine to execute it, in hundredths of a second.
MAXIMUM THRESHOLD:
Specify the maximum cost that an activity can have for this background engine to execute it, in hundredths of a second.
By using Minimum Threshold and Maximum Threshold multiple background engines can be created to handle very specific types of activities. The default values for these arguments are 0 and 100 so that the background engine runs activities regardless of cost.
PROCESS DEFERRED:
Specify whether this background engine checks for deferred activities. Setting this parameter to YES allows the engine to check for deferred activities.
PROCESS TIME OUT:
Specify whether this background engine checks for activities that have timed out. Setting this parameter to YES allows the engine to check for timed out activities.
PROCESS STUCK:
Specify whether this background engine checks for stuck processes. Setting this parameter to YES allows the engine to check for stuck processes.
FNDREVIVER - Theories and Concepts to remember
Theories on FNDREVIVER
FNDREVIVER (also recognized as reviver.sh) is used for momentary disconnects in the system where the concurrent managers and/or forms go down, and forms is later reconnected while the concurrent managers are not. FNDREVIVER revives the Internal Concurrent Manager (ICM) when it fails.
When ICM can no longer get a database connection, it kills itself and spawns the reviver. Reviver loops every 30 seconds, attempting to login to the database as apps user. Once login is successful, it starts up the ICM again.
If the failure is due to a brief network outage, or database issue, the managers are restarted, so the client does not have to restart the managers manually.
Reviver is recovery mechanism runs in the background. In a Real Applications Cluster (RAC) environment, when the primary node goes down and ICM is set to migrate to the secondary node, the reviver parameter will be passed to the secondary node.
The easiest way to determine if reviver.sh exists is by checking the $FND_TOP/bin directory.
The variable resides in the context file under 's_cp_reviver' and can be set to "enabled" or "disabled". Based on the value of s_cp_reviver in the context file, AFCPDNR is started with a value of either "enabled" or "disabled" .
The reviver is started when starting the ICM, by passing a parameter reviver="enabled". You do this on the node you start the manager, and if the ICM is set to migrate to the second node, this parameter will be passes to the second node.
A common misconception is that users must start the reviver.sh manually, however this is not the intended use. It is automatically enabled when the parameter REVIVER_PROCESS="enabled" is passed via the adcmctl.sh concurrent manager startup script.
On a single node concurrent processing system, FNDREVIVER is the only way to recover from a database connection loss.
On a two node system, there is another factor, the Internal Monitor (FNDIMON).The FNDIMON will race to restart the internal manager in a multi node setup, and by the time the reviver starts it will likely see that the ICM is already running and exit accordingly.
FNDIMON checks whether it can connect to the database in order to determine if the ICM is running, and if the database connection is not available it fails to run and exits accordingly. The reviver is a shell script which loops until a connection is obtained, and then starts the manager accordingly. The reviver's job is the last line of defense after a database connection failure, as FNDIMON only works when the database connection is available.
In the event the ICM goes down due to a network outage, then the reviver would be needed to bring the ICM back up.
Context File Parameters related to FNDREVIVER
The following parameters can be set in the context file, and then autoconfig should be re-run to enable reviver:
Concurrent Processing Reviver Process (s_cp_reviver) [Allowed values are {enabled, disabled}]
<cp_reviver oa_var="s_cp_reviver">enabled</cp_reviver>
Reviver Process PID Directory Location (s_fndreviverpiddir)
This variable specifies the path where ICM reviver process pid file will be created. Oracle recommends using a local disk as the PID file location because the reviver process may run when the network is down.
<fndreviverpiddir oa_var="s_fndreviverpiddir">/u02/oracle/visappl/fnd/11.5.0/log</fndreviverpiddir>
High Water Mark
- The high water mark is the boundary between used and unused space in a segment. As requests for new free blocks that cannot be satisfied by existing free lists are received, the block to which the high water mark points to becomes a used block, and the high water mark is advanced to the next block. In other words, the segment space to the left of the high water mark is used, and the space to the right of it is unused.
- The high-water mark is the level at which blocks have never been formatted to receive data.
- When a table is created in a tablespace, some initial number of blocks/extents are allocated to the table. Later, as the number of rows inserted increases, extents are allocated accordingly.
- Inserting records into the table would increase the high water mark.
- Deleting the records does not lower the high water mark. Therefore, deleting the records does not raise the 'Empty_blocks'. After deleting the records, if you query dba_segments or dba_tables, there would be no change.
- ALTER TABLE <TABLE_NAME> DEALLOCATE UNUSED; >>> would not bring the high water mark down.
- The high water mark can be reset with a truncate table or if the table is moved to another tablespace, or with Shrink Space.
SQL> ALTER TABLE <tablename> SHRINK SPACE;
- The ALTER TABLE MOVE can even be a good method to optimize the HWM even if the move occurs within the same tablespace
- High Water Mark After Exporting/Deleting/Importing a Table >>> NO, the HWM is not reset.
- All Oracle segments have an upper boundary containing the data within the segment. This upper boundary is called the "high water mark" or HWM.
- The high water mark is an indicator that marks blocks that are allocated to a segment, but are not used yet. It is reset to ""zero"" (position to the start of the segment) when a TRUNCATE command is issued. So you can have empty blocks below the high water mark, but that means that the block has been used (and is probably empty caused by deletes). Oracle does not move the HWM, nor does it *shrink* tables, as a result of deletes."
- Data files do not have a high water mark; only segments do have them.
- Full table scans typically read up to the high water mark.
