DRM: There are currently no applications available for login

Hi Friends,

Most of you would have faced Oracle Data Relationship Management (DRM) Error: There are currently no applications available for login error while logging to Data Relationship Management (DRM) Web-client. No exception to that, I too faced one such instance in recent times.

In this post, we will see what are things to check in Oracle Data Relationship Management (DRM) when you encounter this error and how this issue got fixed for me.

Note:

• This post has been written and associated activities have been demonstrated on Oracle Data Relationship Management (DRM) version 11.1.2.4.344.
• The demonstrating Hyperion environment has Oracle database server 12.2.0.2 (18c) as backend database. 

One fine morning, one of our DRM users had reported that he is not able to login to DRM Web Client encountering the following error message:

Error: There are currently no applications available for login 

Immediately I opened DRM Web Client to confirm whether it's working with ADMIN credentials or not. Like the user, I too faced the same error even with Data Relationship Management (DRM) ADMIN account.

When I checked the DRM Web services status in the service panel, they were running perfectly fine.

To cross-check the Data Relationship Management (DRM) Web Services status, I connected to Oracle Data Relationship Management (DRM) Configuration Console (as an Administrator):

In Configuration Console, I noticed that, though DRM Web services were up and running, Data Relationship Management (DRM) application was stopped.

I thought why not first validate the database connection here and did the same. 

Database connection was successful.

Its time to start the application.

But starting application did not work. I could see, the application was still in STOPPED state.

Alright, let's search for some errors now.

Open the Windows Event Viewer and Explore Windows Logs-->Application

I noticed total 3 DRM error messages recorded in Event viewer:

Error-1:

Error-2:

Error-3:

Going through the above DRM Error messages, we come to know that DRM application engine could not be started because of:

DRM-63015: Read/Write engine for Application on DRM Server will not start because another Application is currently using the same repository.

Generally, 'DRM-63015' error message indicates that your DRM schema might be locked because some other DRM application has already connected to it i.e. when two DRM applications try to connect to the same DRM schema at the same time, we face 'DRM-63015' error.

This happens when you have two DRM application servers in your Hyperion environment i.e. two DRM Configuration consoles and the secondary DRM application server has been configured to connect to the same DRM schema as the primary DRM application server and you try to start the DRM application on both the servers at the same time.

Ideally, you need to ensure that only one DRM console has been configured to connect to any given DRM schema.

In my Hyperion environment, there is only one DRM Server and only one DRM application. So the above scenario is not applicable at least in my case.

Also when I checked, my DRM Schema was not Locked:

So let's proceed further and try to list out possible causes along with troubleshooting steps to tackle this error. You can try these options in the given sequence and any of these may work for you. 

1- In a particular EPM environment, you might have DRM installed on two servers for load balancing. But you need to make sure that only one DRM configuration console (DRM installation) has been configured to connect to your DRM schema. Sometimes what happens that by mistake we configure the secondary DRM application server too to connect to the same DRM application schema as the primary DRM application server (i.e. connection details to the same DRM schema have been set up on two separate DRM servers) and make an attempt to start the DRM application on both the servers. When you configure two different DRM configuration consoles of your EPM environment try to connect to the same DRM schema at the same time, we face 'DRM-63015' error. Therefore make sure its not the case in your DRM setup. 

2- Make sure your DRM service 'startup type' is set to Manual and not Automatic on all the DRM servers. This will prevent the auto-start of your DRM service during any unplanned server reboot. This is important especially when you have CUP (Common User Provisioning) enabled in your DRM application.

Also, change your DRM service 'log on as' account from Local system to EPM Admin domain account (which was used to install and configure DRM) on all the DRM servers.

3- Do 'iisreset' on Oracle Data Relationship Management (DRM) application server.

As DRM's primary web interface runs through IIS (Microsoft Internet Information Service), there's a chance bouncing IIS will free up whatever rogue session might have been locking things up for you.

To bounce IIS service, open a command prompt on your DRM application server and type "iisreset":

If this workaround works for you, it's well and good, If not, move to the next troubleshooting step 

