Change The Repository (RPD) Password in OBIEE

 How To Change The Repository (RPD) Password in OBIEE

We can Change the Oracle BI Repository Password Using the obieerpdpwdchg Utility

Use the following steps to Change The Repository (RPD) Password:

1. Navigate to the obieerpdpwdchg utility, which is located under $BI_DOMAIN_HOME/bitools/bin directory.

Type the following arguments for obieerpdpwdchg:

-I name_and_path_of_existing_repository

-O name_and_path_of_new_repository

2. Then, enter the current (old) password and the new password when prompted. The repository password must be longer than five characters and cannot be empty.

$ obieerpdpwdchg -I my_repos.rpd -O my_changed_repos.rpd

Please enter the repository password:

Please enter a new repository password:

Note that passwords are masked on the command line unless you include the -C option in the command to disable masking.

3. Use the uploadrpd command to upload the repository to Oracle BI Server.

Please see this link to - OBIEE 12c: Download and Upload Repository(RPD) Commands

ADOP-PATCHING-1.0

 ADOP Patching:

adop phases:

prepare       : Prepare the instance for online patching.

apply         : Apply patch(es) to the Patch Edition.  

finalize      : Ready the instance for cutover.  

abort         : Abort the patching cycle.  

cutover       : Promote the Patch Edition to Run Edition.   

cleanup       : Drop obsolete objects and seed data from Old Editions.

actualize_all : Actualize all objects in the Patch Edition.   

cleanup_full  : Cleanup and drop Old Editions.   

abandon       : yes|no - Abandon failed patches.

adop patch log directory:

<INSTALL BASE>/fs_ne/EBSapps/log/adop

adop patch process cycle steps:

Download any required technology patches and unzip the contents. The patch contents may be unzipped into  $NE_BASE/EBSapps/patch.

1. Prepare the system for patching. 

   source <EBS_ROOT>/EBSapps.env run

   $ adop phase=prepare 

2. Apply technology patches to the Oracle Home under the Patch f/s using the information below. 

   source <EBS_ROOT>/EBSapps.env patch 

3. Apply any Oracle E-Business Suite patches planned for this patching cycle 

   $ adop phase=apply patches=<patch_list> 

4. After all patches have been successfully applied, complete the patching cycle. 

   $ adop phase=finalize 

   $ adop phase=cutover 

Note: Below steps can be done when applications are up and running 

5. source <EBS_ROOT>/EBSapps.env run 

   

   $ adop phase=cleanup

6. To complete the process and synchronize the technology level between patch and run f/s. 

   $ adop phase=fs_clone

adop hotpatch steps (we cannot abort hotpatch and abondon cannot be done):

Hotpatch which can apply directly on run fs

$ adop phase=apply patches=<patch_list> hotpatch=yes

After hotpatch please run phase=cleanup and phase=fs_clone to sync the run fs with patch fs to prepare for next patching cycle

adop re-apply patch forcefully:

If we try to re-apply the patch which is already applied/exists then adop patch terminates 

with below message and by default it takes N when prompted. to overcome this we need to

re-apply patch with options=forceapply.

This Patch seems to have been applied already.

Would you like to continue anyway  [N] ? N *

$ adop phase=apply patches=<patch list> hotpatch=yes options=forceapply

adop deal with "Continue As If It Were Successful" error:

$ adop phase=apply patches=<patch list> abandon=no restart=yes flags=autoskip

To define workers in adop:

$ adop phase=apply patches=<patch list> workers=5

To define patchtop in adop:

$ adop phase=apply patches=<patch list> patchtop=<patch location base>

adop merge patch:

$ adop phase=apply patches=<patch list> merge=yes

Restarting adop From A Failed Session:

 

 $ adop phase=abort

 $ adop phase=cleanup cleanup_mode=full

 $ adop phase=fs_clone 

Then reapply the patch

adop apply for language patch:

$ adop phase=apply patches=18023722_ESA:u18023722.drv

adop non-interactive with patch top and define driver:

$ adop phase=apply options=nocopyportion patchtop=$XLA_TOP/patch/115 patches=driver:xla5584908.drv

