Currency conversion wizard - performance

We have created a cube in which we want to do many-to-many currency conversion - i.e. we have a measure group with amounts measured in 4 different currencies, and we want to be able to display these amounts in any of these 4 currencies. The measure group is linked to a company dimension which in turn is linked to a currency dimension via a referenced relationship (there are 3-4 more dimensions in the cube). Running the currency conversion wizard yields the expected results and we can show our measures in any available currency using the "Reporting Currency" dimension... However - it is SLOW!

We realize that the calculations in the MDX script generated by the wizard scopes on the leaves on the time dimension, which causes a performance hit, but the query runs for 4-5 minutes when choosing a currency other than "Local". Choosing "Local" the query runs for 2-3 seconds. The measure group in question contains approximately 1.4 millions fact rows and we have exchange rates for a 10 year period (approximately 365 x 4 x 10 = 14.600 fact rows for the exchange rate measure group).

We are using the September CTP (Standard Edition). Is there any way to improve the response times? Has bugs that affect this been fixed for RTM?

Thanks...

We are really having problems with this one... Has anyone else had similar experiences? |||Hi Michael,

Although my experience is limited, I can think of some things it might be worth trying...

First of all, using measure expressions instead of pure MDX Script calculations should give you better performance. See the following entries on my blog for more information:
http://spaces.msn.com/members/cwebbbi/Blog/cns!1pi7ETChsJ1un_2s41jm9Iyg!260.entry
http://spaces.msn.com/members/cwebbbi/Blog/cns!1pi7ETChsJ1un_2s41jm9Iyg!299.entry

Secondly (and this is only an educated guess), if you make sure that any aggregations you build are only at the granuarlity attribute of the Time dimension, then with a bit of luck the AS engine will be able to use them for your queries. You can do this by making sure that only the granuarity attribute has its AttributeHierarchyOptimizedState property set to FullyOptimized (the others should have it set to NotOptimized); if you then redesign your aggregations, hopefully you'll still get some built and see some improvement. If you don't get any aggregations built then you might have to design some manually by hacking the XMLA.

Thirdly, I wonder if the fact that the Currency dimension has a referenced relationship with the main fact table could be a factor here? Can you redesign the main fact table so that you have a Currency key as well as a Company key?

Fourthly, and I'm not sure that this will have much impact but it's worth trying, partitioning your Exchange Rate measure group by Month might be a good idea.

Let me know if any of this works..

Chris|||Thanks Chris... I will try your suggestions and report back my findings. My options with regard to your suggestions are limited, however, since the project is being built on a Standard Edition (thus no measure expressions and/or partitioning).

Currency conversion wizard - performance

We have created a cube in which we want to do many-to-many currency conversion - i.e. we have a measure group with amounts measured in 4 different currencies, and we want to be able to display these amounts in any of these 4 currencies. The measure group is linked to a company dimension which in turn is linked to a currency dimension via a referenced relationship (there are 3-4 more dimensions in the cube). Running the currency conversion wizard yields the expected results and we can show our measures in any available currency using the "Reporting Currency" dimension... However - it is SLOW!

We realize that the calculations in the MDX script generated by the wizard scopes on the leaves on the time dimension, which causes a performance hit, but the query runs for 4-5 minutes when choosing a currency other than "Local". Choosing "Local" the query runs for 2-3 seconds. The measure group in question contains approximately 1.4 millions fact rows and we have exchange rates for a 10 year period (approximately 365 x 4 x 10 = 14.600 fact rows for the exchange rate measure group).

We are using the September CTP (Standard Edition). Is there any way to improve the response times? Has bugs that affect this been fixed for RTM?

Thanks...

We are really having problems with this one... Has anyone else had similar experiences? |||Hi Michael,

Although my experience is limited, I can think of some things it might be worth trying...

First of all, using measure expressions instead of pure MDX Script calculations should give you better performance. See the following entries on my blog for more information:
http://spaces.msn.com/members/cwebbbi/Blog/cns!1pi7ETChsJ1un_2s41jm9Iyg!260.entry
http://spaces.msn.com/members/cwebbbi/Blog/cns!1pi7ETChsJ1un_2s41jm9Iyg!299.entry

Secondly (and this is only an educated guess), if you make sure that any aggregations you build are only at the granuarlity attribute of the Time dimension, then with a bit of luck the AS engine will be able to use them for your queries. You can do this by making sure that only the granuarity attribute has its AttributeHierarchyOptimizedState property set to FullyOptimized (the others should have it set to NotOptimized); if you then redesign your aggregations, hopefully you'll still get some built and see some improvement. If you don't get any aggregations built then you might have to design some manually by hacking the XMLA.

Thirdly, I wonder if the fact that the Currency dimension has a referenced relationship with the main fact table could be a factor here? Can you redesign the main fact table so that you have a Currency key as well as a Company key?

Fourthly, and I'm not sure that this will have much impact but it's worth trying, partitioning your Exchange Rate measure group by Month might be a good idea.

Let me know if any of this works..

Chris|||Thanks Chris... I will try your suggestions and report back my findings. My options with regard to your suggestions are limited, however, since the project is being built on a Standard Edition (thus no measure expressions and/or partitioning).

Currency Conversion

I am using the cube intelligence wizard to add currency conversions. I have defined everything properly. At a certain moment, a query is launched against my Oracle backend. This is the query:

SELECT "Reporting Currency".*

FROM