4- 'Apply Updates' in Oracle Data Relationship Management (DRM) Configuration console.

To 'Apply Updates' follow the below steps: 

1- Open Windows service panel and stop DRM Web services. 

2- Check the DRM Configuration console to ensure DRM services are stopped.

3- Now goto DRM Configuration console and select Application-->Apply Updates

4- Click OK on the below message while Applying updates:

5- You will see below CMD window opened. As there were actually no updates to apply so we see the message: No updates were applied. 

Press SPACE key to continue. CMD window will be closed then. 

6- Goto the service panel and start DRM Web services on all the servers. 

7- Check DRM Web services status in DRM Configuration console. Both DRM Web services are up and running fine. Also notice, our DRM application too has been successfully started this time.

8- When I opened DRM web-client, my DRM application was available to login.

9- And application login too was working as expected.

So for me, the issue got fixed following the 3rd workaround. :-)

We know that Applying Updates to Oracle Data Relationship Management (DRM) application refreshes the database connection apart from making any changes like patch upgrade, config changes, etc. in your DRM application, effective. 

But exactly what has caused this issue is still not known. This workaround has fixed this issue for me in one go so it can be used as a temporary fix.

Please note, this DRM error "There are currently no applications available for login" can occur due to many reasons, and above mentioned workarounds reflect only a few of those scenarios. 

You need to check the Windows Event Viewer on your DRM server in order to identify the exact root cause of the problem as Event Viewer will most likely have an error message recorded related to your DRM issue. 

That's all for this post.

I hope this article has helped you. 

Your suggestions/feedback are most welcome.

Keep learning and Have a great day!!!

Read More

HFM Housekeeping in Oracle Hyperion (EPM) 11.1.2.4: PART-2

Hello Friends!

This is PART-2 of our 'Oracle Hyperion Financial Management (HFM) Housekeeping' blog series. If you haven't read PART-1, I would suggest you to first go through that post to have a clear understanding of this PART-2.

In PART-1, we had covered stopping Oracle Hyperion Financial Management (HFM) services and processes, killing HFM database sessions, housekeeping of HFM schema tables, etc.

Now we will see Oracle Hyperion Financial Management (HFM) logs archiving, deleting HFM temp and cache files, etc. activities as part of Oracle Hyperion Financial Management (HFM) Housekeeping.

NOTE: 

• This post has been written and associated activities have been demonstrated on Oracle Hyperion Financial Management (HFM) version 11.1.2.4.204.
• The demonstrating Hyperion environment has Oracle database server 12.2.0.2 (18c) as backend database. 

Oracle Hyperion Financial Management (HFM) logs archiving

To have good Hyperion Financial Management (HFM) application performance, it's recommended to archive HFM application logs on a regular basis as if it's not done on time it keeps growing and can consume your server's resources apart from downgrading your application performance.

1- Login to all your Hyperion Financial Management (HFM) application servers and perform below steps on each one of them.

2- Goto the path E:\apps\Oracle\Middleware\user_projects\epmsystem_hfm\diagnostics\logs\hfm

3- In the above folder, you will find the following log files:

• xfm.odl.<APPLICATION_NAME>.log
• oracle-epm-fm-hsx-server.log
• oracle-epm-fm-bi-publisher.log
• oracle-epm-fm-hsx-registry.log
• oracle-epm-fm-lcm-client.log
• SharedServices_Security.log

4- Archive all the LOG files under \hfm folder by zipping them to a separate backup folder. 

5- Now goto the path E:\apps\OracleEPM\Middleware\user_projects\domains\EPMSystem\servers\HFMWeb0\logs

6- Archive all the LOG files under \logs folder by zipping them to a separate backup folder. 

7- Goto the path E:\apps\OracleEPM\Middleware\user_projects\domains\EPMSystem\servers\HFMWeb0\logs\hfm

 

8- Archive all the LOG files under \hfm folder by zipping them to a separate backup folder. 

9- Now login to your HFM Webservers and perform below steps on each one of them.

10- Goto the path E:\apps\OracleEPM\Middleware\EPMSystem11R1\logs\hfm