adop Steps to follow to skip the failed workers:

1. Use adctrl and select option#8 (This will not be visible) to skip thefailed jobs

2. Restart adop using "restart=yes" parameter

** If the failed jobs are numerous, then better to re-start this patch once again with autoskip option.

ie.  adop restart=no abandon=yes flags=autoskip 

This command will restart the patch once again from starting onwards and will skip all the failures if any comes. But make sure to review the log file at the end of the patch application that you have skipped the failures that you want to.

Weblogic Server Smart Update Patching :

Steps to apply weblogic server smart update patch:

Refer Note: 

How to Apply WebLogic Server (WLS) Patches Using Smart Update [Video] (Doc ID 876004.1)

1.Download the patch 

2.Copy the files (for example, E5W8.jar and WGQJ.jar) and the patch-catalog_xxx.xml from the zip file to the target machine. You do not need the readme file.

Path: $FMW_HOME/utils/bsu/cache_dir

3.cd $FMW_HOME/utils/bsu

To install patch:

./bsu.sh -prod_dir=$FMW_HOME/wlserver_10.3 -patchlist=7FC9 -verbose -install

To Verify:

./bsu.sh -prod_dir=$FMW_HOME/wlserver_10.3 -status=applied -verbose -view | grep 7FC9

To Rollback:

./bsu.sh -remove -patchlist=7FC9 -prod_dir=$FMW_HOME/wlserver_10.3 -verbose

We can also apply the Smart Update patch in graphical (GUI) mode.

Steps to apply opatch on FMW Web Tier HOME :

Set the Environment as below (replace <INSTALL_BASE> path as required): 

 

$ export ORACLE_HOME=$FMW_HOME/webtier

$ export PATH=$ORACLE_HOME/OPatch:$PATH

$ opatch lsinventory 

Apply opatch:

$ opatch apply

Steps to apply opatch on FMW oracle_common HOME :

Set the Environment as below:

$ export ORACLE_HOME=$FMW_HOME/oracle_common

$ export PATH=$ORACLE_HOME/OPatch:$PATH

$ opatch lsinventory 

Apply opatch:

$ opatch apply

Queries :

Query to check if a patch is applied in Oracle EBS R12.2.x:

In Oracle E Business Suite (ebs erp) R12.2.x you cannot query the AD_BUGS table to check if patches have been applied..

The AD_BUGS table may have entries for patches that were applied but later the patching cycle was aborted (not really applied).

The way to check whether a patch is really applied is to use the AD_PATCH.IS_PATCH_APPLIED PL/SQL function.

Usage:

