Re: SQL 2005 SSAS - Cube processing fails due to memory error when more than one SSAS database exists (even when not part of the processing)

Yes, we are up to date on the SQL Server SPs and patches.

I will try your suggestion when I get a moment, but currently we do
not have a 2nd database on there because our production cubes will not
load at night. I will have to backup and restore out Production SSAS
database to a Development Database and then try your suggestion. So,
it may take some time.

In the meantime and to answer you other questions...

The cube has 1 partition (we have Standard Edition)

The Cube has 1 measure group with 70 measures. These measures are
thing like # of sales, # of contacts,etc. However we do have a large
number of "Number of Days" measures...i.e., "Number of Days between
Lead Creation and Sale", "Number of Days between Lead Creation and
Sales Person Contacting them". (Our measures are not named those long
names. Just trying to make it descriptive for this thread.)

We only have 1 measure group with all 70 measures because they come
from the same fact table.

Thanks very much for your response. I will try to do the tests that
you mentioned as soon as possible, but it may take a couple of days to
schedule it. In the meantime, if you have any other thoughts, I'd
greatly appreciate. --John



On Jan 8, 3:58 pm, entaroadun <johnny.c.k...@xxxxxxxxx> wrote:
I have to ask, do you have all of the latest SPs and patches?

This simply cannot be a legitimate memory issue.  Something is
gobbling up your heap.  SSIS uses AMO, so try kicking off a simple XML/
A process to push the cube.  If this doesn't work, trying issuing a
ProcessStructure before doing a ProcessFull (or better yet,
ProcessData followed by ProcessIndexes instead of ProcessFull).

Also, how many measure groups do you have, and how are they
partitioned?  Maybe it's something with maintaining the transaction
space, and serial, non-transaction batch may work.

On Jan 8, 3:30 pm, JM <john.mur...@xxxxxxxxx> wrote:



On Jan 8, 9:23 am, entaroadun <johnny.c.k...@xxxxxxxxx> wrote:

How are you kicking off the process?  Are you using XML/A directly?

On Jan 8, 8:13 am, "Jeje" <willg...@xxxxxxxxxxx> wrote:

how many rows do you have?
do you use x64 or x32 servers? (I think x32)

do you have only SSAS installed on the server?

if you have other applications installed, then switch to an x64 OS and SQL
Server install. My experience is bad if an x32 server share multiple
application with SSAS installed.

also remove any unused cubes an database deployed in SSAS. This consume some
memory for nothing. And reduce the number of unused attributes in the
dimensions.

"JM" <john.mur...@xxxxxxxxx> wrote in message

news:4f0ea8a4-2be3-4e1c-bf89-0b627301507e@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Server Config:

-Xeon 3.60GHz

-8 GB RAM

-Windows Server 2003 R2 Enterprise SP2

-SQL Server 2005 Standard Edition SP2 Version 9.00.3050.00

-3GB BOOT.ini switch enabled

Issue:

-The processing of our Sales cube in our Production database (SSAS)
fails with Memory Error.

Normal process:

- Successfully process all dimensions in Production DB (SSAS)

- Restart SSAS service to clear memory

- Process Sales Cube in Production DB (SSAS)

Events related to the beginning of this failure:

For 2 weeks, this would fail every time our ETL would run.  Then 2
weeks ago, we deleted our Development DB (SSAS) that was restored from
a backup of the Production DB.

Once that database was deleted, the processing of Sales Cube in
Production DB was successful every time for 2 weeks.

Last week, we restored the Development DB (SSAS) from a backup of the
Production DB.  Now, when we try to process Sales Cube in Production
DB, it fails every time.

As you can see above, we restart the service before processing Sales
Cube in Production DB.  Also, this is the only object that we try to
process.  We never even reference of affect Development DB.

Somehow, the presence of this 2nd SSAS database causes our processing
to fail even though we never try to do anything with it.  It's mere
presence on the SSAS instance is causing our processing on Sales Cube
in Production DB to fail.

My questions are:

- Since it is restored from a back up of Production DB, could
Development DB actually be getting processed as well when we specify
to process Production DB...i.e., they are sharing an object link so
that when we specify to process only one, it processes both?

- Is there any memory allocation that happens just because an SSAS
database exists?  for example, if no one is querying it and it is not
processing, is it eating up lots of memory?

If you have any other thoughts which have a solution besides "put the
2nd SSAS database on a separate machine", please let me know.  Thanks
so much in advance.  -John- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

The cube has less than 10 million rows.  The process is occuring in an
SSIS Process Analysis Services task.  It is the only task being run.

Our SQL Server database engine is also installed on this machine and
houses the data warehouse that we load the cubes from.  All of it
happens at night, so most of the behavior that I described in the
earlier post is during the day when now data loading is happening.- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

I'll double check on the Service Packs
.

Relevant Pages

  • Re: SQL 2005 SSAS - Cube processing fails due to memory error when more than one SSAS database e
    ... application with SSAS installed. ... fails with Memory Error. ... Production DB was successful every time for 2 weeks. ... Cube in Production DB. ...
    (microsoft.public.sqlserver.olap)
  • Re: Simple MDX question - selecting dimension members
    ... the cube doesn't have a default measure set. ... Is SSAS just picking one ... > Sales cube has as default, and so these 2 MDX queries ... > Deepak Puri ...
    (microsoft.public.sqlserver.olap)
  • Re: Update 4: Moral dilemma at work....
    ... I hope someone from sales _learned_ about profitability. ... ranted on about how the production arm wasn't doing its job. ... The cost accounting system was carefully set-up to keep the ... Even worse, was the use of worn-out machines, fixtures and ...
    (rec.crafts.metalworking)
  • Re: Update 4: Moral dilemma at work....
    ... I hope someone from sales _learned_ about profitability. ... ranted on about how the production arm wasn't doing its job. ... The cost accounting system was carefully set-up to keep the ... Even worse, was the use of worn-out machines, fixtures and ...
    (rec.crafts.metalworking)
  • Re: Apple idiocy
    ... So much for the eMac displacing Windows sales. ... Apple has HISTORICALLY had supply problems with popular products. ... The only way to throttle demand is usually to raise ...
    (comp.sys.mac.advocacy)
Loading