Showing posts with label EBS. Show all posts
Showing posts with label EBS. Show all posts

12 June 2022

adop phase=actualize_all

 

How to Drop Old Database Editions in EBS R12.2 


In EBS R12.2, as each online patching cycle is completed, the database will accumulate an additional old database edition. An additional column ZD_EDITION_NAME is populated in the seed tables. If the number of these grows too large, system performance will start to be affected. When the number of old database editions reaches 25 or more, we should consider dropping all old database editions by running the adop actualize_all phase and then performing a full cleanup. 

Important: This procedure will take a large amount of time (significantly longer than a normal patching cycle), and should only be performed when there is no immediate need to start a new patching cycle.

Before starting, you should ensure that the system has the recommended database patches and latest AD-TXK code level installed.


When no patches need to be applied in Online Patching

To proceed, run the following commands in the order shown:
$ adop phase=prepare
$ adop phase=actualize_all
$ adop phase=finalize finalize_mode=full
$ adop phase=cutover
$ adop phase=cleanup cleanup_mode=full

Old database editions would be cleared now


OR

Every-time online patching is performed:

$ adop phase=prepare
$ adop phase=apply patches=1,2,3
$ adop phase=actualize_all   -------------> Do this here
$ adop phase=finalize finalize_mode=full
$ adop phase=cutover
$ adop phase=cleanup cleanup_mode=full

It has to be performed just before phase=finalize/cutover

How to execute an Empty Patching cycle in Oracle Apps R12.2

 

How to execute an Empty Patching cycle in Oracle Apps R12.2



Purpose: How to run empty patching cycle in EBS R12.2 

Occasion to run

> Testing purpose
> Switching the filesystem from fs1 to fs2, or vice versa.


Simple Command

login to application tier and invoke env file
cd /u01/install/APPS
. EBSapps.env RUN 

adop phase=prepare,finalize,cutover,cleanup

R12.2-Autoconfig-Testmode

 Purpose : How to run autoconfig in test mode in EBS 12.2 Database and Application

Source : https://docs.oracle.com/cd/E26401_01/doc.122/e22953/T174296T589913.htm (Section: Using the check config utility - adchkcfg.sh )

>>>> DB Tier

> Source the run file system environment

cd /u01/install/APPS/12.1.0/ . EBSDB_apps.env

> Navigate to $ORACLE_HOME/appsutil/bin

> Execute the command - ./adchkcfg.sh contextfile=$CONTEXT_FILE

The script generates both HTML and TEXT reports in $ORACLE_HOME/appsutil/out/$CONTEXT_NAME/MONDDHHMI/ directory on Database Tier

The reports contain both the File System Changes and Database Changes

File System Changes :

  • Autoconfig Context File Changes
  • Service Group Status
  • Changed Configuration Files
  • New Configuration Files
  • Template Customizations

Database Changes :

  • Profile Value Changes
  • Profile Values
  • Other Database Updates


[oracle@apps bin]$ cd $ORACLE_HOME/appsutil/bin
[oracle@apps bin]$
[oracle@apps bin]$ ./adchkcfg.sh contextfile=$CONTEXT_FILE
Enter the APPS password:

The log file for this session is located at: /u01/install/APPS/12.1.0/appsutil/log/EBSDB_apps/06120427/adconfig.log

AutoConfig is running in test mode and building diffs...

AutoConfig will consider the custom templates if present.
        Using ORACLE_HOME location : /u01/install/APPS/12.1.0
        Classpath                   : :/u01/install/APPS/12.1.0/jdbc/lib/ojdbc6.jar:/u01/install/APPS/12.1.0/appsutil/java/xmlparserv2.jar:/u01/install/APPS/12.1.0/appsutil/java:/u01/install/APPS/12.1.0/jlib/netcfg.jar:/u01/install/APPS/12.1.0/jlib/ldapjclnt12.jar

        Using Context file          : /u01/install/APPS/12.1.0/appsutil/out/EBSDB_apps/06120427/EBSDB_apps.xml

Context Value Management will now update the test Context file

        Updating test Context file...COMPLETED

        [ Test mode ]
        No uploading of Context File and its templates to database.

Updating rdbms version in Context file to db121
Updating rdbms type in Context file to 64 bits
Testing templates from ORACLE_HOME ...