11- Archive all the LOG files under \hfm folder by zipping them to a separate backup folder. 

This completes the Hyperion Financial Management (HFM) logs archiving part. 

Deleting Oracle Hyperion Financial Management (HFM) temp and cache files

Note: The purpose to include 'deleting tmp and cache folders on Hyperion Financial Management (HFM) app servers' is that it should be done once in a quarter or probably once in a 6 months period (not weekly/monthly) like truncation of HFM DATA_AUDIT, TASK_AUDIT, HFM_ERRORLOG tables or do it when you need to troubleshoot any particular technical issue where Oracle recommends to perform it. Deleting tmp and cache folders is mainly required during issues in Hyperion Financial Management (HFM) Web pages/interfaces or after Hyperion Financial Management (HFM) patching. On some occasions where frequent and intense data loads are running from FDMEE to HFM apps, it has been observed that truncating overgrown HFM audit and data tables along with clearing tmp and cache folders have worked as a temporary fix to resolve the issue like data is not getting loaded into Hyperion Financial Management (HFM) applications even though FDMEE DLR is getting successfully completed. 

Tmp folder on Hyperion Financial Management (HFM) application managed server is used to store temporary files related to your HFM applications. A cache is a set of temporary files used by HFM application server. 

Oracle recommends that users should periodically clear the tmp and cache directories to help your system run faster and reclaim disk space. Without damaging your applications, you can delete tmp and cache easily.

1- Login to all your Hyperion Financial Management (HFM) application servers and perform the below tasks.

2- Goto path E:\apps\OracleEPM\Middleware\user_projects\domains\EPMSystem\servers\HFMWeb0

3- Rename tmp and cache folders as shown below:

Note: Make sure you keep clearing these backup folders on every next Housekeeping activity. 

Rebooting Oracle Hyperion Financial Management (HFM) Application servers

Rebooting Hyperion Financial Management (HFM) application servers are important in order to clear locking, blocking, hanged, orphan processes/sessions running at the Operating system level. Sometimes these sessions can cause interruptions in HFM application normal functioning. 

Login to all your Hyperion Financial Management (HFM) application servers and reboot them. 

Note: It's also recommended to regularly monitor Hyperion Financial Management (HFM) application servers' space and especially memory utilization. 

Starting Oracle Hyperion Financial Management (HFM) application services

Once you complete all of the above tasks, you can go ahead and start HFM services on all Hyperion Financial Management (HFM) application servers.

Now login to Workspace and open your Hyperion Financial Management (HFM) applications and thoroughly validate them ensuring everything is working fine.

This completes your Hyperion Financial Management (HFM) Housekeeping process.

That's all for this post.

I hope this article has helped you. 

Your suggestions/feedback are most welcome.

Keep learning and Have a great day!!!

Read More

HFM Housekeeping in Oracle Hyperion (EPM) 11.1.2.4: PART-1

Hello Friends!

There are many applications where a lot of data transactions, movement, retrieval, refresh, update, etc. activities happen as a result of day-to-day business activities and thus it creates many log files, temporary files, audit files, database records, etc. If not house kept on time, these files can cause severe performance issues in that application. 

Oracle Hyperion Financial Management (HFM) is one of those apps where we need to regularly perform housekeeping in order to improve application performance, especially in the Production environment. 

In this blog series, we will explore in detail what are the various things, which need to be regularly house kept in Oracle Hyperion Financial Management (HFM) and how to do that.

NOTE: 

• This post has been written and associated activities have been demonstrated on Oracle Hyperion Financial Management (HFM) version 11.1.2.4.204.
• The demonstrating Hyperion environment has Oracle database server 12.2.0.2 (18c) as backend database. 

The complete Hyperion Financial Management (HFM) Housekeeping activity will be covered in two parts.

In this first part, we will cover prerequisites, stopping Hyperion Financial Management (HFM) services and processes, killing Hyperion Financial Management (HFM) database sessions, Hyperion Financial Management (HFM) schema tables housekeeping, etc. You can find the second part of Hyperion Financial Management (HFM) Housekeeping blog series on below link:

