So I was thinking this morning…
When I run partial data clears in ASO via MaxL, I always specify that a physical clear occurs since we have a large database.
When I run a partial data clear via EAS, what happens?
Our app\ApplicationName\default\AppName.dat file, I see that the size of the file is 868,000 KB. When I do a partial clear on roughly half the data, the .dat file stays the same size.
When I reload the “cleared” data, the size of the file grows to 1,376,000 KB since we have added the missing data back.
Next, I exported the data from the cube to see what the exported size of the file was…966,000 KB.
I cleared the database and verified it got down to 0 KB.
When I reloaded the data, the file size was 548,000 KB.
So what did I learn from this exercise? In EAS, the ASO partial data clear performs a logical clear versus a physical data clear. Essentially, Essbase “neutralizes” the data to zero but does not reduce the size of the .dat file. However, when you overwrite the data back to the cube, it adds it as an addition to the cube instead of truly overwriting the space on the server, making the database grow. When the data is exported, there is some zero data that gets exported, but since I set my settings to ignore the zero data, my .dat file size shrank to a “true” value of the space the file is taking on the server.
I think I may experiment more with ASO partial data clears…