Differences text report is located at: /u01/install/APPS/12.1.0/appsutil/out/EBSDB_apps/06120427/cfgcheck.txt

        Generating Profile Option differences report...COMPLETED
Differences text report for the Database is located at: /u01/install/APPS/12.1.0/appsutil/out/EBSDB_apps/06120427/ProfileReport.txt
        Generating File System differences report......COMPLETED
Differences html report is located at: /u01/install/APPS/12.1.0/appsutil/out/EBSDB_apps/06120427/cfgcheck.html

Differences Zip report is located at: /u01/install/APPS/12.1.0/appsutil/out/EBSDB_apps/06120427/ADXcfgcheck.zip

AutoConfig completed successfully.
[oracle@apps bin]$

=========================================================================
>>>> Application Tier

> Source the run file system environment

> Navigate to $AD_TOP/bin

> Execute the command - ./adchkcfg.sh contextfile=$CONTEXT_FILE

The script generates both HTML and TEXT reports in $INST_TOP/admin/out/MONDDHHMI/ directory on Application Tier


[oracle@apps ~]$ cd /u01/install/APPS [oracle@apps APPS]$ . EBSapps.env RUN E-Business Suite Environment Information ---------------------------------------- RUN File System : /u01/install/APPS/fs1/EBSapps/appl PATCH File System : /u01/install/APPS/fs2/EBSapps/appl Non-Editioned File System : /u01/install/APPS/fs_ne DB Host: apps.example.com Service/SID: EBSDB Sourcing the RUN File System ... [oracle@apps APPS]$ cd $AD_TOP/bin [oracle@apps bin]$ ./adchkcfg.sh contextfile=$CONTEXT_FILE Enter the APPS password: The log file for this session is located at: /u01/install/APPS/fs1/inst/apps/EBSDB_apps/admin/log/06120432/adconfig.log wlsDomainName: EBS_domain WLS Domain Name is VALID. AutoConfig is running in test mode and building diffs... AutoConfig will consider the custom templates if present. Using CONFIG_HOME location : /u01/install/APPS/fs1/inst/apps/EBSDB_apps Classpath : /u01/install/APPS/fs1/FMW_Home/Oracle_EBS-app1/shared-libs/ebs-appsborg/WEB-INF/lib/ebsAppsborgManifest.jar:/u01/install/APPS/fs1/EBSapps/comn/java/classes Using Context file : /u01/install/APPS/fs1/inst/apps/EBSDB_apps/admin/out/06120432/EBSDB_apps.xml Context Value Management will now update the test Context file Updating test Context file...COMPLETED [ Test mode ] No uploading of Context File and its templates to database. Testing templates from all of the product tops... Testing AD_TOP........COMPLETED Testing FND_TOP.......COMPLETED Testing ICX_TOP.......COMPLETED Testing MSC_TOP.......COMPLETED Testing IEO_TOP.......COMPLETED Testing BIS_TOP.......COMPLETED Testing CZ_TOP........COMPLETED Testing SHT_TOP.......COMPLETED Testing AMS_TOP.......COMPLETED Testing CCT_TOP.......COMPLETED Testing WSH_TOP.......COMPLETED Testing CLN_TOP.......COMPLETED Testing OKE_TOP.......COMPLETED Testing OKL_TOP.......COMPLETED Testing OKS_TOP.......COMPLETED Testing CSF_TOP.......COMPLETED Testing IBY_TOP.......COMPLETED Testing JTF_TOP.......COMPLETED Testing MWA_TOP.......COMPLETED Testing CN_TOP........COMPLETED Testing CSI_TOP.......COMPLETED Testing WIP_TOP.......COMPLETED Testing CSE_TOP.......COMPLETED Testing EAM_TOP.......COMPLETED Testing GMF_TOP.......COMPLETED Testing PON_TOP.......COMPLETED Testing FTE_TOP.......COMPLETED Testing ONT_TOP.......COMPLETED Testing AR_TOP........COMPLETED Testing AHL_TOP.......COMPLETED Testing IES_TOP.......COMPLETED Testing OZF_TOP.......COMPLETED Testing CSD_TOP.......COMPLETED Testing IGC_TOP.......COMPLETED Differences text report is located at: /u01/install/APPS/fs1/inst/apps/EBSDB_apps/admin/out/06120432/cfgcheck.txt Generating Profile Option differences report...COMPLETED Differences text report for the Database is located at: /u01/install/APPS/fs1/inst/apps/EBSDB_apps/admin/out/06120432/ProfileReport.txt Generating File System differences report......COMPLETED Differences html report is located at: /u01/install/APPS/fs1/inst/apps/EBSDB_apps/admin/out/06120432/cfgcheck.html Differences Zip report is located at: /u01/install/APPS/fs1/inst/apps/EBSDB_apps/admin/out/06120432/ADXcfgcheck.zip AutoConfig completed successfully. [oracle@apps bin]$