HFM Housekeeping in Oracle Hyperion 11.1.2.4: PART-2

Prerequisites:

• As Hyperion Financial Management (HFM) Housekeeping activity requires complete HFM outage and involves some critical tasks in the database, it’s recommended to plan this activity over the weekend if you are doing in Production. Business users should be informed accordingly. 
• As housekeeping of Hyperion Financial Management (HFM) audit tables is also involved, you need to have login credentials of HFM relational database schema. Needless to say, your HFM schema will be having all the required privileges as recommended in the Oracle EPM guide. 
• It’s recommended to have a database user with DBA level privileges in order to check active, Inactive, Killed sessions on your Hyperion Financial Management (HFM) schema. If you can’t own such a user, you can ask your application DBA to do perform such activity which will be described later in this post. 
• Different paths and folders' names mentioned in this blog may slightly vary for different Oracle Hyperion setups but at large it should be the same.  
• Please make sure you take Hyperion Financial Management (HFM) database schema backup before attempting HFM housekeeping steps mentioned below.
• Never forget to take complete backup of EVERYTHING before deleting or changing anything. 

Step-by-step process to do Oracle Hyperion Financial Management (HFM) Housekeeping:

PART-A: Stopping HFM services and killing HFM processes

1- Stop following two HFM services in all your HFM application servers:

1. Oracle Hyperion Financial Management – Java Server
2. Oracle Hyperion Financial Management - Web Tier 

Note: Open task manager and make sure the following two processes are no more running:

1. HyS9FinancialManagementJavaServer.exe
2. HyS9FinancialManagementWeb.exe

2- Open Windows Task Manager and kill all XFMDataSource.exe processes running in all your Oracle HFM application servers. For each HFM application, there will be one XFMDataSource.exe process.

Note: When an HFM application is started the Java Server starts an application process with the name XFMDataSource.exe. 

PART-B: Killing any running “Active, Inactive, Killed” database sessions under HFM schema

1- Using SQL developer, login to your environment’s database with a user having DBA level privileges (user should have access on GV$SESSION view) and run the following query to list out any Active, Inactive or Killed sessions running under HFM schema:

select sid, serial#, inst_id, status from gv$session where username = 'HFM' and status in ('INACTIVE','KILLED','ACTIVE');

2- Now using below query, kill all those Active, Inactive or Killed sessions listed above. You can take the help of your DBA if the user you own, does not have sufficient privileges to do this deletion task.

ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE;

Where sid and serial# are session ID and serial number of your Active, Inactive or Killed sessions listed above.

For example:

If your Oracle Hyperion environment has a RAC database setup, you can specify the INST_ID in your kill command. This way you will be able to kill the session on the respective RAC node.

ALTER SYSTEM KILL SESSION 'sid,serial#,@inst_id' IMMEDIATE;

For example:

Note: The KILL SESSION command doesn't actually kill the session. It only asks the session to kill itself. In some cases, like waiting for a reply from a remote database or rolling back transactions, the session will not kill itself immediately and will wait for the current operation to complete first. In such cases, the session will have a status of "marked for kill". It will then be killed as soon as possible.

Actually, adding the IMMEDIATE clause does not affect the work performed by the command, but it returns control back to the current session immediately, rather than waiting for confirmation of the kill.

If the marked session persists for some time, you should kill the process at the operating system level. Ask your DBA to kill that session at the OS level.

3- Once listed sessions are killed, re-run below query to ensure all sessions are gone:

select sid, serial#, inst_id, status from gv$session where username = 'HFM' and status in ('INACTIVE','KILLED','ACTIVE');

PART-C: HFM schema tables housekeeping

Here we will first archive following three Hyperion Financial Management (HFM) tables and then truncate table entries keeping only past few months data in live tables:

1. <appname>_DATA_AUDIT
2. <appname>_TASK_AUDIT 
3. HFM_ERRORLOG

The general recommendation to maintain good application performance is to archive and delete the content of these tables in the HFM repository database before it reaches 500,000 records.

