Showing posts with label EPM 11.2. Show all posts
Showing posts with label EPM 11.2. Show all posts

Saturday, July 31, 2021

// // Leave a Comment

Oracle Middleware Home, EPM Oracle Home and EPM Oracle Instance

In this post, we will see three important directories related to Oracle EPM installation and configuration:
  1. Oracle Middleware Home
  2. EPM Oracle Home
  3. EPM Oracle Instance
Oracle Middleware Home

In an Oracle EPM system, Oracle Middleware home consists of Oracle WebLogic Server home and EPM Oracle home. You can setup your Oracle Middleware home either on a local file system on the server or on a remote network shared location. 

When you do EPM installation and configuration first-time, you need to define Oracle Middleware Home, which will be then used for all further EPM product installations on that system. 

Oracle Middleware Home installation directory is referred as MIDDLEWARE_HOME with default location as Oracle/Middleware on your EPM system.  For example it could be:

MIDDLEWARE_HOME : E:\apps\OracleEPM\Middleware
Below is an example of MIDDLEWARE_HOME directory structure:

Oracle Middleware Home, EPM Oracle Home and EPM Oracle Instance


EPM Oracle Home

EPM Oracle Home resides within Oracle Middleware Home and contains following things:
  • Files/folders related to EPM applications/products installed on that EPM system
  • Files/folders related to common internal components used by these EPM applications/products .
You cannot change the EPM Oracle Home location, so before starting the installation and configuration of EPM applications on a system make sure you have allocated sufficient disk space to your EPM Oracle Home drive to accommodate all the EPM applications/products that you are going to install on that system. 

The default EPM Oracle home location is MIDDLEWARE_HOME/EPMSystem11R1. EPM Oracle home location is defined in the system environment variable called EPM_ORACLE_HOME. For example it could be:

EPM_ORACLE_HOME : E:\apps\OracleEPM\Middleware\EPMSystem11R1

In a distributed EPM environment setup, the EPM Oracle home directory structure must be the same on each machine of that EPM environment. For example, if the path for EPM Oracle home is E:\apps\OracleEPM\Middleware\EPMSystem11R1 on the first machine you configure, it must be E:\apps\OracleEPM\Middleware\EPMSystem11R1 on all the other machines in the deployment.

Below is an example of EPM_ORACLE_HOME directory structure:

Oracle Middleware Home, EPM Oracle Home and EPM Oracle Instance


EPM Oracle Instance

EPM Oracle Instance contains one or more EPM components like Oracle HTTP Server (OHS), Oracle Essbase Server, one or more Java web applications in one or more domains. 

Unlike EPM Oracle Home, EPM Oracle instance can reside anywhere; it need not to be within the Oracle Middleware home directory.

The default location for the EPM Oracle instance referred to as EPM_ORACLE_INSTANCE is MIDDLEWARE_HOME/user_projects/epmsystem1. For example it could be:

EPM_ORACLE_INSTANCE : E:\apps\OracleEPM\Middleware\user_projects\epmsystem_web

Java web applications are deployed to MIDDLEWARE_HOME/user_projects/domains/domainName for example it could be: E:\apps\OracleEPM\Middleware\user_projects\domains\EPMSystem.

For a distributed EPM environment, you need to create a new EPM Oracle instance on each machine of the environment. But if you are installing all EPM products on a single machine, then all EPM products are configured under a single EPM Oracle instance what you create for the first product configuration.

Below is an example of EPM_ORACLE_INSTANCE directory structure:

Oracle Middleware Home, EPM Oracle Home and EPM Oracle Instance

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

Monday, June 14, 2021

// // Leave a Comment

How to change temporary (temp) directory in Oracle Essbase Server

Recently we got a critical alert where /tmp directory on our Essbase Linux server (Version: 11.1.2.4.033) was utilizing more than 90% of total allocated space. When we checked, there were many temporary Outline(.otl) files created under the /tmp directory. Most of them were of few KBs size but couple of files were really huge-sized of around 2gb each causing this space crunch alert under /tmp directory. Below is some of those huge sized .otl files listed:
-rw-r----- 1 epmadmin sapsys 2049736704 May 22 12:39 0oKEzW.otl
-rw-r----- 1 epmadmin sapsys 1370583040 May 22 07:43 MsnP8R.otl
-rw-r----- 1 epmadmin sapsys 2049994752 May 22 12:53 spQfrr.otl
-rw-r----- 1 epmadmin sapsys 1360232448 May 22 07:43 wpWopg.otl
Temp directory mostly contains files that are required temporarily. Many Essbase activities use this to create lock files and for temporary storage of data. When an Essbase outline is opened, it creates such temp files. Other activities like HPCM application deployment to Essbase and FDMEE data load to Essbase, Metadata load to Essbase etc. also can create these temporary files. 