25 July 2014

How to change Apps Password in R12.2

Apps password change routine in Release 12.2 E-Business Suite changed a little bit. We have now extra options to change password, as well as some manual steps after changing the password using FNDCPASS.

Whether you use FNDCPASS or AFPASSWD to change the APPLSYS/APPS password, you must also perform some additional steps. This is because in R12.2, the old AOL/J connection pooling is replaced with Weblogic Connection Pool ( JDBC Datasource ).  Currently this procedure is not yet automated. It would be good, if this can be automated using some WLS scripting.

Important: These steps must be carried out on the run file system.

1.   Shut down the application tier services using the $INST_TOP/admin/scripts/adstpall.sh script.

2.   Change the APPLSYS password, as described for the utility you are using.

3.   Start AdminServer using the $INST_TOP/admin/scripts/adadminsrvctl.sh script. Do not start any other application tier services.

4.   Change the "apps" password in WLS Datasource as follows:
1.   Log in to WLS Administration Console.
2.   Click Lock & Edit in Change Center.
3.   In the Domain Structure tree, expand Services, then select Data Sources.
4.   On the "Summary of JDBC Data Sources" page, select EBSDataSource.
5.   On the "Settings for EBSDataSource" page, select the Connection Pool tab.
6.   Enter the new password in the "Password" field.
7.   Enter the new password in the "Confirm Password" field.
8.   Click Save.
9.   Click Activate Changes in Change Center.

5.   Start all the application tier services using the $INST_TOP/admin/scripts/adstrtal.sh script.

6.   Verify the WLS Datastore changes as follows:
1.   Log in to WLS Administration Console.
2.   In the Domain Structure tree, expand Services, then select Data Sources.
3.   On the "Summary of JDBC Data Sources" page, select EBSDataSource.
4.   On the "Settings for EBSDataSource" page, select Monitoring > Testing.
5.   Select "oacore_server1".
6.   Click Test DataSource
7.   Look for the message "Test of EBSDataSource on server oacore_server1 was successful".

Important: Steps 4, 5 and 6 are only applicable when changing the APPLSYS password. They are not applicable when changing passwords for product schemas or the SYSTEM schema.

In the next prepare phase after the password change, adop will invoke EBS Domain Configuration to ensure that the WLS datasource on the patch file system will be synchronized with the new APPS password.

How to apply HRGLOBAL in R12.2

Step 1 -Apply hrglobal.drv

There are some changes to apply HRGLOBAL in R12.2 w.r.t previous EBS version. We need to apply hrglobal same as adop patch life cycle. Steps are as below mention.

a) Start an online patching cycle
Source the run edition environment file: Example: UNIX: $RUN_BASE/EBSapps/appl/APPS$CONTEXT_NAME.env

$ adop phase=prepare

b) Run DataInstall from PATCH edition
The command line DataInstall java utility should be run on the tier which has the $APPL_TOP available. It will perform view creation actions against the database pertaining to the options selected. For multi-node/RAC setups, DataInstall need only to be run on the primary node.
Run the DataInstall java utility in order to select the legislations you want to apply as follows:
java oracle.apps.per.DataInstall <un> <pw> thin <host:port: sid >
where
< un > is the username of the main apps account
<pw> is the password for this account
<host:port: sid > represents the database connection information

For example: java oracle.apps.per.DataInstall apps apps thin dbsvr1:1521:testdb
12.2 SPECIFIC: For an Online patch enabled instance, DataInstall will only be runnable against the Patch Edition (Environment is prepared using "adop phase=prepare").
In order to retain the same command line usage from previous codelines, if the connect information passed to the DataInstall utility points to the Run Edition, then DataInstall will internally switch to operate against the Patch Edition.
Aside from this scenario, or for environments that are not Online patch enabled, DataInstall will operate exactly as before.
RUP Upgrade best practice:
On upgrade to a newer RUP, it is advised to apply all live localisations
 and Core (even if no new prereqs are listed).