select AD_PATCH.IS_PATCH_APPLIED(\'$release\',\'$appltop_id\',\'$patch_no\',\'$language\') 

from dual;

Example sql:

SELECT adb.bug_number,ad_patch.is_patch_applied('11i', 1045, adb.bug_number)

FROM ad_bugs adb

WHERE adb.bug_number in (20034256);

or for single app tier installations:

select ad_patch.is_patch_applied('R12',-1,20034256) from dual;

Expected results:

EXPLICIT = applied

NOT APPLIED = not applied / aborted

Note: If you are sure patch is applied, but showing as not applied then do the following workaround.

1. Start adadmin after source the RUN FS env.

2. Select "2. Maintain Applications Files menu" in "AD Administration Main Menu".

3. In "Maintain Applications Files", select "4. Maintain snapshot information".

4. Select "2. Update current view snapshot" in the "Maintain Snapshot Information".

5. Select "1. Update Complete APPL_TOP" in the "Maintain Current View Snapshot Information".

Query to check current AD patchset:

SELECT a.application_short_name, b.patch_level

FROM fnd_application_vl a,fnd_product_installations b

WHERE a.application_id = b.application_id

  and application_short_name = 'AD';

Query to check patches applied correctly and in the expected sequence:

1.1.Run this sql statement:

   select * from ad_adop_session_patches order by end_date desc;

1.2. Run this piece of sql code:

   set pagesize 200;

   set linesize 160;

   column adop_session_id format 999999999999;

   column bug_number format a15;

   column status format a15;

   column applied_file_system_base format a23;

   column patch_file_system_base format a23;

   column adpatch_options format a15;

   column node_name format a15;

   column end_date format a15;

   column clone_status format a15;

   select ADOP_SESSION_ID, BUG_NUMBER, STATUS, APPLIED_FILE_SYSTEM_BASE, PATCH_FILE_SYS   TEM_BASE, ADPATCH_OPTIONS, NODE_NAME, END_DATE, CLONE_STATUS

   from ad_adop_session_patches

   order by end_date desc;

 

Below are possible values of STATUS column:

N - Not Applied In the current node but applied in other nodes

R - Patch Application is going on.

H - Patch failed in the middle. (Hard Failure)

F - Patch failed in the middle but user tried to skip some failures.

S - Patch Application succeeded after skipping the failed jobs.

Y - Patch Application succeeded.

C - Reserved for clone and config_clone. Indicates clone completed

Query to Check AD and TXK C Patch levels:

SELECT codelevel FROM AD_TRACKABLE_ENTITIES WHERE abbreviation in ('txk','ad');

Weblogic authentication denied

Weblogic authentication denied

Problem description

The Weblogic admin server and / or managed server(s) are unable to start properly and throwing an authentication denied error message.

Weblogic errors observed

Error #1

 <Critical> <WebLogicServer> <BEA-000386> <Server subsystem failed.

Reason: weblogic.security.SecurityInitializationException: Authentication denied: Boot identity not valid;

The user name and/or password from the boot identity file (boot.properties) is not valid.

The boot identity may havenbeen changed since the boot identity file was created. Please edit and update

the boot identity file with the proper values of username and password. The first time the updated boot identity file

is used to start the server, these new values are encrypted.

weblogic.security.SecurityInitializationException: Authentication denied: Boot identity not valid;

The user name and/or password from the boot identity file (boot.properties) is not valid.

The boot identity may have been changed since the boot identity file was created. Please edit and update the boot identity file

with the proper values of username and password. The first time the updated boot identity file is used to start the server,

these new values are encrypted.

at weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.doBootAuthorization(Unknown Source)

at weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.initialize(Unknown Source)

at weblogic.security.service.SecurityServiceManager.initialize(Unknown Source)

at weblogic.security.SecurityService.start(SecurityService.java:141)

at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)

Truncated. see log file for complete stacktrace

Error #2

<Jul 30, 2011 5:11:55 AM PST> <Critical> <Security> <BEA-090403> <Authentication for user <user> denied>

<Jul 30, 2011 5:11:55 AM PST> <Critical> <WebLogicServer> <BEA-000386> <Server subsystem failed.

Reason: weblogic.security.SecurityInitializationException: Authentication for user <user> denied

weblogic.security.SecurityInitializationException: Authentication for user <user> denied

at weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.doBootAuthorization(Unknown Source)

at weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.initialize(Unknown Source)

at weblogic.security.service.SecurityServiceManager.initialize(Unknown Source)

at weblogic.security.SecurityService.start(SecurityService.java:141)

at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)

Truncated. see log file for complete stacktrace

Possible root causes and solutions

Root cause #1

The Weblogic boot.properties file is corrupted or contains invalid principal and credentials

Solution >> boot.properties reset

·         Backup and clear the cache and data directories under <WL Domain>/servers/<Admin & Managed server>

·         Recreate boot.properties (put back your plain text username and password) under <WL Domain>/servers/<Admin & Managed server>/security directory and restart the affected server(s)

Root cause #2

The Weblogic boot.properties file is valid but the security realm is corrupted or in an invalid state

Solution >> Weblogic Admin username and password reset

·         Backup your Weblogic server domain

·         Rename or delete <WL Domain>/security/DefaultAuthenticatorInit.ldift

·         Run the following Java command:

        java weblogic.security.utils.AdminAccount <new-admin-user-name> <new-admin-user-pwd> <<WL Domain>/security >

·         Delete the contents inside the file boot.properties under <WL Domain>/servers/< AdminServer>/security

