HFM performance in VM environment

Question

Guys,
We are in the process of tuning HFM application as consolidation were taking more than an hour.
These servers are running with 8 processors with 48GB ram on Windows Server 2008 R2 Enterprise.
I have followed the oracle documentation in setting registry settings as below.
NumConsolidationThreads - 8
MaxNumConcurrentConsolidations - 8
NumMaxDBConnections - 8
MaxNumCubesInRAM - 1000000
MinDataCacheSizeInMB - 8 GB
MaxDataCacheSizeInMB - 12 GB
MaxNumDataRecordsInRAMForConsol - 90000000
MaxNumDataRecordsInRAM - 90000000
Database settings
Cursors - 5000
Redo/archive logs are enabled at this time. We are debating on disable these.
Still it's not performing well. i know it's relative. we are looking to get below 30 mins.
I have looked at DCN, DCE tables - these have 12 million records for a year.
With all these settings, still CPU are not taking more than 25%. I think there a room to improve the consolidation by taking more cpu usage. let me know your thoughts.
Any suggestions, greatly appreciated.

Answer 1

Hi,
Yeah Data Audit for metadata specifically do not affect but if it tracks data changes as well then it might to an extent but am not sure on this as we had it disabled since then i was working on it.
Regarding HFM queries, You could below queries
Below Query would give you the times taken by individual consolidations
select g.servername,g.appname,to_char((to_date('01/1900','MM/YYYY')+g.starttime-2),'DD/MM/YYYY hh24:mi:ss') starttime,to_char((to_date('01/1900','MM/YYYY')+g.endtime-2),'DD/MM/YYYY hh24:mi:ss') endtime,g.strdescription,s.susername,(endtime-starttime)*24*60 TimeTaken
from AppName_task_audit g,hsv_activity_users s
where g.activityuserid in s.luserid and g.strdescription is not null
order by 3 desc
Below Query would give you number of entries created in Data Audit table which implies the frequency of updates.
select to_char(to_date('01/1900', 'MM/YYYY')+DTIMESTAMP-2,'MM/YYYY') as "MMYYYY", count(*) as "Number of entries"
from AppName_DATA_AUDIT
group by to_char(to_date('01/1900', 'MM/YYYY')+DTIMESTAMP-2,'MM/YYYY');
Below query would help in understanding the activity done by users.
SELECT H.SSERVERNAME,s.susername,TO_CHAR((TO_DATE('01/1900','MM/YYYY')+H.DSTARTTIME-2),'DD/MM/YYYY hh24:mi:ss'),H.LACTIVITYCODE,H.SACTIVITYDESC FROM HSV_USERS_ON_SYSTEM H,HSV_ACTIVITY_USERS S
WHERE H.LUSERID IN S.LUSERID and H.LACTIVITYCODE<>0
order by sservername
Activity code would mean like below
ActivityID
ActivityName
0
Idle
1
Rules Load
2
Rules Scan
3
Rules Extract
4
Consolidation
5
Chart Logic
6
Translation
7
Custom Logic
8
Allocate
9
Data Load
And also over a course of time would take to analyze this kind of issues as to pin point exactly the has been caused  by so & so...
Also you could probably check the database size before and after actuals load or periodic submissions.
SELECT SUM(BYTES )/1024/1024/1024 GB FROM  USER_SEGMENTS
Also do you have same metadata in another environment where you can test the timings to see if there is any hardware glitch is causing this, ideally no as its a good amount of configuration.But that would help as there might be multiple applications in this environment and just a single one in other environment. And Also i think HSVDataSource  process cannot increase beyond 2GB on a 32 bit based Operating System , not sure enough though on this.
Also do check with your DBA incase your DB is fragmented and defragmentation would help to increase the performance. And also database analysis would help identify the issue if exists at DB end.
Thanks
Amith