All das brachte uns aber nicht wirklich weiter.<\/p>\n
Letztendlich stellte sich aber heraus, dass die Ursache gar nicht in den (tlw. komplexen) Abfragen zur Ermittlung der Fakten zu suchen war, sondern in „Dimensions-Abfragen“. Damit meine ich folgendes: Unsere Berichte werden (aus einer eigenen Web-Applikation heraus) mit Parametern aufgerufen, die IDs sind (eigentlich die Member Unique Names, also z.B. Datum.Jahr.&[2010]). Dabei haben die Parameter (aus Performancegr\u00fcnden) keine Datasets, die alle verf\u00fcgbaren Werte enthalten. Nun wollen wir aber in dem Bericht nat\u00fcrlich auch den \u00fcbergebenen Wert im Klartext anzeigen, also in obigem Beispiel das Jahr 2010. Deswegen mussten also einfache Abfragen her, die aus dem Member Unique Name den Klartext (Member Caption) ermitteln.<\/p>\n
In unserem Projekt hatten wir uns darauf geeinigt, wenn m\u00f6glich den SSRS-Designer f\u00fcr SSAS-Abfragen zu verwenden, um eine gute Wartbarkeit (ohne tiefere MDX-Kenntnisse) zu erreichen.<\/p>\n
Damit gibt es zwei einfache Arten, dieses Problem zu l\u00f6sen:<\/p>\n
Die erste Art, hat eine Spalte – das Jahr – und zus\u00e4tzlich den (MultiSelect) Report Parameter als Parameter f\u00fcr die Abfrage:<\/p>\n
Als MDX ergibt sich:<\/p>\n SELECT { } ON COLUMNS, { ([Datum].[Jahr].[Jahr].ALLMEMBERS ) } DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME ON ROWS FROM ( SELECT ( STRTOSET(@DatumJahr, CONSTRAINED) ) ON COLUMNS FROM [Verkaeufe]) CELL PROPERTIES VALUE<\/p><\/blockquote>\n Man kann auch die Abfrage etwas erweitern:<\/p>\n Man f\u00fcgt ein berechnets Measure (in diesem Fall namens „UniqueName“) mit dem MDX<\/p>\n [Datum].[Jahr].CurrentMember.UniqueName<\/p><\/blockquote>\n hinzu:<\/p>\n Damit ergibt sich folgendes MDX:<\/p>\n WITH MEMBER [Measures].[UniqueName] AS [Datum].[Jahr].CurrentMember.UniqueName SELECT NON EMPTY { [Measures].[UniqueName] } ON COLUMNS, NON EMPTY { ([Datum].[Jahr].[Jahr].ALLMEMBERS ) } DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME ON ROWS FROM ( SELECT ( STRTOSET(@DatumJahr, CONSTRAINED) ) ON COLUMNS FROM [Verkaeufe]) CELL PROPERTIES VALUE, BACK_COLOR, FORE_COLOR, FORMATTED_VALUE, FORMAT_STRING, FONT_NAME, FONT_SIZE, FONT_FLAGS<\/p><\/blockquote>\n Anmerkung: Das dabei enstehende versteckte Dataset zum Bef\u00fcllen der „verf\u00fcgbaren Werte“ des Parameters l\u00f6schen wir, da wir ja keine „verf\u00fcgbaren Werte“ anzeigen wollen (unsere Dimension hatte zu viele Eintr\u00e4ge).<\/p>\n Beide Abfragen scheinen dasselbe zu tun und mit der selben Performance. Dies ist aber ein Trugschluss!<\/p>\n Leeren wir zun\u00e4chst (und vor Ausf\u00fchrung eines neuen Test-Statements) den SSAS-Cache mit<\/p>\n <ClearCache xmlns=“http:\/\/schemas.microsoft.com\/analysisservices\/2003\/engine“> (siehe dazu auch: http:\/\/www.ssas-info.com\/analysis-services-faq\/27-mdx\/133-mdx-how-do-i-clear-analysis-services-ssas-database-cache<\/a>)<\/p>\n Dann betrachten wir die Darstellung im SQL Server Profiler (mit den Standard-Einstellungen f\u00fcr den SSAS):<\/p>\n Die erste Abfrage ergibt folgendes Bild:<\/p>\n Schauen wir uns die einzelnen Zeilen an:<\/p>\n Die zweite Abfrage ergibt ein anderes Bild:<\/p>\n Hier sehen wir, dass kein Zugriff auf eine Partition erfolgt!<\/p>\n Der Zugriff auf die Partition ist nat\u00fcrlich sch\u00e4dlich, da er bei gro\u00dfen Datenmengen lang dauern kann, zumal er gar nicht ben\u00f6tigt wird, da wir ja nur Dimensions-Element-Bezeichnungen abfragen wollen. Noch ein interessante Anmerkung zum Schluss: Wenn man die erste Abfrage im SQL Server Management Studio ausf\u00fchrt, ist sie auch nicht langsam. Da im Management Studio keine parametrisierten Abfragen m\u00f6glich sind, muss man dazu die Parameter durch die entsprechenden Strings ersetzen, und erh\u00e4lt somit folgendes MDX:<\/p>\n SELECT { } ON COLUMNS, { ([Datum].[Jahr].[Jahr].ALLMEMBERS ) } DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME ON ROWS FROM ( SELECT ( STRTOSET(„{ [Datum].[Jahr].&[2001],[Datum].[Jahr].&[2008] }“, CONSTRAINED) ) ON COLUMNS FROM [Verkaeufe]) CELL PROPERTIES VALUE<\/p><\/blockquote>\n F\u00fchrt man dieses MDX aus (nachdem man den Cache geleert hat), so erh\u00e4lt man folgendes Bild:<\/p>\n Man sieht hier also auch nur ein Query Begin und ein Query End, also auch keinen Zugriff auf die Cube-(bzw. Partitions-)Daten.<\/p>\n Dies hatte uns die Fehlersuche erschwert, da wir nat\u00fcrlich zun\u00e4chst auf der Suche nach dem verantwortlichen Statement alle Statements im SQL Server Profiler mitgeschnitten und dann einzeln im Management Studio ausgef\u00fchrt hatten, was – wie eben gesehen – das problematische Statement leider nicht offenbart.<\/p>\n","protected":false},"excerpt":{"rendered":" Nachdem wir in einem Projekt unseren Test-Datenbestand (12 Mio Fakten) auf den Produktiv-Bestand (73 Mio Fakten) erweitert hatten, zeigten die Berichte (SSRS 2008 R2) massiv schlechte Antwortszeiten in bestimmten Berichten auf unseren Cube (SSAS 2008 R2) – jeweils nach der Cubeaufbereitung. Somit war klar, dass Ursache war, dass einige der im Bericht verwendeten Abfragen nicht … Performanceprobleme bei SSAS-Dimensionsabfragen aus SSRS<\/span> weiterlesen ![\"Wizard](\"https:\/\/www.csopro.de\/biblog\/wp-content\/uploads\/2011\/03\/langsamwizard.jpg\")
<\/a>
\n(Bild zum Verg\u00f6\u00dfern anklicken!)<\/p>\n<\/a>
\n(Bild zum Verg\u00f6\u00dfern anklicken!)<\/p>\n
\n<Object>
\n<DatabaseID>SimpleCube<\/DatabaseID>
\n<CubeID>Verkaeufe<\/CubeID>
\n<\/Object>
\n<\/ClearCache><\/p><\/blockquote>\n<\/a>
\n(Bild zum Verg\u00f6\u00dfern anklicken!)<\/p>\n\n
<\/a>
\n(Bild zum Verg\u00f6\u00dfern anklicken!)<\/p>\n
\nEs ist nicht erkl\u00e4rbar, warum SSAS hier dennoch auf die Fakten zugreift.
\nDeswegen ist die zweite Abfrage auf jeden Fall vorzuziehen!<\/p>\n<\/a>
\n(Bild zum Verg\u00f6\u00dfern anklicken!)<\/p>\n