Usually, Essbase doesn't produce such huge sized temporary files. Mostly you will see the size in KBs only for such temp files. These temporary files are normally deleted automatically when the related operation is over. But on some occasions you will observe they are not automatically deleted.

We noticed that when these huge sized temporary files (around 2gb per file) are created under /tmp directory on Essbase Linux server, it not only causes /tmp directory go out of space with 100% utilization but also the following issues encountered at the same time:
  1. Essbase server gets hanged.
  2. FDMEE data load to Essbase gets failed.
  3. Unable to load Essbase applications in FDMEE 'Target Application' interface.
Apart from the above listed ones, there might be even more problems. All in all, these issues point towards 'Essbase server disconnection' at that particular point of time. 

So in order to fix it, as a temporary workaround, we moved all those huge-sized temporary .otl files from /tmp directory to some other location and it fixed all the issues. You can also delete these temp files, if not required.

In a Windows server, the temporary directory is set by the environment variable TEMP. In UNIX/LINUX server, the temporary directory is /tmp filesystem. As /tmp is a Linux/Unix OS Filesystem, it is not recommended to use OS file system for application usage because it may lead to even server crash if all /tmp space is consumed at any point of time. So the safe way out is to have a separate temp folder assigned for Essbase application usage other than OS /tmp directory.

Workarounds

As mentioned above, instant workaround is to move/delete these temporary files to clear up some space under /tmp directory.

But as a permanent fix, we decided to have a separate temp directory assigned to Essbase application, that we will discuss ahead.

Changing the Default Location for Essbase Temporary Files on Linux Platforms:

On Linux platforms, Essbase uses OS /tmp directory as the default location for creating temporary files.

To create temporary files in a different location, you must set the temp directory environment variable in opmn.xml and in setEnv.sh configuration files.

To set TEMP/TMP environment variable in opmn.xml

1- Find opmn.xml file on your Essbase server located at below path: /apps/oracle/epm/Middleware/user_projects/epmsystem_ess/config/OPMN/opmn/opmn.xml

2- In opmn.xml file, look for the following default entries:
<environment>
<variable id="TEMP" value="/tmp"/>
<variable id="TMP" value="/tmp"/>
</environment>
3- Change the default values of TEMP and TMP variables to your desired location as shown below and save the opmn.xml file :
<environment>
<variable id="TEMP" value="/apps/oracle/epm/Middleware/user_projects/epmsystem_ess/tmp"/>
<variable id="TMP" value="/apps/oracle/epm/Middleware/user_projects/epmsystem_ess/tmp"/>
</environment>

To set TMPDIR in setEnv.sh

1- Find setEnv.sh file on your Essbase server located at below path: /apps/oracle/epm/Middleware/user_projects/epmsystem_ess/bin/setEnv.sh

2- By default there will be no entry set for TEMPDIR in setEnv.sh (means your OS /tmp directory will be used to store temporary files). 
To change the default location, add the following entry at the end of setEnv.sh file and save it:
TEMPDIR="/apps/oracle/epm/Middleware/user_projects/epmsystem_ess/tmp"
export TEMPDIR
Note: You have to restart Essbase services to make these changes effective.

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

Thursday, May 20, 2021

// // 2 comments

Password Policies and Account Lockout Measure on EPM native 'ADMIN' and External Directory Users

As part of EPM Application audit and security control, most of us would have got this requirement to apply User account lockout measures on all EPM users whenever there is some specified number of consecutive failed login attempts.

Being no exception we too faced this question. Our security team had released following 'Account lockout' requirements to be implemented in EPM:
  • Account lockout after 6 or less consecutive failed login attempts.
  • Re-enable locked account after 30 minutes of lockout.
So we explored the available options in EPM that I have shared below.

