cancel
Showing results for 
Search instead for 
Did you mean: 

Performance degrade and TIMEDB

Former Member
0 Kudos

Hello,

Function RSDDCVER_RFC_BW_STATISTICS has returned

the result table with statistics. The "TimeDB"

for one of the cubes "Z_CUBE1" lasts much longer:

INFOCUBE____TIMEDB____DBSEL__DBSEL / TIMEDB

ZCUBE1___36,960937_______181_________4,897062

ZCUBE2___14,816407___141.457______9547,321425

ZCUBE3____0,644531_____3.732______5790,256791

What's a reason for such a performance degrade?

Thanks a lot!

AndyML

Accepted Solutions (1)

Accepted Solutions (1)

0 Kudos

hi Andy,

how's the volume data in each cube ?

z_cube1 has high volume data ?

to improve the performance, aggregate can be used.

is this what you want ?

hope this helps.

Former Member
0 Kudos

Hi,

The Cubes were compressed.

In E-Table:

Z_CUBE1 23.055.349

Z_CUBE2 27.792.617

Z_CUBE3 15.689.165

But should i do aggregates for BW-SEM?

Thanx.

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Andy,

From the above mentioned scenario, i see that infocubes has huge TIMEDB and also

the records selected were very less.

I think the infocubes are storing the line item level data.

The performance of queries on these cubes will be very poor.You should think about creating aggregates.

As a general rule

An aggregate is reasonable and may be created if

. Aggregation ratio > 10 , i.e 10 times more records are read than are displayed and

. Percentage of DB TIME > 30 % , i.e the time spent on database is substantial part of

the whole query runtime.

Above details can be known from Transaction ST03.

Hope this helps

-Doodle

Former Member
0 Kudos

Hi,

Should i use the aggregates for SEM (not BEX)?

Thanx

Former Member
0 Kudos

Andy,

You should create aggregates for SEM

-Doodle

Former Member
0 Kudos

Hi Doodle,

Can you say about

old (compressed) Requests (green)

and new (not yet compressed) Request (yellow)?

Can i shear this data in aggregate?

Did you create aggregates for SEM?

Did this really help in SEM Layouts?

Thanx.

Former Member
0 Kudos

Requests don't change color as a result of compression. They should simply have a checkmark in the compressed status. Are you sure most of the requests in the cube are compressed? Having lots of uncompressed requests will definitely hurt quer performance.

At any rate -

I think what you are referring to is that you have an open request on a transactional cube - that is, one that data is still being written to and appears yellow.

Yes aggregates will work for a transactional cube - 3 SQL queries are generated, one for the E fact table aggregate (compressed), one for the F fact table aggregate, and then a query just for the open request (yellow - which has no aggregate).

Former Member
0 Kudos

Thank you, Pizzaman.

Yes i'm sure. i know what a differences between compressed, not compressed and open requests in

transactional cube. All requests in cube are compressed.

Only one not yet, because it still open for new data from layouts and functions.

<b>Are there problems or disadvantages of using of Aggregates for Transactional Cube?</b>

AndyML.