·         Add the following contents inside the boot.properties

        username=<new-admin-user-name>

        password=<new-admin-user-pwd>

·         Backup and delete the folder: <WL Domain>/servers/<AdminServer>/data/ldap

·          Restart your Weblogic server 

How ADOP works

 

How ADOP works in EBS R12?

The online patching cycle consists of five phases which are executed in order. Example of a typical online patching cycle:

source /EBSapps.env run
adop phase=prepare
adop phase=apply patches=123456
adop phase=finalize
adop phase=cutover
source /EBSapps.env run
adop phase=cleanup

Note that after cutover the command line environment should be re-loaded as the run edition file system has changed.

In a multi-node deployment, adop commands are only executed from the primary node. The primary adop session uses remote execution to automatically perform required actions on any secondary node.

Multiple phases of adop can be executed in a single line command. Example of combined finalize/cutover/cleanup:

adop phase=finalize,cutover,cleanup

Prior to cutover, it is possible to execute additional “apply” and “finalize” phases as needed. Example of applying multiple patches using separate apply commands:

source /EBSapps.env run
adop phase=prepare
adop phase=apply patches=123456
adop phase=apply patches=223456
adop phase=finalize
adop phase=apply patches=323456
adop phase=finalize
adop phase=cutover
source /EBSapps.env run
adop phase=cleanup

Note that it is possible to apply additional patches after running the finalize phase, but if you do so then you will need to run the finalize phase again. Finalize must always be run immediately prior to cutover.

ADOP Common Parameters

workers= [default: computed]

Number of parallel workers used to execute tasks. Default value is computed principally according to number of available CPU cores.

input_file=

adop parameters can be specified in a text file, with one

=

on each line of the file. Command line parameters override input file parameters.

loglevel=(statement|procedure|event|warning|error|unexpected) [default: event]

Controls the level of diagnostic log detail displayed on the console output. Each log message is tagged with a level:

1) statement – is only used for debugging.
2) procedure – is only used for debugging high level procedures.
3) event – is used to display informational messages in normal processing. This is the default value.
4) warning – is used to indicate an internal error that is handled by the system and does not affect processing.
5) error – indicates an action failed and will need to be reviewed by the user, but the system was able to continue processing.
6) unexpected – indicates an unrecoverable error that halts processing and requires user intervention before processing can continue.

Setting loglevel will display messages at that level and higher.

prompt=(yes|no) [default: yes]

Specifies whether adop should prompt for user input on warnings. By default adop will ask user whether to continue or exit on some warning messages. If this parameter is set to “no” adop will remain fully non-interactive, and will continue past any warning messages without user confirmation.

Below is the list of Diagnostic Parameters. Normally these parameters are not used, until unless directed by Oracle Support:

allowcoredump=(yes|no) [default: no]

Specifies whether adop should create a core dump if it crashes. This option should only be used if directed by support.

analytics=(yes|no) [default: no]

Controls whether adop writes additional reports with information that might be helpful in some diagnostic situations. This option should not be used unless directed by Support.

defaultsfile= [default: adalldefaults.txt]

Name of the response file providing default parameter values for non-interactive execution of adadmin and adop. The file must be in the$APPL_TOP/admin/$TWO_TASK directory in both run edition and patch edition file systems. The default file “adalldefaults.txt” is maintained by AutoConfig and normally you should not need to change any values.

ADOP Prepare Phase

Prepare phase will be create a new Online Patching Cycle ID and start with Syncronizing the File System of Run into Patch. This will be followed by creation of Patch Edition in database.

The phase has below specific parameter:

skipsyncerror=(yes|no) [default: no]

It specifies whether to ignore errors that may occur during incremental file system synchronization. This might happen if you applied a patch in the previous patching cycle that had errors but decided to continue with the cutover. When the patch is synchronized on the next patching cycle, the apply errors may occur again, but can be ignored.

After complition of Prepare Phase you can start with migration of customization to the Patch Edition File System and you can apply Application Technology Stack Patches i.e. Oracle Home (10.1.2) Patches and Weblogic Patches. This can be done until you are completed with Cutover Phase.