If the Data Audit feature is not part of your business requirements then it is recommended to turn off auditing of data for Hyperion Financial Management (HFM) applications. There is degradation in performance observed for HFM applications with the Data Audit table having more than 10GB entries.

There is no built-in mechanism in Hyperion Financial Management (HFM) to monitor the size of these tables, so the Hyperion administrator should be tasked with it to do the regular maintenance of these tables.

For the above tables, it is recommended to implement the following housekeeping best practices:

• Quarterly - Business to review the Audit logs, archive and delete.
• Half-Yearly - Archive System Messages and truncate table.

1- Archiving Oracle Hyperion Financial Management (HFM) apps Audit tables

To perform this activity, log in to HFM schema using SQL Developer. Suppose you have the following two HFM applications in your Hyperion environment:

1. HFMAPP1
2. HFMAPP2

So to archive/backup the audit tables of these two HFM apps, run following queries:

Archive HFMAPP1_task_audit table with today's date (ddmmyyyy):

Create table HFMAPP1_task_audit_21032020 as select * from HFMAPP1_task_audit;

Archive HFMAPP1_data_audit table with today's date (ddmmyyyy):

Create table HFMAPP1_data_audit_21032020 as select * from HFMAPP1_data_audit;    

Archive HFMAPP2_task_audit table with today's date (ddmmyyyy):

  Create table HFMAPP2_task_audit_21032020 as select * from HFMAPP2_task_audit;  

Archive HFMAPP2_data_audit table with today's date (ddmmyyyy):

Create table HFMAPP2_data_audit_21032020 as select * from HFMAPP2_data_audit;  

2- Deleting Oracle Hyperion Financial Management (HFM) Audit tables entries keeping last 90 days entries (you can decide the no. of days data to be retained for by checking with your business/team):

Delete HFMAPP1_task_audit table's all entries leaving past 90 days entries in live table: 

Run below query to see how many records are going to be deleted:
select count(*)from HFMAPP1_task_audit where starttime < (select max(starttime)-90 from HFMAPP1_task_audit);     

Run below query to delete the records:                

delete from HFMAPP1_task_audit where starttime < (select max(starttime)-90 from HFMAPP1_task_audit);

Run below query again to see whether all the records have been deleted or not:

select count(*)from HFMAPP1_task_audit where starttime < (select max(starttime)-90 from HFMAPP1_task_audit);

Run below command to end your current transaction and make permanent all changes performed in the transaction:

commit;

Delete HFMAPP1_data_audit table's all entries leaving past 90 days entries in live table: 

Run below query to see how many records are going to be deleted:
select count(*)from HFMAPP1_data_audit where dtimestamp < (select max(dtimestamp)-90 from HFMAPP1_data_audit);

Run below query to delete the records:

delete from HFMAPP1_data_audit where dtimestamp < (select max(dtimestamp)-90 from HFMAPP1_data_audit);

Run below query again to see whether all the records have been deleted or not:

select count(*)from HFMAPP1_data_audit where dtimestamp < (select max(dtimestamp)-90 from HFMAPP1_data_audit);

Run below command to end your current transaction and make permanent all changes performed in the transaction:

commit;

Delete HFMAPP2_task_audit table's all entries leaving past 90 days entries in live table: 

Run below query to see how many records are going to be deleted:
select count(*)from HFMAPP2_task_audit where starttime < (select max(starttime)-90 from HFMAPP2_task_audit);  

                   

Run below query to delete the records:
delete from HFMAPP2_task_audit where starttime < (select max(starttime)-90 from HFMAPP2_task_audit);

Run below query again to see whether all the records have been deleted or not:

select count(*)from HFMAPP2_task_audit where starttime < (select max(starttime)-90 from HFMAPP2_task_audit);

Run below command to end your current transaction and make permanent all changes performed in the transaction:
commit;

Delete HFMAPP2_data_audit table's all entries leaving past 90 days entries in live table: 

Run below query to see how many records are going to be deleted:
select count(*)from HFMAPP2_data_audit where dtimestamp < (select max(dtimestamp)-90 from HFMAPP2_data_audit);

