Right.January 16 2017 at 8:52 PM
No score for this post
from IP address 126.96.36.199
Response to Are we talking Essbase fragmentation or file fragmentation?
So, I sent some notes around looking for an ASO cube that had blown up in size, and got one of my own sent to me. Hurray.
Fundamentally that size difference is caused by fragmentation of the .dat file. This is heavily caused by the default tablespace being set to the full size of the dat file - so continuous fragmentation over time causes significant growth.
For a specific (and slightly horrific) example.
Input Level Data Size (KB) 2,612,800
Disk space allocated for data (KB) 57,499,648
Disk Space used by data (KB) 2,637,792
That's not a typo. 57gb of allocated space, 2.6 gb of used space.
Because this is 'allocated' space by the way, that is also the size of the .dat file on the essbase server.
We then merged the slices, Exported a level zero text file (2.6gb), cleared it and reloaded it.
Input level data size (KB) 2,581,312 (I don't know why this changed...may have been a slice merge?)
Disk space allocated (KB) 2,588,672
Dis space used by data (KB) 2,581,440
So Yeah. We're adding that into an overnight process.
I 'think' this fragementation is a rare case caused by a large number of micropushes (several 100's a day) and a lot of incremental FDMEE loads.
It appears you could also (if your databases were much larger and therefore exporting and importing the data was not a feasible method) you could split the tablespaces up which should reduce the volume of fragmentation.
- Further - Pete on Jan 16, 2017, 11:24 PM