ADOP Apply Phase

This is the phase where in patches are actully applied.

The phase has below specific parameters:

apply=(yes|no) [default: yes]

Controls whether adop actually applies the patch. You can specify “apply=no” to run adop in test mode, where the patch will not actually be applied, and adop will record what it would have done in the log.

patches=[,…]
patches=:[,:…]

This parameter specifies a comma-separated list of patches to be applied. Patches can be specified either as the patch number or by the patch directory and driver file. All patches are expected to be in the $PATCH_TOP directory on all tiers. Patches are applied serially unless the merge=yes parameter is specified.

patchtop= [default: $PATCH_TOP]

Path to a user-specified directory where patches are unzipped. The default and recommend location is the $PATCH_TOP directory automatically created by the install. When using an alternate patchtop you must ensure that the location is not within the editioned file systems (fs1, fs2) and is accessible by the same path for all nodes of a multi-node deployment.

apply_mode=(online|downtime|hotpatch) [default: online]

It is used to specify how the patch will be applied. There 3 option can be explained as below:

online – It will apply a patch to the patch edition during an online patching cycle.
downtime – It will apply a patch to the run edition when application services are down. When using this mode, you only run the apply phase.
hotpatch – apply a patch to the run edition when application services are up. When using this mode, you only run the apply phase

In downtime mode, adop will validate that application services are shutdown before apply the patch. The patch will be applied to the run edition of the system. Downtime mode patching does not use an online patching cycle and hence if there is an online patching cycle in progress. The process of applying a patch in downtime mode completes more quickly than in online mode, but at the cost of increased system downtime.

In hotpatch mode, adop will apply the patch to the run edition of the system while application services are still running. Patches that can be safely applied in hotpatch mode (such as NLS and Online Help patches) will document this in the patch readme. Hotpatch mode cannot be used if there is an online patching cycle in progress.

merge=(yes|no) [default: no]

Indicates whether adop should merge a list of patches before applying. By default, adop will apply a list of patches serially in the order specified. You can also use AD Merge Patch to merge multiple patches ahead of the apply command.

restart=(yes|no) [default: no]

Use restart=yes to resume the previous failed apply command from where processing terminated. If an apply command fails, check the log files for further information. If the problem can be corrected, you can then restart the apply command where it left off using the restart parameter.

When restarting a failed apply it is important to use the same parameters as the failed command, with only the addition of the restart=yes parameter.

abandon=(yes|no) [default: no]

Use abandon=yes to abandon the previous failed apply command and start a new apply command. Note that any changes made to the system by the failed command will remain in effect. The abandon flag is most useful when applying a replacement patch for the failing patch. If a patch fails to apply and there is no replacement patch, you may also abort the online patching cycle. See abort phase later in this blog.

options=[,…]

Options can be specified in a comma-separated list to control advanced features when a patch is applied. These options are normally not needed unless specified by documentation or support. Note that these options can be prefixed with “no”, e.g. “nocheckfile”, to disable the behavior, and for some options “no” is the default.

checkfile [default: checkfile] – Skip running exec, SQL, and exectier commands if they are recorded as already run.

compiledb [default: compiledb] – Compile invalid objects in the database after running actions in the database driver.

compilejsp [default: compilejsp] – Compile out-of-date JSP files, if the patch has copy actions for at least one JSP file.

copyportion [default: copyportion] – Run commands found in a copy driver.

databaseportion [default: databaseportion] – Run commands found in a database driver.

generateportion [default: generateportion] – Run commands found in a generate driver.

integrity [default: nointegrity] – Perform patch integrity checking

autoconfig [default: autoconfig] – Run AutoConfig.

actiondetails [default: actiondetails] – Turn off display of action details.

parallel [default: parallel] – Run actions that update the database or actions that generate files in parallel.

prereq [default: noprereq] – Perform prerequisite patch checking prior to running patch driver files.

validate [default: novalidate] – Connect to all registered Oracle E-Business Suite schemas at the start of patch application.

phtofile [default: nophtofile] – Save patch history to file

