allocation problem/disk space disappears when processing cube

Preston M. Price wrote:

I get this error while processing my cubes:
Error: Memory error: Allocation failure : Not enough storage is available to process this command.
There is plenty of space left on the hard disks on this machine, I can't find a remedy for this problem on Google either. Any help would be appreciated.

Thanks in advance.

I am seeing the same disk space issue as described in original post.

Each partition is about 8GB, total 14 partitions. each partition about 50M rows.

The cube was processed before so it exists with about 110GB total used space.

Free space about 200GB.

When re-processing the same cube, the free space seems to slowly disappear, for example only after processing 2 partitions, the free space went from 200GB to 40GB. This is while the total used space in this cube directory is 120GB. The used space makes sense - 110GB + 8G for 2nd copy of partition that's being processed.

The free space gone to neverland is what doesn't make sense!

I am processing partitions from BIDS (highlighted all partitions). Processing each partition separately, each with its own transaction.

I've seen the same type of Disk space stealing by SSAS server when for example deleting a cube. Somehow when I delete the cube, it does not show that disk space is free, while the files are gone!, - that is until you restart SSAS server.

can anyone shed a light on this?

(win 2003 ent, sql 2005 ent sp2 fin, 32 bit, 16gb ram, 4 cpu)

Does SSAS actually use the Disk for temporary cache of data during aggregation?

can anyone from MS SSAS team clarify?

if that's true, which "directory" is it, and can I change it to be a different disk? I so happen to have more free space available on a different drive (not OLAP Data drive).

any ideas?

I guess this should be filed as a bug. what should I call this bug? "space stealing?"

|||

The error message refers to main memory - not disk.

|||

ok, but why does the disk space disappears?

it goes away in such way that free space + used space does not add up.

until ssas server is restarted.

|||

anyone at MS have an idea when this might be fixed / addressed?

|||

I am processing a cube, during processing aggregations, the OLAP Drive free space trickles down, while nothing is being added to the files under the specific cube's data directories.

Looks like Analysis Services may be temporarily storing aggregations results into some phantom files?

Anyone know about this? Is it possible to tell how much free disk space this requires? I don't like when it fails and doesn't say why...

|||

during this activity, the CPU goes to 100% for a few seconds, and then idle for about 10x that time, not the usuall "100% all the time" pattern when doing aggregations in other cases (when disk does not disappear).

anyone has any insight into this?

|||

Hi,

There is nothing strange about all that, that is just what it does. You might want to read the performance guide on SSAS 2005, it explains various aspects of the internals and what it is trying to do when processing different elements of the database.

http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/SSAS2005PerfGuide.doc

Hope that helps

Matt

|||

thanks for pasting the link here, on what page does it speak to my issue?

The issue is that aggregations never completes, the processing just uses up all free space and fails.

Yesterday my processing did not succeed, but phantomized 600GB of free disk space and then failed.

my total data size is about 50GB, with about 120 aggregations, there is no way it should require 600GB or more space.

besides the pattern is not normal, usually it is 100% CPU all the time without long low CPU periods.

does anyone from SSAS team know what's going on? is this a known issue (if so, has it been fixed in Cumulative update 3 and/or 4)?

|||

the performance paper above cleared this up for me, once I started monitoring the Agg Proc conters with temp rows written/temp bytes written it it clear when it starts using the temp file space as intermediate aggregation memory.

However, it is using way more disk space than eventually aggregation takes up - because data is not yet merged then.

So some clearer reporting of what's going on, and abilty to specify additional locations for temp files would be great - to avoid failures due to disk space.