Run below query to delete the records:

delete from HFMAPP2_data_audit where dtimestamp < (select max(dtimestamp)-90 from HFMAPP2_data_audit);

Run below query again to see whether all the records have been deleted or not:

select count(*)from HFMAPP2_data_audit where dtimestamp < (select max(dtimestamp)-90 from HFMAPP2_data_audit);

Run below command to end your current transaction and make permanent all changes performed in the transaction:

commit;

3- Deleting HFM ERRORLOG table entries keeping last 30 days entries/data (you can decide the no. of days data to be maintained for checking with your business/team):

Run below query to see how many records are going to be deleted:

select count(*)from HFM_ERRORLOG where dtimestamp < (select max(dtimestamp)-30 from HFM_ERRORLOG);  

                                 

Run below query to delete the records:
delete from HFM_ERRORLOG where dtimestamp < (select max(dtimestamp)-30 from HFM_ERRORLOG);

Run below query again to see whether all the records have been deleted or not:

select count(*)from HFM_ERRORLOG where dtimestamp < (select max(dtimestamp)-30 from HFM_ERRORLOG);  

Run below command to end your current transaction and make permanent all changes performed in the transaction:

commit;

4- Purging database Recyclebin:

purge recyclebin;

The 'Purge recyclebin' command removes the items and their objects from the database recyclebin and restores the used storage space. The purge command is used to remove the items which have no use in the future. The main purpose here is to reclaim space used by deleted objects laying in recyclebin.

Note: Keep an eye on the space utilization on the database server and Hyperion Financial Management (HFM) Schema.

That's all for this PART-1.

In the last PART-2 of this blog series, we will see Hyperion Financial Management (HFM) logs archiving, deleting HFM temp and cache files, etc.

I hope this article has helped you.
Your suggestions/feedback are most welcome.
Keep learning and Have a great day!!!

Read More

Oracle WebLogic Server patching in Oracle Hyperion 11.1.2.4

Hi Friends!

As part of Oracle recommendations and organization's IT security requirements, we need to keep patch levels of various Oracle Hyperion components like Hyperion Essbase, Hyperion Planning, Hyperion Financial Management (HFM), Hyperion Financial Data Quality Management (FDMEE) etc. and also Oracle WebLogic server up to date.

In this post, we will see a detailed description of how to patch (Patch Set Update 10.3.6.0.190716) Oracle WebLogic Server in EPM (Hyperion) 11.1.2.4 for both Windows and Linux platforms.

We know that Oracle WebLogic Server 10.3.6.0 is the default version which comes with Oracle Hyperion 11.1.2.4 package. In this article, we will see patching Oracle WebLogic Server 10.3.6.0 of Oracle Hyperion 11.1.2.4 environment with Patch Set Update 10.3.6.0.190716 (Patch 29633432).

Before proceeding further, below are some important points to note: 

1. We need to patch all Oracle WebLogic servers (Admin server and domain servers) of a particular Oracle Hyperion environment. 
2. If previous Oracle WebLogic PSUs were applied before, the PSUs need to be rolled back first. (In our case it is not required as we are patching the Oracle WebLogic Server base version 10.3.6.0).
3. You need to perform this patching activity in each and every server of your Oracle Hyperion environment.
4. This article is applicable for both Windows and Linux servers i.e. same steps will apply on both.

 Prerequisites:

1- Download Oracle WebLogic Server Patch Set Update 10.3.6.0.190716 from Oracle Support portal link given below (This patch is for Generic platform so the same patch is applicable for both Windows and Linux operating systems): 

https://support.oracle.com/rs?type=patch&id=29633432 

(Note: You need to have Oracle support login credentials in order to access the above page.)

You will see following patch download page after login on the above link:

2-The downloaded file name is p29633432_1036_Generic.zip. It is advisable to have this zip file placed in a common network path accessible from all the servers of your Oracle Hyperion environment for the easy movement of extracted files.

3-You, need to login on each Oracle Hyperion server with the same "USER/ACCOUNT" which was used to install & configure Oracle Hyperion 11.1.2.4 components on that server. 