forceapply [default: noforceapply] – Reapply a patch that has already been applied. Useful in combination with “nocheckfile” option to rerun files that have already been executed.

flags=[,…]

Flags can be specified in a comma-separated list to control advanced features when applying a patch. Note that these flags can be prefixed with “no”, e.g. “nologging”, to disable the behavior and for some flags “no” is the default.

hidepw [default: hidepw] – Omit the “HIDEPW:” comments in the log file.

trace [default: notrace] – Log all database operations to a trace file.

logging [default: nologging] – Create indexes in LOGGING or NOLOGGING mode.

autoskip [default: noautoskip] – To proceed with adpatch execution even if some driver actions failed. Failed actions are recorded in a log file.

preinstall=(yes|no) [default: no]

Allows a patch to be applied to the file system without connecting to the database. Do not use this parameter unless directed by Oracle.

wait_on_failed_job=(yes|no) [default: no]

Controls whether adop apply command exits when all workers have failed. Instead of exiting, you can force adop to wait, and use the “adctrl” to retry failed jobs.

printdebug=(yes|no) [default: no]

Controls whether to display additional debugging information.

uploadph=(yes|no) [default: yes]

Controls whether to upload patch history information to database after applying the patch.

ADOP Finalize Phase

Finalize Phase is performed to keep the system ready for Cutover phase. This phase perform various activities like:

1. Compiling Invalid Objects
2. Generating driverd objects
3. Pre-compute DDL to be run during Cutover

Finalize Phase have below specific parameters:

finalize_mode=(full|quick) [default: quick]

Quick mode will provide the shortest execution time, by skipping non-essential actions. Full mode performs additional actions such as gathering statistics that may improve performance after cutover.

ADOP Cutover Phase

Cutover phase perform below activities:

1. Bring down Application services
2. Promote Patch File System to the Run File System.
3. Promote Patch Database Edition to the Run Database Edition.
4. Perform Maintenance task
5. Bring up application services

Cutover Phase have below specific parameters:

mtrestart=(yes|no) [default: yes]

Specifies whether to restart application tier servers after cutover. Leave at default unless you need to perform any manual steps during downtime.

cm_wait= [default: forever]

Specifies the number of minutes to wait for Concurrent Manager shutdown. Adop cutover starts by requesting a concurrent manager shutdown and then waits for in-progress requests to complete. If Concurrent Manager does not shutdown within the specified time limit, remaining concurrent requests will be killed and cutover will proceed.

Note that any concurrent requests killed during forced shutdown may need to be manually re-submitted after cutover. To avoid killing concurrent requests, schedule cutover at a time of minimal user activity or manually shutdown Concurrent Manager in advance of cutover.

ADOP Cleanup Phase

This phase will cleanup the Application and Database for the next Patching Cycle.

Cleanup phase specific parameters are:

cleanup_mode=(full|standard|quick) [default: standard]

Quick mode provides the shortest execution time, by skipping non-essential actions. Standard mode performs additional processing to drop obsolete code objects from old editions. Full mode performs additional processing to drop empty database editions and unused table columns.

Cloning the Patch Edition File System

The patch edition file system is normally synchronized with the run edition file system during the prepare phase. There are some cases where it is helpful or required to manually re-clone the patch edition file system from the run edition.

1) After aborting an online patching cycle.
2) After manually changing the run edition file system.
3) After patching middle-tier technology components.
4) After applying an EBS RUP.

By re-cloning the patch edition file system, you can be certain that it is correctly synchronized, and also minimize any synchronization delay that would normally occur on the next prepare command. This can be down by below command:

adop phase=fs_clone

If there is any error you must examine log files and correct the problem, then restart the fs_clone by running the command again. User below command if fs_clone does not restart correctly and you want to force the process to restart from the beginning.

adop phase=fs_clone force=yes

Aborting an online patching cycle

If an online patching cycle encounters problems that cannot be fixed immediately you can abort the patching cycle and return to normal runtime operation. Aborting an online patching cycle can be issue as below:

adop phase=abort