We know there are mainly two types of users in EPM system:
  1. Hyperion Shared Services Native users (Admin etc.)
  2. External directory users (Microsoft Active Directory-MSAD, LDAP-enabled user directory, Oracle Internet Directory-OID etc.)
Lets see both one by one.

Hyperion Shared Services Native Directory users (Admin etc.)

There is no inbuilt account lockout and password policies setting for EPM Native Directory users including EPM Shared Services ‘Admin’ account. Therefore EPM Shared services 'Admin' account never gets locked after any number of unsuccessful login attempts (due to the obvious reason that if ADMIN gets locked in EPM then none can unlock it). 

On entering wrong password for EPM native ‘Admin’ account, it keeps throwing following error without being locked:
EPMCSS-00301: Failed to authenticate user. Invalid credentials. Enter valid credentials.

Password Policies and Account Lockout Measure on EPM native 'ADMIN' and External Directory Users

You can mitigate this risk for native 'Admin' user failed login attempts by creating a script or using any log analyzing tool to monitor Framework.log present on all Foundation servers (E:\apps\OracleEPM\Middleware\user_projects\domains\EPMSystem\servers\FoundationServicesN\logs\Framework.log) which records the messages for both successful and failed login attempts made by EPM native 'Admin' user.

External directory users (Microsoft Active Directory-MSAD or an LDAP-enabled user directory such as Oracle Internet Directory-OID)

There is no settings within EPM application (till EPM 11.2 release) which can be used to control password policies and account lockout measures for external directory users. 

For external directory users (MSAD, LDAP, OID etc.), password policies and Account lockout measure on failed login attempts can be enforced and controlled at external directory side setup only. So you can check with your external AD team and define password policies for external AD users to specify how many logon attempts to allow before locking out end users and how they will be unlocked. 

EPM System honors all locks controlled by the password policies for the external user directory. Whatever Account lockout policy is set there by your Active Directory (AD) team, EPM system will simply follow that.


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

Friday, April 9, 2021

// // Leave a Comment

EPM 11.2: How to check FDMEE application patch version

Its important to know the current patch version of your EPM (Enterprise Performance Management) products/applications, especially when you are planning to apply any new Oracle patches or want to check the compatibility of existing EPM applications with any other products/software/tools.

For FDMEE (Financial Data Quality Management, Enterprise Edition), you can check its current patch version using following methods:

1. AIF_version.xml (more reliable method):

This is the most reliable method because when you apply any new patch to FDMEE, this is the file which will be updated with the new patch level so it always shows the current version of your FDMEE application.

On FDMEE server, you can find AIF_version.xml file in the following folder:

E:\apps\OracleEPM\Middleware\EPMSystem11R1\products\FinancialDataQuality\xml\AIF_version.xml

When you open this AIF_version.xml file, FDMEE version will be displayed as shown below:

EPM 11.2: How to check FDMEE application/patch version

2. Workspace (Not always the true reflection of the current patch level of EPM products)

To see your EPM products versions in Workspace, navigate to: 

Workspace-->Help-->About Oracle Enterprise Performance Management System Workspace, Fusion Edition

You would have seen on many occasions that the EPM products version number shown in Hyperion Workspace do not match the patch versions that have been recently applied in an EPM environment.

It happens because EPM java web applications versions shown in Workspace are sourced from Shared Services registry (logical web application entry--displayVersion property).

EPM 11.2: How to check FDMEE application/patch version

Further the versions displayed in Shared Services registry are sourced from some property/configuration files of the respective EPM products which get updated immediately after applying any new patches. For example, in case of FDMEE, its is AIF_version.xml file as mentioned in method-1.

Sometimes, applications version shown in Workspace or the displayed version shown in Shared Services registry does not get refreshed from the respective source file of that application. And that's when you see a mismatch in version shown in Workspace and the actual application version. And that's why method-1 is more reliable one to know the FDMEE current patch version.

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

Wednesday, October 14, 2020

// // Leave a Comment

EPM 11.1.2.4: Microsoft Edge and Google Chrome browsers support patching : Part-1

Note: This is Part-1 of 'Google Chrome and Microsoft Edge Browser Support' patching blogs . You can read Part-2 here.

