Skip to main content

Oracle E-Business Suite

Oracle E-Business Suite technology layer include:
  • Oracle Applications DBA (AD)
  • Oracle Application Object Library (FND)
  • Oracle Applications Utilities (AU)
  • Oracle Common Modules (AK)
  • Oracle Workflow (WF)
  • Oracle Alert (ALR)
  • Oracle Application Framework (FWK)
  • Oracle XML Publisher (XDO)
E-Business Suite Services - Concurrent Managers and Workflow Mailers.
Services are composed of one or more processes that must be kept running for the proper functioning of the applications.
With Service Management, the Internal Concurrent Manager (ICM) manages the various service processes across multiple hosts.
Service processes are very much like concurrent manager and transaction manager
processes.
Oracle Applications Manager can be used for a wide variety of tasks such as administering services including concurrent managers, examining system configuration, managing Oracle workflow, examining applied patches, and measuring system usage.

E-business suite Concurrent programs:
01. Executes programs in background.
02. Admin can control no. of OS processes allocation for program.
03. Report->Request->Concurrent Request->Concurrent Manager-> Concurrent Programs
04. Concurrent Program priority is controled by concurrent user profile option.
05. Status of concurrent request - Pending, Running, Active, Inactive
  • Pending - Normal, Waiting, Scheduled, Standby
  • Running - Normal, Resuming, Paused, Terminating
  • Completed - Normal, Error, Warning, Cancelled, Terminated
  • Inactive - No manager, On hold, Disabled
06. OPMN services - Oracle Process Manager Services
07. OHS services - Oracle HTTP Services (Oracle Web logic Server)

Run-edition File System:
Run-edition ($RUN_BASE) file system is designated as run (part of the running system). It appears to the user. $RUN_BASE = /u01/R122_EBS/fs1

Patch-edition File System:
Patch-edition ($PATCH_BASE) file system is either being patched or awaiting the start of the next patching cycle. $PATCH_BASE = /u01/R122_EBS/fs2

Non-edition File System:
Non-edition ($NE_BASE) file system (fs_ne), which is used to store files containing data that is needed across all file systems, the non-editioned file system is designed to store files which will never be changed by run and patch file system life cycles. The most notable examples of this are transactional data and certain log files.

$NE_BASE = /u01/R122_EBS/fs_ne
$FILE_EDITION = patch

Patching:
  • Run edition File system (Run file system)
  • Patch edition file system (Patch file system)
  • Non editioned file system
01. In a normal online patching cycle, the steps should be executed from the patch file system after the apply phase.
02. If the patch is being applied in hotpatch mode or downtime mode, the steps should be executed from the run file system after the apply phase.
03.When applying large patches (such as release update packs, product family RUPs, and pre-upgrade patches), ensure there is enough disk space on the system, where you unzip the patch, or the patching process may fail. We recommend having at least twice the amount of disk space as the unzipped patch file uses.
Tip: When there is no patching cycle in progress, you can if desired delete the files in the backup directory to free the space.
04. A normal Release 12.2 online patching environment requires two application tier file systems, one for the run edition and another for the patch edition. This dual file system
architecture is fundamental to patching of Oracle E-Business Suite Release 12.2, and is necessary both for production environments and test environments that are intended to be representative of production.
05. You can set up a single file system development environment by installing Oracle E-Business Suite Release 12.2 in the normal way, and then deleting the $PATCH_BASE directory with the command: $ rm -rf $PATCH_BASE
06. Applying patches in hotpatch mode is only supported for use with patches that have been designed and tested to be applied in this way. This is because hotpatch mode applies changes to the run edition while this edition is in active use, which may result in one or more of the following issues for patches not designed to be applied as hotpatches:
07. As mentioned in the "adop Options, page 2-24" section of Chapter 2, if you try to apply a patch that has already been applied, and you do not specify options=forceapply, adop will display an error such as:
[WARNING] Skipping the application of patch 14125999_AR since it has been already applied
[WARNING] Hint: Patches can be applied again by specifying options=forceapply when invoking adop.
08. You can run the Online Patching Monitoring utility (adopmon) to provide a continuously refreshed view of key adop actions, in a coceptually similae way to the tail -f UNIX command.
09. A related tool, the Online Patching Diagnostic Reports utility, $AD_TOP/bin/adopreports, can be used to help diagnose issues or simply gather information about the status of your system.
10. The Log Analyzer utility can be run without options, to scan all log directories of the latest adop session for errors: $ adopscanlog
If you attempt to resume a failed session after cutover exits with cutover_status=3, you may receive an 'Invalid Credentials' error. This will be because the database patch edition has already been promoted to be the new run edition. To resume and complete cutover successfully, run the command: $ adop phase=cutover action=nodb
11. The cutover operation is the most critical phase of an online patching cycle. Although other adop operations can be left to run unattended, you should carefully monitor the progress of cutover, so that you can respond quickly in case of any issues. If cutover fails to complete, check log messages for any problems that may require correction. Then try executing the cutover command again.
When cutover is re-executed after a previous failure, adop will restart cutover processing at the failure point for any nodes that did not complete, and the processing may be successful this time.
12. Important: AD utilities such as AD Admin and AD Splice can be invoked from the run edition only if there is no patch edition. If a patch edition exists, attempting to invoke the utility from the run edition will fail with an error.
Important: Remember that there are two file systems in Release 12.2, run and patch. The environment must be set correctly on both.
Important: AD Controller (adctrl) can only be run from the patch edition of the file system. Attempting to run it from the run edition will give an error. You can identify which edition you are in by checking the value of the FILE_EDITION environment variable.
13. If system users are having difficulty accessing messages, forms, or reports, you may be able to resolve the issue by generating the associated files. Or, when you apply a patch that adds or changes product functionality, you may want to generate the associated files after you apply the patch, instead of running the generate driver during the patching downtime. 14. The Generate Files tasks may be performed on any server, as required.
You do not have to shut down your system to generate files. However, users that access the files being generated (for example, for Human Resources forms) must log off.
Important: AD Administration cannot be used to link executables for the AD products themselves. You must use AD Relink for this. See Relinking AD Executables in this chapter.
15. AD Controller is a utility you can use to determine the status of workers and manage worker tasks. You use it to monitor the actions or workers and the status of the processing jobs they have been assigned.
Important: Oracle E-Business Suite requires Oracle Database Enterprise Edition. No other Oracle Database editions are certified for use with Oracle E-Business Suite environments.
Warning: At present, Rapid Install does not support installing Oracle E-Business Suite into a directory that has more than 2 TB of free space.This is because of address space restrictions.
adop Patching Modes:
• To run a patching cycle, and test patch application without actually taking any apply actions, in test mode
• To apply patches outside a patching cycle in downtime mode
• To apply patches without connecting to the database in preinstall mode
Test mode:
To run adop in test mode, add the apply=no parameter to the adop command
The way you run adop affects the way it stores patch history information. When you apply a patch in test mode (using apply=no on the command line), adop does not write to the patch information files, and it does not upload patch history information to the database.
Downtime mode:
adop will first confirm that the application tier services are down, and will then proceed to apply the patch to the run edition of the Oracle E-Business Suite database and file system. Downtime mode patching does not use an online patching cycle. The process of applying a patch in downtime mode completes more quickly than in online mode, but at the cost of increased system downtime.
To run adop in downtime mode, you use the following command line options. In this example, patch 123456 is applied in downtime mode:
$ adop phase=apply patches=123456 apply_mode=downtime
Be aware that:
• Release 12.2 patches are not normally tested in downtime mode.
• Downtime mode is only supported for production use where explicitly documented, or when directed by Oracle Support or Development.
Pre-install mode:
Preinstall mode is generally used during the upgrade process to update AD utilities, apply pre-upgrade patches, or work around other patching issues. adop asks all startup questions except those relating to the database.
When you apply a patch in pre-install mode (using preinstall=y on the command line), adop writes patch history information to the patch information files, and it uploads the contents of these files to the database the next time it runs.
Note: Run adop in preinstall mode only if the patch readme instructs you to do so. To run adop in preinstall mode, include preinstall=y on the adop command line.