Note that once you are done with Cutover phase, you can abort ADOP Cycle.

The abort command drops the database patch edition and returns the system to normal runtime state. Immediately following abort, you must also run a full cleanup and fs_clone operation to fully remove effects of the failed online patching cycle.

Dropping old database editions

As online patching cycles are completed, the system will build up a number of old database editions. When the number of old database editions reaches about 25, you should consider running a special maintenance operation to drop old database editions. This can be down as below:

adop phase=prepare
adop phase=actualize_all
adop phase=finalize
adop phase=cutover
adop phase=cleanup cleanup_mode=full

This maintenance operation will take much longer than a typical online patching cycle, and should only be performed when there is no immediate need to start a new online patching cycle. The actualize all and full cleanup can be done separately as shown above, or can be executed in conjunction with an online patching cycle.

Log File Location

The adop log files are located on the non-editioned file system (fs_ne), under:

$NE_BASE/EBSapps/log/adop//__//log

Session

The adop utility maintains a session for each online patching cycle. A new session is created when you run the prepare phase. Each session is given a numeric ID number. The session is used to maintain the state of the online patching cycle across the various adop phases and commands. You can only run one adop session at a time on a particular Oracle E-Business Suite system

Patching-WebLogic-Server

 

Applying patches to WebLogic Server 12c is done using the OPatch utility. Make sure any processes running under this WebLogic installation are stopped before applying a patch.

Download the latest version of OPatch and the WebLogic updates from Oracle Support and put them into the "/u01/software" directory with the other software. For example.

• OPatch : p6880880_132000_Generic.zip *** See Note Below
• Updates : p22331568_122100_Generic.zip

 At the time of writing, the latest version of OPatch (OUI NextGen 13.2) is older than the version of OPatch that ships with WebLogic Server 12.2.1.

Assuming a newer version of OPatch were available you would unzip the OPatch utility and add it to your path.

cd /u01/software
unzip p6880880_132000_Generic.zip
export PATH=/u01/software/OPatch:$PATH

Since there isn't a newer version available at the time of writing, we will use the existing one.

export PATH=$MW_HOME/OPatch:$PATH

Unzip the patch and change to the resulting directory, then apply the patch.

unzip -d PATCH_TOP p22331568_122100_Generic.zip
cd PATCH_TOP/22331568
export ORACLE_HOME=$MW_HOME
opatch apply

Answer any prompts and take appropriate action when required.

When the patch is complete, check the WebLogic version using the following command. Depending on the scale of the patch, the version may not have changed.

. $WLS_HOME/server/bin/setWLSEnv.sh
java weblogic.version

Oracle WebLogic Server (WLS) 12cR2 (12.2.1) Installation on Oracle Linux 7

 

Setup

The following actions should be performed by the "root" user.

Make sure the "/etc/hosts" file contains correct entries for both the "localhost" and real host names.

127.0.0.1      localhost localhost.localdomain localhost4 localhost4.localdomain4
192.168.56.133 ol6.localdomain ol6

Create a new group and user.

groupadd -g 54321 oinstall
useradd -u 54321 -g oinstall oracle
passwd oracle

Create the directories in which the Oracle software will be installed.

mkdir -p /u01/app/oracle/product/12.2.1
mkdir -p /u01/app/oracle/config/domains
mkdir -p /u01/app/oracle/config/applications
chown -R oracle:oinstall /u01
chmod -R 775 /u01/

Append the following entries into the "/home/oracle/.bash_profile" file.

# Adjust paths as required.
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/12.2.1
export MW_HOME=$ORACLE_HOME
export WLS_HOME=$MW_HOME/wlserver
export WL_HOME=$WLS_HOME
export DOMAIN_BASE=$ORACLE_BASE/config/domains
export DOMAIN_HOME=$DOMAIN_BASE/mydomain
export JAVA_HOME=/u01/app/oracle/jdk1.8.0_144
export PATH=$JAVA_HOME/bin:$PATH

Install the JDK.

# su - oracle
$ cd $ORACLE_BASE
$ tar -xvzf /tmp/jdk-8u144-linux-x64.gz