In April 2020, one of our clients (on EPM 11.1.2.4) informed us that effective immediately, their IT team would begin supporting Microsoft’s new Edge* web browser making it the default browser on user machines. Users were recommended to use Edge for day-to-day browser activities. However, they did mention that there are several apps that are not yet compatible. So if you use one of those apps that have known compatibility issues, then you can continue using Internet Explorer (IE11) in these cases.

*Microsoft Edge is based on the Chromium open-source engine, just like Chrome. Compared to IE, with Edge, you can look forward to significantly faster browsing performance and compatibility, better overall security, and a slew of helpful new features.

We checked the EPM 11.1.2.4 certification matrix and informed the client that currently (as of May 2020), Google Chrome and Microsoft Edge Browsers are not supported by all the EPM applications so we should use IE11 only to smoothly access all the Hyperion apps.

But this whole picture got changed when in June 2020, Oracle notified that Google Chrome and Microsoft Edge Browser Support has been added to Enterprise Performance Management (EPM) 11.1.2.4 (click here to read).

Oracle updated the EPM 11.1.2.4 certification matrix to reflect the new changes, as shown below:

EPM 11.2.2 and 11.1.2.4: Google Chrome and Microsoft Edge Browser Support

In order to make your EPM 11.1.2.4 environment compatible with Google Chrome and Microsoft Edge Browsers, you must update to the following supported releases:
  • Hyperion Shared Services 11.1.2.4.100+ (Patch 31319089. Use Patch 31574562 for release 11.1.2.4.9xx) 
  • Hyperion Planning, Hyperion Capital Asset Planning, Hyperion Workforce Planning, Hyperion Project Financial Planning 11.1.2.4.009+ (Patch 29889455) 
  • Hyperion Calculation Manager 11.1.2.4.014+ (Patch 28557058) 
  • Hyperion Financial Reporting 11.1.2.4.712+ (Patch 30670918. Use Patch 30671119 for release 11.1.2.4.9xx) 
  • Hyperion Financial Management 11.1.2.4.208+ (Patch 28511735) 
  • Hyperion Financial Close Management and Hyperion Tax Governance 11.1.2.4.253+ (Patch 29060830) 
  • Hyperion Tax Provision 11.1.2.4.202+ (Patch 25316913) 
  • Hyperion Financial Data Management 11.1.2.4.220+ (Patch 25312033) 
  • Hyperion Profitability and Cost Management 11.1.2.4.130+ (Patch 29461894) 
  • Hyperion Workspace 11.1.2.4.825+ (Patch 31124100. Use Patch 31486872 for release 11.1.2.4.9xx) 
  • Hyperion Data Relationship Management 11.1.2.4.350+ (Patch 31420887)
  • Additionally, you must also update Oracle JDeveloper / Application Development Framework 11.1.1.7.1 (Patch 31246831).

EXCEPTIONS

  • Oracle JDeveloper / Application Development Framework does not apply to Hyperion Data Relationship Management or Hyperion Workspace.

For more information, read the following knowledge article: Browser Support Added for Google Chrome and Microsoft Edge with EPM System Releases Beginning with Release 11.1.2.4 - Doc ID 2675883.1

So we planned to apply these compatibility patches in our EPM 11.1.2.4 environment starting with DEV to make it work with Google Chrome and Microsoft Edge browsers.

As an obvious next step, we started looking for known issues/errors faced by any users after applying these compatibility patches.

Then we came to know about one technical issue reported as Hyperion Shared Services not working in Google Chrome and Microsoft Edge (Doc ID 2698535.1).

Notably, as per the Doc ID 2698535.1, this issue is reported not only in EPM 11.1.2.4 but also in the very latest EPM 11.2.1 and EPM 11.2.2 releases (Let me know in the comment section if you have a functional EPM 11.2.1 or 11.2.2 environment and face this issue on Microsoft Edge or Google Chrome browser.) 

As per Doc ID 2698535.1, after applying these compatibility patches mentioned in Doc ID 2675883.1, from Shared Services Console, attempting the following tasks results in an "empty" grey screen or grey pop-up:

  • create new Native User
  • provision existing user
  • LCM import/export
  • Migration Status Report

In short, you will be having issues while using Hyperion Shared Services Console on Google Chrome or Microsoft Edge browsers post applying these patches.

Oracle has already raised two bugs for this problem as mentioned in Doc ID 2698535.1:

  1. Unpublished bug created for 11.1.2.4 Bug 31686588
  2. Unpublished bug created for 11.2.1 Bug 31546643