Ref.: https://docs.oracle.com/cd/E26401_01/doc.122/e22954/T202991T531062.htm#5281339
 

Comments

Popular posts from this blog

MySQL InnoDB cluster troubleshooting | commands

Cluster Validation: select * from performance_schema.replication_group_members; All members should be online. select instance_name, mysql_server_uuid, addresses from  mysql_innodb_cluster_metadata.instances; All instances should return same value for mysql_server_uuid SELECT @@GTID_EXECUTED; All nodes should return same value Frequently use commands: mysql> SET SQL_LOG_BIN = 0;  mysql> stop group_replication; mysql> set global super_read_only=0; mysql> drop database mysql_innodb_cluster_metadata; mysql> RESET MASTER; mysql> RESET SLAVE ALL; JS > var cluster = dba.getCluster() JS > var cluster = dba.getCluster("<Cluster_name>") JS > var cluster = dba.createCluster('name') JS > cluster.removeInstance('root@<IP_Address>:<Port_No>',{force: true}) JS > cluster.addInstance('root@<IP add>,:<port>') JS > cluster.addInstance('root@ <IP add>,:<port> ') JS > dba.getC

MySQL slave Error_code: 1032 | MySQL slave drift | HA_ERR_KEY_NOT_FOUND

MySQL slave Error_code: 1032 | MySQL slave drift: With several MySQL, instance with master slave replication, I have one analytics MySQL, environment which is larger in terabytes, compared to other MySQL instances in the environment. Other MySQL instances with terabytes of data are running fine master, slave replication. But this analytics environment get started generating slave Error_code :1032. mysql> show slave status; Near relay log: Error_code: 1032; Can't find record in '<table_name>', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log <name>-bin.000047, end_log_pos 5255306 Near master section: Could not execute Update_rows event on table <db_name>.<table_name>; Can't find record in '<table_name>', Error_code: 1032; Can't find record in '<table_name>', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log <name>-bin.000047, end_l

InnoDB cluster Remove Instance Force | Add InnoDB instance

InnoDB cluster environment UUID is different on node: To fix it stop group replication, remove instance (use force if require), add instance back Identify the node which is not in sync: Execute following SQL statement on each node and identify the node has different UUID on all nodes. mysql> select * from mysql_innodb_cluster_metadata.instances; Stop group replication: Stop group replication on the node which does not have same UUID on all nodes. mysql > stop GROUP_REPLICATION; Remove instances from cluster: Remove all secondary node from the cluster and add them back if require. $mysqlsh JS >\c root@<IP_Address>:<Port_No> JS > dba.getCluster().status() JS > dba.getCluster () <Cluster:cluster_name> JS > var cluster = dba.getCluster("cluster_name"); JS >  cluster.removeInstance('root@<IP_Address>:<Port_No>'); If you get "Cluster.removeInstance: Timeout reached waiting......" JS > cluster.removeInstance(&#