For Oracle Linux 6, as specified in MOS Note [ID 1487773.1], amend the "/etc/security/limits.d/90-nproc.conf" file, making the following change.

# From
*          soft    nproc     1024

#To
* - nproc 16384

Installation

 The images were originally captured from a 12.2.1.0 installation. The process is the same for 12.2.1.2.

Run the installer as the "oracle" user.

$ unzip fmw_12.2.1.2.0_infrastructure_Disk1_1of1.zip
$ $JAVA_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure.jar

If this is is the first installation on the machine you will need to specify an inventory location. Enter the inventory location, like "/u01/app/oraInventory" and click the "OK" button.

Click the "Next" button on the welcome screen.

Select the "Skip Auto Updates" options, then click the "next" button.

Enter the middleware home ("/u01/app/oracle/product/12.2.1") and click the "Next" button.

Accept the "Fusion Middleware Infrastructure" option by clicking the "Next" button.

Wait for the prerequisite checks to complete. If there are failures, correct them and rerun the checks. If there are no failures, click the "Next" button.

Either enter your support details, or uncheck the security updates checkbox. Click the "Next" button. If you chose not to receive security updates, click the "Yes" button on the warning dialog.

If you are happy with the summary information, click the "Install" button.

Wait for the installation to complete, then click the "Next" button.

On the installation complete screen, click the "Finish" button to launch the Configuration Wizard.

If you are doing an installation for Oracle Forms and Reports Services, you don't need to create the domain at this point, so stop here.

Create Domain

Launch the Configuration Wizard with the following command.

$ $ORACLE_HOME/oracle_common/common/bin/config.sh

Accept the "Create a new domain" option, enter the domain name at the end of the "Domain Location", then click the "Next" button. In this case my domain was called "mydomain", so the path I used was "/u01/app/oracle/config/domains/mydomain".

Select the required product template and click the "Next" button.

Enter the administrator credentials and click the "Next" button.

Enter the domain mode and JDK details, then click the "Next" button.

Select any required advanced configuration options. For this example I ignored the advanced configuration. Click the "Next" button.

If you are happy with the configuration summary screen, click the "Create" button.

Once the domain is created, click the "Next" button.

Make a note of the Admin Server URL and click the "Finish" button.

Post-Installation

If you chose the "Production Mode" options for the domain, you will need to create a "boot.properties" file for the scripts referred to later to work without credentials. Adjust the DOMAIN_HOME and credentials appropriately.

$ export DOMAIN_HOME=$ORACLE_BASE/config/domains/mydomain
$ mkdir -p $DOMAIN_HOME/servers/AdminServer/security
$ echo "username=weblogic" > $DOMAIN_HOME/servers/AdminServer/security/boot.properties
$ echo "password=Password1" >> $DOMAIN_HOME/servers/AdminServer/security/boot.properties

The "$ORACLE_BASE/config/domains/mydomain" directory now contains a script that can be used to start the server. Remember to use the "&" if you want access to the commandline to be returned.

$ $DOMAIN_HOME/startWebLogic.sh &

Once the server is started you can access the administrator console using the "http://hostname:port/console" URL. Log in using the username and password provided in the previous step.

The following scripts are useful.

$ # Start NodeManager (if you configured one-per-domain)
$ nohup $DOMAIN_HOME/bin/startNodeManager.sh > /dev/null 2>&1 &


$ # Start WebLogic
$ nohup $DOMAIN_HOME/startWebLogic.sh > /dev/null 2>&1 &
$ # or
$ nohup $DOMAIN_HOME/bin/startWebLogic.sh > /dev/null 2>&1 &

$ # Stop WebLogic
$ $DOMAIN_HOME/bin/stopWebLogic.sh


$ # Start Managed Server
$ nohup $DOMAIN_HOME/bin/startManagedWebLogic.sh AdminServer > /dev/null 2>&1 &

$ # Stop Managed Server
$ $DOMAIN_HOME/bin/stopManagedWebLogic.sh AdminServer


$ # Start the configuration wizard
$ $WLS_HOME/common/bin/config.sh