As a workaround for this issue in Hyperion Shared Services console, the following is suggested in Doc ID 2698535.1:

  • For 11.1.2.4, workaround is to use Internet Explorer 11.x or Firefox 31+ ESR
  • For 11.2.1, workaround is to use Internet Explorer 11.x or Firefox ESR
  • For 11.2.2, workaround is to use Firefox ESR 

We decided to first clear the air about this compatibility patches and reported bugs before we patch our systems.

To that effect, we recently had a call with Oracle, and below is what we can summarize based on our discussion:

As far as these two bugs are concerned, there is still no solution provided for EPM 11.1.2.4, EPM 11.2.1, or EPM 11.2.2. Most probably, these bugs will be fixed in the EPM 11.2.3 release (as of Oct 2020). 

For EPM 11.1.2.4, you should go-ahead and patch your EPM 11.1.2.4 environment with these compatibility patches. As post patching there will be no impact on EPM 11.2.4 functioning with IE11 browser i.e. all the features/functionalities will continue to work fine on IE11 browser regardless of whether you have applied the new compatibility patches or not to make your EPM 11.2.4 environment compatible with Google Chrome and Microsoft Edge.

Post compatibility patching, the reported issue of "empty" grey screen in Doc ID 2698535.1 is limited to Hyperion Shared Services Console only for the tasks like create new Native User, provision existing user, LCM import/export, Migration Status Report. Other functionalities/features/consoles in EPM 11.1.2.4 work fine on Google Chrome and Microsoft Edge browsers. 

For the end-users, there are hardly any issues because Hyperion Shared services Console is mostly used by Hyperion Admins for user management and LCM related tasks.


The above summary gives a sense of security that at least there is nothing to lose after applying these compatibility patches mentioned in Doc ID 2675883.1 in your EPM 11.1.2.4 environment. After applying these patches in your EPM 11.1.2.4 environment, you can use:

  • Google Chrome or Microsoft Edge browser for all the activities except on Hyperion Shared Services console
  • IE11 for Hyperion Shared Services console activities only (mostly by Hyperion Admins)

As for the client, upgrading the current EPM version 11.1.2.4 to EPM 11.2 is still a good 6 months away (as of Oct 2020) and their IT team has already made Microsoft Edge the default browser, we are going to apply these compatibility patches in our 11.1.2.4 DEV environment for Microsoft Edge and Google Chrome compatibility. 

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

Saturday, September 19, 2020

// // Leave a Comment

EPM 11.2 servers and HyperThreading

A few days ago, we had a discussion with our server build team for acquiring new hardware for EPM 11.2 installation & configuration. To put it in context, one of our clients has EPM 11.1.2.4 on-premise setup consisting of multiple Hyperion instances running across IBM AIX 7.1 (Oracle Database), RedHat Linux 6.10 x86_64 (Essbase app), and Windows Server 2012 R2 64-bit (all other apps like HFM, FDMEE, DRM, HPCM, etc.) in a distributed environment.

Recently, the client wished to move the complete setup to the latest EPM 11.2.x release having Windows Servers 2019 and Linux 7 (why EPM 11.2 and not EPM Cloud for this setup? Well its a matter we will discuss some other time.)

In the current 11.1.2.4 setup, we have both kinds of servers -Physical Servers + VM Servers. To be precise, only HFM and Essbase apps are hosted on Physical machines in both PROD and TEST environments rest all are on VM servers.

All Physical servers (HFM + Essbase App servers) have HyperThreading** ENABLED while there is no HyperThreading on VM machines. 

**HyperThreading: HyperThreading is Intel’s term for simultaneous multithreading (SMT). This is a process where a CPU splits each of its physical cores into virtual cores, which are known as threads. For example, most of Intel's CPUs with two cores use hyper-threading to provide four threads, and Intel CPUs with four cores use hyper-threading to provide eight threads. Therefore, when HyperThreading is enabled, every CPU core has two CPU threads instead of one. A server with 8 cores would appear to have 16 CPU threads. If one thread is idle or stalls on a cache miss, the other thread can continue to execute. This is a potential throughput advantage, especially for multithreaded workloads that frequently have cache misses. HyperThreading (HT) permits the CPU to continue useful processing by running the other thread. On the other hand, both threads compete for the core’s resources, and each thread may run slower than if it owned an entire core. Each thread potentially displaces the other thread’s level 1 cache contents, causing both threads to run slower. This is especially visible for compute-intensive workloads that might normally fit in the cache without HT. The result is that it's reasonable to enable HyperThreading by default, but it can be valuable to test performance to see whether it adds performance for a specific application or not.

