dbTalk Databases Forums  

Process problem

microsoft.public.sqlserver.olap microsoft.public.sqlserver.olap


Discuss Process problem in the microsoft.public.sqlserver.olap forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Cymryr
 
Posts: n/a

Default Process problem - 01-03-2005 , 04:05 AM






Hello,
I have an olap cube in an Production application since one year.
Today the number of fact is 10 000 000
Each month i have 600 000 new fact

Since a couple of day the process failed everyday (daily full process of
cube and dimension)

I have no logs in my DTS and doesn't know where to search.
The only workaround i found is to stop and restart the olap service befor to
launch the DTS that process the database

The SP3a is installed on the server since a few month

Thanks for your help

Cymryr




Reply With Quote
  #2  
Old   
Ofri
 
Posts: n/a

Default RE: Process problem - 01-04-2005 , 04:31 AM






Maybe you have a very large dimension that fills your memory. For a process
you need this space twice.
- look in the task manager to see how much memory the process msmdsrv.exe
needs. Presumably you get memory-errors in your eventlog while processing
your database.
- analyse your dimension sizes (just look in your data-directory of the
analysis-service). Maybe you can reduce the size of a large dimension by
changing your design.
- try to adjust the conservation threshold in the properties of your
analysis-service. The value should be half of your physical memory, max. 1600
MB.

greetings,
Olaf

"Cymryr" wrote:

Quote:
Hello,
I have an olap cube in an Production application since one year.
Today the number of fact is 10 000 000
Each month i have 600 000 new fact

Since a couple of day the process failed everyday (daily full process of
cube and dimension)

I have no logs in my DTS and doesn't know where to search.
The only workaround i found is to stop and restart the olap service befor to
launch the DTS that process the database

The SP3a is installed on the server since a few month

Thanks for your help

Cymryr





Reply With Quote
  #3  
Old   
Dave Wickert [MSFT]
 
Posts: n/a

Default Re: Process problem - 01-05-2005 , 06:49 PM



There are several best practices here.
Look at the AS Operations Guide
http://www.microsoft.com/technet/pro.../anservog.mspx
for things like turning on the system-wide processing log file, etc.
--
Dave Wickert [MSFT]
dwickert (AT) online (DOT) microsoft.com
Program Manager
BI SystemsTeam
SQL BI Product Unit (Analysis Services)
--
This posting is provided "AS IS" with no warranties, and confers no rights.

"Ofri" <Ofri (AT) discussions (DOT) microsoft.com> wrote

Quote:
Maybe you have a very large dimension that fills your memory. For a
process
you need this space twice.
- look in the task manager to see how much memory the process msmdsrv.exe
needs. Presumably you get memory-errors in your eventlog while processing
your database.
- analyse your dimension sizes (just look in your data-directory of the
analysis-service). Maybe you can reduce the size of a large dimension by
changing your design.
- try to adjust the conservation threshold in the properties of your
analysis-service. The value should be half of your physical memory, max.
1600
MB.

greetings,
Olaf

"Cymryr" wrote:

Hello,
I have an olap cube in an Production application since one year.
Today the number of fact is 10 000 000
Each month i have 600 000 new fact

Since a couple of day the process failed everyday (daily full process of
cube and dimension)

I have no logs in my DTS and doesn't know where to search.
The only workaround i found is to stop and restart the olap service
befor to
launch the DTS that process the database

The SP3a is installed on the server since a few month

Thanks for your help

Cymryr







Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.