TI process taking too long to update Dimension attributes

[ram123]

HI Guys,

I have 2 issues in TM1
1)I am trying to update the dimension attributes through TI process,which data source as ODBC(loading from oracle table).for updating 700+ records its taking more than 30 mins.could any one help on how to reduce the time to update.

2)I copied the cube A from another cube B(live cube) through links in PM and which I created the views in the cube A and when I try to open the view its taking more than 20 mins time.could any one suggest the option to avoid this error.

[declanr]

1) Could be the query itself being slow if the table is badly indexed etc. If you rule that out then you should look to see whether your changes are firing feeders in TM1. If so - look to see if you can improve the feeders; or remove the rules altogether at the start of the process and add them back on at the end. (Also search the forum as there was another post recently suggesting other ways to achieve faster performance related to feeder issues.)

H
2)I copied the cube A from another cube B(live cube) through links in PM and which I created the views in the cube A and when I try to open the view its taking more than 20 mins time.could any one suggest the option to avoid this error.

- Doesn't sound like an "error" as such; I would just assume that there are some terrible rules/feeders that have been generated - rewrite/improve them.

For both problems though we will need more info (code etc.) to provide a detailed answer.

[ram123]

Hi,

I tried from the xls source imput also,and There is no feeders and rules for this dimension element,other than dynamic subset.does this dynamic subsets of this dimension are effecting the performance?

[TrevorGoss]

hello ram123

Try using the DimensionUpdateDirect function on the relevant dimension. It performs a full re-write of the dimension to try and help performance.

Here is the documentation: http://www-01.ibm.com/support/knowledge ... irect.html

Use the function on the dimension being updated, even if it is a control dimension.

[Duncan P]

If the attribute is an alias there will be performance implications as rules of cubes using that dimension will need to be recompiled.

[lotsaram]

If the attribute is an alias there will be performance implications as rules of cubes using that dimension will need to be recompiled.

Thanks for the explanation, that makes sense. I often wi feted why the data tab often took a long time to complete on dim update processes. Especially for larger dimensions this can be a big issue. HOWEVER surely this should be configurable! If you observe good practices and elements are only ever referred to by principal name then you shouldn't be slugged with a performance hit for this.

[Duncan P]

When I was there I argued for a "rules cannot use aliases" config option to improve performance, but it fell on deaf ears.

If your attribute cube has an alias in it I have a feeling that this recompilation used to happen whenever you wrote to any attribute, whether an alias or not. However they may have fixed that.

A slightly more esoteric aspect was that if you had rule calculated aliases (which you might be tempted to do) an upstream change would not trigger this recompilation and so rules that used the alias wouldn't clear their associated cube caches.

All in all, aliases on the left hand side of rule statements are a bad thing (IMHO).