Embed Size (px)
Citation preview
Leistungshandbuch für Analysis Services
Technischer Artikel zu SQL Server
Autoren: Richard Tkachuk und Thomas Kejser
Beiträge und technische Lektoren:
T.K. AnandMarius DumitruGreg GallowaySiva HarinathDenny LeeEdward MelomedAkshai MirchandaniMosha PasumanskyCarl RabelerElizabeth VittSedat YogurtcuogluAnne Zorner
Veröffentlicht: Oktober 2008
Betrifft: SQL Server 2008
Zusammenfassung: In diesem Whitepaper wird beschrieben, wie Anwendungsentwickler Techniken zur Optimierung der Abfrage- und Verarbeitungsleistung auf ihre OLAP-Lösungen für SQL Server 2008 Analysis Services anwenden können.
CopyrightDie Informationen in diesem Dokument stellen die zum Datum der Veröffentlichung aktuelle Ansicht der Microsoft Corporation zu den erörterten Themen dar. Da Microsoft auf geänderte Marktbedingungen reagieren muss, dürfen diese Informationen nicht als Verpflichtung von Microsoft ausgelegt werden, und Microsoft kann nicht garantieren, dass alle Informationen in dem Dokument nach dem Datum der Veröffentlichung noch genau zutreffen.
Dieses Whitepaper dient ausschließlich Informationszwecken. MICROSOFT ÜBERNIMMT FÜR DIE INFORMATIONEN IN DIESEM DOKUMENT KEINE GEWÄHRLEISTUNG, WEDER AUSDRÜCKLICH, KONKLUDENT NOCH GESETZLICH.
Die Benutzer/innen sind verpflichtet, sich an alle anwendbaren Urheberrechtsgesetze zu halten. Unabhängig von der Anwendbarkeit der entsprechenden Urheberrechtsgesetze darf kein Teil dieses Dokuments ohne ausdrückliche schriftliche Erlaubnis der Microsoft Corporation für irgendwelche Zwecke vervielfältigt oder in einem Datenempfangssystem gespeichert oder darin eingelesen werden, unabhängig davon, auf welche Art und Weise oder mit welchen Mitteln (elektronisch, mechanisch, durch Fotokopieren, Aufzeichnen usw.) dies geschieht.
Es ist möglich, dass Microsoft Rechte an Patenten bzw. an angemeldeten Patenten, an Marken, Urheberrechten oder sonstigem geistigen Eigentum besitzt, die sich auf den fachlichen Inhalt dieses Dokuments beziehen. Die Bereitstellung dieses Dokuments gewährt Ihnen jedoch keinerlei Lizenzrechte an diesen Patenten, Marken, Urheberrechten oder anderem geistigen Eigentum, es sei denn, dies wurde ausdrücklich durch einen schriftlichen Lizenzvertrag mit der Microsoft Corporation vereinbart.
© 2008 Microsoft Corporation. Alle Rechte vorbehalten.
Microsoft, Excel, SQL Server, Visual Basic, Windows und Windows Server sind Marken der Microsoft-Unternehmensgruppe.
Alle anderen Marken sind Eigentum ihrer jeweiligen Inhaber.
2
Inhalt1 Einführung...........................................................................................................................................6
2 Grundlegendes zur Architektur des Abfrageprozessors......................................................................6
2.1 Sitzungsverwaltung..................................................................................................................7
2.2 Auftragsarchitektur..................................................................................................................8
2.3 Abfrageprozessor.....................................................................................................................9
2.3.1 Abfrageprozessorcache......................................................................................................10
2.3.2 Abfrageprozessorinterna...................................................................................................12
2.4 Datenabruf.............................................................................................................................17
3 Verbessern der Abfrageleistung........................................................................................................18
3.1 Basislinien für Abfragegeschwindigkeiten..............................................................................18
3.2 Diagnostizieren von Abfrageleistungsproblemen...................................................................21
3.3 Optimieren von Dimensionen................................................................................................23
3.3.1 Identifizieren von Attributbeziehungen.............................................................................23
3.3.2 Effektive Verwendung von Hierarchien.............................................................................25
3.4 Maximieren des Werts von Aggregationen............................................................................26
3.4.1 Ermitteln von Aggregationstreffern...................................................................................26
3.4.2 Interpretieren von Aggregationen.....................................................................................27
3.4.3 Erstellen von Aggregationen..............................................................................................28
3.5 Verbessern der Abfrageleistung mithilfe von Partitionen......................................................32
3.5.1 Einführung.........................................................................................................................32
3.5.2 Aufteilen von Partitionen in Slices.....................................................................................33
3.5.3 Überlegungen zu Aggregationen für mehrere Partitionen.................................................33
3.5.4 Distinct Count-Partitionsentwurf.......................................................................................34
3.5.5 Ändern der Größe von Partitionen.....................................................................................34
3.6 Optimieren von MDX.............................................................................................................35
3.6.1 Diagnostizieren des Problems............................................................................................35
3.6.2 Bewährte Methoden für Berechnungen............................................................................35
3.7 Cachevorbereitung.................................................................................................................49
3.8 Verbessern der Mehrbenutzerleistung..................................................................................51
3
3.8.1 Erhöhen der Abfrageparallelität........................................................................................51
3.8.2 Speicherheaptyp................................................................................................................53
3.8.3 Blockieren von Abfragen mit langer Ausführungszeit........................................................53
3.8.4 Netzwerklastenausgleich und schreibgeschützte Datenbanken........................................54
4 Verstehen und Messen der Verarbeitung..........................................................................................55
4.1 Verarbeitungsauftrag (Übersicht)...........................................................................................55
4.2 Verarbeiten von Basislinien....................................................................................................56
4.2.1 Systemmonitor-Ablaufverfolgung......................................................................................56
4.2.2 Profiler-Ablaufverfolgung..................................................................................................57
4.3 Ermitteln der Vorgänge, bei denen Verarbeitungszeit aufgewendet wird.............................57
5 Verbessern der Leistung der Dimensionsverarbeitung......................................................................58
5.1 Grundlegendes zur Dimensionsverarbeitungsarchitektur......................................................58
5.2 Dimensionsverarbeitungsbefehle..........................................................................................61
5.3 Flussdiagramm zur Optimierung der Dimensionsverarbeitung..............................................62
5.4 Bewährte Methoden für die Leistung der Dimensionsverarbeitung......................................63
5.4.1 Verwenden von SQL-Sichten zum Implementieren der Abfragebindung für Dimensionen63
5.4.2 Optimieren der Attributverarbeitung für mehrere Datenquellen......................................63
5.4.3 Reduzieren des Aufwands für Attribute.............................................................................64
5.4.4 Effektive Verwendung der Eigenschaften KeyColumns, ValueColumn und NameColumn.64
5.4.5 Bitmapindizes entfernen....................................................................................................65
5.4.6 Deaktivieren der Attributhierarchie und Verwenden von Elementeigenschaften.............65
5.5 Optimieren der relationalen Dimensionsverarbeitungsabfrage.............................................66
6 Verbessern der Leistung der Partitionsverarbeitung.........................................................................66
6.1 Grundlegendes zur Partitionsverarbeitungsarchitektur.........................................................67
6.2 Partitionsverarbeitungsbefehle..............................................................................................67
6.3 Flussdiagramm zur Optimierung der Partitionsverarbeitung.................................................68
6.4 Bewährte Methoden für die Leistung der Partitionsverarbeitung.........................................70
6.4.1 Optimieren von Dateneinfügungen, Aktualisierungen und Löschungen............................71
6.4.2 Auswählen effizienter Datentypen in Faktentabellen........................................................72
6.5 Optimieren der relationalen Partitionsverarbeitungsabfrage................................................72
6.5.1 Entfernen von Joins............................................................................................................73
4
6.5.2 Hinweise zur relationalen Partitionierung.........................................................................73
6.5.3 Hinweise zur relationalen Indizierung................................................................................74
6.5.4 Verwenden von FILLFACTOR = 100 für den Index und der Datenkomprimierung.............76
6.6 Beseitigen des Datenbanksperrenaufwands..........................................................................76
6.7 Optimieren des Netzwerkdurchsatzes...................................................................................77
6.8 Verbessern des E/A-Subsystems............................................................................................79
6.9 Erhöhen der Parallelität durch Hinzufügen weiterer Partitionen...........................................79
6.10 Anpassen der maximalen Anzahl von Verbindungen.............................................................80
6.11 Anpassen von ThreadPool und CoordinatorExecutionMode.................................................81
6.12 Anpassen von BufferMemoryLimit.........................................................................................81
6.13 Optimieren der ProcessIndex-Phase......................................................................................82
6.13.1 Verhindern des Überlaufs temporärer Daten auf den Datenträger...................................82
6.13.2 Beseitigen von E/A-Engpässen...........................................................................................83
6.13.3 Hinzufügen von Partitionen zum Erhöhen der Parallelität.................................................83
6.13.4 Optimieren von Threads und AggregationMemory-Einstellungen.....................................83
7 Optimieren von Serverressourcen.....................................................................................................85
7.1 Verwenden von PreAllocate...................................................................................................85
7.2 Deaktivieren von Flight Recorder...........................................................................................86
7.3 Überwachen und Anpassen des Serverarbeitsspeichers........................................................86
8 Zusammenfassung.............................................................................................................................87
5
1 EinführungDa die Optimierung der Abfrage- und Verarbeitungsleistung für Microsoft® SQL Server® Analysis Services ein relativ umfassendes Thema ist, sind in diesem Whitepaper die Leistungsoptimierungstechniken in die folgenden drei Segmente unterteilt.
Verbessern der Abfrageleistung – Die Abfrageleistung beeinflusst direkt die Qualität der Endbenutzerumgebung. Daher ist sie der primäre Vergleichstest zum Bewerten des Erfolgs einer OLAP-Implementierung (Online Analytical Processing, analytische Onlineverarbeitung). Analysis Services bietet eine Reihe von Mechanismen zum Beschleunigen der Abfrageleistung, einschließlich Aggregationen, Zwischenspeichern und indizierten Datenabruf. Darüber hinaus können Sie die Abfrageleistung durch Optimieren des Entwurfs der Dimensionsattribute, Cubes und MDX-Abfragen (Multidimensional Expressions) verbessern.
Verbessern der Verarbeitungsleistung – Die Verarbeitung ist der Vorgang, bei dem Daten in einer Analysis Services-Datenbank aktualisiert werden. Je höher die Verarbeitungsleistung ist, desto schneller können Benutzer auf aktualisierte Daten zugreifen. Analysis Services bietet eine Reihe von Mechanismen zum Beeinflussen der Verarbeitungsleistung, einschließlich effizienter Dimensionsentwurf, effektive Aggregationen, Partitionen und eine sparsame Verarbeitungsstrategie (z. B. inkrementelle statt vollständige Aktualisierung und proaktives Zwischenspeichern).
Optimieren von Serverressourcen – Verschiedene Moduleinstellungen, die sich auf die Abfrage- und Verarbeitungsleistung auswirken, können optimiert werden.
2 Grundlegendes zur Architektur des AbfrageprozessorsZum möglichst schnellen Ausführen von Abfragen für Endbenutzer bietet die Analysis Services-Abfragearchitektur mehrere Komponenten, die beim effizienten Abrufen und Auswerten von Daten zusammenarbeiten. In Abbildung 1 werden die drei wichtigsten Vorgänge aufgeführt, die bei Abfragen auftreten – Sitzungsverwaltung, Ausführung von MDX-Abfragen und Datenabruf –, sowie die Serverkomponenten, die am jeweiligen Vorgang beteiligt sind.
6
Abbildung 1 Architektur des Abfrageprozessors in Analysis Services
2.1 SitzungsverwaltungClientanwendungen kommunizieren mit Analysis Services mithilfe von XML for Analysis (XMLA) über TCP/IP oder HTTP. Analysis Services stellt eine XMLA-Überwachungskomponente bereit, die alle XMLA-Kommunikationen zwischen Analysis Services und den Clients verarbeitet. Der Analysis Services-Sitzungs-Manager steuert, wie Clients Verbindungen zu einer Analysis Services-Instanz herstellen. Benutzer, die durch das Windows®-Betriebssystem authentifiziert wurden und Zugriff auf mindestens eine Datenbank haben, können eine Verbindung zu Analysis Services herstellen. Nachdem ein Benutzer eine Verbindung mit Analysis Services hergestellt hat, bestimmt der Sicherheits-Manager Benutzerberechtigungen basierend auf der Kombination von Analysis Services-Rollen, die für den Benutzer gelten. Je nach Architektur der Clientanwendung und der Sicherheitsberechtigungen der Verbindung erstellt der Client bei Anwendungsstart eine Sitzung und verwendet dann die Sitzung erneut für alle Anforderungen des Benutzers. Die Sitzung stellt den Kontext bereit, unter dem Clientabfragen vom Abfrageprozessor ausgeführt werden. Eine Sitzung besteht, bis sie von der Clientanwendung oder vom Server geschlossen wird.
7
2.2 Auftragsarchitektur Analysis Services verwendet eine zentralisierte Auftragsarchitektur zum Implementieren von Abfrage- und Verarbeitungsvorgängen. Ein Auftrag ist eine generische Einheit der Verarbeitungs- oder Abfragearbeit. Ein Auftrag kann je nach Komplexität der Anforderung mehrere Ebenen geschachtelter untergeordneter Aufträge umfassen.
Bei Verarbeitungsvorgängen wird beispielsweise ein Auftrag für das zu verarbeitende Objekt wie z. B. eine Dimension erstellt. Ein Dimensionsauftrag kann dann mehrere untergeordnete Aufträge erzeugen, die die Attribute in der Dimension verarbeiten. Bei Abfragen werden Aufträge zum Abrufen von Faktendaten und Aggregationen aus der Partition verwendet, um Abfrageanforderungen zu erfüllen. Bei einer Abfrage, die auf mehrere Partitionen zugreift, wird z. B. ein untergeordneter oder Koordinatorauftrag für die Abfrage selbst zusammen mit einem oder mehreren untergeordneten Aufträgen pro Partition generiert.
Abbildung 2 Auftragsarchitektur
Im Allgemeinen wirkt sich die parallele Ausführung mehrerer Aufträge positiv auf die Leistung aus, solange ausreichend Prozessorressourcen zur effektiven Verarbeitung der gleichzeitigen Vorgänge sowie ausreichend Speicher- und Datenträgerressourcen vorhanden sind. Die maximale Anzahl von Aufträgen, die für die aktuellen Vorgänge (einschließlich Verarbeitungs- und Abfragevorgänge) parallel ausgeführt werden können, wird durch die CoordinatorExecutionMode-Eigenschaft bestimmt:
• Ein negativer Wert gibt die maximale Anzahl von parallelen Vorgängen an, die pro Kern pro Vorgang gestartet werden können.
• Der Wert 0 signalisiert, dass keine Einschränkung besteht.
• Ein positiver Wert gibt eine absolute Anzahl von parallelen Vorgängen an, die pro Server gestartet werden können.
Der Standardwert für CoordinatorExecutionMode ist -4, wodurch angegeben wird, dass vier Aufträge parallel pro Kern gestartet werden. Dieser Wert ist für die meisten Serverumgebungen ausreichend. Zum Vergrößern des Grads der Parallelität auf dem Server können Sie den Wert dieser Eigenschaft
8
erhöhen, indem Sie entweder die Anzahl der Aufträge pro Prozessor erhöhen oder die Eigenschaft auf einen absoluten Wert festlegen.
Damit wird global die Anzahl von Aufträgen erhöht, die parallel ausgeführt werden können. Allerdings ist CoordinatorExecutionMode nicht die einzige Eigenschaft, die parallele Vorgänge beeinflusst. Sie müssen auch die Auswirkungen weiterer globaler Einstellungen wie der MaxThreads-Servereigenschaften berücksichtigen, die die maximale Anzahl von Abfrage- oder Verarbeitungsthreads ermitteln, die parallel ausgeführt werden können (weitere Informationen zu Threadeinstellungen finden Sie unter Verbessern der Mehrbenutzerleistung). Darüber hinaus können Sie mit feinerer Granularität für einen bestimmten Verarbeitungsvorgang die maximale Anzahl von Verarbeitungstasks, die parallel ausgeführt werden können, mit dem MaxParallel-Befehl angeben. Diese Einstellungen werden in den folgenden Abschnitten ausführlicher erläutert.
2.3 Abfrageprozessor Der Abfrageprozessor führt MDX-Abfragen aus und generiert ein entsprechendes Cellset oder Rowset. Dieser Abschnitt enthält eine Übersicht darüber, wie der Abfrageprozessor Abfragen ausführt. Weitere Informationen zum Optimieren von MDX finden Sie unter Optimieren von MDX.
Zum Abrufen der von einer Abfrage angeforderten Daten erstellt der Abfrageprozessor einen Ausführungsplan, um die angeforderten Ergebnisse aus den Cubedaten und -berechnungen zu generieren. Es gibt zwei unterschiedliche Typen von Abfrageausführungsplänen, und welcher Plan vom Modul ausgewählt wird, kann sich in bedeutendem Maße auf die Leistung auswirken. Weitere Informationen finden Sie unter Teilbereichberechnung.
Zur Kommunikation mit dem Speichermodul verwendet der Abfrageprozessor den Ausführungsplan zum Übersetzen der Datenanforderung in eine oder mehrere für das Speichermodul verständliche Teilcubeanforderungen. Ein Teilcube ist eine logische Einheit für Abfrage, Zwischenspeichern und Datenabruf – er ist eine Teilmenge von durch den Kreuzjoin eines oder mehrerer Elemente aus einer einzelnen Ebene jeder Attributhierarchie definierten Cubedaten. Ein oder mehrere Elemente aus einer einzelnen Ebene werden manchmal auch als einzelne Auflösung oder einzelne Granularität bezeichnet. Eine MDX-Abfrage kann je nach Attributgranularität und Berechnungskomplexität in mehrere Teilcubeanforderungen aufgelöst werden. So würde z. B. eine Abfrage, die jedes Element der Country-Attributhierarchie enthält (sofern es sich nicht um eine Parent-Child-Hierarchie handelt) in zwei Teilcubeanforderungen aufgeteilt werden: eine für das Alle-Element und eine weitere für die Country-Elemente.
Beim Auswerten von Zellen verwendet der Abfrageprozessor den Abfrageprozessorcache zum Speichern von Berechnungsergebnissen. Die entscheidenden Vorteile des Caches sind die Optimierung der Auswertung von Berechnungen und die Unterstützung der Wiederverwendung von Berechnungsergebnissen für mehrere Benutzer (mit denselben Sicherheitsrollen). Zur Optimierung der Cachewiederverwendung verwaltet der Abfrageprozessor drei Cacheebenen, die die Ebene der Cachewiederverwendbarkeit bestimmen: global, Sitzung und Abfrage.
9
2.3.1 Abfrageprozessorcache Beim Ausführen einer MDX-Abfrage speichert der Abfrageprozessor Berechnungsergebnisse im Abfrageprozessorcache. Die entscheidenden Vorteile des Caches sind die Optimierung der Auswertung von Berechnungen und die Unterstützung der Wiederverwendung von Berechnungsergebnissen für mehrere Benutzer. Ziehen Sie zur Verdeutlichung, wie der Abfrageprozessor das Zwischenspeichern bei der Ausführung der Abfrage verwendet, das folgende Beispiel in Betracht. Sie verfügen über ein berechnetes Element mit der Bezeichnung "Profit Margin". Wenn eine MDX-Abfrage "Profit Margin" nach "Sales Territory" anfordert, speichert der Abfrageprozessor die "Profit Margin"-Werte ungleich NULL für jedes Sales Territory zwischen. Zum Verwalten der Wiederverwendung der zwischengespeicherten Ergebnisse für mehrere Benutzer unterscheidet der Abfrageprozessor zwischen verschiedenen Kontexten im Cache:
Abfragekontext – enthält das Ergebnis von Berechnungen unter Verwendung des WITH-Schlüsselworts innerhalb einer Abfrage. Der Abfragekontext wird nach Bedarf erstellt und nach Abschluss der Abfrage beendet. Daher wird der Cache des Abfragekontexts nicht für mehrere Abfragen in einer Sitzung freigegeben.
Sitzungskontext – enthält das Ergebnis von Berechnungen unter Verwendung des CREATE-Schlüsselworts innerhalb einer bestimmten Sitzung. Der Cache des Sitzungskontexts wird zwischen Anforderungen in derselben Sitzung wiederverwendet, jedoch für mehrere Sitzungen freigegeben.
Globaler Kontext – enthält das Ergebnis von für Benutzer freigegebenen Berechnungen. Der Cache des globalen Kontexts kann für Sitzungen freigegeben werden, wenn für die Sitzungen dieselben Sicherheitsrollen gelten.
Die Kontextebenen richten sich nach der jeweiligen Ebene der Wiederverwendung. Auf der obersten Ebene kann der Abfragekontext nur innerhalb der Abfrage wiederverwendet werden. Auf der untersten Ebene hat der globale Kontext das größte Potenzial zur Wiederverwendung für mehrere Sitzungen und Benutzer.
Abbildung 3 Ebenen des Cachekontexts
Während der Ausführung muss jede MDX-Abfrage auf alle drei Kontexte verweisen, um alle potenziellen Berechnungen und Sicherheitsbedingungen zu identifizieren, die die Auswertung der Abfrage beeinflussen können. Zum Auflösen einer Abfrage, die ein von einer Abfrage berechnetes Element
10
enthält, erstellt der Abfrageprozessor z. B. einen Sitzungskontext zur Auswertung von Sitzungsberechnungen und einen globalen Kontext zur Auswertung des MDX-Skripts und zum Abrufen der Sicherheitsberechtigungen des Benutzers, der die Abfrage gesendet hat. Diese Kontexte werden nur dann erstellt, wenn dies noch nicht geschehen ist. Nach dem Erstellen werden sie nach Möglichkeit wiederverwendet.
Obwohl eine Abfrage auf alle drei Kontexte verweist, kann sie nur den Cache eines Kontexts verwenden. Dies bedeutet, dass der Abfrageprozessor für jede Abfrage den zu verwendenden Cache auswählen muss. Der Abfrageprozessor versucht immer, den umfassend anwendbaren Cache zu verwenden, je nachdem, ob er das Vorhandensein von Berechnungen bei einem engeren Kontext erkennt.
Stellt der Abfrageprozessor zur Abfragezeit erstellte Berechnungen fest, verwendet er immer den Abfragekontext, selbst wenn eine Abfrage auch auf Berechnungen aus dem globalen Kontext verweist (die Ausnahme sind Abfragen mit von einer Abfrage berechneten Elementen in der Form Aggregate(<set>), die den Sitzungscache gemeinsam nutzen). Sind keine Abfrageberechnungen, jedoch Sitzungsberechnungen vorhanden, verwendet der Abfrageprozessor den Sitzungscache. Der Abfrageprozessor wählt den Cache je nach Vorhandensein von Berechnungen im Bereich aus. Dieses Verhalten ist besonders für Benutzer mit MDX-generierenden Front-End-Tools relevant. Erstellt das Front-End-Tool Sitzungsberechnungen oder Abfrageberechnungen, wird der globale Cache nicht verwendet, auch wenn die Sitzungs- oder Abfrageberechnungen nicht ausdrücklich verwendet werden.
Es gibt weitere Berechnungsszenarien, die beeinflussen, wie der Abfrageprozessor Berechnungen zwischenspeichert. Beim Aufrufen einer gespeicherten Prozedur aus einer MDX-Berechnung verwendet das Modul immer den Abfragecache. Der Grund dafür ist, dass gespeicherte Prozeduren nicht deterministisch sind (dies bedeutet, dass nicht sichergestellt werden kann, was die gespeicherte Prozedur zurückgibt). Folglich wird nichts global oder im Sitzungscache zwischengespeichert. Die Berechnungen werden stattdessen im Abfragecache gespeichert. Darüber hinaus bestimmen die folgenden Szenarien, wie der Abfrageprozessor Berechnungsergebnisse zwischenspeichert:
• Die Verwendung von Zellensicherheit, eine der Funktionen UserName, StToSet oder LookupCube im MDX-Skript oder in der Dimensions- oder Zellensicherheitsdefinition deaktivieren den globalen Cache (dies bedeutet, dass bereits ein Ausdruck, der diese Funktionen verwendet, das globale Zwischenspeichern für den gesamten Cube deaktiviert).
• Falls sichtbare Gesamtwerte für die Sitzung durch Festlegen der standardmäßigen MDX Visual Mode-Eigenschaft in der Analysis Services-Verbindungszeichenfolge auf 1 aktiviert sind, verwendet der Abfrageprozessor den Abfragecache für alle in dieser Sitzung ausgegebenen Abfragen.
• Wenn Sie sichtbare Gesamtwerte für eine Abfrage durch die VisualTotals-Funktion in MDX aktivieren, verwendet der Abfrageprozessor den Abfragecache.
11
• Bei Abfragen, die die untergeordnete SELECT-Syntax (SELECT FROM SELECT) verwenden oder auf einem Sitzungsteilcube (CREATE SUBCUBE) basieren, wird der Abfragecache bzw. Sitzungscache verwendet.
• Willkürliche Formen können den Abfragecache nur dann verwenden, wenn sie in einem untergeordneten SELECT-Ausdruck, in der WHERE-Klausel oder in einem berechneten Element verwendet werden. Eine willkürliche Form ist eine Menge, die nicht als Kreuzjoin von Elementen von derselben Ebene einer Attributhierarchie ausgedrückt werden kann. So ist z. B. {(Food, USA), (Drink, Canada)} eine willkürliche Menge, ebenso wie {customer.geography.USA, customer.geography.[British Columbia]}. Eine willkürliche Form auf der Abfrageachse schränkt die Verwendung eines Caches nicht ein.
Auf der Grundlage dieses Verhaltens wird, wenn die Abfragearbeitsauslastung von der Wiederverwendung von Daten für mehrere Benutzer profitieren kann, das Definieren von Berechnungen im globalen Bereich empfohlen. Ein Beispiel für dieses Szenario ist eine strukturierte Berichtsarbeitsauslastung mit wenigen Sicherheitsrollen. Im Gegensatz dazu ist bei einer Arbeitsauslastung, die einzelne Datasets für jeden Benutzer erfordert, wie in einem HR-Cube mit vielen Sicherheitsrollen oder bei Verwendung dynamischer Sicherheit, die Gelegenheit zur Wiederverwendung von Berechnungsergebnissen für mehrere Benutzer reduziert oder ausgeschlossen. Folglich sind die Leistungsvorteile im Zusammenhang mit der Wiederverwendung des Abfrageprozessorcaches nicht so hoch.
Teilausdrücke (d. h. Teile einer Berechnung, die mehrmals im Ausdruck verwendet werden können) und Zelleigenschaften werden nicht zwischengespeichert. Erstellen Sie stattdessen ein separates berechnetes Element, damit der Abfrageprozessor zuerst ausgewertete Ergebnisse zwischenspeichern und die Ergebnisse für nachfolgende Verweise wiederverwenden kann. Weitere Informationen finden Sie unter Zwischenspeichern von Teilausdrücken und Zelleigenschaften.
2.3.2 AbfrageprozessorinternaEs gibt mehrere Änderungen an Abfrageprozessorinterna in SQL Server 2008 Analysis Services. In diesem Abschnitt werden diese Änderungen vor der Einführung spezifischer Optimierungstechniken erläutert.
2.3.2.1 TeilbereichberechnungDas Konzept der Teilbereichberechnung lässt sich am besten durch die Gegenüberstellung mit einer naiven oder zellenweisen Auswertung einer Berechnung erklären. Nehmen wir eine RollingSum für eine einfache Berechnung an, die den Umsatz für das Vorjahr und das laufende Jahr summiert, und eine Abfrage, die die RollingSum für 2005 für alle Produkte anfordert.
RollingSum = (Year.PrevMember, Sales) + Sales
SELECT 2005 on columns, Product.Members on rows WHERE RollingSum
12
Eine zellenweise Auswertung dieser Berechnung würde dann wie in Abbildung 4 dargestellt erfolgen.
Abbildung 4 Zellenweise Auswertung
Dabei werden die 10 Zellen für [2005, All Products] jeweils der Reihe nach ausgewertet. Für jede Zelle wird zum Vorjahr navigiert, der Umsatzwert abgerufen und zum Umsatz für das laufende Jahr hinzugefügt. Bei diesem Ansatz gibt es zwei wesentliche Leistungsprobleme.
Zum einen werden, wenn die Daten eine geringe Dichte besitzen (d. h., wenn sie dünn gefüllt sind), Zellen berechnet, obwohl sie einen NULL-Wert zurückgeben sollten. Im obigen Beispiel ist die Berechnung der Zellen außer für Product 3 und Product 6 überflüssig. Die Auswirkungen dessen können extrem sein – in einem dünn gefüllten Cube kann der Unterschied mehrere Größenordnungen bei der Anzahl ausgewerteter Zellen betragen.
Zum anderen ergibt sich ein hoher Mehraufwand, selbst wenn die Daten absolut dicht sind, d. h. jede Zelle einen Wert enthält und keine überflüssige Bearbeitung leerer Zellen stattfindet. Dieselben Schritte (z. B. Abrufen des Elements für das Vorjahr, Einrichten des neuen Kontexts für die Zelle des Vorjahrs und Prüfen auf Rekursion) werden für jedes Produkt neu ausgeführt. Es wäre viel effizienter, diese Schritte aus der inneren Schleife für die Auswertung jeder Zelle auszulagern.
Nehmen wir jetzt an, dasselbe Beispiel wäre mit Teilbereichberechnung ausgeführt worden. Zuerst nehmen wir an, dass in einer Ausführungsstruktur bestimmt wird, welche Stellen ausgefüllt werden müssen. Bei der entsprechenden Abfrage muss die Stelle
[Product.*, 2005, RollingSum]
berechnet werden (wobei * jedes Element der Attributhierarchie bedeutet). Bei der entsprechenden Berechnung bedeutet dies, dass zuerst die Stelle
13
[Product.*, 2004, Sales]
gefolgt von der Stelle
[Product.*, 2005, Sales]
berechnet werden und dann der +-Operator auf diese beiden Stellen angewendet werden muss.
Wenn "Sales" selbst von Berechnungen abgedeckt ist, werden die zum Berechnen von "Sales" erforderlichen Stellen bestimmt, und die Struktur wird erweitert. In diesem Fall ist "Sales" ein Basis-Measure, sodass wir einfach die Speichermoduldaten zum Füllen der beiden Stellen auf den Blättern abrufen und dann in der Struktur nach oben gehen. Dabei wird der Operator zum Füllen der Stelle am Stamm angewendet. Daher werden die eine Zeile (Product3, 2004, 3) und die beiden Zeilen { (Product3, 2005, 20), (Product6, 2005, 5)} abgerufen, und der +-Operator wird auf sie angewendet, um die Ergebnisse in Abbildung 5 zu erzielen.
Abbildung 5 Ausführungsplan
Der +-Operator wird für Stellen ausgeführt, nicht nur für Skalarwerte. Er ist für das Kombinieren der beiden angegebenen Stellen verantwortlich, um eine Stelle mit jedem Produkt zu erstellen, das an einer der beiden Stellen mit dem summierten Wert angezeigt wird. Dies ist der Abfrageausführungsplan. Wir arbeiten dabei immer nur mit Daten, die einen Beitrag zum Ergebnis leisten können. Es geht nicht um die theoretische Stelle, für die wir die Berechnung ausführen müssen.
Ein Abfrageausführungsplan kann sowohl Teilbereich- als auch zellenweise Knoten enthalten. Einige Funktionen werden im Teilbereichmodus nicht unterstützt, und das Modul greift dann auf den zellenweisen Modus zurück. Das Modul kann aber auch beim Auswerten eines Ausdrucks im zellenweisen Modus in den Teilbereichmodus zurückkehren.
14
2.3.2.2 Aufwändige und nicht aufwändige AbfragepläneDas Erstellen eines Abfrageplans kann aufwändig sein. Der Aufwand für das Erstellen eines Abfrageplans kann sogar den Aufwand für die Abfrageausführung übersteigen. Das Analysis Services-Modul verfügt über ein grobes Klassifizierungsschema – aufwändig im Vergleich zu nicht aufwändig. Ein Plan wird als aufwändig angesehen, wenn der zellenweise Modus verwendet wird oder Cubedaten zum Erstellen des Plans gelesen werden müssen. Andernfalls wird der Ausführungsplan als nicht aufwändig angesehen.
Cubedaten werden in Abfrageplänen in verschiedenen Szenarien verwendet. Einige Abfragepläne führen auf Grund von MDX-Funktionen wie PrevMember und Parent zur gegenseitigen Zuordnung von Elementen. Die Zuordnungen werden aus Cubedaten erstellt und während der Erstellung des Abfrageplans materialisiert. Die IIf-, CASE- und IF-Funktionen können auch aufwändige Abfragepläne generieren, falls Cubedaten zur Partitionierung von Cuberaum für die Auswertung einer Verzweigung gelesen werden müssen. Weitere Informationen finden Sie unter IIf-Funktion in SQL Server 2008 Analysis Services.
2.3.2.3 AusdrucksdichteDie Dichte eines Ausdrucks bezieht sich auf die Anzahl von Zellen mit Werten ungleich NULL im Vergleich zur Gesamtanzahl von Zellen. Wenn relativ wenige Werte ungleich NULL vorhanden sind, wird der Ausdruck als Ausdruck mit geringer Dichte bezeichnet. Bei vielen Werten weist der Ausdruck eine hohe Dichte auf. Wie wir weiter unten sehen, kann die Dichte eines Ausdrucks den Abfrageplan beeinflussen.
Wie lässt sich aber feststellen, ob ein Ausdruck eine hohe oder geringe Dichte aufweist? Nehmen wir ein einfaches nicht berechnetes Measure – hat es eine hohe oder geringe Dichte? In OLAP weisen Basisfakten-Measures eine geringe Dichte auf. Dies bedeutet, dass ein typisches Measure nicht über Werte für jedes Attributelement verfügt. Beispielsweise kauft ein Kunde nicht an den meisten Tagen die meisten Produkte von den meisten Geschäften. Vielmehr trifft das Gegenteil zu. Ein typischer Kunde kauft an einigen Tagen einen kleinen Prozentsatz aller Produkte von einer kleinen Anzahl von Geschäften. Weiter unten sind weitere einfache Regeln für häufig verwendete Ausdrücke aufgeführt.
Ausdruck Geringe/hohe DichteReguläres Measure Geringe DichteKonstanter Wert Hohe Dichte (ausgenommen konstante NULL-Werte, Werte
TRUE/FALSE)Skalarer Ausdruck, z. B. count, .properties
Hohe Dichte
<exp1>+<exp2><exp1>-<exp2>
Geringe Dichte, wenn sowohl exp1 als auch exp2 eine geringe Dichte aufweisen; andernfalls hohe Dichte
<exp1>*<exp2> Geringe Dichte, wenn entweder exp1 oder exp2 eine geringe Dichte aufweisen; andernfalls hohe Dichte
<exp1> / <exp2> Geringe Dichte, wenn <exp1> eine geringe Dichte aufweist; andernfalls hohe Dichte
Sum(<set>, <exp>) Von <exp> geerbt
15
Aggregate(<set>, <exp>)
IIf(<cond>, <exp1>, <exp2>) Wird durch die Dichte der Standardverzweigung bestimmt (siehe IIf)
2.3.2.4 StandardwerteJeder Ausdruck besitzt einen Standardwert – den Wert, den der Ausdruck in den meisten Fällen annimmt. Der Abfrageprozessor berechnet den Standardwert eines Ausdrucks und verwendet diesen an den meisten Stellen wieder. In den meisten Fällen ist dies NULL (leer oder ohne Eintrag in der Microsoft Excel®-Tabellenkalkulationssoftware), da häufig (jedoch nicht immer) das Ergebnis eines Ausdrucks mit NULL-Eingabewerten NULL ist. Das Modul kann dann das NULL-Ergebnis einmal berechnen und muss nur Werte für die stark reduzierte Stelle ungleich NULL berechnen.
Außerdem werden die Standardwerte in der Bedingung in der IIf-Funktion verwendet. Der Ausführungsplan hängt häufig davon ab, welche Verzweigung ausgewertet wird. Die Standardwerte häufig verwendeter Ausdrücke werden in der folgenden Tabelle aufgelistet.
Ausdruck Standardwert KommentarReguläres Measure NULL Keine. IsEmpty(<regular measure>) TRUE Die meisten theoretischen Stellen werden von
NULL-Werten belegt. Daher gibt IsEmpty meist TRUE zurück.
<regular measure A> = <regular measure B>
TRUE Werte für beide Measures sind prinzipiell NULL, dies wird somit in den meisten Fällen zu TRUE ausgewertet.
<member A> IS <member B> FALSE Dies unterscheidet sich vom Vergleichen von Werten – das Modul geht davon aus, dass in den meisten Fällen unterschiedliche Elemente verglichen werden.
2.3.2.5 Veränderliche AttributeZellenwerte hängen meistens von Attributkoordinaten ab. Bestimmte Berechnungen hängen jedoch nicht von jedem Attribut ab. Beispielsweise hängt der Ausdruck
[Customer].[Customer Geography].properties("Postal Code")
nur vom Customer-Attribut in der Customer-Dimension ab. Wenn dieser Ausdruck über einem Teilbereich mit anderen Attributen ausgewertet wird, können alle Attribute, von denen der Ausdruck nicht abhängt, entfernt, der Ausdruck aufgelöst und über den ursprünglichen Teilbereich zurück projiziert werden. Die Attribute, von denen ein Ausdruck abhängt, werden als seine veränderlichen Attribute bezeichnet. Betrachten Sie beispielsweise die folgende Abfrage:
16
with member measures.Zip as
[Customer].[Customer Geography].currentmember.properties("Postal Code")
select measures.zip on 0,
[Product].[Category].members on 1
from [Adventure Works]
where [Customer].[Customer Geography].[Customer].&[25818]
Der Ausdruck hängt vom Customer-Attribut und nicht vom Category-Attribut ab, daher ist "Customer" im Gegensatz zu "Category" ein veränderliches Attribut. In diesem Fall wird der Ausdruck nur einmal für den Kunden ausgewertet und nicht entsprechend der Anzahl von Produktkategorien.
2.3.2.6 Zusammenfassung zu AbfrageprozessorinternaAbfragepläne, Ausdrucksdichte, Standardwerte und veränderliche Attribute sind die wichtigsten internen Konzepte für das Abfrageprozessorverhalten – wir kehren zu diesen Konzepten zurück, wenn wir das Optimieren der Abfrageleistung erläutern.
2.4 DatenabrufBei der Abfrage eines Cubes zerlegt der Abfrageprozessor die Abfrage in Teilcubeanforderungen für das Speichermodul. Für jede Teilcubeanforderung versucht das Speichermodul zuerst, Daten vom Speichermodulcache abzurufen. Wenn im Cache keine Daten verfügbar sind, versucht das Modul, Daten von einer Aggregation abzurufen. Falls keine Aggregation vorhanden ist, müssen die Daten von den Faktendaten von Partitionen einer Measuregruppe abgerufen werden.
Jede Partition ist in Gruppen von Datensätzen mit 64 KB unterteilt, die als Segment bezeichnet werden.
Für jede Teilcubeanforderung wird ein Koordinatorauftrag erstellt. Die Anzahl der erstellten Aufträge entspricht der Anzahl der Partitionen. (Dies gilt dann, wenn die Abfrage Daten innerhalb des Partitionsslice anfordert. Weitere Informationen finden Sie unter Aufteilen von Partitionen in Slices.) Jeder dieser Aufträge:
Nimmt einen weiteren Auftrag für das nächste Segment in die Warteschlange auf (wenn das aktuelle Segment nicht das letzte Segment ist).
Verwendet die Bitmapindizes, um zu bestimmen, ob im Segment der Teilcubeanforderung entsprechende Daten vorhanden sind.
Scannt das Segment, wenn Daten vorhanden sind.
17
Bei einer einzelnen Partition sieht die Auftragsstruktur wie folgt aus, nachdem jeder Segmentauftrag in die Warteschlange aufgenommen wurde.
Unmittelbar nach dem Aufnehmen eines Segmentauftrags in die Warteschlange werden weitere Segmentaufträge gestartet. Dabei entspricht die Anzahl der Aufträge der Anzahl der Segmente. Wenn die Indizes anzeigen, dass im Segment keine dem Teilcube entsprechenden Daten enthalten sind, wird der Auftrag beendet.
3 Verbessern der AbfrageleistungZum Verbessern der Abfrageleistung muss zuerst eine Diagnose der aktuellen Situation und des Engpasses erstellt und dann eine der verschiedenen Techniken wie Optimieren des Dimensionsentwurfs, Entwerfen und Erstellen von Aggregationen, Partitionierung und Anwenden bewährter Methoden angewendet werden.
Dabei ist es wichtig, vor dem Anwenden bestimmter Techniken zuerst die Ursache des Problems zu erkennen, um zielgerichtet vorzugehen.
3.1 Basislinien für AbfragegeschwindigkeitenVor dem Beginn der Optimierung ist eine reproduzierbare Basislinie erforderlich. Nehmen Sie eine Messung für leere (nicht aufgefüllte) Speichermodul- und Abfrageprozessorcaches und einen vorbereiteten Betriebssystemcache vor. Führen Sie dazu wie folgt die Abfrage aus, leeren Sie den Formelcache und Speichermodulcache, und initialisieren Sie dann das Berechnungsskript durch Ausführen einer Abfrage, die nichts zurückgibt und zwischenspeichert.
select {} on 0 from [Adventure Works]
18
Abbildung 6 Auftragsstruktur beim Scannen der Partition
Führen Sie die Abfrage ein zweites Mal aus. Verwenden Sie bei der erneuten Ausführung der Abfrage SQL Server Profiler zur Ablaufverfolgung mit den aktivierten zusätzlichen Ereignissen:
Query Processing\Query Subcube Verbose Query Processing\Get Data From Aggregation
Die Ablaufverfolgung enthält wichtige Informationen.
Abbildung 6 Beispielablaufverfolgung
Der Text für das Query Subcube Verbose-Ereignis verdient eine Erklärung. Er enthält Informationen für jedes Attribut in jeder Dimension:
0: Zeigt an, dass das Attribut nicht in der Abfrage enthalten ist (das Alle-Element wird getroffen).
*: Zeigt an, dass jedes Element des Attributs angefordert wurde. +: Zeigt an, dass mindestens zwei Elemente des Attributs angefordert wurden. <ganzzahliger Wert>: Zeigt an, dass ein einzelnes Element des Attributs getroffen wurde. Die
ganze Zahl stellt die Daten-ID des Elements dar (einen vom Modul generierten internen Bezeichner).
Speichern Sie die Ablaufverfolgung, sie enthält wichtige Informationen zur zeitlichen Steuerung und zeigt weiter unten erläuterte Ereignisse an.
19
Verwenden Sie den ClearCache-Befehl, um den Speicher- und Abfrageprozessorcache zu leeren.
<ClearCache xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
<Object>
<DatabaseID>Adventure Works DW</DatabaseID>
</Object>
</ClearCache>
Der Betriebssystemdateicache wird von allen anderen Hardwareaktivitäten beeinflusst. Versuchen Sie daher, sonstige Aktivitäten zu reduzieren oder zu vermeiden. Dies kann besonders schwierig sein, wenn der Cube auf einem von anderen Anwendungen verwendeten SAN (Storage Area Network) gespeichert wird.
SQL Server Management Studio zeigt Abfragezeiten an, dabei ist jedoch einiges zu beachten. Diese Zeit ist die Zeitdauer für das Abrufen und Anzeigen des Cellsets. Bei umfangreichen Ergebnissen kann die Zeit zum Rendern des Cellsets der Zeit entsprechen, die der Server zum Generieren benötigt hat. Eine SQL Server Profiler-Ablaufverfolgung informiert nicht nur darüber, für was die Zeit aufgewendet wird, sondern auch über die genaue Moduldauer.
20
3.2 Diagnostizieren von AbfrageleistungsproblemenWenn die Leistung nicht Ihren Erwartungen entspricht, kann die Ursache in mehreren Bereichen liegen. In Abbildung 8 wird veranschaulicht, wie die Ursache des Problems diagnostiziert werden kann.
Abbildung 7 Flussdiagramm zur Optimierung der Abfrageleistung
21
Im ersten Schritt wird bestimmt, ob das Problem im Abfrageprozessor oder im Speichermodul liegt. Erstellen Sie mit SQL Server Profiler eine Ablaufverfolgung, um die Zeitdauer für das Scannen von Daten durch das Modul zu bestimmen. Schränken Sie die Ereignisse auf nicht zwischengespeicherte
Speichermodulabrufe durch ausschließliches Auswählen des Query Subcube Verbose-Ereignisses und Filtern nach Ereignisunterklasse=22 ein. Das Ergebnis ähnelt Abbildung 9.
Wird der Großteil der Zeit im Speichermodul für Abfrageteilcubeereignisse mit langer Ausführungsdauer aufgewendet, liegt wahrscheinlich ein Problem mit dem Speichermodul vor. Ziehen Sie Techniken wie das Optimieren des Dimensionsentwurfs, das Entwerfen von Aggregationen oder die Verwendung von Partitionen in Betracht, um die Abfrageleistung zu verbessern. Wenn der Großteil der Zeit nicht im Speichermodul, sondern im Abfrageprozessor aufgewendet wird, konzentrieren Sie sich auf das Optimieren von MDX.
Das Problem kann das Formelmodul und das Speichermodul betreffen. Fragmentierter Abfrageraum kann dort mit Profiler diagnostiziert werden, wo viele Abfrageteilcubeereignisse generiert werden. Die einzelnen Anforderungen dauert möglicherweise nicht lange, die Summe unter Umständen schon. Ziehen Sie in diesem Fall das Vorbereiten des Caches in Betracht, um die eventuell auftretende E/A-Überlastung zu reduzieren.
Bestimmte Probleme mit der Mehrbenutzerleistung können durch Behandeln von Einzelbenutzerabfragen gelöst werden, jedoch sicherlich nicht alle. Einige für Mehrbenutzerumgebungen benutzerdefinierte Konfigurationseinstellungen sind im Abschnitt Verbessern der Mehrbenutzerleistung beschrieben.
Wenn der Cube optimiert ist, kann die CPU- und Speicherressourcennutzung optimiert werden. Das Erhöhen der Anzahl von Threads für Einzel- und Mehrbenutzerszenarien wird im Abschnitt Erhöhen der Abfrageparallelität beschrieben. Dieselbe Technik kann zum Reservieren von Arbeitsspeicher für das Verbessern der Abfrage- und Verarbeitungsleistung verwendet werden und ist im Abschnitt zur Verarbeitung mit dem Titel Verwenden von PreAllocate enthalten.
Die Leistung kann im Allgemeinen durch Erweitern von CPU, Arbeitsspeicher oder E/A verbessert werden. Derartige Empfehlungen werden in diesem Dokument nicht behandelt. Es gibt andere verfügbare Techniken zum dezentralen Skalieren mit Clustern oder schreibgeschützten Datenbanken. Diese werden in folgenden Abschnitten nur kurz erläutert, um ihre Eignung zu bestimmen.
Das Überwachen der Speicherauslastung wird in einem separaten Abschnitt mit dem Titel Überwachen und Anpassen des Serverarbeitsspeichers erläutert.
22
Abbildung 8 Bestimmen der zum Scannen von Partitionen aufgewendeten Zeit
3.3 Optimieren von DimensionenEin optimierter Dimensionsentwurf ist einer der wichtigsten Erfolgsfaktoren für eine leistungsstarke Analysis Services-Lösung. Einer der ersten Schritte zur Verbesserung der Cubeleistung ist das schrittweise Durchlaufen der Dimensionen und Feststellen der Attributbeziehungen. Die beiden wichtigsten Techniken zum Optimieren des Dimensionsentwurfs für die Abfrageleistung sind:
Identifizieren von Attributbeziehungen
Effektive Verwendung von Benutzerhierarchien
3.3.1 Identifizieren von Attributbeziehungen Attributbeziehungen definieren funktionale Abhängigkeiten zwischen Attributen. Mit anderen Worten heißt das, wenn A ein verknüpftes Attribut B hat, geschrieben: A B, dann gibt es ein Element in B für jedes Element in A und viele Elemente in A für ein bestimmtes Element in B. Bei der Attributbeziehung City State muss z. B., wenn die aktuelle Stadt Seattle ist, der "State" Washington sein.
Häufig bestehen Beziehungen zwischen Attributen, die nicht unbedingt in der ursprünglichen Dimensionstabelle manifestiert sind, mit der das Analysis Services-Modul die Leistung optimieren kann. Standardmäßig sind alle Attribute mit dem Schlüssel verbunden, und das Attributbeziehungsdiagramm stellt einen "Busch" dar, in dem alle Beziehungen vom Schlüsselattribut abgehen und am jeweiligen Attribut enden.
Abbildung 9 Attributbeziehungen als Busch
23
Die Leistung kann durch das Festlegen von durch die Daten unterstützten Beziehungen optimiert werden. In diesem Fall identifiziert ein Modellname die Produktlinie und Unterkategorie, und die Unterkategorie identifiziert ein Kategorie (ein einzelne Unterkategorie ist also in nicht mehr als einer Kategorie vorhanden). Nach dem Neudefinieren der Beziehungen im Attributbeziehungs-Editor ergibt sich Folgendes.
Abbildung 10 Neu definierte Attributbeziehungen
Durch Attributbeziehungen wird die Leistung in zwei wichtigen Punkten verbessert:
Indizes werden erstellt, und Kreuzprodukte müssen nicht das Schlüsselattribut durchlaufen.
Auf Attributen basierende Aggregationen können für Abfragen für verknüpfte Attribute wiederverwendet werden.
Betrachten Sie das Kreuzprodukt zwischen Subcategory und Category in den beiden Abbildungen weiter oben. In der ersten Abbildung, in der keine Attributbeziehungen explizit definiert wurden, muss das Modul zuerst feststellen, welche Produkte in jeder Unterkategorie vorhanden sind, und dann bestimmen, zu welchen Kategorien das jeweilige Produkt gehört. Für Dimensionen mit nicht trivialer Größe kann dies zeitaufwändig sein. Bei definierter Attributbeziehung erkennt das Analysis Services-Modul über bei der Verarbeitung erstellte Indizes im Voraus, zu welcher Kategorie jede Unterkategorie gehört.
Betrachten Sie beim Definieren der Attributbeziehung den Beziehungstyp als flexibel oder fest. Bei einer flexiblen Attributbeziehung können die Elemente während Dimensionsaktualisierungen verschoben werden. Bei einer festen Attributbeziehung wird sichergestellt, dass die Elementbeziehungen fest sind. Beispielsweise ist die Beziehung zwischen "Month" und "Year" fest, da sich das Jahr für einen bestimmten Monat bei der erneuten Verarbeitung der Dimension nicht ändert. Die Beziehung zwischen "Customer" und "City" kann jedoch flexibel sein, da sich Kunden bewegen. (Dabei ist anzumerken, dass sich das Definieren einer Aggregation als flexibel oder fest nicht auf die Abfrageleistung auswirkt.)
24
3.3.2 Effektive Verwendung von HierarchienNur in Attributhierarchien verfügbar gemachte Attribute werden vom Aggregationsentwurfs-Assistenten nicht automatisch für die Aggregation berücksichtigt. Abfragen, die diese Attribute enthalten, werden durch das Zusammenfassen von Daten aus dem Primärschlüssel beantwortet. Ohne Aggregationen kann sich die Abfrageleistung für diese Attributhierarchien verlangsamen.
Zur Verbesserung der Leistung kann ein Attribut mit der Aggregation Usage-Eigenschaft als Aggregationskandidat markiert werden. Detailliertere Informationen zu dieser Technik finden Sie unter Vorschlagen von Aggregationskandidaten. Sie sollten jedoch vor dem Ändern der Aggregation Usage-Eigenschaft überlegen, ob Sie Benutzerhierarchien nutzen können.
Mithilfe von Analysis Services können Sie zwei Typen von Benutzerhierarchien, natürliche und unnatürliche Hierarchien, mit jeweils unterschiedlichem Entwurfs- und Leistungsmerkmalen erstellen.
In einer natürlichen Hierarchie verfügen alle als Ebenen an der Hierarchie beteiligten Attribute über direkte oder indirekte Attributbeziehungen von der untersten bis zur obersten Ebene der Hierarchie.
In einer unnatürlichen Hierarchie besteht die Hierarchie aus mindesten zwei aufeinander folgenden Ebenen ohne Attributbeziehungen. In der Regel werden mithilfe dieser Hierarchien Drilldownpfade häufig angezeigter Attribute erstellt, die keiner natürlichen Hierarchie folgen. So können Benutzer z. B. eine Hierarchie von "Gender" und "Education" anzeigen.
Abbildung 11 Natürliche und unnatürliche Hierarchien
In Bezug auf die Leistung verhalten sich natürliche Hierarchien ganz anders als unnatürliche Hierarchien. In natürlichen Hierarchien wird die Hierarchiestruktur in Hierarchiespeichern auf dem Datenträger materialisiert. Zudem werden alle an natürlichen Hierarchien beteiligten Attribute automatisch als Aggregationskandidaten betrachtet.
Unnatürliche Hierarchien werden nicht auf dem Datenträger materialisiert, und die an unnatürlichen Hierarchien beteiligten Attribute werden nicht automatisch als Aggregationskandidaten betrachtet. Stattdessen bieten sie Benutzern einfach zu verwendende Drilldownpfade für häufig angezeigte Attribute ohne natürliche Beziehungen. Durch das Zusammenstellen dieser Attribute in Hierarchien können Sie auch eine Vielzahl von MDX-Navigationsfunktionen verwenden, um Berechnungen wie Prozentsatz des übergeordneten Elements einfach auszuführen.
25
Definieren Sie für alle an der Hierarchie beteiligten Attribute kaskadierende Attributbeziehungen, um natürliche Hierarchien zu nutzen.
3.4 Maximieren des Werts von AggregationenEine Aggregation ist eine im Voraus berechnete Zusammenfassung von Daten, mit der Analysis Services die Abfrageleistung verbessert.
Das Entwerfen von Aggregationen ist der Vorgang, bei dem die effektivsten Aggregationen für die Abfragearbeitsauslastung ausgewählt werden. Beim Entwerfen von Aggregationen müssen Sie die Abfragevorteile von Aggregationen im Vergleich zum Zeitaufwand für das Erstellen und Aktualisieren der Aggregationen berücksichtigen. Durch das Hinzufügen nicht benötigter Aggregationen kann sich die Abfrageleistung sogar verschlechtern, da die Aggregation durch die seltenen Treffer in den Dateicache verschoben wird und gleichzeitig andere Elemente entfernt werden.
Während Aggregationen pro Measuregruppe-Partition physisch entworfen werden, gelten die Optimierungstechniken zum Maximieren des Aggregationsentwurfs unabhängig von der Anzahl der Partitionen. In diesem Abschnitt werden Aggregationen, wenn nicht anders angegeben, im grundlegenden Konzept eines Cubes mit einer Measuregruppe und einer Partition erläutert. Weitere Informationen dazu, wie die Abfrageleistung mithilfe mehrerer Partitionen verbessert werden kann, finden Sie unter Verbessern der Abfrageleistung mithilfe von Partitionen.
3.4.1 Ermitteln von AggregationstreffernZeigen Sie mithilfe von SQL Server Profiler an, wie und wann Aggregationen zum Beantworten von Anfragen verwendet werden. In SQL Server Profiler gibt es mehrere Ereignisse, die das Erfüllen einer Abfrage beschreiben. Das Ereignis, das sich speziell auf Aggregationstreffer bezieht, ist das Get Data From Aggregation-Ereignis.
Abbildung 12 Szenario 1: SQL Server Profiler-Ablaufverfolgung für Cube mit Aggregationstreffer
In Abbildung 13 wird eine SQL Server Profiler-Ablaufverfolgung der Auflösung der Abfrage für einen Cube mit Aggregationen dargestellt. In der SQL Server Profiler-Ablaufverfolgung werden die vom Speichermodul zum Produzieren des Resultsets ausgeführten Vorgänge angezeigt.
26
Das Speichermodul ruft Daten von Aggregation C 0000, 0001, 0000 ab, wie vom Get Data From Aggregation-Ereignis angegeben. Zusätzlich zum Aggregationsnamen, Aggregation C, wird in Abbildung 13 der Vektor 000, 0001, 0000 angezeigt, der den Inhalt der Aggregation beschreibt. Weitere Informationen zur Bedeutung dieses Vektors finden Sie im nächsten Abschnitt Interpretieren von Aggregationen.Die Aggregationsdaten werden in den Measuregruppencache des Speichermoduls geladen, wo sie vom Abfrageprozessor abgerufen werden, der das Resultset zum Client zurückgibt.In Abbildung 14 wird eine SQL Server Profiler-Ablaufverfolgung derselben Abfrage für denselben Cube dargestellt. Diesmal enthält der Cube jedoch keine Aggregationen, die die Abfrageanforderung erfüllen können.
Abbildung 14 Szenario 2: SQL Server Profiler-Ablaufverfolgung für Cube ohne Aggregationstreffer
Nach dem Übermitteln der Abfrage ruft das Speichermodul keine Daten aus einer Aggregation ab, sondern wechselt zu den Detaildaten in der Partition. Ab diesem Punkt ist der Vorgang gleich. Die Daten werden in den Measuregruppencache des Speichermoduls geladen.
3.4.2 Interpretieren von AggregationenBeim Erstellen einer Aggregation durch Analysis Services wird jede Dimension nach einem Vektor bekannt, der angibt, ob das Attribut auf die Attribut- oder auf die Alle-Ebene zeigt. Die Attributebene wird durch 1 und die Alle-Ebene wird durch 0 dargestellt. Betrachten Sie z. B. die folgenden Beispiele von Aggregationsvektoren für die Produktdimension:
Aggregation By ProductKey Attribute = [Product Key]:1 [Color]:0 [Subcategory]:0 [Category]:0 or 1000
Aggregation By Category Attribute = [Product Key]:0 [Color]:0 [Subcategory]:0 [Category]:1 or 0001
Aggregation By ProductKey.All and Color.All and Subcategory.All and Category.All = [Product Key]:0 [Color]:0 [Subcategory]:0 [Category]:0 or 0000
Zum Identifizieren jeder Aggregation kombiniert Analysis Services die Dimensionsvektoren in einem langen Vektorpfad, der auch als Teilcube bezeichnet wird, wobei die Dimensionsvektoren durch Kommas getrennt werden.
27
Die Reihenfolge der Dimensionen im Vektor wird durch die Reihenfolge der Dimensionen im Cube bestimmt. Verwenden Sie zum Feststellen der Reihenfolge der Dimensionen im Cube eine der beiden folgenden Techniken. Wenn der Cube in SQL Server Business Intelligence Development Studio geöffnet ist, können Sie auf der Registerkarte Cubestruktur die Reihenfolge von Dimensionen in einem Cube überprüfen. Die Reihenfolge von Dimensionen im Cube wird im Bereich "Dimensionen" angezeigt. Alternativ können Sie die Reihenfolge von in der XMLA-Definition des Cubes aufgeführten Dimensionen überprüfen.
Die Reihenfolge von Attributen im Vektor für jede Dimension wird durch die Reihenfolge von Attributen in der Dimension bestimmt. Die Reihenfolge von Attributen in jeder Dimension kann durch Überprüfen der XML-Datei der Dimension festgestellt werden.
Die folgende Subcubedefinition (0000, 0001, 0001) beschreibt beispielsweise eine Aggregation für Folgendes:
Product – All, All, All, All Customer – All, All, All, State/Province Order Date – All, All, All, Year
Beim Überprüfen von Aggregationstreffern in SQL Server Profiler ist es hilfreich, wenn Sie wissen, wie diese Vektoren gelesen werden. In SQL Server Profiler können Sie anzeigen, wie der Vektor durch Aktivieren des Query Subcube Verbose-Ereignisses bestimmten Dimensionsattributen zugeordnet wird.
3.4.3 Erstellen von AggregationenUm das erfolgreiche Anwenden des Aggregationsentwurfsalgorithmus durch Analysis Services zu unterstützen, können Sie die folgenden Optimierungstechniken zum Beeinflussen und Verbessern des Aggregationsentwurfs ausführen. (In den folgenden Abschnitten werden die jeweiligen Techniken genauer beschrieben.)
Vorschlagen von Aggregationskandidaten – Beim Entwerfen von Aggregationen in Analysis Services berücksichtigt der Aggregationsentwurfsalgorithmus nicht automatisch jedes Attribut für die Aggregation. Überprüfen Sie daher im Cubeentwurf die für die Aggregation berücksichtigten Attribute, und entscheiden Sie, ob zusätzliche Aggregationskandidaten vorgeschlagen werden müssen.
Angeben von Statistiken zu Cubedaten – Für sinnvolle Bewertungen von Aggregationskosten analysiert der Entwurfsalgorithmus für jeden Aggregationskandidaten Statistiken zum Cube. Beispiele für diese Metadaten sind die Anzahl von Elementen und Faktentabellen. Durch das Sicherstellen der Aktualität der Metadaten kann die Effizienz des Aggregationsentwurfs verbessert werden.
Verwendungsbasierte Optimierung – Führen Sie die Abfragen aus, und starten Sie den Assistenten für verwendungsbasierte Optimierung, um Aggregationen auf bestimmte Verwendungsmuster auszurichten.
28
3.4.3.1 Vorschlagen von AggregationskandidatenBeim Entwerfen von Aggregationen in Analysis Services berücksichtigt der Aggregationsentwurfsalgorithmus nicht automatisch jedes Attribut für die Aggregation. Zum Optimieren dieses Prozesses verwendet Analysis Services die Aggregation Usage-Eigenschaft, um die zu berücksichtigenden Attribute zu bestimmen. Überprüfen Sie für jede Measuregruppe die automatisch für die Aggregation berücksichtigten Attribute, und entscheiden Sie dann, ob zusätzliche Aggregationskandidaten vorgeschlagen werden müssen.
Aggregation Usage-RegelnEin Aggregationskandidat ist ein Attribut, das von Analysis Services für eine potenzielle Aggregation in Betracht gezogen wird. Um zu ermitteln, ob ein bestimmtes Attribut ein Aggregationskandidat ist, greift das Speichermodul auf den Wert der Aggregation Usage-Eigenschaft zurück. Der Aggregation Usage-Eigenschaft wird ein Attribut pro Cube zugewiesen, sie gilt daher global für alle Measuregruppen und Partitionen im Cube. Für jedes Attribut in einem Cube kann die Aggregation Usage-Eigenschaft einen von vier potenziellen Werten haben: Full, None, Unrestricted und Default.
Full – Jede Aggregation für den Cube muss dieses Attribut oder ein verknüpftes Attribut enthalten, das sich weiter unten in der Attributkette befindet. Nehmen wir als Beispiel eine Produktdimension mit der folgenden Kette verknüpfter Attribute an: Product, Product Subcategory und Product Category. Wenn Sie als Aggregation Usage für Product Category Full angeben, erstellt Analysis Services unter Umständen eine Aggregation, die Product Subcategory im Gegensatz zu Product Category enthält, falls Product Subcategory mit Category verknüpft ist und damit Gesamtwerte für Category abgeleitet werden können.
None – Keine Aggregation für den Cube darf dieses Attribut enthalten.
Unrestricted – Für den Aggregations-Designer gelten keine Einschränkungen, das Attribut muss aber dennoch ausgewertet werden, um festzustellen, ob es sich um einen wertvollen Aggregationskandidaten handelt.
Default – Der Designer wendet eine Standardregel basierend auf dem Typ des Attributs und der Dimension an. Dies ist der Standardwert der Aggregation Usage-Eigenschaft.
Die Standardregel legt fest, welche Attribute für die Aggregation berücksichtigt werden. Die Standardregel ist in vier Einschränkungen unterteilt.
Default Constraint 1 – Unrestricted: Für das Granularitätsattribut der Measuregruppe einer Dimension bedeutet der Standardwert Unrestricted. Das Granularitätsattribut entspricht dem Schlüsselattribut der Dimension, solange die Measuregruppe über das Primärschlüsselattribut mit einer Dimension verbunden ist.
Default Constraint 2 – None for Special Dimension Types: Für alle Attribute (außer Alle) in nicht materialisierten m:n-Bezugsdimensionen und Data Mining-Dimensionen bedeutet der Standardwert None.
29
Default Constraint 3 – Unrestricted for Natural Hierarchies: Eine natürliche Hierarchie ist eine Benutzerhierarchie, in der alle an der Hierarchie beteiligten Attribute Attributbeziehungen zu dem Attribut enthalten, das als Quelle für die nächste Ebene dient. Für solche Attribute bedeutet der Standardwert Unrestricted, außer für nicht aggregierbare Attribute, die auf Full festgelegt werden (selbst wenn sie sich nicht in einer Benutzerhierarchie befinden).
Default Constraint 4 – None For Everything Else. Für alle anderen Dimensionsattribute bedeutet der Standardwert None.
3.4.3.2 Beeinflussen von Aggregationskandidaten Beachten Sie angesichts des Verhaltens der Aggregation Usage-Eigenschaft die folgenden Richtlinien:
Nur als Attributhierarchien verfügbar gemachte Attribute – Wird ein bestimmtes Attribut nur als Attributhierarchie wie Color verfügbar gemacht, sollte die entsprechende Aggregation Usage-Eigenschaft wie folgt geändert werden.
Ändern Sie zuerst den Wert der Aggregation Usage-Eigenschaft von Default in Unrestricted, wenn das Attribute ein häufig verwendetes Attribut ist oder besondere Überlegungen zum Verbessern der Leistung in einem bestimmten Pivotvorgang oder Drilldown vorliegen. Bei zusammengefassten Berichten im Scorecardformat möchten Sie z. B. für Benutzer eine gute Antwortzeit für die erste Abfrage vor dem Drill zu weiteren Details sicherstellen.
Das Festlegen der Aggregation Usage-Eigenschaft einer bestimmten Attributhierarchie auf Unrestricted empfiehlt sich zwar in bestimmten Szenarien, allerdings sollten nicht alle Attributhierarchien auf Unrestricted festgelegt werden. Durch das Erhöhen der Anzahl der zu berücksichtigenden Attribute vergrößert sich auch der Problemraum, den der Aggregationsalgorithmus betrachten muss. Der Assistent braucht mindestens eine Stunde zum Abschließen des Entwurfs und bedeutend mehr Zeit zur Verarbeitung. Legen Sie die Eigenschaft nur für die am häufigsten abgefragten Attributhierarchien auf Unrestricted fest. Die allgemeine Regel sind fünf bis zehn Unrestricted-Attribute pro Dimension.
Ändern Sie dann den Wert der Aggregation Usage-Eigenschaft von Default zu Full in dem ungewöhnlichen Fall, dass sie in nahezu jeder Abfrage verwendet wird, die Sie optimieren möchten. Dieser Fall kommt jedoch selten vor, und die Änderung sollte nur für Attribute mit relativ wenigen Elementen vorgenommen werden.
Selten verwendete Attribute – Für an natürlichen Hierarchien beteiligten Attributen sollten Sie die Aggregation Usage-Eigenschaft von Default zu None ändern, wenn sie nur selten von Benutzern verwendet werden. Mit diesem Ansatz können Sie den Aggregationsspeicherplatz reduzieren und zu den fünf bis zehn Unrestricted-Attributen pro Dimension gelangen. Ein Beispiel sind bestimmte Attribute, die nur von einigen fortgeschrittenen Benutzer verwendet werden, die eine etwas verlangsamte Leistung akzeptieren würden. In diesem Szenario zwingen Sie im Prinzip den Aggregationsentwurfsalgorithmus dazu, nur Zeit für das Erstellen der Aggregationen aufzuwenden, die der Mehrheit der Benutzer die meisten Vorteile bieten.
30
Der Aggregationsentwurfsalgorithmus analysiert das Kosten-Nutzen-Verhältnis jeder auf Aggregationen basierten Anzahl von Elementen und von Faktentabellen-Datensätzen. Durch das Sicherstellen der Aktualität der Metadaten kann die Effizienz des Aggregationsentwurfs verbessert werden. Die Anzahl von Faktentabellen-Quelldatensätzen kann in der EstimatedRows-Eigenschaft jeder Measuregruppe und die Anzahl von Attributelementen kann in der EstimatedCount-Eigenschaft jedes Attributs definiert werden.
3.4.3.3 Verwendungsbasierte OptimierungDer Assistent für verwendungsbasierte Optimierung prüft die Abfragen im Abfrageprotokoll (das vorher eingerichtet werden muss) und entwirft Aggregationen, die die obersten 100 der langsamsten Abfragen abdecken. Verwenden Sie den Assistenten für verwendungsbasierte Optimierung mit einem Leistungsgewinn von 100 %, dadurch werden Aggregationen so entworfen, dass direkte Treffer der Partition vermieden werden.
Nachdem die Aggregationen entworfen wurden, können sie dem vorhandenen Entwurf hinzugefügt werden oder den Entwurf vollständig ersetzen. Achten Sie beim Hinzufügen zum vorhandenen Entwurf darauf, dass die beiden Entwürfe Aggregationen enthalten können, die nahezu identischen Zwecken dienen und beim Kombinieren miteinander redundant sind. Überprüfen Sie die neuen Aggregationen im Vergleich zu den alten und stellen Sie sicher, dass keine nahezu doppelten Aggregationen vorhanden sind. Der Aggregationsentwurf kann in SQL Server Management Studio oder Business Intelligence Design Studio auf andere Partitionen kopiert werden.
Aggregationsentwürfe haben hinsichtlich des Aufwands Auswirkungen auf Metadaten. Vermeiden Sie daher ein Übermaß an Entwürfen und versuchen Sie stattdessen, die Anzahl von Aggregationsentwürfen pro Measuregruppe auf ein Minimum zu beschränken.
3.4.3.4 Aggregationen und Parent-Child-HierarchienIn Parent-Child-Hierarchien werden Aggregationen nur für das Schlüsselattribut und das Attribut der obersten Ebene, d. h. das Alle-Attribut, erstellt, außer wenn es deaktiviert ist. Verwenden Sie möglichst keine Parent-Child-Hierarchien mit vielen Elementen. (Was sind viele Elemente? Es gibt keine bestimmte Anzahl, da die Abfrageleistung auf Zwischenebenen der Parent-Child-Hierarchie mit der Anzahl der Elemente linear abnimmt.) Schränken Sie darüber hinaus die Anzahl von Parent-Child-Hierarchien im Cube ein.
In einem Entwurfsszenario mit einer großen Parent-Child-Hierarchie sollten Sie das Quellschema ändern, um einen Teil oder die gesamte Hierarchie in eine reguläre Hierarchie mit einer festen Anzahl von Ebenen neu zu organisieren. Nach der Neuorganisation der Daten in die Benutzerhierarchie können Sie mit der Hide Member If-Eigenschaft jeder Ebene die redundanten oder fehlenden Elemente ausblenden.
31
3.5 Verbessern der Abfrageleistung mithilfe von PartitionenPartitionen unterteilen Measuregruppendaten in physische Einheiten. Durch die effiziente Verwendung von Partitionen werden die Abfrage- und Verarbeitungsleistung verbessert und die Datenverwaltung vereinfacht. In diesem Abschnitt wird speziell erläutert, wie die Abfrageleistung mithilfe der Partitionen verbessert werden kann. Betrachten Sie die Vor- und Nachteile von Abfrage- und Verarbeitungsleistung, bevor Sie die Partitionierungsstrategie festlegen.
3.5.1 EinführungMithilfe mehrerer Partitionen können Sie die Measuregruppe in separate physische Komponenten aufteilen. Die Vorteile der Partitionierung für eine verbesserte Abfrageleistung sind:
Aufteilen von Partitionen in Slices: Partitionen ohne Daten im Teilcube werden nicht abgefragt, wodurch die Kosten für das Lesen des Index vermieden werden (oder für das Scannen der Tabelle im ROLAP-Modus, in dem keine MOLAP-Indizes vorhanden sind).
Aggregationsentwurf: Jede Partition kann über einen eigenen oder freigegebenen Aggregationsentwurf verfügen. Folglich können häufiger oder unterschiedlich abgefragte Partitionen über eigene Entwürfe verfügen.
Abbildung 15 Intelligentes Abfragen nach PartitionenIn Abbildung 15 wird die Profiler-Ablaufverfolgung der Abfrage angezeigt, die Reseller Sales Amount nach Business Type von Adventure Works anfordert. Die Reseller Sales-Measuregruppe des Adventure Works-Cubes enthält vier Partitionen, eine für jedes Jahr. Da die Abfrage zu 2003 in Slices aufgeteilt ist, kann das Speichermodul direkt zur 2003 Reseller Sales-Partition wechseln und andere Partitionen ignorieren.
32
3.5.2 Aufteilen von Partitionen in SlicesPartitionen sind an eine Quelltabelle, Sicht oder Quellabfrage gebunden. Bei MOLAP-Partitionen identifiziert Analysis Services während der Verarbeitung intern den in jeder Partition enthaltenen Datenbereich mithilfe der Min und Max DataIDs jedes Attributs, um den in der Partition enthaltenen Datenbereich zu berechnen. Der Datenbereich für jedes Attribut wird dann kombiniert, um die Slicedefinition für die Partition zu erstellen. Mithilfe dieser Informationen kann das Speichermodul optimieren, welche Partitionen während der Abfrage gescannt werden, indem nur die für die Abfrage relevanten Partitionen ausgewählt werden. Bei ROLAP-Partitionen und Partitionen zum proaktiven Zwischenspeichern muss der Slice in den Eigenschaften der Partition manuell identifiziert werden.
Die Min und Max DataIDs können ein einzelnes Segment oder einen Bereich angeben. So ergibt z. B. die Partitionierung nach Jahr denselben Min und Max DataID-Slice für das Year-Attribut, und Abfragen zu einem bestimmten Zeitpunkt ergeben nur Partitionsabfragen an die Partition dieses Jahres.
Sie sollten stets bedenken, dass der Partitionsslice als Bereich von DataIDs beibehalten wird, den Sie nicht explizit steuern können. DataIDs werden während der Dimensionsverarbeitung zugewiesen, wenn neue Elemente gefunden werden. Bei einer falschen Reihenfolge in der Dimensionstabelle kann sich die interne Sequenz von DataIDs von Attributschlüsseln unterscheiden. Dies kann zu unnötigen Lesevorgängen in der Partition führen. Daher kann es ein Vorteil sein, den Slice für MOLAP-Partitionen selbst zu definieren. Wenn Sie z. B. nach Jahr partitionieren und einige Partitionen einen Bereich von Jahren enthalten, wird durch das Definieren des Slices das Problem überlappender DataIDs explizit vermieden.
Stellen Sie beim Verwenden mehrerer Partitionen für eine bestimmte Measuregruppe immer sicher, dass Sie die Datenstatistiken für jede Partition aktualisieren. Stellen Sie insbesondere sicher, dass die Partitionsdaten und die Anzahl der Elemente die spezifischen Daten in der Partition genau wiedergeben und nicht die Daten in der gesamten Measuregruppe.
Für Partitionen mit weniger Zeilen als IndexBuildThreshold (mit einem Standardwert von 4096) wird der Slice nicht definiert, und es werden keine Indizes erstellt.
3.5.3 Überlegungen zu Aggregationen für mehrere PartitionenBeachten Sie beim Definieren der Partitionen, dass diese keine einheitlichen Datasets oder Aggregationsentwürfe enthalten müssen. Für eine bestimmte Measuregruppe verfügen Sie z. B. über drei 3 Jahrespartitionen, 11 Monatspartitionen, 3 Wochenpartitionen und 1 bis 7 Tagespartitionen. Der Vorteil heterogener Partitionen mit verschiedenen Detailebenen besteht darin, dass Sie das Laden neuer Daten einfacher verwalten können, ohne vorhandene Partitionen zu beeinflussen (mehr dazu im Abschnitt zur Verarbeitung), und Aggregationen für Gruppen von Partitionen entwerfen können, die dieselbe Detailebene nutzen.
Für jede Partition kann ein unterschiedlicher Aggregationsentwurf verwendet werden. Mithilfe dieser Flexibilität können Sie die Datasets bestimmen, die einen höheren Aggregationsentwurf erfordern.
33
Betrachten Sie das folgende Beispiel. In einem Cube mit mehreren Monatspartitionen fließen neue Daten unter Umständen in eine einzelne Partition, die dem letzten Monat entspricht. Im Allgemeinen ist das auch die am häufigsten abgefragte Partition. Eine gängige Aggregationsstrategie ist in diesem Fall die Ausführung der verwendungsbasierten Optimierung für die aktuellste Partition, wobei ältere, weniger häufig abgefragte Partitionen unverändert bleiben.
Außerdem kann der neueste Aggregationsentwurf zu einer Basispartition kopiert werden. Diese Basispartition enthält keine Daten, sondern nur den aktuellen Aggregationsentwurf. Wenn eine neue Partition hinzugefügt werden soll, z. B. am Beginn eines neuen Monats, kann die Basispartition zu einer neuen Partition geklont werden. Wenn der Slice für die neue Partition festgelegt wurde, kann sie Daten als die aktuelle Partition entgegennehmen. Nach der ersten vollständigen Verarbeitung kann die aktuelle Partition für den restlichen Zeitraum inkrementell aktualisiert werden.
3.5.4 Distinct Count-PartitionsentwurfBei Distinct Count-Partitionen sind einige Besonderheiten zu beachten. Beim Abfragen von Distinct Count-Partitionen müssen die Segmentaufträge jeder Partition miteinander koordiniert werden, um Zählungsduplikate zu vermeiden. Beispielsweise müssen beim Zählen unterschiedlicher Kunden mit Kunden-ID und gleicher Kunden-ID in mehreren Partitionen die Aufträge der Partitionen die Übereinstimmung erkennen, um denselben Kunden nicht mehrmals zu zählen.
Enthält jede Partition einen nicht überlappenden Wertebereich, wird diese Koordination zwischen Aufträgen vermieden, und die Abfrageleistung kann sich um 20 % bis 300 % verbessern!
Weitere Informationen zu Optimierungen für Distinct Count finden Sie im Whitepaper "Analysis Services Distinct Count" unter folgendem Link: http://www.microsoft.com/downloads/details.aspx?FamilyID=65df6ebf-9d1c-405f-84b1-08f492af52dd&displaylang=en
3.5.5 Ändern der Größe von PartitionenFür Nicht-Distinct Count-Measuregruppen haben Tests mit Partitionsgrößen zwischen 200 MB und 3 GB gezeigt, dass die Partitionsgröße alleine keine deutlichen Auswirkungen auf die Abfragegeschwindigkeit hat. Die Partitionierungsstrategie sollte auf den folgenden Faktoren basieren:
Erhöhung von Verarbeitungsgeschwindigkeit und -flexibilität
Erweiterung der Verwaltbarkeit beim Einfügen neuer Daten
Verbesserung der Abfrageleistung durch das Löschen von Partitionen
Unterstützung für unterschiedliche Aggregationsentwürfe
34
3.6 Optimieren von MDX Das Debuggen bei Problemen mit der Berechnungsleistung in einem Cube kann sich beim Vorliegen vieler Berechnungen schwierig gestalten. Versuchen Sie zuerst, die Auswirkungen des Problems einzugrenzen, und wenden Sie dann bewährte Methoden auf MDX an.
3.6.1 Diagnostizieren des ProblemsDas Diagnostizieren des Problems kann relativ einfach sein, wenn eine einfache Abfrage eine bestimmte Berechnung aufruft (in diesem Fall können Sie mit dem nächsten Abschnitt fortfahren). Bei Ausdrucksketten oder einer komplexen Abfrage dagegen kann die Suche nach dem Problem zeitaufwändig sein.
Versuchen Sie, die Abfrage auf den einfachsten Ausdruck zu reduzieren, der das Leistungsproblem reproduziert. Bei einigen Clientanwendungen kann die Abfrage selbst das Problem sein, sollte sie große Datenmengen verlangen, ein Pushdown zu unnötig niedrigen Granularitäten (unter Umgehung von Aggregationen) durchführen oder Abfrageberechnungen enthalten, die den globalen Cache und den Sitzungscache des Abfrageprozessors umgehen.
Wenn sich bestätigt, dass das Problem im Cube selbst vorliegt, müssen Sie alle Berechnungen aus dem Cube entfernen oder auskommentieren. Dazu gehören:
Benutzerdefinierte Elementformeln
Unäre Operatoren
MDX-Skripts (außer der Berechnungsanweisung, die beibehalten werden sollte)
Führen Sie die Abfrage erneut aus. Unter Umständen muss sie wegen fehlender Elemente geändert werden. Ändern Sie die Berechnungen, bis das Problem reproduziert wird.
3.6.2 Bewährte Methoden für BerechnungenDieser Abschnitt enthält eine Reihe bewährter Methoden, mit denen die beste Abfrageleistung für den Cube erzielt werden kann.
3.6.2.1 Zellenweiser Modus im Vergleich zum TeilbereichmodusDie mit dem Teilbereichmodus erzielte Leistung ist fast immer höher als die mit dem zellenweisen Modus erzielte Leistung. Weitere Informationen, einschließlich einer Liste von im Teilbereichmodus unterstützten Funktionen, finden Sie unter "Leistungsverbesserungen für MDX in SQL Server 2008 Analysis Services" in der SQL Server-Onlinedokumentation unter folgendem Link:
http://msdn.microsoft.com/de-de/library/bb934106(SQL.100).aspx
35
In der folgenden Tabelle werden die häufigsten Gründe für das Verlassen des Teilbereichmodus aufgelistet.
Feature oder Funktion KommentarFestlegen von Aliasen Verwenden Sie zum Ersetzen einen Mengenausdruck statt eines Alias.
Beispielsweise wird diese Abfrage im Teilbereichmodus ausgeführt:
with member measures.SubspaceMode as
sum([Product].[Category].[Category].members,[Measures].[Internet Sales Amount]
)select {measures.SubspaceMode,[Measures].[Internet Sales Amount]} on 0 ,[Customer].[Customer Geography].[Country].members on 1from [Adventure Works]cell properties value
aber fast dieselbe Abfrage, in der der Mengenausdruck durch einen Alias ersetzt wurde, wird im zellenweisen Modus ausgeführt:
with set y as [Product].[Category].[Category].membersmember measures.Naive as
sum(y,[Measures].[Internet Sales Amount]
)select{measures.Naive,[Measures].[Internet Sales Amount]} on 0 ,[Customer].[Customer Geography].[Country].members on 1from [Adventure Works]cell properties value
Spätes Binden in Funktionen:
LinkMember, StrToSet, StrToMember, StrToValue
Funktionen zum spätem Binden sind Funktionen, die vom Abfragekontext abhängig sind und nicht statisch ausgewertet werden können. Der folgende Code ist z. B. statisch gebunden:
with member measures.x as (strtomember("[Customer].[Customer Geography].[Country].&[Australia]"),[Measures].[Internet Sales Amount])
36
select measures.x on 0,
[Customer].[Customer Geography].[Country].members on 1 from [Adventure Works]
cell properties value
Eine Abfrage ist spät gebunden, wenn ein Argument nur im Kontext ausgewertet werden kann:
with member measures.x as (strtomember([Customer].[Customer Geography].currentmember.uniquename),[Measures].[Internet Sales Amount])
select measures.x on 0,
[Customer].[Customer Geography].[Country].members on 1 from [Adventure Works]
cell properties value Benutzerdefinierte gespeicherte Prozeduren
Häufig verwendete Microsoft Visual Basic® for Applications (VBA)- und Excel-Funktionen werden in MDX vom System unterstützt. Benutzerdefinierte gespeicherte Prozeduren werden im zellenweisen Modus ausgewertet.
LookupCube Häufig sind verknüpfte Measuregruppen eine geeignete Alternative.
3.6.2.2 IIf-Funktion in SQL Server 2008 Analysis Services Die IIf-Funktion von MDX ist ein häufig verwendeter Ausdruck, dessen Auswertung aufwändig sein kann. Das Modul optimiert die Leistung auf Grundlage einiger einfacher Kriterien. Die IIf-Funktion verwendet drei Argumente:
iif(<condition>, <then branch>, <else branch>)
Wenn die Bedingung TRUE ergibt, dann wird der Wert aus der THEN-Verzweigung verwendet; andernfalls wird der Ausdruck aus der ELSE-Verzweigung verwendet.
Beachten Sie den Begriff "verwendet" – eine oder beide Verzweigungen werden unter Umständen ausgewertet, auch wenn ihr Wert nicht verwendet wird. Es kann für das Modul weniger aufwändig sein, den Ausdruck im gesamten Bereich auszuwerten und bei Bedarf zu verwenden – dies wird als Eager-Plan bezeichnet –, als den Bereich in eine möglicherweise große Anzahl von Fragmenten aufzuteilen und nur bei Bedarf auszuwerten – dies wäre ein Strict-Plan.
Hinweis: Einer der häufigsten Fehler in MDX-Skripts ist die Verwendung von IIf, wenn die Bedingung von Zellenkoordinaten statt von Werten abhängig ist. Verwenden Sie Bereiche und Zuweisungen, wenn die Bedingung von Zellenkoordinaten abhängig ist. Danach wird die Bedingung nicht im gesamten Bereich ausgewertet, und das Modul wertet eine oder beide Verzweigungen nicht im gesamten Bereich aus. Zugegebenermaßen erzwingt die Verwendung von Zuweisungen in einigen Fällen eine schwer
37
verwaltbare Bereichsdefinierung und die Wiederholung von Zuweisungen, es lohnt sich jedoch immer, die beiden Methoden zu vergleichen.
Die erste Überlegung ist, ob der Abfrageplan aufwändig oder nicht aufwändig ist. Die meisten Abfragepläne mit IIf-Bedingung sind nicht aufwändig, bei komplexen geschachtelten Bedingungen mit mehreren IIf-Funktionen kann jedoch ein Wechsel zum zellenweisen Modus erfolgen.
Als nächste Überlegung stellt das Modul fest, welchen Wert die Bedingung am meisten verwendet. Dies hängt vom Standardwert der Bedingung ab. Wenn TRUE der Standardwert der Bedingung ist, dann ist die THEN-Verzweigung die Standardverzweigung – die Verzweigung, die im überwiegenden Teil des Teilbereichs ausgewertet wird. Mithilfe einiger einfacher Regeln zur Auswertung der Bedingung kann die Standardverzweigung bestimmt werden:
In Ausdrücken mit geringer Dichte sind die meisten Zellen leer. Der Standardwert der IsEmpty-Funktion für einen Ausdruck mit geringer Dichte ist TRUE.
Der Vergleich mit NULL für einen Ausdruck mit geringer Dichte ist TRUE.
Der Standardwert des IS-Operators ist FALSE.
Wenn die Bedingung nicht im Teilbereichmodus ausgewertet werden kann, ist keine Standardverzweigung vorhanden.
Einer der häufigsten Verwendungszwecke der IIf-Funktion besteht darin, zu überprüfen, ob der Nenner ungleich NULL ist:
iif([Measures].[Internet Sales Amount]=0, null, [Measures].[Internet Order Quantity]/[Measures].[Internet Sales Amount])
Es gibt keine Berechnung für "Internet Sales Amount", die Dichte ist daher gering. Folglich ist TRUE der Standardwert der Bedingung, und die Standardverzweigung ist die THEN-Verzweigung mit dem NULL-Ausdruck.
Die folgende Tabelle zeigt, wie jede Verzweigung einer IIf-Funktion ausgewertet wird.
Verzweigungs-Abfrageplan Verzweigung ist Standardverzweigung
Verzweigungs-Ausdrucksdichte
Auswertung
Aufwändig Nicht zutreffend Nicht zutreffend Strict
Nicht aufwändig TRUE Nicht zutreffend Eager
Nicht aufwändig FALSE Hohe Dichte Strict
Nicht aufwändig FALSE Geringe Dichte Eager
38
In SQL Server 2008 Analysis Services kann das Standardverhalten mit Abfragehinweisen außer Kraft gesetzt werden.
iif([<condition>, <then branch> [hint [Eager | Strict]], <else branch> [hint [Eager | Strict]]
)
Wann sollte das Standardverhalten überschrieben werden? Hier finden Sie die häufigsten Szenarien, in denen Sie das Standardverhalten überschreiben sollten:
Das Modul ermittelt, dass der Abfrageplan für die Bedingung aufwändig ist, und wertet jede Verzweigung im Strict-Modus aus.
Die Bedingung wird im zellenweisen Modus und jede Verzweigung im Eager-Modus ausgewertet.
Der Verzweigungsausdruck weist eine hohe Dichte auf, wird jedoch problemlos ausgewertet.
Betrachten Sie z. B. den einfachen Ausdruck weiter unten, der den Umkehrwert eines Measures verwendet.
with member
measures.x as
iif(
[Measures].[Internet Sales Amount]=0
, null
, (1/[Measures].[Internet Sales Amount]) )
select {[Measures].x} on 0,
[Customer].[Customer Geography].[Country].members *
[Product].[Product Categories].[Category].members on 1
from [Adventure Works]
cell properties value
39
Der Abfrageplan ist nicht aufwändig, die ELSE-Verzweigung ist nicht die Standardverzweigung und der Ausdruck weist eine hohe Dichte auf, er wird also im Strict-Modus ausgewertet. Dadurch wird das Modul gezwungen, den Raum zu materialisieren, in dem es ausgewertet wird. Dies wird in SQL Server Profiler mit ausgewählten Query Subcube Verbose-Ereignissen veranschaulicht, wie in Abbildung 16 dargestellt.
Abbildung 16 Standardmäßige IIf-Abfrageablaufverfolgung
Beachten Sie die Teilcubedefinition für die Product- und Customer-Dimension (Dimension 7 bzw. 8) mit dem '+'-Indikator für das Country-Attribut und das Category-Attribut. Dies bedeutet, dass mehrere, jedoch nicht alle Elemente eingeschlossen werden – der Abfrageprozessor hat festgestellt, welche Tupel die Bedingung erfüllen, den Speicherplatz partitioniert und wertet den Teil für diesen Speicherplatz aus.
Um die Partitionierung des Speicherplatzes durch den Abfrageplan zu verhindern, kann die Abfrage wie folgt geändert werden (fett angezeigt).
with member
measures.x as
iif(
[Measures].[Internet Sales Amount]=0
, null
, (1/[Measures].[Internet Sales Amount]) hint eager)
select {[Measures].x} on 0,
[Customer].[Customer Geography].[Country].members *
40
[Product].[Product Categories].[Category].members on 1
from [Adventure Works]
cell properties value
Abbildung 17 IIf-Ablaufverfolgung mit MDX-Abfragehinweisen
Jetzt sind dieselben Attribute mit einem '*'-Indikator markiert. Dies bedeutet, dass der Ausdruck über den gesamten Bereich statt über einen partitionierten Bereich ausgewertet wird.
3.6.2.3 Zwischenspeichern von Teilausdrücken und ZelleigenschaftenTeilausdrücke (Teile eines berechneten Elements oder einer Zuweisung) werden nicht zwischengespeichert. Wenn ein aufwändiger untergeordneter Ausdruck mehrmals verwendet wird, sollten Sie daher ein separates berechnetes Element erstellen, das der Abfrageprozessor zwischenspeichern und wiederverwenden kann. Betrachten Sie das folgende Beispiel.
this = iif(<expensive expression >= 0, 1/<complex expression>, null);
Die wiederholten Teilausdrücke können extrahiert und wie folgt durch ein ausgeblendetes berechnetes Element ersetzt werden.
create member currentcube.measures.MyPartialExpression as <expensive expression> , visible=0;
this = iif(measures.MyPartialExpression >= 0, 1/ measures.MyPartialExpression, null);
41
Nur die Wertzelleneigenschaft wird zwischengespeichert. Falls komplexe Zelleneigenschaften Elemente wie Blasen-Ausnahmefarben unterstützen müssen, sollten Sie ein separates berechnetes Measure erstellen; beispielsweise statt:
create member currentcube.measures.[Value] as <exp> , backgroundColor=<complex expression>;
das folgende:
create member currentcube.measures.MyCellPrope as <complex expression> , visible=0;
create member currentcube.measures.[Value] as <exp> , backgroundColor=<complex expression>;
3.6.2.4 Vermeiden des Imitierens von Modulfunktionen mit AusdrückenMehrere systemeigene Funktionen können mit MDX imitiert werden:
Unäre Operatoren
Berechnete Spalten in der Datenquellensicht (Data Source View, DSV)
Measureausdrücke
Semiadditive Measures
Sie können alle diese Funktionen in MDX-Skript reproduzieren (in bestimmten Fällen ist dies sogar erforderlich, da einige nur in der Enterprise-SKU unterstützt werden), dies beeinträchtigt jedoch häufig die Leistung.
Beispielsweise versuchen distributive unäre Operatoren (Operatoren, deren Elementreihenfolge nicht relevant ist, wie +, - und ~) im Allgemeinen doppelt so schnell, ihre Möglichkeiten mit Zuweisungen zu imitieren.
Es gibt seltene Ausnahmen. Beispielsweise lässt sich die Leistung nicht distributiver unärer Operatoren (Operatoren mit *, / oder numerischen Werten) mit MDX verbessern. Möglicherweise kennen Sie darüber hinaus spezifische Merkmale Ihrer Daten, um mithilfe einer Abkürzung die Leistung zu verbessern.
42
3.6.2.5 Entfernen veränderlicher Attribute in MengenausdrückenMengenausdrücke unterstützen keine veränderlichen Attribute. Dies wirkt sich auf alle Mengenfunktionen wie Filter, Aggregate, Avg und andere aus. Sie können dieses Problem umgehen, indem Sie invariante Attribute für ein einzelnes Element explizit überschreiben.
In dieser Berechnung werden z. B. für den Verkaufsdurchschnitt nur die Verkäufe im Wert von mehr als 100 Dollar berücksichtigt.
with member measures.AvgSales as
avg(
filter(
descendants([Customer].[Customer Geography].[All Customers],,leaves)
, [Measures].[Internet Sales Amount]>100
)
,[Measures].[Internet Sales Amount]
)
select measures.AvgSales on 0,
[Customer].[Customer Geography].[City].members on 1
from [Adventure Works]
Diese Berechnung dauert auf einem Laptop immerhin 2:29. Der Verkaufsdurchschnitt für alle Kunden überall hängt jedoch nicht von der aktuellen Stadt ab ("City" ist somit kein veränderliches Attribut). Wir können "City" als veränderliches Attribut durch Überschreiben für das Alle-Element wie folgt explizit entfernen.
with member measures.AvgSales as
avg(
filter(
descendants([Customer].[Customer Geography].[All Customers],,leaves)
, [Measures].[Internet Sales Amount]>100
43
)
,[Measures].[Internet Sales Amount]
)
member measures.AvgSalesWithOverWrite as (measures.AvgSales, root([Customer]))
select measures.AvgSalesWithOverWrite on 0,
[Customer].[Customer Geography].[City].members on 1
from [Adventure Works]
Dies dauert nicht einmal eine Sekunde – eine deutliche Änderung der Leistung.
3.6.2.6 Vermeiden der Zuweisung von Werten ungleich NULL zu andernfalls nicht leeren Zellen
Das Analysis Services-Modul entfernt leere Zeilen sehr effizient. Werden Berechnungen mit Werten ungleich NULL hinzugefügt, die NULL-Werte ersetzen, kann Analysis Services diese Zeilen nicht entfernen. Beispielsweise ersetzt diese Abfrage NULL-Werte durch den Bindestrich, und das nicht leere Schlüsselwort entfernt sie nicht.
with member measures.x as
iif( not isempty([Measures].[Internet Sales Amount]),[Measures].[Internet Sales Amount],"-")
select descendants([Date].[Calendar].[Calendar Year].&[2004] ) on 0,
non empty [Customer].[Customer Geography].[Customer].members on 1
from [Adventure Works]
where measures.x
non empty bezieht sich auf Zellenwerte und nicht auf formatierte Werte. In seltenen Fällen können NULL-Werte stattdessen mit der Formatzeichenfolge durch dasselbe Zeichen ersetzt werden, dabei werden leere Zeilen und Spalten in ungefähr der Hälfte der Zeit entfernt.
with member measures.x as
44
[Measures].[Internet Sales Amount], FORMAT_STRING = "#.00;(#.00);#.00;-"
select descendants([Date].[Calendar].[Calendar Year].&[2004] ) on 0,
non empty [Customer].[Customer Geography].[Customer].members on 1
from [Adventure Works]
where measures.x
Dies kann nur in seltenen Fällen verwendet werden, weil die Abfrage nicht gleichwertig ist – bei der zweiten Abfrage werden vollständig leere Zeilen entfernt. Wichtiger ist, dass weder Excel noch Reporting Services das vierte Argument in format_string unterstützen. Weitere Informationen zum Verwenden der format_string-Berechnungseigenschaft finden Sie unter "FORMAT_STRING Contents (MDX)" in der SQL Server-Onlinedokumentation unter folgendem Link:http://msdn.microsoft.com/de-de/library/ms146084.aspx
3.6.2.7 Vermeiden des Aufwands für das Berechnen formatierter WerteUnter bestimmten Umständen wiegen die Kosten für das Bestimmen der Formatzeichenfolge für einen Ausdruck die Kosten für den Wert selbst auf. Um festzustellen, ob dies für eine langsam ausgeführte Abfrage gilt, vergleichen Sie die Ausführungszeit mit und ohne die FORMATTED_VALUE-Zelleneigenschaft wie in der folgenden Abfrage.
select [Measures].[Internet Average Sales Amount] on 0 from [Adventure Works] cell properties value
Falls das Ergebnis ohne die Formatierung deutlich schneller ist, wenden Sie die Formatierung wie folgt direkt im Skript an.
scope([Measures].[Internet Average Sales Amount]);
FORMAT_STRING(this) = "currency";
end scope;
Führen Sie außerdem die Abfrage (mit angewendeter Formatierung) aus, um den Umfang eines Leistungsvorteils festzustellen.
45
3.6.2.8 Überlegungen zu geringer/hoher Dichte mit "expr1 * expr2"-Ausdrücken Platzieren Sie beim Schreiben von Ausdrücken als Produkte von zwei anderen Ausdrücken den Ausdruck mit der geringeren Dichte auf der linken Seite.
Betrachten Sie die folgenden beiden Abfragen, die über die Signatur einer Währungsumrechnung zum Anwenden des Wechselkurses an Blättern der Date-Dimension in Adventure Works verfügen. Der einzige Unterschied besteht im Austauschen der Reihenfolge der Ausdrücke im Produkt der Zellenberechnung. Die Ergebnisse sind gleich, die Verwendung von Internet Sales Amount mit geringerer Dichte führte jedoch zu Einsparungen von ungefähr 10 %. (Das ist in diesem Fall nicht viel, kann jedoch in anderen Fällen erheblich mehr sein. Die Einsparungen hängen von der relativen Dichte zwischen den beiden Ausdrücken ab, und die Leistungsvorteile können variieren).
Geringe Dichte zuerst
with cell CALCULATION x for '({[Measures].[Internet Sales Amount]},leaves([Date]))'
as
[Measures].[Internet Sales Amount] *
([Measures].[Average Rate],[Destination Currency].[Destination Currency].&[EURO])
select
non empty [Date].[Calendar].members on 0,
non empty [Product].[Product Categories].members on 1
from [Adventure Works]
where ([Measures].[Internet Sales Amount], [Customer].[Customer Geography].[State-Province].&[BC]&[CA])
Hohe Dichte zuerst
with cell CALCULATION x for '({[Measures].[Internet Sales Amount]},leaves([Date]))'
as
([Measures].[Average Rate],[Destination Currency].[Destination Currency].&[EURO])*
46
[Measures].[Internet Sales Amount]
select
non empty [Date].[Calendar].members on 0,
non empty [Product].[Product Categories].members on 1
from [Adventure Works]
where ([Measures].[Internet Sales Amount], [Customer].[Customer Geography].[State-Province].&[BC]&[CA])
3.6.2.9 Vergleichen von Objekten und WertenVerwenden Sie IS, um zu bestimmen, ob das aktuelle Element oder Tupel ein bestimmtes Objekt ist. Beispielsweise ist die folgende Abfrage nicht nur nicht leistungsfähig, sondern falsch. Sie erzwingt eine unnötige Zellenauswertung und vergleicht Werte statt Elemente.
[Customer].[Customer Geography].[Country].&[Australia] = [Customer].[Customer Geography].currentmember
Führen Sie darüber hinaus beim Ableiten, ob CurrentMember ein bestimmtes Element ist, keine zusätzlichen Schritte aus, indem Sie Intersect und Counting einschließen.
intersect({[Customer].[Customer Geography].[Country].&[Australia]}, [Customer].[Customer Geography].currentmember).count > 0
Führen Sie diese Abfrage aus.
[Customer].[Customer Geography].[Country].&[Australia] is [Customer].[Customer Geography].currentmember
47
3.6.2.10 Auswerten der MengenmitgliedschaftMit Intersect kann am besten bestimmt werden, ob sich ein Element oder Tupel in einer Menge befindet. Mit der Rank-Funktion wird der zusätzliche Vorgang zum Bestimmen der Position dieses Objekts in der Menge ausgeführt. Verwenden Sie diese Funktion nicht, wenn Sie sie nicht benötigen. Führen Sie beispielsweise statt
rank( [Customer].[Customer Geography].[Country].&[Australia],
<set expression> )>0
Folgendes aus
intersect({[Customer].[Customer Geography].[Country].&[Australia]}, <set> ).count > 0
3.6.2.11 Verschieben von Berechnungen zum relationalen ModulIn einigen Fällen können Berechnungen zum relationalen Modul verschoben und mit weitaus besserer Leistung als einfache Aggregate verarbeitet werden. Hier gibt es keine einzelne Lösung. Wenn jedoch Leistungsprobleme auftreten, sollten Sie überlegen, wie die Berechnung statt der Auswertung bei der Abfrage in der Quelldatenbank oder DSV aufgelöst und vorab gefüllt werden kann.
Statt z. B. Ausdrücke wie Sum(Customer.City.Members, cint(Customer.City.Currentmember.properties(“Population”))) zu schreiben, sollten Sie eine separate Measuregruppe für die Tabelle "City" mit einem Summenmeasure für die Spalte "Population" definieren.
Als zweites Beispiel können Sie das Produkt von revenue * Products Sold an Blättern berechnen und mit Berechnungen aggregieren. Bei der Berechnung dieses Ergebnisses in der Quelldatenbank oder in der DSV wird eine außerordentlich hohe Leistung erzielt.
3.6.2.12 NON_EMPTY_BEHAVIORIn einigen Fällen ist die Berechnung des Ergebnisses eines Ausdrucks aufwändig, selbst wenn wir basierend auf dem Wert eines Indikatortupels im Voraus wissen, dass es NULL ist. Die NONEMPTY_BEHAVIOR-Eigenschaft war in einigen Fällen für diese Art von Berechnungen hilfreich. Wenn die Auswertung dieser Eigenschaft NULL ergab, war der Ausdruck garantiert NULL und (in den meisten Fällen) umgekehrt.
Diese Eigenschaft erbrachte in früheren Versionen häufig erhebliche Leistungsverbesserungen. In SQL Server 2008 wird die Eigenschaft häufig ignoriert (da das Modul in vielen Fällen automatisch mit nicht
48
leeren Zellen umgeht) und kann in einigen Fällen zu einer verminderten Leistung führen. Entfernen Sie sie aus dem MDX -Skript und fügen Sie sie wieder hinzu, nachdem der Leistungstest eine Verbesserung ergibt.
Für Zuweisungen wird die Eigenschaft wie folgt verwendet.
this = <e1>;
Non_Empty_Behavior(this) = <e2>;
Für berechnete Elemente im MDX-Skript wird die Eigenschaft folgendermaßen verwendet.
create member currentcube.measures.x as <e1>, non_empty_behavior = <e2>
In SQL Server 2005 Analysis Services gab es komplexe Regeln für das Definieren der Eigenschaft, wenn sie vom Modul verwendet oder ignoriert wurde, und für die Verwendung durch das Modul. In SQL Server 2008 Analysis Services hat sich das Verhalten dieser Eigenschaft geändert:
Es ist weiterhin garantiert, dass, wenn NON_EMPTY_BEHAVIOR NULL ist, der Ausdruck auch NULL sein muss. (Falls dies nicht zutrifft, können immer noch falsche Abfrageergebnisse zurückgegeben werden.)
Der umgekehrte Fall gilt jedoch nicht unbedingt; d. h., der NON_EMPTY_BEHAVIOR-Ausdruck kann ein Ergebnis ungleich NULL zurückgeben, wenn der ursprüngliche Ausdruck NULL ist.
Das Modul ignoriert diese Eigenschaft in den meisten Fällen und leitet das Verhalten für nicht leere Elemente des Ausdrucks selbst ab.
Wird die Eigenschaft durch das Modul definiert und angewendet, dann ist sie semantisch gleichwertig (jedoch nicht gleichwertig hinsichtlich der Leistung) mit dem folgenden Ausdruck.
this = <e1> * iif(isempty(<e2>), null, 1)
Die NON_EMPTY_BEHAVIOR-Eigenschaft wird verwendet, wenn <e2> eine geringe Dichte und <e1> eine hohe Dichte aufweist oder <e1> im naiven zellenweisen Modus ausgewertet wird. Wenn diese Bedingungen nicht erfüllt werden und sowohl <e1> als auch <e2> eine geringe Dichte aufweisen (z. B. <e2> eine viel geringere Dichte als <e1> aufweist), kann eine verbesserte Leistung durch Erzwingen des Verhaltens wie folgt erzielt werden.
this = iif(isempty(<e2>), null, <e1>);
Die NON_EMPTY_BEHAVIOR-Eigenschaft kann als einfacher Tupelausdruck mit einfachen Elementnavigationsfunktionen wie .prevmember oder .parent oder als aufgelistete Menge ausgedrückt werden. Eine aufgelistete Menge ist gleichwertig mit NON_EMPTY_BEHAVIOR der resultierenden Summe.
49
3.7 CachevorbereitungBei Abfragen wird der Arbeitsspeicher in erster Linie zum Speichern zwischengespeicherter Ergebnisse im Speichermodul- und Abfrageprozessorcache verwendet. Zum Optimieren der Vorteile des Zwischenspeicherns können Sie häufig die Antwortzeiten für Abfragen durch das Vorabladen von Daten in einen oder beide Caches verbessern. Dies kann entweder durch vorheriges Ausführen einer oder mehrerer Abfragen oder mit der CREATE CACHE-Anweisung erreicht werden. Dieser Prozess wird als Cachevorbereitung bezeichnet.
Die beiden Mechanismen sind ähnlich, obwohl die CREATE CACHE-Anweisung den Vorteil hat, dass keine Zellenwerte zurückgegeben werden und sie im Allgemeinen schneller ausgeführt wird, da der Abfrageprozessor umgangen wird.
Die Ermittlung der Elemente für die Zwischenspeicherung kann schwierig sein. Ein Ansatz besteht darin, eine Ablaufverfolgung bei der Ausführung der Abfrage und der Überprüfung von Teilcubeereignissen auszuführen. Das Auffinden vieler Teilcubeanforderungen derselben Granularität zeigt an, dass der Abfrageprozessor viele Anforderungen für leicht unterschiedliche Daten ausführt. Als Ergebnis führt das Speichermodul viele kleine, aber zeitaufwändige E/A-Anforderungen aus, statt die Daten effizienter massenhaft abzurufen und dann Ergebnisse aus dem Cache zurückzugeben.
Zur Vorabausführung von Abfragen können Sie eine Anwendung erstellen, die eine Menge verallgemeinerter Abfragen ausführt, um typische Benutzeraktivitäten zur Beschleunigung des Prozesses zum Auffüllen des Caches zu simulieren. Wenn Sie z. B. feststellen, dass Benutzer Abfragen nach Monat und nach Produkt ausführen, können Sie eine Menge von Abfragen erstellen, die Daten nach Produkt und nach Monat anfordern. Wenn Sie diese Abfrage beim Starten von Analysis Services bzw. beim Verarbeiten der Measuregruppe oder einer ihrer Partitionen ausführen, wird der Abfrageergebniscache vorab mit Daten zum Auflösen dieser Abfragen geladen, bevor Benutzer diese Typen von Abfragen übermitteln. Durch diese Technik werden die Antwortzeiten von Analysis Services auf von dieser Menge von Abfragen erwartete Benutzerabfragen deutlich verbessert.
Zum Feststellen einer Menge verallgemeinerter Abfragen können Sie mit dem Analysis Services-Abfrageprotokoll die in der Regel durch Benutzerabfragen abgefragten Dimensionsattribute feststellen. Mit einer Anwendung wie einem Microsoft Excel-Makro oder einer Skriptdatei können Sie den Cache vorbereiten, wenn Sie einen Vorgang ausgeführt haben, der den Abfrageergebniscache leert. Diese Anwendung könnte z. B. am Ende des Cubeverarbeitungsschritts automatisch ausgeführt werden.
Beim Testen der Effektivität verschiedener Cachevorbereitungsabfragen sollten Sie den Abfrageergebniscache zwischen den einzelnen Tests leeren, um die Gültigkeit der Tests sicherzustellen.
Beachten Sie, dass die zwischengespeicherten Ergebnisse durch andere Abfrageergebnisse verschoben werden können. Möglicherweise müssen die Ergebnisse im Cache nach einem bestimmten Zeitplan aktualisiert werden. Beschränken Sie außerdem die Cachevorbereitung entsprechend der Kapazität im Arbeitsspeicher, um weitere Abfragen zwischenspeichern zu können.
50
Aggressives Scannen von DatenMöglicherweise werden bei der Auswertung eines Ausdrucks mehr Daten angefordert, als zum Bestimmen des Ergebnisses erforderlich sind.
Wenn Sie vermuten, dass mehr Daten als erforderlich abgerufen werden, können Sie mithilfe von SQL Server Profiler diagnostizieren, wie eine Abfrage für Teilcubeabfrageereignisse und Partitionsscans verarbeitet wird. Überprüfen Sie für Teilcubescans das Subcube Verbose-Ereignis und ob mehr Elemente als erforderlich vom Speichermodul abgerufen werden. Bei kleinen Cubes ist dies wahrscheinlich kein Problem. Bei größeren Cubes mit mehreren Partitionen kann dies die Abfrageleistung deutlich beeinträchtigen. Die folgende Abbildung veranschaulicht, wie ein einzelnes Abfrageteilcubeereignis zu Scans von Partitionen führt.
Es gibt dazu zwei Lösungsmöglichkeiten. Enthält ein Berechnungsausdruck eine willkürliche Form (diese
wird im Abschnitt zum Abfrageprozessorcache definiert), kann der Abfrageprozessor unter Umständen nicht feststellen, dass die Daten auf eine Partition beschränkt sind und Daten von allen Partitionen anfordern. Versuchen Sie, die willkürliche Form zu vermeiden.
In anderen Fällen ist der Abfrageprozessor beim Anfordern von Daten einfach übermäßig aggressiv. Bei kleinen Cubes spielt dies keine Rolle, bei sehr großen Cubes dagegen schon. Wenn Sie dieses Verhalten beobachten, wenden Sie sich an den Kundenservice und -support von Microsoft, um weitere Hinweise zu erhalten.
3.8 Verbessern der MehrbenutzerleistungIn vielen Fällen lässt sich eine schlechte Mehrbenutzerleistung auf eine schlechte Einzelbenutzerleistung zurückführen. Dies trifft jedoch nicht immer zu. In einigen Fällen nutzt Analysis Services beim Skalieren der Anzahl von Benutzern nicht alle Ressourcen auf dem Computer. Es gibt einige Optionen zur Steigerung der Leistung.
3.8.1 Erhöhen der AbfrageparallelitätBei Abfragen verwendet Analysis Services zum Verwalten von Clientverbindungen einen Überwachungsthread, um Anforderungen zu brokern und bei Bedarf neue Serververbindungen zu erstellen. Zum Erfüllen von Abfrageanforderungen verwaltet der Überwachungsthread Arbeitsthreads im Abfragethreadpool und Verarbeitungsthreadpool, weist bestimmten Anforderungen Arbeitsthreads zu, initiiert neue Arbeitsthreads, wenn in einem bestimmten Pool nicht genügend aktive Arbeitsthreads vorhanden sind, und beendet bei Bedarf im Leerlauf befindliche Arbeitsthreads.
Zum Erfüllen einer Abfrageanforderung werden die Threadpools wie folgt verwendet:
51
Abbildung 18 Aggressives Scannen von Partitionen
Arbeitsthreads vom Abfragepool überprüfen die Daten bzw. Berechnungscaches für alle zu einer Clientanforderung gehörenden Daten und/oder Berechnungen.
Gegebenenfalls werden Arbeitsthreads vom Verarbeitungspool zugeordnet, um Daten vom Datenträger abzurufen.
Nachdem Daten abgerufen wurden, speichern Arbeitsthreads vom Abfragepool die Ergebnisse im Abfragecache, um zukünftige Abfragen aufzulösen.
Arbeitsthreads vom Abfragepool führen erforderliche Berechnungen aus und verwenden einen Berechnungscache zum Speichern von Berechnungsergebnissen.
Je mehr Threads zum Beantworten von Anfragen verfügbar sind, desto mehr Abfragen können parallel ausgeführt werden. Dies ist besonders wichtig in Szenarien mit einer großen Anzahl von Benutzern, die Abfragen ausführen.
Threadpool\Query\MaxThreads legt die maximale Anzahl von Arbeitsthreads fest, die im Abfragethreadpool verwaltet werden. Der Standardwert dieser Eigenschaft ist entweder 10 oder 2x die Anzahl der Kerne (dies ist ein Unterschied zu SQL Server 2005, überprüfen Sie daher diesen Wert für aktualisierte Instanzen). Durch das Erhöhen von Threadpool\Query\MaxThreads wird die Leistung einer bestimmten Abfrage nicht erheblich gesteigert. Der Vorteil des Erhöhens dieser Eigenschaft besteht vielmehr darin, dass die Anzahl gleichzeitig verarbeitbarer Abfragen erhöht werden kann.
Da Abfragen auch das Abrufen von Daten von Partitionen umfassen, müssen Sie außerdem die im Verarbeitungspool verfügbare maximale Anzahl von Threads berücksichtigen, wie von der Threadpool\Process\MaxThreads-Eigenschaft angegeben. Standardmäßig ist der Wert dieser Eigenschaft 64 in SQL Server 2005. Dieser Wert hat sich in SQL Server 2008 in 64 oder 10x die Anzahl der Kerne geändert, je nachdem, welcher Wert größer ist (dies ist auch der gegenwärtig empfohlene Wert). Beachten Sie bei den Szenarien für das Ändern der Threadpool\Process\MaxThreads-Eigenschaft, dass sich Änderungen dieser Einstellung auf den Verarbeitungsthreadpool für Abfragen und für die Verarbeitung auswirken. Weitere Informationen dazu, wie sich diese Eigenschaft speziell auf Verarbeitungsvorgänge auswirkt, finden Sie unter Anpassen von Threadeinstellungen.
Während Änderungen der Threadpool\Process\MaxThreads-Eigenschaft und der Threadpool\Query\MaxThreads-Eigenschaft den Parallelitätseffekt bei Abfragen steigern kann, müssen auch die zusätzlichen Auswirkungen von CoordinatorExecutionMode berücksichtigt werden. Betrachten Sie das folgende Beispiel. Wenn Sie auf einem Server mit vier Prozessoren die Standardeinstellung von -4 für CoordinatorExecutionMode übernehmen, können für alle Servervorgänge insgesamt 16 Aufträge gleichzeitig ausgeführt werden. Werden also zehn Abfragen parallel ausgeführt und insgesamt 20 Aufträge benötigt, können jeweils immer nur 16 Aufträge gestartet werden (vorausgesetzt, dass zu dieser Zeit keine Verarbeitungsvorgänge ausgeführt werden). Beim Erreichen des Auftragsschwellenwertes warten nachfolgende Aufträge in einer Warteschlange, bis ein neuer Auftrag erstellt werden kann. Wenn die Anzahl der Aufträge der Engpass für den Vorgang ist, wird folglich durch Erhöhen der Anzahl von Threads nicht unbedingt die Gesamtleistung verbessert.
52
In der Praxis kann der Ausgleich von Aufträgen und Threads schwierig sein. Wenn der Parallelitätseffekt gesteigert werden soll, muss der größte Engpass für die Parallelität bewertet werden, z. B. die Anzahl gleichzeitiger Aufträge und/oder die Anzahl gleichzeitiger Threads oder beides. Um dies zu bestimmen, überprüfen Sie die folgenden Leistungsindikatoren:
Threads\Warteschlangenlänge für Aufträge im Abfragepool: Die Anzahl von Aufträgen in der Warteschlange des Abfragethreadpools. Ein Wert ungleich NULL bedeutet, dass die Anzahl von Abfrageaufträgen die Anzahl verfügbarer Abfragethreads überschritten hat. In diesem Szenario sollten Sie die Anzahl von Abfragethreads erhöhen. Ist jedoch die CPU-Auslastung bereits sehr hoch, führt eine erhöhte Anzahl von Threads nur zu Kontextwechseln und einer beeinträchtigten Leistung.
Threads\Ausgelastete Threads im Abfragepool: Die Anzahl ausgelasteter Threads im Abfragethreadpool.
Threads\Im Leerlauf befindliche Threads im Abfragepool: Die Anzahl im Leerlauf befindlicher Threads im Abfragethreadpool.
Weitere Informationen finden Sie unter http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/ssasqptb.mspx.
3.8.2 SpeicherheaptypDer Mehrbenutzerdurchsatz kann durch Verwendung des Windows-Heaps statt des Analysis Services-Heaps verbessert werden. Diese Steigerung beim Durchsatz kann zu geringen, aber messbaren Kosten bei Einzelbenutzerabfragen führen. Beim Mehrbenutzerdurchsatz wurden jedoch Verbesserungen um bis zu 100 % gemessen (dies bedeutet die Verwaltung doppelt so vieler Abfragen im selben Zeitraum). Die deutlichen Vorteile beim Mehrbenutzerdurchsatz wiegen in der Regel die Kosten bei der Einzelbenutzerleistung auf. Ändern Sie die folgenden Parameter, um den NTLFH-Heap-Manager anstelle des OLAP-Heap-Managers zu verwenden.
Einstellung Standardwert Mehrere BenutzerMemoryHeapType 1 2HeapTypeForObjects 1 0
3.8.3 Blockieren von Abfragen mit langer AusführungszeitIn Mehrbenutzerszenarien können Abfragen mit langer Ausführungszeit andere Abfragen ausschließen – sogar Abfragen mit kürzerer Ausführungszeit –, indem sie alle verfügbaren Threads beanspruchen. Außerdem können sie die Ausführung anderer Abfragen blockieren, bis die Abfrage mit längerer Ausführungszeit abgeschlossen wurde. Die Aggressivität, mit der jeder Koordinatorauftrag Abfragen verwendet, kann durch Ändern der Methode für die Aufnahme jedes Segmentauftrags in die Warteschlange reduziert werden. Wie unter Datenabruf erläutert, wird jeder Segmentauftrag sofort in die Warteschlange aufgenommen, bevor der vorherige Segmentauftrag das Scannen von Daten startet. Sie können dieses Verhalten ändern, um Segmentaufträge zu serialisieren, indem Sie die folgenden Einstellungen verwenden.
53
Einstellung Standardwert Nicht blockierende Einstellungen für mehrere Benutzer
CoordinatorQueryBalancingFactor -1 1CoordinatorQueryBoostPriorityLevel 3 0
Beachten Sie dabei, dass diese Einstellungen zwar das Blockieren von Abfragen mit kürzerer Ausführungszeit durch Abfragen mit längerer Ausführungszeit reduzieren oder beenden, jedoch auch den Gesamtdurchsatz verringern. Wenden Sie sich an den Kundenservice und -support von Microsoft, wenn nach dem Ändern dieser Einstellungen weiterhin blockierende Abfragen auftreten.
3.8.4 Netzwerklastenausgleich und schreibgeschützte DatenbankenObwohl sie über den Rahmen dieses Dokuments hinausgehen, können grundlegende Entwurfsänderungen zum Behandeln von Abfrageproblemen genutzt werden und werden hier kurz erläutert.
3.8.4.1 NetzwerklastenausgleichWenn die Prozessorauslastung in einem einzelnen System als Ergebnis einer Mehrbenutzerabfrage-Arbeitsauslastung der Leistungsengpass ist, kann mit einem Cluster von Analysis Services-Servern zum Verarbeiten von Abfrageanforderungen die Abfrageleistung verbessert werden. An Anforderungen kann ein Lastenausgleich über zwei Analysis Services-Server oder über eine größere Anzahl von Analysis Services-Servern vorgenommen werden, um eine große Anzahl gleichzeitiger Benutzer zu unterstützen (dies wird als Serverfarm bezeichnet). Bei Lastenausgleichsclustern nimmt die Leistung in der Regel linear zu. Sowohl Microsoft als auch Drittanbieter stellen Clusterlösungen bereit. Die Lastenausgleichslösung von Microsoft ist Netzwerklastenausgleich (Network Load Balancing, NLB), eine Funktion des Windows Server®-Betriebssystems. Mit NLB kann ein NLB-Cluster von Analysis Services-Servern erstellt werden, der im Mehrhostmodus ausgeführt wird. Wenn ein NLB-Cluster von Analysis Services-Servern im Mehrhostmodus ausgeführt wird, wird an eingehenden Anforderungen ein Lastenausgleich zwischen Analysis Services-Servern ausgeführt. Beachten Sie bei der Verwendung eines Lastenausgleichsclusters, dass die Datencaches für jeden Server im Lastenausgleichscluster verschieden sind, was bei Abfragen durch denselben Client zu unterschiedlichen Abfrageantwortzeiten führt.
Mit einem Lastenausgleichscluster kann außerdem die Verfügbarkeit für den Fall sichergestellt werden, dass ein einzelner Analysis Services-Server ausfällt. Eine zusätzliche Optionen zum Steigern der Leistung mit einem Lastenausgleichscluster ist die Verteilung von Verarbeitungstasks an einen Offlineserver. Nach der Verarbeitung neuer Daten auf dem Offlineserver können die Analysis Services-Server im Lastenausgleichscluster mithilfe der Analysis Services-Datenbanksynchronisierung aktualisiert werden.
Wenn die Benutzer viele Abfragen übermitteln, die Faktendatenscans erfordern, kann ein Lastenausgleichscluster eine gute Lösung darstellen. Abfragen, die eine große Anzahl von Faktendatenscans erfordern können, umfassen z. B. umfangreiche Abfragen (wie Anzahl erste Daten oder Mediane) und Zufallsabfragen für sehr komplexe Cubes, bei denen die Wahrscheinlichkeit von Aggregationstreffern sehr gering ist.
54
Im Allgemeinen ist ein Lastenausgleichscluster zum Steigern der Analysis Services-Leistung jedoch nicht erforderlich, wenn die meisten Abfragen mit Aggregationen aufgelöst werden. Konzentrieren Sie sich also zuerst auf einen guten Aggregations- und Partitionierungsentwurf. Außerdem wird das Leistungsproblem nicht durch einen Lastenausgleichscluster gelöst, wenn die Verarbeitung den Engpass darstellt oder wenn Sie versuchen, eine einzelne Abfrage von einem einzelnen Benutzer zu verbessern. Eine Einschränkung bei der Nutzung eines Lastenausgleichsclusters ist die Nichtverwendbarkeit des Rückschreibens, da für das Rückschreiben der Daten kein einzelner Server vorhanden ist.
3.8.4.2 Schreibgeschützte DatenbankenAls Neuigkeit in SQL Server 2008 kann eine Datenbank als schreibgeschützt markiert und von mehreren Instanzen von Analysis Services verwendet werden. Mehrere Instanzen von Analysis Services können also ein einzelnes Datenverzeichnis gemeinsam nutzen (das sich in der Regel in einem SAN befindet). Diese Option sollte berücksichtigt werden, wenn die Mehrbenutzerarbeitsauslastung für Speichermodulanforderungen niedrig, für den Abfrageprozessor jedoch hoch ist. Analysis Services unterstützt zwar mehrere Instanzen, die auf denselben Datenordner verweisen, die Verwaltung von Benutzersitzungen für diese Instanzen liegt jedoch bei der Anwendung.
4 Verstehen und Messen der VerarbeitungDie folgenden Abschnitte bieten eine Anleitung zum Optimieren der Verarbeitung von Cubes. Bei der Verarbeitung werden Daten aus einer oder mehreren Datenquellen in ein oder mehrere Analysis Services-Objekte geladen. Während OLAP-Systeme in der Regel nicht danach beurteilt werden, wie schnell sie Daten verarbeiten, wirkt sich die Verarbeitungsleistung darauf aus, wie schnell neue Daten für Abfragen verfügbar sind. Für jede Anwendung gelten zwar unterschiedliche Anforderungen für die Datenaktualisierung von monatlichen Aktualisierungen bis hin zu Datenaktualisierungen nahezu in Echtzeit, aber je höher die Verarbeitungsleistung ist, desto früher können Benutzer aktualisierte Daten abfragen.
Analysis Services stellt mehrere Verarbeitungsbefehle bereit, die eine genaue Steuerung der Datenladevorgänge und der Aktualisierungsfrequenz von Cubes ermöglichen.
4.1 Verarbeitungsauftrag (Übersicht)Zur Verwaltung von Verarbeitungsvorgängen verwendet Analysis Services zentral gesteuerte Aufträge. Ein Verarbeitungsauftrag ist eine von einer Verarbeitungsanforderung erzeugte generische Arbeitseinheit.
In Bezug auf die Architektur kann ein Auftrag in übergeordnete und untergeordnete Aufträge unterteilt werden. Für ein bestimmtes Objekt können je nach der Position des Objekts in der OLAP-Datenbankhierarchie mehrere Ebenen geschachtelter Aufträge vorhanden sein. Anzahl und Typ übergeordneter und untergeordneter Aufträge richten sich nach 1) dem zu verarbeitenden Objekt wie Dimension, Cube, Measuregruppe oder Partition und 2) dem angeforderten Verarbeitungsvorgang wie ProcessFull, ProcessUpdate oder ProcessIndexes.
55
Wenn Sie z. B. einen ProcessFull-Vorgang für eine Measuregruppe ausgeben, wird ein übergeordneter Auftrag für die Measuregruppe mit untergeordneten Aufträgen für jede Partition erstellt. Für jede Partition werden mehrere untergeordnete Aufträge erzeugt, um den ProcessFull-Vorgang für die Faktendaten und Aggregationen auszuführen. Darüber hinaus implementiert Analysis Services Abhängigkeiten zwischen Aufträgen. Beispielsweise sind Cubeaufträge von Dimensionsaufträgen abhängig.
Die wichtigsten Gelegenheiten zum Optimieren der Leistung betreffen die Verarbeitungsaufträge für die Kernverarbeitungsobjekte: Dimensionen und Partitionen. Beide haben einen eigenen Abschnitt in diesem Handbuch.
Zusätzliche Hintergrundinformationen zur Verarbeitung finden Sie im technischen Hinweis Analysis Services 2005 Processing Architecture.
4.2 Verarbeiten von BasislinienErstellen Sie zuerst eine Basislinie, um die Auswirkungen der Optimierungs- und Diagnoseprobleme zu bestimmen. Mithilfe der Basislinie können Sie die Ursachen von Problemen analysieren und die Optimierungsmaßnahmen entsprechend ausrichten.
In diesem Abschnitt wird beschrieben, wie die Basislinie eingerichtet wird.
4.2.1 Systemmonitor-AblaufverfolgungWindows-Leistungsindikatoren sind die wichtigsten Grundlagen der Leistungsoptimierung von Analysis Services. Richten Sie mit dem Tool perfmon eine Ablaufverfolgung mit diesen Leistungsindikatoren ein:
MSOLAP: Verarbeitung o Gelesene Zeilen/Sekunde
MSOLAP: Prozeduraggregationen o Geschriebene Temp-Datei-Bytes/Sekundeo Erstellte Zeilen/Sekundeo Aktuelle Partitionen
MSOLAP: Threadso Im Leerlauf befindliche Threads im Verarbeitungspoolo Warteschlangenlänge für Aufträge im Verarbeitungspoolo Ausgelastete Threads im Verarbeitungspool
MSSQL: Speicher-Managero Serverspeicher gesamto Zielserverspeicher
Prozess o Virtuelle Bytes – msmdsrv.exeo Arbeitsseiten – msmdsrv.exeo Private Bytes – msmdsrv.exeo % Prozessorzeit – msmdsrv.exe und sqlservr.exe
56
Logischer Datenträger: o Mittlere Sek./Übertragung – Alle Instanzen
Prozessor: o % Prozessorzeit – Gesamt
System:o Kontextwechsel/Sekunde
Konfigurieren Sie die Ablaufverfolgung so, dass die Daten in einer Datei gespeichert werden. Beim Optimieren der Verarbeitung reicht es aus, alle 15 Sekunden zu messen.
Messen Sie beim Optimieren diese Leistungsindikatoren nach jeder Änderung erneut, um festzustellen, ob Sie sich Ihrem Leistungsziel nähern. Beachten Sie auch die für die Verarbeitung benötigte Gesamtzeit. Die Verwendung und Interpretation der einzelnen Indikatoren werden in den nachfolgenden Abschnitten erläutert.
4.2.2 Profiler-AblaufverfolgungFühren Sie zum Optimieren der SQL-Abfragen, die einen Teil der Verarbeitung bilden, auch eine Ablaufverfolgung für die relationale Datenbank aus. Verwenden Sie dazu SQL Server Profiler, wenn SQL Server die relationale Datenbank ist. Wenn Sie nicht SQL Server verwenden, wenden Sie sich an den jeweiligen Datenbankhersteller, um Hilfe zum Optimieren der Datenbank zu erhalten. Nachfolgend wird angenommen, dass SQL Server als relationale Datenbank für Analysis Services verwendet wird.
Erfassen Sie in der SQL Server Profiler-Ablaufverfolgung auch folgende Ereignisse:
Performance/Showplan XML Statistics Profile TSQL/SQL:BatchCompleted
Schließen Sie die folgenden Ereignisspalten ein:
TextData Reads DatabaseName SPID Duration
Sie können die Vorlage Tuning verwenden und einfach die Spalte Reads und Showplan XML Statistics Profiles hinzufügen. Konfigurieren Sie die Ablaufverfolgung ähnlich wie die perfmon-Ablaufverfolgung so, dass sie zur späteren Analyse in einer Datei gespeichert wird.
Konfigurieren Sie die SQL Server Profiler-Ablaufverfolgung so, dass sie in einer Tabelle statt einer Datei protokolliert wird. Dadurch können die Ablaufverfolgungen später einfacher korreliert werden.
Die von diesen Ablaufverfolgungen erfassten Leistungsdaten werden im folgenden Abschnitt zum Optimieren der Verarbeitung verwendet.
57
4.3 Ermitteln der Vorgänge, bei denen Verarbeitungszeit aufgewendet wirdZum korrekten Ausrichten der Verarbeitungsoptimierung sollten Sie zuerst ermitteln, wo die Zeit aufgewendet wird: bei der Partitionsverarbeitung oder der Dimensionsverarbeitung. Da Dimensionen vor Partitionen verarbeitet werden, lässt sich einfach messen, wie viel Zeit für Dimensionen aufgewendet wird.
Unterscheiden Sie bei der Partitionsverarbeitung zwischen ProcessData und ProcessIndex – die jeweiligen Optimierungstechniken sind sehr verschieden. Wenn Sie die von uns empfohlene bewährte Methode befolgen, zuerst ProcessData gefolgt von ProcessIndex statt ProcessFull auszuführen, lässt sich die aufgewendete Zeit einfach ablesen.
Wenn Sie ProcessFull verwenden, statt eine Aufteilung in ProcessData und ProcessIndex vorzunehmen, erhalten Sie eine Vorstellung davon, wann jede Phase endet, indem Sie die folgenden Perfmon-Leistungsindikatoren beobachten:
Während ProcessData ist der Leistungsindikator MSOLAP:Verarbeitung – Gelesene Zeilen/Sekunde größer als NULL.
Während ProcessIndex ist der Leistungsindikator MSOLAP:Prozeduraggregationen – Erstellte Zeilen/Sekunde größer als NULL.
ProcessData kann weiter in die durch den SQL Server-Prozess aufgewendete Zeit und die durch den Analysis Services-Prozess aufgewendete Zeit aufgeteilt werden. Mithilfe der erfassten Prozess-Leistungsindikatoren können Sie ermitteln, wo die meiste CPU-Zeit aufgewendet wird.
5 Verbessern der Leistung der DimensionsverarbeitungDas Leistungsziel der Dimensionsverarbeitung ist die Aktualisierung von Dimensionsdaten mit einer effizienten Methode, die sich nicht negativ auf die Abfrageleistung abhängiger Partitionen auswirkt. Die folgenden Techniken zum Erreichen dieses Ziels werden in diesem Abschnitt erläutert:
Optimieren von SQL-Quellenabfragen Reduzieren des Aufwands für Attribute
Dieser Abschnitt enthält außerdem Informationen zur Dimensionsverarbeitungsarchitektur.
5.1 Grundlegendes zur DimensionsverarbeitungsarchitekturBei der Verarbeitung von MOLAP-Dimensionen werden Aufträge zum Extrahieren, Indizieren und permanenten Speichern von Daten in mehreren Dimensionsspeichern verwendet.
Zum Erstellen dieser Dimensionsspeicher verwendet das Speichermodul die in Abbildung 19 dargestellten Aufträge.
58
Abbildung 19 Aufträge zur Dimensionsverarbeitung
Erstellen von Attributspeichern
Für jedes Attribut in einer Dimension wird ein Auftrag instanziiert, um die Attributelemente zu extrahieren und in einem Attributspeicher permanent zu speichern. Der Attributspeicher besteht aus dem Schlüsselspeicher, Namensspeicher und Beziehungsspeicher.
Da der Beziehungsspeicher Informationen zu abhängigen Attributen enthält, ist das Sortieren der Verarbeitungsaufträge erforderlich. Zum Bereitstellen des richtigen Workflows analysiert das Speichermodul die Abhängigkeiten zwischen Attributen und erstellt dann eine Ausführungsstruktur mit der richtigen Sortierung. Mithilfe der Ausführungsstruktur wird dann die beste parallele Ausführung der Dimensionsverarbeitung festgelegt.
Abbildung 20 stellt eine Beispielausführungsstruktur für eine Time-Dimension dar. Die durchgezogenen Pfeile stellen die Attributbeziehungen in der Dimension dar. Die gestrichelten Pfeile stellen die implizite Beziehung jedes Attributs zum Alle-Attribut dar.
Hinweis: Die Dimension wurde mit kaskadierenden Attributbeziehungen konfiguriert, eine bewährte Methode für alle Dimensionsentwürfe.
59
Abbildung 20 Beispiel einer Ausführungsstruktur
In diesem Beispiel wird das Alle-Attribut zuerst verarbeitet, falls keine Abhängigkeiten zu einem anderen Attribut bestehen, gefolgt vom Fiscal Year-Attribut und Calendar Year-Attribut, die parallel verarbeitet werden können. Die weiteren Attribute folgen entsprechend der Abhängigkeiten in der Ausführungsstruktur. Dabei wird das Primärschlüsselattribut immer zuletzt verarbeitet, da es immer über mindestens eine Attributbeziehung verfügt, außer wenn es das einzige Attribut in der Dimension ist.
Die zur Verarbeitung eines Attributs aufgewendete Zeit hängt in der Regel von 1) der Anzahl von Elementen und 2) der Anzahl von Attributbeziehungen ab. Die Anzahl von Elementen für ein bestimmtes Attribut lässt sich zwar nicht steuern, allerdings kann die Verarbeitungsleistung durch die Verwendung von kaskadierenden Attributbeziehungen verbessert werden. Dies ist besonders wichtig für das Schlüsselattribut, da es die meisten Elemente enthält und alle anderen Aufträge (Hierarchie, Decodieren, Bitmapindizes) auf seinen Abschluss warten. Attributbeziehungen senken die Speicheranforderung während der Verarbeitung. Bei der Verarbeitung eines Attributs müssen alle abhängigen Attribute im Arbeitsspeicher gespeichert werden. Ohne Attributbeziehungen müssten bei der Verarbeitung des Schlüsselattributs alle Attribute im Arbeitsspeicher gespeichert werden. Dies kann dazu führen, dass nicht genügend Speicherplatz vorhanden ist.
Weitere Informationen zur Bedeutung der Verwendung von kaskadierenden Attributbeziehungen finden Sie unter Identifizieren von Attributbeziehungen.
Erstellen von Decodierungsspeichern
Decodierungsspeicher werden vom Speichermodul intensiv verwendet. Bei Abfragen werden damit Daten von der Dimension abgerufen. Bei der Verarbeitung werden sie zum Erstellen der Bitmapindizes der Dimension verwendet.
60
Erstellen von Hierarchiespeichern
Ein Hierarchiespeicher ist eine permanente Darstellung der Baumstruktur. Für jede natürliche Hierarchie in der Dimension wird ein Auftrag zum Erstellen der Hierarchiespeicher instanziiert.
Erstellen von Bitmapindizes
Für die effiziente Suche nach Attributdaten im Beziehungsspeicher zur Abfragezeit erstellt das Speichermodul zur Berichtsverarbeitungszeit Bitmapindizes. Bei Attributen mit einer sehr großen Anzahl von Elementen kann die Verarbeitung der Bitmapindizes einige Zeit in Anspruch nehmen. In den meisten Szenarien bieten die Bitmapindizes bedeutende Vorteile bei Abfragen. Bei Attributen mit hoher Kardinalität wiegt dieser Vorteil jedoch unter Umständen den Verarbeitungsaufwand beim Erstellen des Bitmapindex nicht auf.
5.2 DimensionsverarbeitungsbefehleWenn Sie einen Verarbeitungsvorgang für eine Dimension ausführen müssen, geben Sie Dimensionsverarbeitungsbefehle aus. Jeder Verarbeitungsbefehl erstellt einen oder mehrere Aufträge zum Ausführen der erforderlichen Vorgänge.
In Bezug auf die Leistung sind die folgenden Dimensionsverarbeitungsbefehle die wichtigsten:
ProcessFull ProcessData ProcessIndexes ProcessUpdate ProcessAdd
Mit dem ProcessFull-Befehl wird der gesamte Speicherinhalt der Dimension gelöscht und neu erstellt. ProcessFull führt im Hintergrund alle Aufträge zur Dimensionsverarbeitung und einen impliziten ProcessClear-Auftrag für alle abhängigen Partitionen aus. Dies bedeutet, dass bei jeder Ausführung eines ProcessFull-Vorgangs für eine Dimension ein ProcessFull-Vorgang für abhängige Partitionen ausgeführt werden muss, um den Cube erneut online zu schalten.
Mit ProcessData wird der gesamte Speicherinhalt der Dimension gelöscht, und nur die Attribut- und Hierarchiespeicher werden neu erstellt. Außerdem werden Partitionen gelöscht. ProcessData ist die erste Komponente, die von einem ProcessFull-Vorgang ausgeführt wird.
ProcessIndexes erfordert, dass für eine Dimension bereits ein Attribut- und Hierarchiespeicher erstellt wurden. Die Daten in diesen Speichern werden beibehalten, anschließend werden die Bitmapindizes neu erstellt. ProcessIndexes ist die zweite Komponente des ProcessFull-Vorgangs.
Im Gegensatz zu ProcessFull löscht ProcessUpdate den Inhalt des Dimensionsspeichers nicht. Stattdessen wendet es Aktualisierungen intelligent an, um abhängige Partitionen beizubehalten. Insbesondere sendet ProcessUpdate SQL-Abfragen zum Lesen der vollständigen Dimensionstabelle und wendet dann Änderungen auf die Dimensionsspeicher an. ProcessUpdate kann Einfüge-, Update- und
61
Löschvorgänge verarbeiten, abhängig vom Typ der Attributbeziehungen (fest oder flexibel) in der Dimension. Beachten Sie, dass ProcessUpdate ungültige Aggregationen und Indizes löscht, sodass die Aggregationen neu erstellt werden müssen, um die Abfrageleistung zu verwalten. Flexible Aggregationen werden jedoch nur dann gelöscht, wenn eine Änderung festgestellt wird.
ProcessAdd optimiert ProcessUpdate in Szenarien, in denen nur neue Elemente eingefügt werden müssen. ProcessAdd löscht oder aktualisiert keine vorhandenen Elemente. Der Leistungsvorteil von ProcessAdd besteht darin, dass eine andere benannte Abfrage von Quelltabellen oder Datenquellensichten verwendet kann. Diese beschränkt die Zeilen der Quelldimensionstabelle, sodass nur die neuen Zeilen zurückgegeben werden. Dadurch ist es nicht notwendig, alle Quelldaten zu lesen. Darüber hinaus behält ProcessAdd auch alle Indizes und Aggregationen (flexible und feste) bei.
Hinweis: ProcessAdd steht nur als XMLA-Befehl zur Verfügung.
5.3 Flussdiagramm zur Optimierung der Dimensionsverarbeitung
62
Weitere Informationen zur SQL Server-Wartestatistik und zu ihrer Verfolgung finden Sie unter sys.dm_os_wait_stats in der SQL Server-Onlinedokumentation.
5.4 Bewährte Methoden für die Leistung der DimensionsverarbeitungEs gibt einige allgemeine und gute Entwurfsmethoden, die einfach zu implementieren sind und schnell Vorteile für die Leistung der Dimension bringen. Versuchen Sie, diese beim Entwerfen von Dimensionen in die bewährten Methoden einzubinden.
In SQL Server 2008 Analysis Services werden die Analysis Management Objects (AMO)-Warnungen von Business Intelligence Development Studio bereitgestellt, um das Entwerfen bewährter Methoden zu unterstützen.
5.4.1 Verwenden von SQL-Sichten zum Implementieren der Abfragebindung für Dimensionen
Die Abfragebindung für Dimensionen ist zwar in SQL Server 2008 Analysis Services nicht vorhanden, kann jedoch durch die Verwendung einer Sicht (anstelle von Tabellen) für die zugrunde liegende Dimensionsdatenquelle implementiert werden. Auf diese Weise können Sie Hinweise, indizierte Sichten und andere Optimierungstechniken relationaler Datenbanken zum Optimieren der SQL-Anweisung verwenden, die über die Sicht auf die Dimensionstabellen zugreift.
Es ist in der Regel sinnvoll, das Unified Dimensional Model (UDM) auf der Grundlage von Datenbanksichten zu erstellen. Sie können somit nicht nur die relationale Optimierung anwenden, sondern auch den NOLOCK-Hinweis in der Sichtdefinition verwenden. Dieser Hinweis entfernt den Sperrenaufwand aus der Datenbank, wodurch sich noch weitere Vorteile für die Leistung ergeben können.
Sichten erleichtern das Debuggen. SQL-Abfragen können direkt an Sichten ausgeführt werden, um die relationalen Daten mit dem Cube zu vergleichen. Daher bieten Sichten eine gute Möglichkeit zum Kapseln von Geschäftslogik, die Sie normalerweise als Abfragebindung in das UDM implementieren würden. Obwohl die UDM-Syntax der SQL-Sichtsyntax ähnelt, können keine SQL-Anweisungen für das UDM ausgegeben werden.
5.4.2 Optimieren der Attributverarbeitung für mehrere DatenquellenStammt eine Dimension aus mehreren Datenquellen, ermöglicht die Verwendung von kaskadierenden Attributbeziehungen das Unterteilen von Attributen während der Verarbeitung entsprechend der Datenquelle. Stammen die Schlüssel-, Namens- und Attributbeziehungen eines Attributs aus derselben Datenbank, kann die SQL-Abfrage für dieses Attribut durch das Abfragen nur einer Datenbank optimiert werden. Ohne kaskadierende Attributbeziehungen wird die OPENROWSET-Funktion von SQL Server, die eine Methode für das Zugreifen auf Daten aus mehreren Quellen bereitstellt, zum Zusammenführen der Datenstreams verwendet. In diesem Fall wird die Verarbeitung für das Schlüsselattribut wegen des erforderlichen Zugriffs auf mehrere abgeleitete OPENROWSET-Tabellen extrem langsam ausgeführt.
63
Wenn möglich, führen Sie ETL aus, um alle für die Dimension erforderliche Daten in derselben SQL Server-Datenbank zu speichern. Dies ermöglicht Ihnen, die Abfrage mit dem relationalen Modul zu optimieren.
5.4.3 Reduzieren des Aufwands für AttributeJedes Attribut, das in eine Dimension eingebunden wirkt, beeinflusst die Cubegröße, die Dimensionsgröße, den Aggregationsentwurf und die Verarbeitungsleistung. Wenn Sie feststellen, dass ein Attribut nicht von Endbenutzern verwendet wird, sollten Sie dieses Attribut vollständig aus der Dimension löschen. Nach dem Entfernen überflüssiger Attribute können Sie eine Reihe von Techniken anwenden, um die Verarbeitung der übrigen Attribute zu optimieren.
5.4.4 Effektive Verwendung der Eigenschaften KeyColumns, ValueColumn und NameColumn
Wenn Sie einer Dimension ein neues Attribut hinzufügen, wird das Attribut mithilfe von drei Eigenschaften definiert. Die KeyColumns-Eigenschaft gibt ein oder mehrere Quellfelder an, die jede Instanz des Attributs eindeutig identifizieren.
Die NameColumn-Eigenschaft gibt das Quellfeld an, das Endbenutzern angezeigt wird. Wird für die NameColumn-Eigenschaft kein Wert angegeben, dann wird sie automatisch auf den Wert der KeyColumns-Eigenschaft festgelegt.
ValueColumn ermöglicht das Übermitteln weiterer Informationen zum Attribut und wird in der Regel für Berechnungen verwendet. Im Gegensatz zu Elementeigenschaften ist diese Eigenschaft eines Attributs stark typisiert und bietet in Berechnungen eine verbesserte Leistung. Auf den Inhalt dieser Eigenschaft kann über die MemberValue-Funktion von MDX zugegriffen werden.
Durch die Verwendung von ValueColumn und NameColumn sind keine überflüssigen Attribute mehr erforderlich. Dadurch wird die Gesamtzahl an Attributen im Entwurf reduziert, und der Entwurf wird effizienter.
Analysis Services ermöglicht das Abrufen der Eigenschaften KeyColumns, ValueColumn und NameColumn von verschiedenen Quellspalten. Dies ist nützlich beim Vorliegen einer einzelnen Entität wie eines Produkts, das durch zwei unterschiedliche Attribute identifiziert wird: einen Ersatzschlüssel und einen beschreibenden Produktnamen. Wenn Benutzer Daten nach Produkten in Slices aufteilen möchten, stellen sie möglicherweise fest, dass der Ersatzschlüssel nicht über Geschäftsrelevanz verfügt, und entscheiden sich stattdessen für die Verwendung des Produktnamens.
Die bewährte Methode besteht darin, ein numerisches Quellfeld der KeyColumns-Eigenschaft statt einer Zeichenfolgeneigenschaft zuzuweisen. Damit wird nicht nur die Verarbeitungszeit reduziert, sondern auch die Größe der Dimension. Dies gilt besonders für Attribute mit vielen Elementen, d. h. mehr als eine Million Elemente.
64
5.4.5 Bitmapindizes entfernenBei der Verarbeitung des Primärschlüsselattributs werden Bitmapindizes für jedes verknüpfte Attribut erstellt. Das Erstellen der Bitmapindizes für den Primärschlüssel kann zeitaufwändig sein, wenn dieser ein oder mehrere verknüpfte Attribute mit hoher Kardinalität enthält. Zur Abfragezeit sind die Bitmapindizes für diese Attribute beim Beschleunigen des Abrufvorgangs nicht sinnvoll, da das Speichermodul noch zahlreiche unterschiedliche Werte durchsuchen muss. Dies hat möglicherweise negative Auswirkungen auf die Abfrageantwortzeiten.
Beispielsweise identifiziert der Primärschlüssel der Customer-Dimension jeden Kunden eindeutig nach Kontonummer, Benutzer möchten für Daten jedoch möglicherweise auch eine Slice-and-Dice-Analyse nach der Sozialversicherungsnummer des Kunden durchführen. Jede Kundenkontonummer weist eine 1:1-Beziehung mit der Sozialversicherungsnummer eines Kunden auf. Um zu verhindern, dass Zeit für das Erstellen unnötiger Bitmapindizes für das Sozialversicherungsnummer-Attribut aufgewendet wird, können die entsprechenden Bitmapindizes durch Festlegen der AttributeHierarchyOptimizedState-Eigenschaft auf Not Optimized deaktiviert werden.
5.4.6 Deaktivieren der Attributhierarchie und Verwenden von Elementeigenschaften
Als Alternative zu Attributhierarchien bieten Elementeigenschaften einen anderen Mechanismus zum Verfügbarmachen von Dimensionsinformationen. Beim jeweiligen Attribut werden Elementeigenschaften automatisch für jede Attributbeziehung erstellt. Für das Primärschlüsselattribut bedeutet dies, dass jedes Attribut mit direkter Beziehung zum Primärschlüssel als Elementeigenschaft des Primärschlüsselattributs verfügbar ist.
Falls Sie nur auf ein Attribut als Elementeigenschaft zugreifen möchten, können Sie nach der Überprüfung der Gültigkeit der korrekten Beziehung die Hierarchie des Attributs deaktivieren, indem Sie die AttributeHierarchyEnabled-Eigenschaft auf False festlegen. In Bezug auf die Verarbeitung können durch Deaktivieren der Attributhierarchie die Leistung verbessert und die Cubegröße reduziert werden, da das Attribut nicht mehr indiziert oder aggregiert wird. Dies kann sich besonders bei Attributen mit hoher Kardinalität als hilfreich erweisen, die eine 1:1-Beziehung mit dem Primärschlüssel aufweisen. Für Attribute mit hoher Kardinalität wie Telefonnummern und Adressen ist in der Regel keine Slice-and-Dice-Analyse erforderlich. Durch das Deaktivieren der Hierarchien für diese Attribute und den Zugriff über Elementeigenschaften kann Verarbeitungszeit gespart und die Cubegröße reduziert werden.
Bei der Entscheidung über die Deaktivierung der Attributhierarchie müssen die Auswirkungen der Verwendung von Elementeigenschaften auf Abfragen und die Verarbeitung berücksichtigt werden. Elementeigenschaften können nicht auf die gleiche Weise wie Attributhierarchien und Benutzerhierarchien auf einer Abfrageachse in Business Intelligence Design Studio platziert werden. Zum Abfragen einer Elementeigenschaft müssen die Eigenschaften des Attributs abgefragt werden, das die Elementeigenschaft enthält.
65
Wenn Sie die dienstliche Telefonnummer für einen Kunden benötigen, müssen Sie z. B. die Eigenschaften des Kunden abfragen und dann die Telefonnummer-Eigenschaft anfordern. Aus Gründen der Benutzerfreundlichkeit stellen die meisten Front-End-Tools Elementeigenschaften problemlos in der Benutzeroberfläche dar.
Im Allgemeinen ist das Abfragen von Elementeigenschaften langsamer als das Abfragen von Attributhierarchien, da Elementeigenschaften nicht indiziert und nicht an Aggregationen beteiligt sind. Die tatsächlichen Auswirkungen auf die Abfrageleistung hängen von der Verwendungsweise des Attributs ab.
Falls Benutzer z. B. für Daten auch eine Slice-and-Dice-Analyse nach Kontonummer und Kontobeschreibung durchführen möchten, kann es in Bezug auf die Abfrage vorteilhafter sein, wenn bei Problemen mit der Verarbeitungsleistung die Attributhierarchien vorhanden sind und die Bitmapindizes entfernt werden.
5.5 Optimieren der relationalen DimensionsverarbeitungsabfrageIm Gegensatz zu Faktenpartitionen, die nur eine Abfrage an den Server senden, senden Verarbeitungsvorgänge für Dimensionen mehrere Abfragen. Dimensionen sind in der Regel kleine, komplexe Tabellen mit sehr wenigen Änderungen im Vergleich zu Fakten. Tabellen mit solchen Merkmalen können häufig vielfach indiziert mit geringem Einfügungs-/Aktualisierungsverwaltungsaufwand für das System sein. Sie können dies bei der Verarbeitung zu Ihrem Vorteil nutzen und die relationalen Indizes großzügig verwenden.
Die einfachste Methode zum Optimieren der für die Dimensionsverarbeitung verwendeten relationalen Abfragen ist die Verwendung des Datenbankoptimierungsratgebers für eine Profiler-Ablaufverfolgung der Dimensionsverarbeitung. Bei den kleinen Dimensionstabellen müssen Sie möglicherweise nur jeden vorgeschlagenen Index hinzufügen. Richten Sie bei den größeren Tabellen die Indizes auf die am längsten ausgeführten Abfragen aus.
6 Verbessern der Leistung der PartitionsverarbeitungDas Leistungsziel der Partitionsverarbeitung ist die Aktualisierung von Faktendaten und Aggregationen mit einer effizienten Methode, die die allgemeinen Anforderungen für die Datenaktualisierung erfüllt. Die folgenden Techniken zum Erreichen dieses Ziels werden in diesem Abschnitt erläutert: Optimieren von SQL-Quellenabfragen, Verwenden von mehreren Partitionen, Abstimmung von E/A, Optimieren von Netzwerkgeschwindigkeiten und Abstimmung von Thread- und Parallelitätseinstellungen.
66
6.1 Grundlegendes zur PartitionsverarbeitungsarchitekturWährend der Verarbeitung von Partitionen werden Quelldaten mit den in Abbildung 21 dargestellten Aufträge extrahiert und auf einem Datenträger gespeichert.
Abbildung 21 Aufträge zur Partitionsverarbeitung
Verarbeiten von Faktendaten
Faktendaten werden mit drei gleichzeitigen Threads verarbeitet, die die folgenden Aufgaben ausführen:
Senden von SQL-Anweisungen zum Extrahieren von Daten aus Datenquellen Suchen von Dimensionsschlüsseln in Dimensionsspeichern und Füllen des Verarbeitungspuffers Schreiben des Puffers auf den Datenträger, wenn der Verarbeitungspuffer voll ist
Erstellen von Aggregationen und Bitmapindizes
Aggregationen werden bei der Verarbeitung im Arbeitsspeicher erstellt. Während zu wenige Aggregationen kaum Einfluss auf die Abfrageleistung haben, kann sich bei übermäßig vielen Aggregationen die Verarbeitungszeit ohne zusätzlichen Vorteil für die Abfrageleistung erhöhen.
Falls Aggregationen nicht in den Arbeitsspeicher passen, werden Segmente in temporäre Dateien geschrieben und am Ende des Vorgangs zusammengeführt. Bitmapindizes werden ebenfalls in dieser Phase erstellt und segmentweise auf den Datenträger geschrieben.
6.2 PartitionsverarbeitungsbefehleWenn Sie einen Verarbeitungsvorgang für eine Partition ausführen müssen, geben Sie Partitionsverarbeitungsbefehle aus. Jeder Verarbeitungsbefehl erstellt einen oder mehrere Aufträge zum Ausführen der erforderlichen Vorgänge.
Die folgenden Partitionsverarbeitungsbefehle sind verfügbar:
ProcessFull ProcessData ProcessIndexes ProcessAdd
67
ProcessClear ProcessClearIndex
ProcessFull löscht den Speicherinhalt der Partition und erstellt ihn neu. Im Hintergrund führt ProcessFull ProcessData-Aufträge und ProcessIndexes-Aufträge aus.
ProcessData löscht den Speicherinhalt des Objekts und erstellt nur die Faktendaten neu.
Für ProcessIndexes ist eine Partition mit bereits erstellten Daten erforderlich. ProcessIndexes behält die während ProcessData erstellten Daten bei und erstellt auf deren Grundlage neue Aggregationen und Bitmapindizes.
ProcessAdd erstellt intern eine temporäre Partition, verarbeitet sie mit den Zielfaktendaten und führt sie dann mit der vorhandenen Partition zusammen. Beachten Sie, dass ProcessAdd der Name des XMLA-Befehls ist, in Business Intelligence Development Studio und SQL Server Management Studio erfolgt die Bereitstellung als ProcessIncremental.
ProcessClear entfernt alle Daten aus der Partition. Beachten Sie, dass ProcessClear der Name des XMLA-Befehls ist. In Business Intelligence Development Studio und SQL Server Management Studio erfolgt die Bereitstellung als UnProcess.
ProcessClearIndexes entfernt alle Indizes und Aggregate aus der Partition. Damit werden die Partitionen in denselben Zustand versetzt, als wäre ProcessClear gefolgt von ProcessData gerade ausgeführt worden. Beachten Sie, dass ProcessClearIndexes der Name des XMLA-Befehls ist. Dieser Befehl steht in Business Intelligence Development Studio und SQL Server Management Studio nicht zur Verfügung.
6.3 Flussdiagramm zur Optimierung der PartitionsverarbeitungIm folgenden Flussdiagramm wird der Optimierungsprozess von ProcessData beschrieben.
68
Für ProcessIndexes gilt das nachfolgende Flussdiagramm.
69
6.4 Bewährte Methoden für die Leistung der PartitionsverarbeitungVerwenden Sie für den Entwurf der Faktentabellen die Anweisungen in den folgenden technischen Hinweisen:
Die zehn wichtigsten bewährten Methoden zur Erstellung eines großen skalierbaren relationalen Data Warehouse
Bewährte Methoden zur Verarbeitung in Analysis Services
70
6.4.1 Optimieren von Dateneinfügungen, Aktualisierungen und LöschungenDieser Abschnitt enthält Informationen zum effizienten Aktualisieren von Partitionsdaten für das Verarbeiten von Einfügungen, Aktualisierungen und Löschungen.
EinfügungenWenn in einem durchsuchbaren, verarbeiteten Cube einer vorhandenen Measuregruppe-Partition neue Daten hinzugefügt werden sollen, können Sie eine der folgenden Techniken anwenden:
ProcessFull – Führen Sie einen ProcessFull-Vorgang für die vorhandene Partition aus. Während des ProcessFull-Vorgangs bleibt der Cube für das Durchsuchen mit den vorhandenen Daten verfügbar, während eine separate Gruppe von Datendateien für die neuen Daten erstellt wird. Wenn die Verarbeitung abgeschlossen ist, stehen die neuen Partitionsdaten zum Durchsuchen zur Verfügung. Beachten Sie, dass ProcessFull technisch gesehen nicht erforderlich ist, falls Sie nur Einfügungen vornehmen. Zum Optimieren der Verarbeitung für Einfügevorgänge können Sie ProcessAdd verwenden.
ProcessAdd – Verwenden Sie diesen Vorgang zum Anhängen von Daten an die vorhandenen Partitionsdateien. Beim häufigen Ausführen von ProcessAdd wird empfohlen, in regelmäßigen Abständen ProcessFull auszuführen, um die Partitionsdatendateien neu zu erstellen und neu zu komprimieren. ProcessAdd erstellt intern eine temporäre Partition und führt diese zusammen. Dies führt im Laufe der Zeit zur Datenfragmentierung und zur Notwendigkeit, ProcessFull in regelmäßigen Abständen auszuführen.
Enthält die Measuregruppe mehrere Partitionen, wie im vorherigen Abschnitt beschrieben, besteht ein effektiverer Ansatz darin, eine neue Partition zu erstellen, die die neuen Daten enthält, und dann ProcessFull für diese Partition auszuführen. Mit dieser Methode können neue Daten ohne Auswirkungen auf die vorhandenen Partitionen hinzugefügt werden. Wenn die Verarbeitung für die neue Partition abgeschlossen ist, steht sie für Abfragen zur Verfügung.
AktualisierungenWenn Datenaktualisierungen ausgeführt werden müssen, können Sie ProcessFull ausführen. Dabei ist es natürlich sinnvoll, die Aktualisierungen auf eine bestimmte Partition auszurichten, damit nur eine einzelne Partition verarbeitet werden muss. Eine bessere Methode als die direkte Aktualisierung von Faktendaten ist die Verwendung eines Journal-Mechanismus zum Implementieren von Datenänderungen. In diesem Szenario wandeln Sie eine Aktualisierung in eine Einfügung um, die die vorhandenen Daten korrigiert. Mit dieser Methode können Sie einfach fortfahren, der Partition neue Daten mit ProcessAdd hinzuzufügen. Durch die Verwendung von Journalen verfügen Sie außerdem über einen Überwachungspfad der Änderungen der Faktentabelle.
LöschungenFür Löschungen bieten mehrere Partitionen einen hervorragenden Mechanismus zum Rollout abgelaufener Daten. Betrachten Sie das folgende Beispiel. Sie verfügbar zurzeit über 13 Monate Daten in einer Measuregruppe, 1 Monat pro Partition. Der älteste Monat soll aus dem Cube entfernt werden. Dazu löschen Sie einfach die Partition ohne Auswirkungen auf eine der anderen Partitionen.
71
Falls bestimmte alte Dimensionselemente nur im abgelaufenen Monat vorhanden waren, können Sie diese mit einem ProcessUpdate-Vorgang für die Dimension entfernen (jedoch nur, wenn sie flexible Beziehungen enthält). Zum Löschen von Elementen aus dem Schlüssel-/Granularitätsattribut einer Dimension muss die UnknownMember-Eigenschaft der Dimension auf Hidden festgelegt werden. Der Grund dafür ist, dass der Server nicht weiß, ob ein dem gelöschten Element zugewiesener Faktendatensatz vorhanden ist. Bei entsprechender Festlegung dieser Eigenschaft wird das Element bei der Abfrage ausgeblendet. Eine weitere Möglichkeit besteht darin, die Daten aus der zugrunde liegenden Tabelle zu entfernen und einen ProcessFull-Vorgang auszuführen. Dies kann jedoch mehr Zeit in Anspruch nehmen als ProcessUpdate.
Wenn die Größe der Dimension zunimmt, sollten Sie einen ProcessFull-Vorgang für die Dimension ausführen, um gelöschte Schlüssel vollständig zu entfernen. In diesem Fall müssen jedoch auch alle verknüpften Partitionen erneut verarbeitet werden. Dies erfordert möglicherweise ein großes Batchfenster und ist nicht für alle Szenarien geeignet.
6.4.2 Auswählen effizienter Datentypen in FaktentabellenWährend der Verarbeitung müssen Daten aus SQL Server in Analysis Services verschoben werden. Je größer die Zeilen sind, desto mehr Bandbreite ist zum Verschieben der Zeilen erforderlich.
Bestimmte Datentypen können vom Charakter ihres Entwurfs her schneller verwendet werden als andere. Verwenden Sie in Faktentabellen möglichst nur diese Datentypen, um die beste Leistung zu erzielen.
Faktenspaltentyp Schnellste SQL Server-DatentypenErsatzschlüssel tinyint, smallint, int, bigintDatumsschlüssel int im Format jjjjMMttMeasures mit ganzen Zahlen tinyint, smallint, int, bigint Numerische Measures smallmoney, money, real, float
(Beachten Sie, dass zum Verarbeiten der Typen decimal und vardecimal mehr CPU-Leistung erforderlich ist als für die Typen money und float.)
Distinct Count-Spalten tinyint, smallint, int, bigint (Wenn die Count-Spalte char ist, sollten Sie entweder Hashing oder das Ersetzen durch einen Ersatzschlüssel in Betracht ziehen.)
6.5 Optimieren der relationalen PartitionsverarbeitungsabfrageIn der ProcessData-Phase werden Zeilen aus einer relationalen Quelle und in Analysis Services gelesen. Analysis Services kann in dieser Phase Zeilen mit einer sehr hohen Rate verwenden. Zum Erreichen dieser hohen Geschwindigkeiten muss die relationale Datenbank so optimiert werden, dass ein geeigneter Durchsatz bereitgestellt wird.
72
Im nachfolgenden Unterabschnitt wird angenommen, dass SQL Server die relationale Quelle ist. Beim Verwenden einer anderen relationalen Quelle sind einige Hinweise weiterhin gültig. Wenden Sie sich jedoch an Ihren Datenbankexperten, um plattformspezifische Anweisungen zu erhalten.
Analysis Services verwendet die Partitionsinformationen zum Generieren der Abfrage. Falls Sie keine Abfragebindungen im UDM vorgenommen haben, ist die Ausgabe der SELECT-Anweisung an die relationale Quelle ganz einfach. Sie besteht aus:
SELECT für die zur Verarbeitung erforderlichen Spalten. Dies sind die Dimensionsspalten und die Measures.
Optional einem WHERE-Kriterium bei der Verwendung von Partitionen. Sie können dieses WHERE-Kriterium durch Ändern der Abfragebindung der Partition steuern.
6.5.1 Entfernen von JoinsFalls Sie eine Datenbanksicht oder eine benannte UDM-Abfrage als Basis von Partitionen verwenden, sollten Sie Joins in dieser Abfrage entfernen. Denormalisieren Sie dazu die die verknüpften Spalten zur Faktentabelle. Wenn Sie einen Sternschemaentwurf verwenden, sollten Sie diesen Schritt schon durchgeführt haben.
Hintergrundinformation zu relationalen Sternschemas und zum Durchführen von Entwurf und Denormalisierung für eine optimale Leistung finden Sie unter:
Ralph Kimball, The Data Warehouse Toolkit
6.5.2 Hinweise zur relationalen PartitionierungBeim Verwenden der Partitionierung auf der relationalen Seite sollten Sie sicherstellen, dass jede Cubepartition maximal eine relationale Partition berührt. Verwenden Sie zum Überprüfen das XML Showplan-Ereignis aus der SQL Server Profiler-Ablaufverfolgung.
Nach dem Entfernen aller Joins sollte der Abfrageplan ähnlich wie in Abbildung 22 aussehen.
Abbildung 22 Optimale Partitionsverarbeitungsabfrage
73
Klicken Sie auf den Tabellenscan (in diesem Fall kann es auch ein Bereichsscan oder eine Indexsuche sein), und zeigen Sie den Eigenschaftenbereich an.
Abbildung 23 Zugriff auf zu viele Partitionen
Es wird auf Partition 4 und Partition 5 zugegriffen. Der Wert für Tatsächliche Partitionsanzahl sollte 1 sein. Ist dies nicht der Fall (wie oben), sollten Sie die Partitionierung der relationalen Quelldaten erneut ausführen, sodass jede Cubepartition maximal eine relationale Partition berührt.
6.5.2.1 Sonderfall: Distinct CountFür Distinct Count-Measuregruppen gelten spezielle Anforderungen bei der Partitionierung. In der Regel wird die Time-Dimension oder eine andere Dimension als Partitionierungsspalte verwendet. Bei der Partitionierung einer Distinct Count-Measuregruppe muss die Partitionierung jedoch nach dem Wert der Distinct Count-Measurespalte erfolgen.
Gruppieren Sie die Distinct Count-Measurespalte in separate, nicht überlappende Intervalle. Jedes Intervall sollte ungefähr gleich viele Zeilen aus der Quelle enthalten. Diese Intervalle bilden dann die Quelle der Analysis Services-Partitionen.
Da die Parallelität der ProcessData-Phase von der Menge der vorhandenen Partitionen beschränkt wird, sollten Sie die Distinct Count-Measure in so viele gleich große, nicht überlappende Intervalle aufteilen, wie CPU-Kerne auf dem Analysis Services-Computer vorhanden sind.
Ab Analysis Services 2005 ist es möglich, nicht ganzzahlige Spalten für Distinct Count-Measuregruppen zu verwenden. Sie sollten dies jedoch aus Leistungsgründen vermeiden. Im unten angeführten Whitepaper wird erläutert, wie mit Hashfunktionen nicht ganzzahlige Spalten für Distinct Count in ganze Zahlen umgewandelt werden. Es enthält außerdem Beispiele für die Partitionierungsstrategie mit nicht überlappenden Intervallen.
Analysis Services Distinct Count Optimization
6.5.3 Hinweise zur relationalen IndizierungWährend in der Regel angestrebt wird, dass jede Cubepartition maximal eine relationale Partition berührt, gilt dies nicht für den umgekehrten Fall. Es ist absolut umsetzbar, dass mehrere Cubepartitionen auf dieselbe relationale Partition zugreifen. Beispielsweise kann eine relationale Quelle, die mit einem nach Monat partitionierten Cube nach Jahr partitioniert wird, weiterhin eine optimale Verarbeitungsleistung bieten.
74
Wenn zwischen relationaler und Cubepartition keine 1:1-Beziehung besteht, sollte in der Regel ein Index die Faktenverarbeitungsabfrage unterstützen. Für diesen Zweck ist ein gruppierter Index am besten geeignet, wenn die Belastungsstrategie die Verwaltung eines solchen Index zulässt.
Wenn eine Verarbeitungsabfrage von einem Index unterstützt wird, sollte der Plan wie folgt aussehen.
Abbildung 24 Korrekt vom Index unterstützte Verarbeitung
Weitere Informationen zum Optimieren von Abfragen finden Sie unter:
Top 10 SQL Server 2005 Performance Issues for Data Warehouse and Reporting Applications Itzik Ben-Gan und Lubor Kollar, Inside Microsoft SQL Server 2005: T-SQL Querying
6.5.3.1 Sonderfall: Distinct CountWie bei der Partitionierung ist Distinct Count auch beim Indizieren ein Sonderfall.
Den Distinct Count-Verarbeitungsabfragen wird durch Analysis Services eine ORDER BY-Klausel hinzugefügt. Wenn Sie z. B. einen Distinct Count für CustomerPONumber in FactInternetSales erstellen, erhalten Sie bei der Verarbeitung diese Abfrage:
SELECT … FROM FactInternetSalesORDER BY [CustomerPONumber]
Wenn die Partition viele Zeilen enthält, kann das Sortieren der Daten einige Zeit in Anspruch nehmen. Ohne unterstützende Indizes sieht der Abfrageplan etwa folgendermaßen aus.
Abbildung 25 Durch Distinct Count verursachte relationale Sortierung
Bemerken Sie die lange Zeitdauer, die der Sortiervorgang beansprucht? Durch Erstellen eines nach der Distinct Count-Spalte sortierten gruppierten Index (in diesem Fall CustomerPONumber) können Sie diesen Sortiervorgang löschen und erhalten einen Abfrageplan, der wie folgt aussieht.
75
Abbildung 26 Durch einen optimale Index unterstützte Distinct Count-Abfrage
Dieser Index muss natürlich verwaltet werden. Durch seine Platzierung werden die Verarbeitungsabfragen auf jeden Fall beschleunigt.
6.5.4 Verwenden von FILLFACTOR = 100 für den Index und der Datenkomprimierung
Die Seitenteilung in einem Index kann dazu führen, dass die Seiten des Index zu weniger als 100 % voll sind. Der Effekt ist, dass SQL Server beim Scannen des Index mehr Datenbankseiten als nötig liest.
Sie können durch Abfragen der SQL Server-DMV sys.dm_db_index_physical_stats nach Indexseiten suchen, die nicht voll sind. Liegt der Wert der Spalte avg_page_space_used_in_percent deutlich unter 100 %, muss eine Neuerstellung des Index mit FILLFACTOR 100 vorgenommen werden. Es ist nicht immer möglich, den Index auf diese Weise neu zu erstellen, mit diesem Trick können jedoch E/A-Vorgänge reduziert werden. Bei veralteten Daten empfiehlt es sich, die Indizes in der Tabelle neu zu erstellen, bevor die Daten als schreibgeschützt markiert werden.
In SQL Server 2008 können Sie entweder mit der Zeilen- oder der Seitenkomprimierung die Anzahl von E/A-Vorgängen weiter reduzieren, die die relationale Datenbank zum Ausführen der Faktenverarbeitungsabfrage benötigt. Bei der Komprimierung entsteht CPU-Verarbeitungsaufwand, die Reduzierung von E/A-Vorgängen ist diesen Aufwand jedoch häufig wert.
6.6 Beseitigen des DatenbanksperrenaufwandsWenn SQL Server einen Index oder eine Tabelle scannt, werden beim Lesen der Zeilen Seitensperren eingerichtet. So wird sichergestellt, dass viele Benutzer gleichzeitig auf die Tabelle zugreifen können. Für Data Warehouse-Arbeitsauslastungen ist dieses Sperren auf Seitenebene jedoch nicht immer die optimale Strategie, besonders wenn große Datenabrufabfragen wie die Faktenverarbeitung auf die Daten zugreifen.
Durch Messen des Perfmon-Leistungsindikators MSSQL:Sperren – Sperranforderungen/Sekunde und die Suche nach LCK-Ereignissen in sys.dm_os_wait_stats können Sie sehen, wie groß der bei der Verarbeitung verursachte Sperrenaufwand ist.
Zum Beseitigen dieses Sperrenaufwands stehen Ihnen drei Optionen zur Verfügung:
Option 1: Legen Sie die relationale Datenbank vor der Verarbeitung auf schreibgeschützten Modus fest.
Option 2: Erstellen Sie die Faktenindizes mit ALLOW_PAGE_LOCKS = OFF und ALLOW_ROW_LOCKS = OFF.
76
Option 3: Verarbeiten Sie über eine Ansicht, die den WITH (NOLOCK)-Abfragehinweis oder den WITH (TABLOCK)-Abfragehinweis angibt.
Option 1 passt möglicherweise nicht immer in Ihr Szenario, da zum Festlegen der Datenbank auf schreibgeschützten Modus exklusiver Zugriff auf die Datenbank erforderlich ist. Es ist jedoch eine schnelle und einfache Möglichkeit, um eventuelle Wartevorgänge auf eine Sperre vollständig zu entfernen.
Option 2 ist häufig ein sinnvoller Ansatz für Data Warehouses. Da SQL Server-Lesesperren (S-Sperren) mit anderen S-Sperren kompatibel sind, können zwei Leser zwei Mal auf dieselbe Tabelle zugreifen, ohne dass die feine Granularität von Seiten- oder Zeilensperren erforderlich ist. Wenn Einfügevorgänge nur während der Batchausführung erfolgen, kann die Beschränkung auf Tabellensperren eine geeignete Option sein. Erstellen Sie zum Deaktivieren von Zeilen-/Seitensperren für eine Tabelle und einen Index ALL folgendermaßen neu.
ALTER INDEX ALL ON FactInternetSales REBUILD WITH (ALLOW_PAGE_LOCKS = OFF, ALLOW_ROW_LOCKS = OFF)
Option 3 ist eine überaus nützliche Methode. Die Verarbeitung über eine Ansicht bietet Ihnen eine zusätzliche Abstraktionsebene auf der Datenbank – eine gute Entwurfsstrategie. In der Sichtdefinition können Sie einen NOLOCK- oder TABLOCK-Hinweis zum Entfernen des Datenbanksperrenaufwands während der Verarbeitung hinzufügen. Dies hat den Vorteil, dass die Beseitigung der Sperren unabhängig von der Erstellung und Verwaltung von Indizes ist.
CREATE VIEW vFactInternetSalesAS SELECT [ProductKey], [OrderDateKey], [DueDateKey] ,[ShipDateKey], [CustomerKey], [PromotionKey] ,[CurrencyKey], [SalesTerritoryKey], [SalesOrderNumber] ,[SalesOrderLineNumber], [RevisionNumber], [OrderQuantity] ,[UnitPrice], [ExtendedAmount], [UnitPriceDiscountPct] ,[DiscountAmount], [ProductStandardCost], [TotalProductCost] ,[SalesAmount], [TaxAmt], [Freight] ,[CarrierTrackingNumber] ,[CustomerPONumber]FROM [dbo].[FactInternetSales] WITH (NOLOCK)
Beachten Sie beim Verwenden des NOLOCK-Hinweises die möglicherweise auftretenden Dirty Reads. Weitere Informationen zum Sperrverhalten finden Sie unter SET TRANSACTION ISOLATION LEVEL in der SQL Server-Onlinedokumentation.
6.7 Optimieren des NetzwerkdurchsatzesWährend ProcessData müssen Zeilen zwischen SQL Server und Analysis Services übertragen werden. Sind diese beiden Dienste auf verschiedenen Computern installiert, tritt TCP/IP-Netzwerkverkehr auf. Alle Netzwerkkomponenten sollten so konfiguriert sind, dass sie den erforderlichen Durchsatz unterstützen. Wenn der Ethernet-Durchsatz durchgängig bei 80 % der maximalen Kapazität liegt, wird
77
durch zusätzliche Netzwerkkapazität ProcessData. in der Regel beschleunigt. Außerdem werden Sie Wartezeiten für ASYNC_NETWORK_IO in SQL Server feststellen, wenn das Netzwerk zu einem Engpass wird.
Zusätzlich zum Erstellen eines Hochgeschwindigkeitsnetzwerks gibt es weitere Konfigurationen, die Sie ändern können, um den Netzwerkverkehr weiter zu beschleunigen.
Unter den Eigenschaften der Datenquelle wird durch Vergrößern der Netzwerkpaketgröße für SQL Server der zum Erstellen vieler kleiner Pakete erforderliche Protokollaufwand reduziert. Der Standardwert für SQL Server 2008 ist 4096. Mit einer Data Warehouse-Auslastung kann eine Paketgröße von 32K (in SQL Server entspricht dies dem Zuweisen des Wertes 32767) zu einer schnelleren Verarbeitung beitragen. Ändern Sie nicht den Wert von SQL Server, sondern überschreiben Sie ihn in der Datenquelle.
Abbildung 13 Optimieren der Netzwerkpaketgröße
Beachten Sie, dass der Aufwand für den Transport von Daten über das TCP/IP-Netzwerk beträchtlich ist. Denken Sie daran, dass Analysis Services bei Installation auf demselben Computer wie SQL Server Shared Memory-Verbindungen verwenden kann. Shared Memory-Verbindungen verursachen beim Datenaustausch zwischen SQL Server und Analysis Services einen minimalen Aufwand. Je nach Verarbeitungsauslastung können Sie daher die Verarbeitung durch Konsolidierung von SQL Server und Analysis Services auf demselben Computer beschleunigen.
78
Sie können durch Ausführen der folgenden SELECT-Anweisung überprüfen, ob die Verbindung Shared Memory verwendet.
SELECT session_id, net_transport, net_packet_sizeFROM sys.dm_exec_connections
net_transport für die Analysis Services-SPID sollte Folgendes anzeigen: Shared memory.
Weitere Informationen zu Shared Memory-Verbindungen finden Sie unter:
Erstellen einer gültigen Verbindungszeichenfolge mithilfe des Shared Memory-Protokolls
6.8 Verbessern des E/A-SubsystemsWenn Sie das relationale Quellsystem vollständig optimiert und Netzwerkengpässe beseitigt haben, sollten Sie sich dem E/A-Subsystem zuwenden.
In Bezug auf SQL Server können Sie die E/A-Latenz aus sys.dm_os_wait_stats messen. Wenn Sie durchgängig lange Wartezeiten für PAGELATCH_IO sehen, können Sie von einem schnelleren E/A-Subsystem für SQL Server profitieren.
Falls Sie die Analysis Services-Dateien auf einem separate Laufwerkbuchstaben oder Bereitstellungspunkt platziert haben (was empfohlen wird), können Sie mit dem perfmon-Leistungsindikator Physischer Datenträger E/A-Wartezeiten messen. Liegen die Wartezeiten konsistent über 0,015 Sekunden, können Sie auch von schnelleren I/O-Vorgängen auf den Analysis Services-Laufwerken profitieren.
Techniken zum Optimieren von E/A-Subsystemen gehen über den Rahmen dieses Dokuments hinaus. Weitere Informationen finden Sie in den folgenden technischen Hinweisen und Whitepapers:
Storage Top 10 Best Practices SQL Server 2000 I/O Basics Predeployment I/O Best Practices
6.9 Erhöhen der Parallelität durch Hinzufügen weiterer PartitionenJetzt bestehen die Einschränkungen beim Optimieren nur noch in der verfügbaren CPU-Leistung und der Fähigkeit, Vorgänge mit hoher Parallelität auszugeben. Entscheidend ist dabei der Prozessor:Gesamt-Leistungsindikator in der Basislinien-Ablaufverfolgung. Falls dieser Leistungsindikator nicht 100 % beträgt, wird die CPU-Leistung nicht voll ausgenutzt. Vergleichen Sie im weiteren Verlauf der Optimierung die Basislinien, um eine Verbesserung festzustellen, und achten Sie beim Senden von mehr Daten durch das System auf das erneute Auftreten von Engpässen.
Durch die Verwendung mehrerer Partitionen kann die Verarbeitungsleistung verbessert werden. Mithilfe von Partitionen können Sie parallel an vielen, kleineren Teilen der Faktentabelle arbeiten. Da mit einer einzelnen Verbindung zu SQL Server nur die Übertragung einer begrenzten Anzahl von Zeilen pro Sekunde möglich ist, kann durch das Hinzufügen von mehr Partitionen und damit mehr Verbindungen der Durchsatz erhöht werden. Die Anzahl der Partitionen, die parallel verarbeitet werden
79
können, hängt von der CPU- und Computerarchitektur ab. Vergrößern Sie als Faustregel die Parallelität, bis bei MSOLAP:Verarbeitung – Gelesene Zeilen/Sekunde keine Erhöhung mehr festzustellen ist. Die Anzahl der parallel verarbeiteten Partitionen kann mithilfe des perfmon-Leistungsindikators MSOLAP: Prozeduraggregationen – Aktuelle Partitionen gemessen werden.
Durch die parallele Verarbeitung mehrerer Partitionen ergeben sich Vorteile in verschiedenen Szenarien, dabei sind jedoch einige Richtlinien zu beachten. Beachten Sie, dass bei der Verarbeitung einer Measuregruppe ohne verarbeitete Partitionen Analysis Services die Cubestruktur für diese Measuregruppe initialisieren muss. Dazu wird eine exklusive Sperre angewendet, die die parallele Verarbeitung von Partitionen verhindert. Entfernen Sie diese Sperre, bevor Sie den vollständigen parallelen Prozess auf dem System starten. Stellen Sie beim Entfernen der Initialisierungssperre sicher, dass vor dem Beginn des parallelen Vorgangs mindestens eine verarbeitete Partition pro Measuregruppe vorhanden ist. Falls keine verarbeitete Partition vorhanden ist, können Sie ProcessStructure für den Cube ausführen, um seine Anfangsstruktur zu erstellen, und dann die Measuregruppe-Partitionen parallel verarbeiten. Diese Beschränkung tritt nicht auf, wenn Sie Partitionen in derselben Clientsitzung verarbeiten und mit dem MaxParallel-XMLA-Element den Grad der Parallelität steuern.
6.10 Anpassen der maximalen Anzahl von VerbindungenWenn der Parallelitätseffekt der Verarbeitung auf mehr als 10 parallele Partitionen gesteigert wird, muss die maximale Anzahl von Verbindungen angepasst werden, die Analysis Services für die Datenbank geöffnet hält. Diese Anzahl kann in den Eigenschaften der Datenquelle geändert werden.
Abbildung 28 Hinzufügen weiterer Datenbankverbindungen
Legen Sie diese Anzahl mindestens auf die Anzahl von Partitionen fest, die parallel verarbeitet werden sollen.
80
6.11 Anpassen von ThreadPool und CoordinatorExecutionModeDiese serverweiten Eigenschaften erhöhen die Anzahl von Threads, mit denen parallele Verarbeitungsvorgänge unterstützt werden können.
ThreadPool\Process\MaxThreads legt die maximale Anzahl der während der Verarbeitung für Analysis Services verfügbaren Threads fest. Auf großen Computern mit mehreren CPUs ist der Standardwert dieser Einstellung unter Umständen zu niedrig, um alle CPU-Kerne nutzen zu können. Beachten Sie beim Erhöhen dieses Leistungsindikators jedoch, dass sich eine erhöhte Parallelität der Verarbeitung auch auf Abfragen auswirkt, die auf dem System ausgeführt werden. Wenn Sie mehr CPU-Leistung und Threads für die Verarbeitung reservieren, wird weniger CPU-Leistung für Abfrageantworten verwendet. Bei der Verarbeitung der Cubes in einem Batchfenster ist dies unter Umständen kein Problem.
Überprüfen Sie zum Optimieren dieser Einstellungen für die ProcessData-Phase den perfmon-Leistungsindikator für das Objekt MSOLAP: Threads, und beachten Sie die Anweisungen in der nachfolgenden Tabelle.
Situation AktionWarteschlangenlänge für Aufträge im Verarbeitungspool > 0 und Im Leerlauf befindliche Threads im Verarbeitungspool = 0über eine längere Zeit während der Verarbeitung.
Erhöhen Sie Threadpool\Process\MaxThreads, und testen Sie erneut.
Warteschlangenlänge für Aufträge im Verarbeitungspool > 0 und Im Leerlauf befindliche Threads im Verarbeitungspool > 0 gleichzeitig während der Verarbeitung.
Verringern Sie CoordinatorExecutionMode, und testen Sie erneut.
Der Prozessor –% Prozessorzeit – Gesamt-Leistungsindikator kann als ungefähre Anzeige dafür verwendet werden, in welchem Maße diese Einstellungen geändert werden sollten. Das Ziel sollte sein, möglichst in die Nähe von 100 % CPU-Auslastung zu gelangen. Wenn z. B. die CPU-Last 50 % beträgt, können Sie Threadpool\Process\MaxThreads verdoppeln, um zu sehen, ob sich damit auch die CPU-Auslastung verdoppelt.
Weitere Informationen zum Anpassen von Threadpools finden Sie im folgenden Whitepaper:
SQL Server 2005 Analysis Services (SSAS) Server Properties
6.12 Anpassen von BufferMemoryLimitOLAP\Process\BufferMemoryLimit legt die Größe der während der Partitionsverarbeitung verwendeten Faktendatenpuffer fest. Der Standardwert von OLAP\Process\BufferMemoryLimit ist zwar für die meisten Bereitstellungen ausreichend, im folgenden Szenario sollte die Eigenschaft jedoch geändert werden.
81
Wenn die Granularität der Measuregruppe stärker zusammengefasst ist als die relationale Quellfaktentabelle, sollte die Größe der Puffer erhöht werden, um die Datengruppierung zu vereinfachen. Wenn z. B. die Quelldaten die Granularität Tag und die Measuregruppe die Granularität Monat aufweist, muss Analysis Services die täglichen Daten vor dem Schreiben auf den Datenträger nach Monat gruppieren. Diese Gruppierung erfolgt innerhalb eines einzelnen Puffers und wird in den Datenträger geleert, nachdem sie voll ist. Durch das Erhöhen der Puffergröße wird die Häufigkeit verringert, mit der die Puffer auf den Datenträger ausgelagert werden. Da dadurch ein höheres Komprimierungsverhältnis möglich ist, verringert sich die Größe der Faktendaten auf dem Datenträger, und die Leistung erhöht sich. Beachten Sie jedoch, dass bei hohen Werten für BufferMemoryLimit mehr Arbeitsspeicher verwendet wird. Wenn nicht mehr genügend Arbeitsspeicher vorhanden ist, wird die Parallelität verringert.
6.13 Optimieren der ProcessIndex-PhaseWährend der ProcessIndex-Phase werden Aggregationen im Cube erstellt. Zu diesem Zeitpunkt werden im relationalen Modul keine Aktivitäten mehr ausgeführt. Wenn Analysis Services und SQL Server dasselbe Feld verwenden, können Sie alle CPU-Kerne für Analysis Services nutzen.
Die Kennzahl, die während ProcessIndex optimiert wird, ist der Leistungsindikator MSOLAP:Prozeduraggregationen – Erstellte Zeilen/Sekunde. Mit zunehmendem Leistungsindikator nimmt die ProcessIndex-Zeit ab. Mit diesem Leistungsindikator können Sie überprüfen, ob durch die Optimierungsmaßnahmen die Geschwindigkeit erhöht wurde.
6.13.1 Verhindern des Überlaufs temporärer Daten auf den DatenträgerWährend der Verarbeitung legt der Aggregationspuffer den Speicherplatz fest, der zum Erstellen von Aggregationen für eine bestimmte Partition verfügbar ist. Ist der Aggregationspuffer zu klein, wird er von Analysis Services mit temporären Dateien ergänzt. Temporäre Dateien werden im Ordner TempDir erstellt, wenn der Arbeitsspeicher gefüllt ist und Daten sortiert und auf den Datenträger geschrieben werden. Nachdem alle erforderlichen Dateien erstellt wurden, werden sie am endgültigen Ziel zusammengeführt. Die Verwendung temporärer Dateien kann möglicherweise während der Verarbeitung zu einer Leistungseinbuße führen. Überprüfen Sie zum Überwachen von während der Verarbeitung verwendeten temporären Dateien den Indikator MSOLAP:Prozeduraggregationen\Geschriebene Temp-Datei-Bytes/Sekunde.
Außerdem müssen Sie bei der parallelen Verarbeitung mehrerer Partitionen oder bei der Verarbeitung eines gesamten Cubes in einer einzigen Transaktion sicherstellen, dass der erforderliche Gesamtarbeitsspeicher den Wert der Memory\TotalMemoryLimit-Einstellung nicht überschreitet. Falls Analysis Services Memory\TotalMemoryLimit während der Verarbeitung erreicht, wird die Vergrößerung des Aggregationspuffers unterdrückt, und unter Umständen werden temporäre Dateien während der Aggregationsverarbeitung verwendet. Außerdem ist möglicherweise bei unzureichendem virtuellen Adressraum für diese gleichzeitig ausgeführten Vorgänge nicht genügend Arbeitsspeicher verfügbar. Bei nicht ausreichendem physikalischen Arbeitsspeicher erfolgt die Speicherauslagerung. Führen Sie bei beschränkten Ressourcen weniger Vorgänge parallel aus.
82
In der Standardkonfiguration löst Analysis Services eine Ausnahme wegen unzureichenden Arbeitsspeichers aus, wenn während der Verarbeitung versucht wird, zu viel Arbeitsspeicher anzufordern. Dieser Fehler kann unter Umständen durch Festlegen von MemoryLimitErrorEnabled auf false in den Servereigenschaften deaktiviert werden. Dies kann jedoch zu einem Überlauf des Datenträgers und zum Verlangsamen des Verarbeitungsvorgangs führen.
Sollte es nicht möglich sein, den Überlauf von Daten auf den Datenträgers zu verhindern, ist zumindest sicherzustellen, dass sich der Ordner TempDir und die Seitendatei auf einem schnellen E/A-System befinden.
6.13.2 Beseitigen von E/A-EngpässenWährend ProcessIndex ist die Datenträgeraktivität in der Regel niedriger als während ProcessData. Wenn bei ProcessData kein E/A-Engpass auftritt, ist die E/A-Geschwindigkeit mit hoher Wahrscheinlichkeit auch für ProcessIndex ausreichend. Überwachen Sie trotzdem den E/A-Vorgang mithilfe der Richtlinien aus Verbessern des E/A-Subsystems.
6.13.3 Hinzufügen von Partitionen zum Erhöhen der ParallelitätAnalog zu ProcessData kann durch die parallele Verarbeitung vom mehr Partitionen ProcessIndex beschleunigt werden. Dabei gilt dieselbe Optimierungsstrategie: Erhöhen Sie die Anzahl der Partitionen, bis sich keine höhere Verarbeitungsgeschwindigkeit mehr feststellen lässt.
6.13.4 Optimieren von Threads und AggregationMemory-EinstellungenWährend ProcessIndex scannt und aggregiert Analysis Services die während ProcessData erstellten Partitionen. Dieser Vorgang lässt sich auf zwei Arten parallel ausführen:
Verwenden Sie mehrere Threads, um die Segmente einer Partition jeweils gleichzeitig zu scannen und zu aggregieren.
Scannen und aggregieren Sie mehrere Partition gleichzeitig mit einer geringeren Anzahl von Threads.
Beide Methoden können in den meisten Fällen gleichzeitig verwendet werden. Sie können die Ausführung mithilfe von Servereigenschaften steuern. Darüber hinaus sind beide Einstellungen durch die Threadeinstellungen auf dem Server beschränkt, wie in Anpassen von ThreadPool und CoordinatorExecutionMode erläutert.
Falls Sie mehr Partitionen hinzufügen, um den Parallelitätseffekt zu steigern, müssen Sie eventuell die AggregationMemory-Einstellungen ändern. Ermöglicht der Entwurf das Hinzufügen von mehr Partitionen nicht, können Sie CoordinatorBuildMaxThreads ändern, um den Parallelitätseffekt weiter zu steigern.
Wenn die mit dem Leistungsindikator Prozessor –% Prozessorzeit – Gesamt gemessene CPU-Auslastung unter 100 % liegt und keine E/A-Engpässe bestehen, können Sie die Geschwindigkeit der ProcessIndex-Phase mit den Techniken in diesem Abschnitt unter Umständen weiter steigern.
83
6.13.4.1 Anpassen von ThreadeinstellungenAnalog zu ProcessData muss möglicherweise die Threadpooleinstellung angepasst werden, um eine optimale Leistung zu erzielen. Halten Sie sich an die Richtlinien aus Anpassen von ThreadPool und CoordinatorExecutionMode.
6.13.4.2 Anpassen der AggregationMemoryMin-EigenschaftUnter den Servereigenschaften finden Sie die folgenden Einstellungen:
OLAP\Process\AggregationMemoryLimitMin OLAP\Process\AggregationMemoryLimitMax
Diese Einstellungen, ausgedrückt als Prozentsatz des Analysis Services-Arbeitsspeichers, bestimmen, wie viel Arbeitsspeicher in jeder Partition für das Erstellen von Aggregationen zugeordnet wird. Wenn Analysis Services die Partitionsverarbeitung startet, wird die Parallelität basierend auf der AggregationMemoryMin-Einstellung gedrosselt. Wenn Sie z. B. fünf parallele Partitionsverarbeitungsaufträge mit AggregationMemoryMin = 10 starten, werden ungefähr 50 % des Arbeitsspeichers für die Verarbeitung zugeordnet. Wenn nicht mehr genügend Arbeitsspeicher vorhanden ist, werden neue Partitionsverarbeitungsaufträge gesperrt, während sie auf verfügbaren Arbeitsspeicher warten. Wenn viele Partitionen parallel verarbeitet werden, kann durch Reduzieren des Werts für AggregationMemoryLimitMin die Geschwindigkeit von ProcessIndex erhöht werden. Durch die Begrenzung des pro Partition zugeordneten Mindestarbeitsspeichers kann ein höherer Grad an Parallelität in der ProcessIndex-Phase erzielt werden.
Analog zu den anderen Analysis Services-Leistungsindikatoren wird bei dieser Einstellung ein Wert von über 100 als feste Anzahl von Kilobytes interpretiert. Bei Computer mit großem Arbeitsspeicher kann ein absoluter Kilobyte-Wert eine bessere Kontrolle des Arbeitsspeichers als ein Prozentwert bieten.
6.13.4.3 Anpassen von CoordinatorBuildMaxThreadsBeim Scannen einer einzelnen Partition wird die Anzahl von Threads zum Scannen von Blöcken durch die CoordinatorBuildMaxThreads-Einstellung eingeschränkt. Diese Einstellung legt die maximale Anzahl der pro Partitionsverarbeitungsauftrag zugeordneten Threads fest. Ihr Verhalten entspricht CoordinatorExecutionMode (weitere Informationen finden Sie im Abschnitt zur Auftragsarchitektur.) Weist diese Einstellung einen negativen Wert auf, wird ihr absoluter Wert mit der Anzahl von Kernen im Computer multipliziert, um die maximale Anzahl ausführbarer Threads zu bestimmen. Weist die Einstellung einen positiven Wert auf, ist dies die absolute Anzahl ausführbarer Threads. Beachten Sie dabei, dass bei der Verarbeitung die Einschränkung durch die Anzahl von Threads im Verarbeitungsthreadpool weiterhin besteht. Eine Erhöhung dieses Werts kann also auch eine Vergrößerung des Verarbeitungsthreadpools bedeuten.
84
Abbildung 29 CoordinatorBuildMaxThreads
Falls durch die Verwendung von mehr Partitionen keine hohe Parallelität erzielt werden konnte, können Sie den CoordinatorBuildMaxThreads-Wert ändern. Durch die Erhöhung dieses Werts können Sie mehr Threads pro Partition verwenden.
Möglicherweise müssen Sie auch die AggregationMemoryMin-Einstellungen anpassen, um optimale Ergebnisse zu erzielen.
7 Optimieren von ServerressourcenNeben dem Optimieren der Anwendung müssen in bestimmten Fällen einfach nur mehr Hardwareressourcen hinzugefügt werden, um den Server selbst zu optimieren. In diesem Abschnitt werden serverweite Einstellungen erläutert, mit denen die Leistung verbessert werden kann.
7.1 Verwenden von PreAllocateMit der PreAllocate-Einstellung in msmdsrv.ini kann physischer Arbeitsspeicher für Analysis Services reserviert werden. Wenn neben Analysis Services noch andere Dienste auf demselben Computer installiert sind, kann durch das Festlegen von PreAllocate eine stabilere Speicherkonfiguration bereitgestellt werden.
Verfügt das zum Ausführen von Analysis Services verwendete Dienstkonto auch über das Privileg Sperren von Seiten im Speicher, dann bewirkt PreAllocate, dass Analysis Services große Speicherseiten verwendet. Sperren von Seiten im Speicher wird mit gpedit.msc festgelegt. Beachten Sie, dass große Speicherseiten nicht an die Auslagerungsdatei ausgelagert werden können. Dies kann in Bezug auf die
85
Leistung ein Vorteil sein, allerdings können viele zugeordnete große Seiten dazu führen, dass das System nicht mehr reagiert.
Lassen Sie ungefähr 20 % des Systemarbeitsspeichers für das Betriebssystem frei, wenn PreAllocate mit großen Seiten verwendet wird.
Wichtig: PreAllocate hat die größten Auswirkungen auf das Windows Server® 2003-Betriebssystem. Mit der Einführung von Windows Server 2008 wurde die Arbeitsspeicherverwaltung deutlich verbessert. Wir haben diese Einstellung unter Windows 2008 Server getestet, jedoch keine Vorteile durch die Verwendung von PreAllocate auf dieser Plattform festgestellt. Angesichts der Nachteile von PreAllocate bietet diese Einstellung unter Windows Server 2008 wahrscheinlich kaum Vorteile.
Weitere Informationen zu den Auswirkungen von PreAllocate finden Sie im folgenden technischen Hinweis:
Running Microsoft SQL Server 2008 Analysis Services on Windows Server 2008 vs. Windows Server 2003 and Memory Preallocation: Lessons Learned
7.2 Deaktivieren von Flight RecorderFlight Recorder stellt einen Mechanismus zum Aufzeichnen der Analysis Services-Serveraktivität in einem kurzfristigen Protokoll bereit. Flight Recorder bietet zwar viele Vorteile bei der Problembehandlung bestimmter Abfrage- und Verarbeitungsprobleme, führt aber auch zu einem gewissen E/A-Aufwand. Wenn Sie in einer Produktionsumgebung arbeiten und die Funktionen von Flight Recorder nicht benötigen, können Sie diese Protokollierung deaktivieren und den E/A-Aufwand entfernen. Mit der Servereigenschaft Log\Flight Recorder\Enabled wird gesteuert, ob Flight Recorder aktiviert ist. Standardmäßig ist diese Eigenschaft auf true festgelegt.
7.3 Überwachen und Anpassen des ServerarbeitsspeichersIn der Regel ist ein möglichst großer Arbeitsspeicher optimal. Falls die Datendateien im Betriebssystemcache gespeichert werden können, wird die Leistung des Speichermoduls nicht beeinflusst. Wenn das Formelmodul eigene Ergebnisse zwischenspeichern kann, werden Zellenwerte wiederverwendet statt neu berechnet. Während der Verarbeitung wird die Leistung auch verbessert, wenn kein Überlauf von Ergebnisse auf den Datenträger erfolgt. Beachten Sie jedoch, dass Analysis Services AWE-Arbeitsspeicher auf 32-Bit-Systemen nicht verwendet. Falls für den Cube ein großer Arbeitsspeicher erforderlich ist, wird die Verwendung von 64-Bit-Hardware empfohlen.
Wichtige Arbeitsspeichereinstellungen sind Memory\TotalMemoryLimit und Memory\LowMemoryLimit, ausgedrückt als Prozentsatz des verfügbaren Arbeitsspeichers. Der Arbeitsspeicher kann mit dem Task-Manager oder mit den folgenden Leistungsindikatoren überwacht werden:
MSAS2008:Speicher\Speicherauslastung KB MSAS2008:Speicher\Speicheruntergrenze KB MSAS2008:Speicher\Speicherobergrenze KB
86
Wenn PreAllocate nicht verwendet wird, gibt Analysis Services bei nicht vorhandener Auslastung Speicher frei – andere Anwendungen (wie das SQL Server-Modul) können freigegebenen Speicher beanspruchen. Daher ist es wichtig, nicht nur Analysis Services korrekt zu konfigurieren, sondern auch andere Anwendungen auf dem Computer.
Führen Sie, bevor Sie entscheiden, dass zusätzlicher Arbeitsspeicher erforderlich ist, die in den Abschnitten zu Abfragen und Verarbeitung beschriebenen Schritte aus, um die Cubeleistung zu optimieren.
8 ZusammenfassungDieses Dokument bietet die Mittel zur Diagnose und zum Behandeln von Verarbeitungs- und Abfrageleistungsproblemen mit SQL Server 2008 Analysis Services. Weitere Informationen finden Sie unter den folgenden Themen:
http://sqlcat.com/: SQL Customer Advisory Team
http://www.microsoft.com/sqlserver/: SQL Server-Website
http://technet.microsoft.com/de-de/sqlserver/: SQL Server TechCenter
http://msdn.microsoft.com/de-de/sqlserver/: SQL Server DevCenter
Wenn Sie Vorschläge oder Anmerkungen haben, können Sie sich jederzeit an die Autoren wenden. Sie erreichen Richard Tkachuk unter [email protected] oder Thomas Kejser unter [email protected].
War dieses Whitepaper hilfreich? Senden Sie uns Ihr Feedback. Nennen Sie uns anhand einer Skala von 1 (schlecht) bis 5 (sehr gut) die Bewertung dieses Whitepapers und die Gründe für Ihre Bewertung. Beispiel:
Vergeben Sie eine gute Bewertung auf Grund der guten Beispiele, hervorragenden Screenshots, klaren Formulierungen oder aus einem anderen Grund?
Vergeben Sie eine weniger gute Bewertung auf Grund schlechter Beispiele, ungenauer Screenshots oder unklarer Formulierungen?
Dieses Feedback trägt zur Verbesserung der Qualität von uns veröffentlichter Whitepapers bei.
Feedback senden
87
![Parallelrechner: Motivation Parallelrechner ... · PC-T echnologie SMP-Multiprozessorsysteme 69 MISD prozessor Array-prozessor Vektor-gemeinsamer Speicher Nachrichtenaustausch [Tanenbaum]](https://img.pdfslide.org/doc/110x75/5e0670240b667f3b7514f00a/parallelrechner-motivation-parallelrechner-pc-t-echnologie-smp-multiprozessorsysteme.jpg)
