FixParallel–How fast is fast?

Addendum to this blog post.

I lied, I lied, but not intentionally. When I wrote this post, I thought it was true and the timings were as I saw them, but upon further investigation, It turns out I had encountered a bug with FixParallel where including the set DataExportRelationalFile  on causes some problem with data exports using FixParallel.  The export only returned data for one node of the hierarchy not the entire hierarchy as it should have.  Unfortunately, I don’t have access to rerun the tests again. This issue was fixed in 11.1.2.4 and I think a patch for 11.1.2.3.5X that had not been installed on the system I was using. I’m guessing the performance will still be faster than without it, but can’t give you correct numbers

Sorry if I misled you

*****************************************************************************

I have finally been able to use FixParallel introduced in 11.1.2.3.500 on an Exalytics server. I’ve used it for for calculations and dataexports, so how fast is it and does it really make a difference?

For my allocations calculations, I really can’t tell you how much of a difference it made, but I know it was a lot faster to do my allocations with FixParalled than without it. I just didn’t capture the times.

For my DataExport, I was able to measure the difference.  I was exporting 1083702 level 0 blocks in column format with a block size of 9984b. I created a Dataexport calc script and set CalcParallel to16 in the script. Running it took 336.95 seconds. I thought that was reasonable, but I wanted better.

I changed the script to use FixParallel using 16 threads across my location dimension which has abut 800 members. The calculation took 9.94 seconds. If I multiply out that number by 16 I come up with 159.04 seconds so it it telling me the FixParrallel calculation is improving performance more than just the parallelization of the script.

What I did not expect is; just like ParallelExport, the FixParallel dataexport created a file for each thread, so instead of one file I ended up with 15. They were named with a suffix of _T? where ? was a number between 1 and 15.  (not sure why I didn’t have 16 files).  I also don’t know what would happen f the file size spanned 2 gig. Would it append a _1 to the file name? I tried reducing the number of threads  to 3 and reran the script. Alas, I ended up with only three files so I can’t give you an answer. But interestingly the script took 690.63 seconds, much longer that the script without FixParallel, so apparently there it tuning we can do to the script.  I could try including another dimension in my FixParallel, but am happy with my less than 10 second export. Perhaps a test for another day.

So is FixParallel worth it, my testing says YES! FixParallel for me was an awesome new feature and one I will use often.

Everything must come to an end

I finally got my new laptop after having a loaner for over a month so I can now resume blogging (at least more easily).  I’ve been excited about all of the new features and functionality of Essbase 11.1.2.4 and there has bee a flurry of blogs that have described that functionality. Today, Tim Tow posted one feature going away the VB API.   There are a number of other features that you might not be aware of as either completely gone or depreciated so they won’t be supported in the future.

So first what is already gone?

1. Essbase Native Security. Shared services should be used to manage and maintain users.
2. Essbase Integration Services. The writing has been on the wall for this for a while with Essbase Studio taking its place, there is little need to duplicate functionality. Of course along with this goes Hybrid analysis.
3. VB API (Time talks about that in his blog)
4. A number of Configuration file (Essbase.cfg) settings. I believe the functionality has been built into the base product so these are no longer needed.

• PRELOADALIASNAMESPACE

• PRELOADMEMBERNAMESPACE

• PRELOADUDANAMESPACE

• MAXACTIVEUPDATETRANSACTIONS

• MAXTOTALACTIVETRANSACTIONS

So what is depreciated (This means not recommend for use and will most likely go away completely in the next release)

1. Direct I/O Can’t say I’m sorry to see this go. I’ve never had an implementation where it was advantageous to use it and it always seemed to be buggy.
2. Outline change log. While not widely used I do have some clients that use this for SOX compliance so the auditors can track who made outline changes and when. I’m hoping a new method for tracking this will be forthcoming.
3. Currency Conversion applications and Currency partitions. I don’t know anyone who used currency applications. Most consultants I know build it themselves within the primary cube. That said, Oracle announced at Open World last September that they are working on incorporating more HFM like financial functionality into Essbase, so I would expect to see a new method for currency conversion to appear at some point.
4. Data compression types ZLIB and None. Don’t know anyone who used them. I guess it means a certification test question will need to be updated. Really since Essbase already figures out what compression a block should use, these are outdated.
5. Linked Partitions. While a great idea, no one uses them (ok I have one client that implemented them, but doesn’t really use them)
6. the EAS API. again a nice idea to customize EAS, who really needed to do so,
7. Network File System (NFS) protocol on Network Attached Storage (NAS) devices. Who really cares. I think this was for Windows NT which is long gone.
8. MaxL statements relating to security. I believe this goes along with all of the other security changes. getting rid of the Essbase.sec file. I will miss this one as I used it as do some clients to automate some security processes. It means I’ll finally have to learn JAVA and use the JAVA Shared Services API to replicate what I did in the past.  These are the commands going away.

• alter user statement—only the add [to group] and remove [from group] grammar is deprecated

• create group statement—the entire statement is deprecated

• create user statement—the entire statement is deprecated

• display group statement—only the all grammar is deprecated

• display user statement—only the all grammar is deprecated

• drop group statement—all grammar is deprecated except for the from security_file grammar

• drop user statement—all grammar is deprecated except for the from security_file grammar

9. XOLAP is being limited to Teradata, Netezza and IBM DB2. Really these are where it was being used on higher powered machines so it makes sense.

With all of the great changes occurring in Essbase, I am sure Oracle is getting rid of code that makes the changes difficult or had to be modified or maintained with the changes. As can be seen from the list, Most will have minimal impact on users. If there are any of the depreciated features that are critical to your organization, let Oracle know, They do listen. (If you like you can communicate through me). While they may not keep a feature, they may have other ways coming out to accomplish what you need to do.

 

In closing I say Rest in peace to those items already removed 

 

and for those processes on life support get ready for the plug to be pulled