Hi all:

I have deployed my cube for two months and have been incremental update
everyday without any problems. However, today MSSQLServerOLAPService keeps
restart every sec, and it has generated a set of SQLDmpr.mdmp files in the
Data Folder. Anyone know why this happen?

Thanks,

Chi

It could possibly be a corruption in one of the dimension files. AS2k
loads all the dimensions into memory on startup, so if one of them is
corrupt it might cause this issue.

One way to fix this would to do a full rebuild of your OLAP Database.
You would need to take a backup of the Data folder (while the services
is stopped) and then delete all the files in the data folder so that you
could get the service to start up without crashing.

It might be possible to just rebuild the dimensions, but I think it
would be safer just to let AS rebuild everything from scratch.

Note that a corrupt dimension is not an overly common occurrence. I have
been working with AS2k since it was in Beta and have never seen one so
hopefully your situation is just a once off.

HTH

--
Regards
Darren Gosbell [MCSD]
<dgosbell_at_yahoo_dot_com>
Blog: http://www.geekswithblogs.net/darrengosbell

I have to disagree with Darren, I had this problem in many occasions. Usually
this problem when one or more users are changing cubes. It think it never
happened in the production servers.

What I normally do is to identify the last(s) cube(s) being changed and
delete them directly in the OLAPDATA directory (must delete the corresponding
“.odb” file and directory).

If you need the last version of the cube try to copy the meta data the few
seconds the server is up to another server.

Hope it helps.
"Darren Gosbell" wrote:

Just a general comment everyone.
Having the service recycle because of corrupted dimensions is a very serious
problem.
In Microsoft terms, we would call it a Sev 1 (severity 1) bug: data
corruption. This is the top problem severity that we classify.

If this is happening to you (particularly if you are running the latest
service pack), then you need to get these to Premier Support as soon as
possible so we can fix the problem.

The technique that Tiago suggested is the right workaround to get the server
back up and running, but it doesn't help us fix the product. Particularly if
there are mini-dumps generated, please get them to Premier Support so we can
fix the problem for everyone else.

Thanks.
--
Dave Wickert [MSFT]
dwickert (AT) online (DOT) microsoft.com
Program Manager
BI Systems Team
SQL BI Product Unit (Analysis Services)
--
This posting is provided "AS IS" with no warranties, and confers no rights.


"Tiago Rente" <TiagoRente (AT) discussions (DOT) microsoft.com> wrote

If you are getting this a lot I would definitely follow David Wickert's
suggestion and open up a call with PSS.

I have clients ranging from small insurance companies running on 32bit
AS, up to a large telco running on 64bt AS and I have another client
running AS in a 64bit cluster - and I have seen this issue once.

The one time I did see it, a few hours later a hard disk in our raid
array died, so I was fairly comfortable that it was a once off hardware
issue.

Technically all you should have to delete are the .dim* files in the
database's directory under the Olap Data directory.

Or for an even quicker approach, rename them to something like .xxx* and
then restart the server. If it starts OK, stop it and try renaming the
..xxx* files back to .dim*, one or two at a time until you find the one
that is causing the issue.

This step is unnecessary as the cube metadata is store in the repository
which will either be in a SQL database or in the default access format
in the bin folder under the AS program files folder.

--
Regards
Darren Gosbell [MCSD]
<dgosbell_at_yahoo_dot_com>
Blog: http://www.geekswithblogs.net/darrengosbell

In article <F7A862E2-4D48-494E-B9DB-2349BC5AF841 (AT) microsoft (DOT) com>,
TiagoRente (AT) discussions (DOT) microsoft.com says...

BTW: Darren, these corruption issues typically arise based on using some
particular feature or data operation. For example, if you do an incremental
update rather than a full reprocess when you have deleted dimension records.
If your clients are doing straightforward data changes and are not doing
anything unusual it wouldn't surprise me that you haven't seen this kind of
thing. It is the kind of thing that you are doing something unexpected that
it crops up. But when it does it is difficult to detect what kind of
operation you are doing differently which causes the corruption to occur.

Thus it is important that when it happens to people that we find out what is
happening and get to the bottom of it. This is particularly true if it
happens fairly regularly. If it is once or twice in a system's lifecycle,
then like you I'd be tempted to blame it on flake hardware. If it is
happening every other day or every week, then there is something about the
way that the data is changing that is unexpected. by the system.
--
Dave Wickert [MSFT]
dwickert (AT) online (DOT) microsoft.com
Program Manager
BI Systems Team
SQL BI Product Unit (Analysis Services)
--
This posting is provided "AS IS" with no warranties, and confers no rights.


"Darren Gosbell" <xxx (AT) xxx (DOT) com> wrote

Thanks Dave, that's a good thing to know for future reference.

I hope that I did not come across as saying that it never happens, I
just wanted to point out that there are a lot of very stable AS2k
environments out there. I was wondering if it might have been related to
particular usage patterns and I absolutely agree that it is vital that
these issues should be reported back to MS.

I thought it was interesting that you mentioned incremental processing.
As it happens, a lot of the clients I have dealt with have movements in
their data that often requires doing a full rebuild. The main exception
to this in my experience has been the retail sector, but I am sure there
are many others out there. So maybe I have been lucky not to strike this
issue before.

--
Regards
Darren Gosbell [MCSD]
<dgosbell_at_yahoo_dot_com>
Blog: http://www.geekswithblogs.net/darrengosbell

In article <eTot9bo2FHA.3588 (AT) TK2MSFTNGP15 (DOT) phx.gbl>,
dwickert (AT) online (DOT) microsoft.com says...

Just to add my 2 cents.

I do never do a incremental processing. I do incremental processing of the
dimensions, a full processing for the needed partitions and reaggregate
processing for the remaining partitions

When those problems happens usually is in the development stage, prior to
any processing. So I am not sure that your technique will work, but I will
keep it in mind for next time.
After SP4 was installed in the development environment, it had not happened
again (yet).

"Darren Gosbell" wrote: