FDMEE 11.1.2.3.520 connections – ODI trickery for Oracle databases

I recently wrapped up an infrastructure project at a client that needed to prove the connection between Peoplesoft and FDMEE would work. The client will then use this connection going forward as he builds out his brand new implementation.

We kept getting stuck with the FDMEE connection “initialize” step. The DBA granted us read-only access to the Peoplesoft tables through a separate schema than the owner of the tables. For security reasons, they didn’t want us logging directly into the Oracle database as the owner of the Peoplesoft tables and for that I cannot blame them. I setup the connection in ODI as I have a few times before and expected that everything would be just fine. Unfortunately, we kept getting an Oracle error in ODI: ORA-00942: table or view does not exist.

I connected to the schema using SQL Developer and when I tried to view the tables, I could see that no tables existed under my service account schema. I was able to query the Peoplesoft tables through synonyms, though, so we assumed that everything would work fine.

As we looked at the errors in the ODI logs, we could see that it was attempting to access the tables using a “Schema.Table” naming convention. The schema that it was using was our service account schema “SVC_HYPERIONSQL”. Since that schema didn’t contain any tables, it was clear that was the cause behind the errors, but how to get the integration to point to the correct schema where the tables exist?

I went back into ODI and looked at the Data Server connection. That’s when I realized that the “Schema” that it was asking for needed to be the owner of the Peoplesoft tables. We could use our other service account schema as the Work Schema, but in order for the integrations to run properly, they needed to access the tables using the correct account, which was SYSADM for this environment.

Must select the proper schema that owns the ERP tables when using Oracle repositories.

After selecting the proper schema, the “Initialize” step in FDMEE worked without a hitch.

Essbase, EAS, APS, and Essbase Studio 11.1.2.3.505

Last Tuesday, Oracle released new patches for Essbase and friends (EAS, APS, and Essbase Studio).  The Patch Set Update brings the new version to 11.1.2.3.505.  Here are the relevant patch numbers for your reference:

Product:	Patch Number:
EAS Server	19613844
EAS Console MSI	19613853
APS	19509172
Essbase Studio Server	19509186
Essbase Studio Console MSI	19509181
Essbase Server	19906085
Essbase Runtime Client	19906081
Essbase Client	19906103
Essbase Client MSI	19906079

I think that it’s great that we now have Oracle Essbase, APS, EAS, and Studio all on the same patch versions again.  The readme files actually state, “Oracle recommends using the same version of all Essbase portfolio products (Essbase, Essbase Administration Services, Hyperion Provider Services, and Essbase Studio) and components (server, client, runtime client, API, and JAPI).” Given that, if you want one of these patches, you should install them all.

The majority of the content in these patches are various bug fixes that are covered in the readmes for each patch.  The Essbase server patch appears to focus on performance optimization and stabilization; however, there a couple of noteworthy items in that readme.

There was a new calculator command added with Essbase 11.1.2.3.500 that was not documented.  It is SET CALCDIAGNOSTICS.  This command enables diagnostic logging for CALCPARALLEL and FIXPARALLEL commands.  This logging is not on by default, since there is some performance overhead.  This feature is designed to help in tuning parallel operations, then it should be turned off.

Here are the example from the Essbase 11.1.2.3.505 readme:

Examples

The following example enables diagnostic logging for all parallel calculations in the calculation script.

SET CALCDIAGNOSTICS { LOGSIZE 4; };

FIXPARALLEL (2, @IDESCENDANT(“US_Market”))

AGG (“Product”);

ENDFIXPARALLEL

The following example enables diagnostic logging for a specific FIXPARALLEL block.

FIXPARALLEL (2, @IDESCENDANT(“US_Market”))

SET CALCDIAGNOSTICS { LOGSIZE 4; };

AGG (“Product”);

ENDFIXPARALLEL

Sample Diagnostic Log Output for FIXPARALLEL

The following sample output pertains to FIXPARALLEL parallel calculation.

OK/INFO – 1012899 – Statistics for [Calc1.csc], FIXPARALLEL of index [1] at line [14]: Number of FIXPARALLEL Threads = [2], Total Tasks = [261], Min/Max/Avg Thread’s Time = [103.453]/[103.519]/[103.486] secs.

OK/INFO – 1012899 – For [4] Longest tasks, next rows display : Time(secs), Thread_id, (Task_index/Task_count), Task_id, Member-combinations.

OK/INFO – 1012899 – 15.131, 1, (30/132), 53, [ID_051341].

OK/INFO – 1012899 – 10.759, 2, (124/129), 211, [ID_050092].

OK/INFO – 1012899 – 9.690, 1, (42/132), 125, [ID_052230].

OK/INFO – 1012899 – 7.192, 1, (38/132), 105, [ID_052073].

OK/INFO – 1012899 – Summary for thread[1]: Total Time = [103.519] secs, Total Tasks = [132].

OK/INFO – 1012899 – Longest tasks executing on thread[1] : Time(secs), Thread_id, (Task_index/Task_count), Task_id.

OK/INFO – 1012899 – 15.131, 1, (30/132), 53.

OK/INFO – 1012899 – 7.192, 1, (38/132), 105.

OK/INFO – 1012899 – 9.690, 1, (42/132), 125.

OK/INFO – 1012899 – Summary for thread[2]: Total Time = [103.453] secs, Total Tasks = [129].

OK/INFO – 1012899 – Longest tasks executing on thread[2] : Time(secs), Thread_id, (Task_index/Task_count), Task_id.

OK/INFO – 1012899 – 10.759, 2, (124/129), 211.

The diagnostic output is organized into 3 sections.

Under the known issues section, I did see this interesting tidbit:

  To avoid abnormal application shutdowns,

o    Do not use the DELAYEDRECOVERY configuration setting in essbase.cfg, and in particular, do not set it to FALSE

o    Do not run the MaxL statement alter database recover freespace.

There are a few other documentation updates listed at the bottom of the Essbase readme, mostly clarifications on a few points from previous readmes.