(

SELECT "CCDM_IL"."CCDM_IL_CRRN_T"."CURRENCY_CODE","CCDM_IL"."CCDM_IL_CRRN_T"."CURRENCY_NAME"

FROM "CCDM_IL"."CCDM_IL_CRRN_T"

WHERE [CURRENCY_NAME] IN ('Euro') UNION

SELECT

DISTINCT

'Local' "Local",'Local' "Local 2"

FROM "CCDM_IL"."CCDM_IL_CRRN_T"

)

"Reporting Currency"

Now, this query returns the error "ORA-00936: Missing Expression". This error is caused by the square brackets around currency_name in the where clause. Once I remove these the query runs fine.

How can I make this query work?

Thanks

Joos

By the look of it this is coming from a named query in the DSV. Check if the wizard has actually inserted the square brackets into the named query in the DSV. If so, you should be able to edit the definition to remove the square brackets.|||

The query is generated by the BI wizard itself. In my DSV, I do not have a named query for the currency dimension. It is a real table...

The currency dimension has one attribute for which the key is set to CCDM_IL_CRRN_T.CURRENCY_CODE and the name is set to CCDM_IL_CRRN_T.CURRENCY_NAME.

|||Can you double check? Right click on the object in the DSV and tell me if the third menu item you see says either "Edit Named Query..." or "Replace Table with...". I would not normally ask, but the reason I am is becuase the BI wizard actually generates objects in your DSV and cubes, but it does not actually send any queries to the relational source.|||

For the table CCDM_IL_CRRN_T, it definitely says "Replace Table".

Joos

|||

Have you been able to isolate if this error is coming from a dimension or from a partition? (by processing objects associated with currencies one at a time)

Try going into SSMS, right clicking on the database and generating an alter script. This will generate a heap of xmla, search through this for the table name in square brackets or some other identifiable portion of this problem query. You can then either run the alter script and then import the database back into BIDS or hopefully this will help identify where exactly the problem query is coming from.

|||

In the script, the square brackets do not occur. Extracts where currency_name occurs:

<NameColumn>

<DataType>WChar</DataType>

<DataSize>255</DataSize>

<Source xsi:type="ColumnBinding">

<TableID>CCDM_CCDM_IL_CRRN_T</TableID>

<ColumnID>CURRENCY_NAME</ColumnID>

</Source>

</NameColumn>

<xs:element name="CURRENCY_NAME" msprop:FriendlyName="CURRENCY_NAME" mspropbColumnName="CURRENCY_NAME" minOccurs="0">

<xsimpleType>

<xs:restriction base="xstring">

<xs:maxLength value="255" />

</xs:restriction>

</xsimpleType>

</xs:element>

Joos

Cube Wizard not detecting a Fact Table in SSAS

Hi,

While trying to create a Cube using the Cube Wizard, Under 'Identify Fact and Dimension Tables' screen, When I try to check either 'Fact' or 'Dimension' option box for a FactTable, SS is flagging an error.

Can someone tell me as to why this is happening ?

The wizard relies on the relationships in the DSV, so if these are missing or incorrect the wizard may have problems figuring things out.|||A little more specificially, every Fact Table must have one or more Dimension Tables which can be reached from it based on the relationships in the DSV. You probably just need to select a table for use as a dimension, possibly even the fact table itself, and then the wizard should let you continue.|||

Thanks Darren and Matt for your replies.

I modified the Fact table to have FKs with Dimension Tables and now the Wizard detects it successfully.

Cheers,

Sundar

Cube Wizard not detecting a Fact Table in SSAS

Hi,

While trying to create a Cube using the Cube Wizard, Under 'Identify Fact and Dimension Tables' screen, When I try to check either 'Fact' or 'Dimension' option box for a FactTable, SS is flagging an error.

Can someone tell me as to why this is happening ?

The wizard relies on the relationships in the DSV, so if these are missing or incorrect the wizard may have problems figuring things out.|||A little more specificially, every Fact Table must have one or more Dimension Tables which can be reached from it based on the relationships in the DSV. You probably just need to select a table for use as a dimension, possibly even the fact table itself, and then the wizard should let you continue.|||

Thanks Darren and Matt for your replies.

I modified the Fact table to have FKs with Dimension Tables and now the Wizard detects it successfully.

Cheers,

Sundar

Cube Wizard not detecting a Fact Table in SSAS

Hi,

While trying to create a Cube using the Cube Wizard, Under 'Identify Fact and Dimension Tables' screen, When I try to check either 'Fact' or 'Dimension' option box for a FactTable, SS is flagging an error.

Can someone tell me as to why this is happening ?

The wizard relies on the relationships in the DSV, so if these are missing or incorrect the wizard may have problems figuring things out.|||A little more specificially, every Fact Table must have one or more Dimension Tables which can be reached from it based on the relationships in the DSV. You probably just need to select a table for use as a dimension, possibly even the fact table itself, and then the wizard should let you continue.|||

Thanks Darren and Matt for your replies.

I modified the Fact table to have FKs with Dimension Tables and now the Wizard detects it successfully.

Cheers,

Sundar

Cube Wizard not detecting a Fact Table in SSAS

Hi,

While trying to create a Cube using the Cube Wizard, Under 'Identify Fact and Dimension Tables' screen, When I try to check either 'Fact' or 'Dimension' option box for a FactTable, SS is flagging an error.

Can someone tell me as to why this is happening ?

The wizard relies on the relationships in the DSV, so if these are missing or incorrect the wizard may have problems figuring things out.|||A little more specificially, every Fact Table must have one or more Dimension Tables which can be reached from it based on the relationships in the DSV. You probably just need to select a table for use as a dimension, possibly even the fact table itself, and then the wizard should let you continue.|||

Thanks Darren and Matt for your replies.

I modified the Fact table to have FKs with Dimension Tables and now the Wizard detects it successfully.

Cheers,

Sundar