I have a cube with a moderately complex snowflake schema (6 fact
tables, 70 dimension tables) with about 380K rows. Everything builds
and processes fine with less than 50 or so dimensions. But once I
exceed the 50 or so dimensions all heck breaks loose. I get spurious
messages on keys not found (yes they are there and foreign keys are in
place) on dimensions that processed properly before. Removing these
dimensions seems to move the errors to other dimensions (that processed
properly before). And I am getting HY008 messages that seem to
indicate OLEDB type errors but I can't find anything specific on it.
I've spent a large amount of time exploring this problem and it shifts
around and is impossible to pin down. It seems to be an AS 2005 bug
that I hit when going above a certain level of cube complexity.
Removing dimensions eventually gets me a stable cube but I need all of
the dimensions so I cannot just cut down the complexity of the cube.
Also, since virtual cubes were dropped in AS 2005 I can just make up
two or cubes and virtuallize them together. I have to have all this
data together in this cube to make the final reporting work.

So has anyone encountered HY008 errors and have a solution? Anyone hit
problems that seem to connected to cube complexity? Anyone have any
other ideas?

Thanks!

- Grant Anderson

Are you trying to process all the dimensions at once? Have you tried to
serialize the processing operations and process one dimension (or just a
few) at a time?

Btw, virtual cubes weren't really "cut" -- they were superseded by measure
groups (and linked measure groups)...

Thanks,
Akshai
--
Try out the MSDN Forums for Analysis Services at:
http://forums.microsoft.com/MSDN/Sho...ID=83&SiteID=1

This posting is provided "AS IS" with no warranties, and confers no rights
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.

"C. Grant Anderson" <GAnderson (AT) HealthGrades (DOT) com> wrote

Akshai,

Thanks for replying.

Processing each dimension individually works because it is not a full
processing. When I hit the limit that the problem occurs then I get
the errors on full processing. I will try processing just the
structure and then the data and see if this has any effect. I think
that this is an SP1 problem and am trying to find a work around.
Dropping SP1 is not an option because SP1 fixed an aggregation problem
(undocumented by Microsoft) so I can't go backwards (as inviting as it
sounds).

I still miss the virtual cubes. I find that linked measure groups are
very nice but don't really replace virtual cubes. I'd rather have two
separate cubes that I can query as one. We are using ProClarity and I
can't query two separate cubes with it. I'm stuck with merging the
data into a single cube unless someone has some idea of an alternative
that would work in this application space.

- Grant

I'm not sure I understand this. You can make dimension processing also do a
ProcessFull instead of ProcessUpdate...

I definitely will not recommend going backwards from SP1 to RTM And I
wouldn't expect it to help much.

FYI, you can create two cubes with the physical measure groups in them. Then
create a new cube in the same database with two linked measure groups that
point to the first two cubes as their source.

Thanks,
Akshai
--
Try out the MSDN Forums for Analysis Services at:
http://forums.microsoft.com/MSDN/Sho...ID=83&SiteID=1

This posting is provided "AS IS" with no warranties, and confers no rights
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.

"C. Grant Anderson" <GAnderson (AT) HealthGrades (DOT) com> wrote

Akshai,

We're out of synch a bit regarding the dimension processing...but in
synch regarding going backwards from SP1.

I wish Microsoft would publish a list of al the bugs fixed by SP1. I
previously encountered an aggregation error that was fixed by SP1 but
was not in the SP1 fix list. It would also be nice if they maintained
a public list of known bugs. I have already confirmed that adding and
deleting numbers of dimensions can cause problems, apparently
corrupting the base XML files. I don't have time to pinpoint the exact
effect(s) and areas. Sigh....

I will try the cube with linked measure groups accessing two sub-cubes.
We are using ProClarity as our front end so I have to take into
account what and how ProClarity will handle. We are trying to provide
our users with as unified and simplified cube interface as possible
(thus combining all the data). ProClarity originally told us that that
their product could query two cubes in the same view (report) but when
we tried it did not work. Their tech support told us that it is not
possible. So there may be a limitation there but I will try your
suggestion and see if we can get it working in our environment.

Thanks!

- Grant

Everyone,

An update on this problem.

I set up a cube database with multiple cubes. It isolates the fact
tables into their own cubes with a top linked "virtual" cube rather
than using a large snowflake schema. The main problem I encountered I
think was that some of the fact tables were very large and some quite
moderate in size. This created an imbalance that AS 2005 had trouble
managing with a large number of shared dimensions.

Here's a listing of my notes of the weird problems I encountered:

When I build individual cubes no problems processing the individual
cubes.

Also no problem processing the entire database.

When I build a combined cube with the full data source view and all
the dimensions I get many, continuous, spurious processing errors.
Deleting the dimensions one by one from the cube does not solve
the problems.
Deleting the combined cube then processing the entire database
does NOT work.
I get spurious errors on the individual cubes now.
Processing the cubes individually works.
This would indicate a problem with the cube definition becoming
corrupted or the code not being able to handle these changes properly.
Dropping the project and restoring from a backup (of course) is
necessary to get the project processing correctly.
I cannot ever continue re-using the corrupted project because it
just will not ever work correctly repeatedly.

So a virtual linked cube approach can help when encountering problems
with a large unbalanced snowflake design. The cube definition
corruption problem is probably caused by the AS 2005/BIDS code getting
into a non-normal state and then writing entries to the cube definition
file(s) that cannot be properly read back or parsed fully. If I had
more time I would compare the before and after files and narrow it down
but I don't have the time right now.

Oh, and I used special prefix naming conventions to help associate the
various dimensions with the specific cubes. This can help the report
developers and cube users figure out which dimensions go with which
cubes and measure groups.

- Grant

Everyone,

Another update on this problem.

I've encountered the cube processing problem again on simpler cubes.
What happens is that the cube errors out on processing with a spurious
error, in my cases saying that an ID key cannot be found when it is
actually present in the database. And a foreign key is present.
Reprocessing the dimensions one by one then doing a full reprocessing
of the cube solves this problem, at least in some cases. I didn't get
spurious HY008 errors in these other cubes when I had processing
problems but the cubes were much simpler so I cannot say definitively
that this is the solution to my previous problems. The Microsoft
person did suggest reprocessing the dimensions one by one in a previous
post here and I believe that I did that on my big cube but I cannot be
sure if this was the only problem/solution with my big cube. (I don't
have time to check.) This may have been the intersection of more than
"quirk" (bug) that caused my original problem.

So, if you get wierd processing errors that do not make sense based
upon the underlaying data then try reprocessing all the dimensions one
by one then reprocessing the cube. And be careful when building complex
cubes.

- Grant