4-Stop Oracle WebLogic servers (Admin server + domain servers) running on all servers of your Oracle Hyperion environment. Make sure there are no processes or services running which could be holding a lock on any jar file. If Node Manager is running, you should also stop that.

5-Stop all Oracle Hyperion services and any java processes used by Oracle Hyperion applications, running on all the servers of your Hyperion Environment.

6-In Task manager check any Oracle WebLogic or Oracle Hyperion service-related processes should not be running.

Installing Oracle WebLogic Server Patch Set Update 10.3.6.0.190716 (Patch 29633432)

1- On the server create directory cache_dir  under E:\apps\OracleEPM\Middleware\utils\bsu\ if it does not exist (E:\apps\OracleEPM\Middleware\utils\bsu\cache_dir).

2- Unzip p29633432_1036_Generic.zip to a common network path and then copy the extracted files to E:\apps\OracleEPM\Middleware\utils\bsu\cache_dir directory of your Oracle Hyperion servers (On both Windows server as well as Linux server. Path will be almost same).

After unzip, your cache_dir directory will have the following 3 files:

1. MXLE.jar
2. patch-catalog_26707.xml
3. README.txt

You must make sure that the target directory for unzip has required write and executable permissions for the "USER/ACCOUNT" which was used to install & configure Oracle Hyperion on that server.

3- Open E:\apps\OracleEPM\Middleware\utils\bsu folder and Do the following to prevent 'Java OutofMemory Error' during the installation of the patch:

• Take a backup of bsu.cmd/bsu.sh.
• Edit bsu.cmd/bsu.sh file and change MEM_ARGS settings to 4GB (4096m):

          set MEM_ARGS=-Xms4096m -Xmx4096m

• Now save the file bsu.cmd/bsu.sh.  

4- Open CMD and Goto E:\apps\OracleEPM\Middleware\utils\bsu and Execute the following command to install the path:

Command format:

bsu.cmd -install -patch_download_dir={MW_HOME}/utils/bsu/cache_dir -patchlist={PATCH_ID} -prod_dir={MW_HOME}/{WL_HOME}

Where WL_HOME is the path of the WebLogic home.

On Windows Server command will be:

bsu.cmd -install -patch_download_dir=E:\apps\OracleEPM\Middleware\utils\bsu\cache_dir -patchlist=MXLE -prod_dir=E:\apps\OracleEPM\Middleware\wlserver_10.3

On Linux Server command will be:

./bsu.sh -install -patch_download_dir=/apps/oracle/epm/Middleware/utils/bsu/cache_dir -patchlist=MXLE -prod_dir=/apps/oracle/epm/Middleware/wlserver_10.3

Once the command gets completed and the patch is successfully applied, you will see below SUCCESS message:

On Windows Server:

On Linux Server:

We see the patch has been successfully installed. Now its time to verify the same.

5- Post-Installation verification:

To check whether the Oracle WebLogic Server version has been updated or not do the following:

1-Goto this path:

E:\apps\OracleEPM\Middleware\wlserver_10.3\server\bin\ 

2- Run below command to set the Oracle WebLogic Environment variables:

setWLSEnv.cmd   (On Linux server: ./setWLSEnv.cmd)

3- Now run following command to check the version:

java weblogic.version (On Linux server too same command: java weblogic.version)

In the below output, 10.3.6.0.190716 is the currently installed Oracle WebLogic Server PSU. It confirms now our Oracle WebLogic Server has been upgraded from 10.3.6.0 to version 10.3.6.0.190716 :

Oracle WebLogic Server 10.3.6.0.190716 PSU Patch for BUG29633432

Do verify on each and every server of your Oracle Hyperion environment whether the Oracle WebLogic Server has been successfully upgraded or not.

6- Start Oracle WebLogic servers of your Oracle Hyperion environment.

7- Start all Oracle Hyperion services in your environment.

This completes the patching process.

That's all for this post.

I hope this article has helped you.
Your suggestions/feedback are most welcome.
Keep learning and Have a great day!!!

Read More