For customers running non supported localisations, they should install just Core on RUP upgrade

Usage of DataInstall is fairly straightforward, basically select/deselect legislations to install using the index number of the legislation shown in the list in menu 1 followed by I for install or C for clear;
e.g. In menu 1, to install Global choose 1I, to cancel a selected operation, choose 1C etc. Menu 4 to choose to save your changes when you are OK with them.

c) Apply hrglobal.drv

The driver is located at $PER_TOP/patch/115/driver/hrglobal.drv and should be run on the tier which has the $APPL_TOP available. In most cases this will be the Apps tier.
hrglobal.drv is a pure "database, d type" driver so the actions in the driver apply only to the database. As such, for RAC/multi-node setups, it is only required to run the hrglobal.drv on one node. Be mindful to only run the driver located in the directory $PER_TOP/patch/115/driver hrglobal.drv driver should be applied as per a normal patch using the adop utility.

12.2 SPECIFIC: The driver will be applied via the adop patcing utility, as opposed to adpatch which was used prior to 12.2.

Care must be taken when applying hrglobal.drv via adop that the following parameters are passed with the adop command line:

options=nocopyportion,nogenerateportion,forceapply

Example: adop phase=apply patchtop=$PER_TOP/patch/115 patches=driver:hrglobal.drv options=nocopyportion,nogenerateportion,forceapply
where $PER_TOP corresponds to the patch file system

These options are mandatory in order to
a) avoid adop trying to sync the file system when applying a patch (in this case the hrglobal.drv file) that contains database operations only and
b) ensure that adop will not consider during an upgrade to have been installed previously and proceed with the current request.
Please also ensure the forceapply parameter is at the end of the options list.

Note:
- adop apply phase by default runs in autoskip mode, meaning that if there is failure, it will be skipped and the failed file will be mentioned in the autoskip.log
- users wont see the failures on the screen where the adop command is running
- users need to review the autoskip.log file after the completion of hrglobal to find any failed files which are skipped and take appropriate action

Once completed and no issues are reported in the autoskip.log file, you have successfully installed your legislative HRMS data.
d) Complete the online patching cycle by running the following commands in the order shown:

1. $ adop phase=finalize
2. $ adop phase=cutover
3. $ adop phase=cleanup
Step 2 - OPTIONAL
For customers using other languages than US and wishing to apply translated legislative seed data, please apply the relevant language specific version of the consolidated translation patch after successfully completing the hrglobal.drv above.


12 May 2014

Maintenance Mode -- EBS

Maintenance Mode is a new mode of operation introduced with Release 11.5.10, in which the Oracle Applications system is made accessible only for patching activities not allowing the users to login to any responsibility. This provides optimal performance for AutoPatch sessions, and minimizes downtime needed.

1. Scheduling System Downtime

Administrators can schedule 'System Downtime' using Oracle Applications Manager (OAM):
Site Map --> Maintenance --> Manage Downtime Schedules

When the System has been scheduled for 'Downtime', Apache should be re-started on Restricted Mode by using the Script (adaprstctl.sh).  By doing this, users attempting to log on to Oracle Applications will be automatically redirected to a System Downtime URL showing a message similar to the following one:
Scheduled Downtime Details

Start Time       : 17:30:00 12/11/2004
Expected Up Time : 09:00:00 12/12/2004
For Updates      : John.Smith@oracle.com

The system is currently undergoing a scheduled maintenance.

<Current Status>

This message can be customized with any text message.  If No Downtime has been specified, and the users try to access theApplications, the following message might also appear:
! Warning
The system has not been taken off maintenance mode completely.
Please contact your System Administrator.

2. Advantages

There are several practical points relating to the use of Maintenance Mode:
  • You can toggle Maintenance Mode between Enabled and Disabled using the new Change Maintenance Mode menu in AD Administration, or the equivalent function in Oracle Applications Manager.

  • Although you can run AutoPatch with Maintenance Mode disabled, there will be a significant degradation in performance.

  • There is a separate logon page for Restricted Mode access while the system is in Maintenance Mode. Restricted Mode allows administrators access to specific privileged functionality in OAM, for example to view the timing report that shows the progress of a patching session.
    For more Information on Restricted Mode Access please consult Metalink Note: 364236.1
    or the OAM Online Help (OAM->Patches and Utilities -> Managing Downtime Schedules -> Restricted Mode)