The current EPM 11.1.2.4 setup is working perfectly fine for past many years having an optimum performance for all the apps.

Now, while we have decided to upgrade it to EPM 11.2, it was quite apparent for us to get the answers of the following queries:

  • Is there any recommendation for HyperThreading in EPM 11.2 version (Windows server 2019, Linux 7)?
  • Can we continue with having the existing 11.1.2.4 HyperThreading CPU configuration even in EPM 11.2?
  • Is there any known issue or performance improvement if we continue to run Essbase and HFM on HyperThreading enabled servers even in EPM 11.2?

Let's try to find out.......

Oracle and HyperThreading:

Oracle will work just fine on any OS that is running and recognizes a HyperThreading enabled system and will take advantage of the logical CPUs to their fullest extent (assuming the OS reports that it recognizes that hyper-threading is enabled). All Oracle versions can take advantage of hyper-threading and is considered a supported configuration since no support code has been added for it on the Oracle end to take advantage of HyperThreading; all the changes were in the OS, the bios, and the hardware. When Oracle asks the OS how many CPUs are in the system, the OS just reports the total number of logical CPUs.

Oracle Hyperion and HyperThreading:

I googled and read some blogs and what I found is that the experience of Oracle EPM apps with HyperThreading is quite mixed. For some, it worked well while others didn’t. I will leave it up to you to google and read those observations.

I remember there used to be a line in the Essbase 11.1.2.1 dbag document -"Enabling hyperthreading on the computer on which Essbase Server runs is not recommended." But now this line is no more there in Essbase dbag Release 11.1.2.4, implying the statement is no more valid.

My current EPM 11.1.2.4 configuration was done much before I joined this project so not sure about the exact reason to have HyperThreading enabled physical servers for Essbase and HFM apps and not for other apps which were installed on VM machines (please let me know if you know any technical correlation). But I am sure there must have been some idea behind opting the current 11.1.2.4 servers' CPU configuration (on Windows Server 2012 R2 and Linux 6).

However seeing the good performance of the current 11.1.2.4 PROD environment (Essbase, HFM, FDMEE, DRM, and HPCM) over the past many years and in the absence of any conclusive stats about HyperThreading impact in EPM servers, I was tempted to take the current PROD 11.1.2.4 HyperThreading setup as a reference for the EPM 11.2 hardware configuration too.

But, notably, EPM 11.2 version will be running on Windows servers 2019 compared to currently used Windows servers 2012 R2, so I thought better to consult Oracle to make a final recommendation on HyperThreading for EPM 11.2 Servers' CPU configuration.

And below is what Oracle said:

There are no specific Recommendations on HyperThreading for EPM 11.2 version (Windows server 2019) and we didn't see any issues reported by other customers as well. However, you can enable HyperThreading in your 11.2 setup and let us know if you face any issues post the implementation.

So it’s clear that there is no clear-cut YES/NO from the Oracle side as far as Enabling/Disabling HyperThreading in EPM 11.2 servers are concerned. Oracle leaves it to the discretion of your Hyperion technical team and Servers build team to decide whether you want to have servers built with HyperThreading enabled or disabled. Of course, it will vary with different Hyperion environments, OS, applications and most importantly it should be guided by the time-tested performance of your Hyperion applications for example in terms of HFM consolidation, Essbase calculation, aggregation, data load, and report script run, FDMEE data load run time, etc.

But yes! Oracle will come to your rescue if you face any issues post EPM 11.2 implementation (irrespective of what you chose for your CPU configuration).

And for those who are interested to know how we have decided to go for HyperThreading in EPM 11.2 servers. Well, it’s still under discussion (as of Sep 2020)....(but its almost certain that our EPM 11.2 servers will be having the same Hardware configuration what we have in our existing 11.1.2.4 setup being a time-tested reference for our current set of Essbase, HFM, HPCM, FDMEE, DRM, etc. applications).

Do leave a comment to let me know how you have built your EPM 11.2 servers (with/without HyperThreading).

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