3. Enabling and Disabling Maintenance Mode

Maintenance mode is Enabled or Disabled from adadmin.

When you Enable or Disable 'Maintenance Mode', adadmin will execute the script:
$AD_TOP/patch/115/sql/adsetmmd.sql sending the parameter 'ENABLE' or 'DISABLE' :

sqlplus <APPS_Schema name>/<APPS Password>@adsetmmd.sql ENABLE | DISABLE

    ENABLE  -   Enable Maintenance Mode .
    DISABLE -   Disable Maintenance Mode.

When adsetmmd.sql runs, it sets the Profile Option 'Applications Maintenance Mode' (APPS_MAINTENANCE_MODE) to 'MAINT' to Enable 'Maintenance Mode' and to 'NORMAL' to Disable it.

4.  Determining if Maintenance Mode is Running

A quick way to verify if the Environment is on Maintenance Mode or not, is by checking the value of this Profile Option as follows:
sqlplus apps/apps
SQL> select fnd_profile.value('APPS_MAINTENANCE_MODE') from dual;

If the query returns 'MAINT', then Maintenance Mode has been Enabled and the Users will not be able to Login.  If the query returns 'NORMAL' then Maintenance Mode has been De-Activated and the Users will be able to use the application.

Note:  Maintenance Mode is only needed for AutoPatch Sessions. Other AD utilities do not require Maintenance Mode to be enabled. Maintenance Mode must be 'Enabled' before running AutoPatch and 'Disabled' after the patch application was completed.

When Maintenance Mode is disabled, you can still run Autopatch by using options=hotpatch on the command line, if necessary.  However, doing so can cause a significant degradation of performance.

5. Error Messages

Always remember to Disable Maintenance Mode after any Patch application. If Maintenance Mode is not Disabled, the Application will not allow the users to use the system.  Take note that Apache must be re-started in normal mode after disabling 'Maintenance Mode' by using the Script adapcctl.sh (or adstrtal.sh)

As explained before, when 'Maintenance Mode' is enabled, a Downtime should be Scheduled from OAM and Apache should be started on Restricted Mode by using the Script (adaprstctl.sh).

If a 'DownTime' is not Scheduled from OAM and Apache has not been re-started on Restricted Mode, the Application will allow the users to Login, but it might experience unusual behaviors afterwards depending on the Patch Level.

Here are some examples of the possible error messages:
  • When clicking on a Responsibility from the PHP
There are no applications available for this responsibility.  Please click on a different responsibility link to display the list of available applications.

or

You are not authorized to access the function Applications Home Page.  Please contact your System Administrator.

  • When trying to access to the Application via CGI directly (not supported):

There are no valid navigations for this responsibility

Cause: The menu compilation has failed.
Cause: There is not valid menu defined for this responsibility.
Cause: There are no navigable forms associated with this responsibility.

Action: Contact your system administrator. Ensure that a valid menu,
containing navigable forms, is defined for the responsibility.
Ensure that the menu is correctly compiled.

Note:  In some cases, the behavior is slightly different.  Instead of showing the above messages, the Application might not show any Responsibilities listed for the user at all.

6. Step by Step Process
1.  Schedule the 'System Downtime' from OAM
OAM: Site Map --> Maintenance --> Manage Downtime Schedules


At the moment of the downtime, do the following:
2.  Shutdown Apache (on Normal Mode):
   adapcctl.sh stop
   or
   adstpall.sh <apps_user>/<apps_pwd>

3.  Enable 'Maintenance Mode' from adadmin
   adadmin: Options 5, 1

4. Start Apache (on Restricted Mode)
   adaprstctl.sh start

5. Apply the Patch with adpatch

6.  Stop Apache (on Restricted Mode)
  adaprstctl.sh stop

7.  Disable 'Maintenance Mode' from adadmin
   adadmin: Options 5, 2

8.  Start Apache (on Normal Mode):
 
  adapcctl.sh start
  or
  adstrtal.sh <apps_user>/<apps_pwd>