ORACLE 11g PERFORMANCE FORECAST

Transkript

1 lutz FRÖHLICH ORACLE 11g PERFORMANCE FORECAST AKTUELLE UND ZUKÜNFTIGE PERFORMANCE-PROBLEME ERKENNEN UND VERMEIDEN E D I T I O N P R A X I S W I S S E N

2 Inhalt Vorwort...VII 1 Einführung Wozu Performance Forecast? Für wen ist dieses Buch bestimmt? Einordnung in die IT-Landschaft Ansatz und Vorgehen Einflüsse auf die Performance Trennung von Change und Capacity Management Die Bedeutung von Workload-Statistiken Ein Beispiel Forecast-Modelle Mathematische Forecast-Modelle Queuing-Modelle Benchmark-Modelle Workload-Statistiken Rohdaten sammeln Statistik-Daten auswählen Statistiken mit Agenten und mit DB-Links sammeln Statistiken aus dem Oracle AWR und dem Oracle EM lesen Sicherheitsaspekte Mathematische Forecast-Modelle Notationen Das Basic Relation Model Lineare Regressions-Modelle Simple Linear Regression Model Multiple Linear Regression Model Fazit für Lineare Regressionsmodelle V

3 Inhalt 5 Queuing-Modelle Zur Queuing-Theorie Die M/M/1 Queue im Überblick Queuing in Computersystemen Queuing und Performance Forecast Beispiel für Antwortzeiten von Online-Sessions Forecasts für I/O-Subsysteme System-Forecasts erstellen Fazit zu Forecasts mit der Queuing-Theorie Benchmark-Modelle Einsatzmöglichkeiten von Benchmarks Oracle Real Application Testing Workload Capture Workload Preprocessing Workload Replay Den Workload auswerten Skalierung von Benchmarks Skalierung nach Amdahl Super-Serial-Skalierung Bestimmen der Skalierungsfaktoren Benchmarks für Entwickler und Software-Hersteller Fazit zu den Benchmark-Modellen Performance Monitoring Mehrstufiges Monitoring Eine Baseline bilden Statistiken aufbereiten Überwachung durch Schwellwerte Berichterstellung Die Vorhersage von Performance-Problemen Monitoring mit eigenen Skripten Monitoring mit dem Oracle Enterprise Manager Überwachung von Datenbank-Metriken SQL-Ausführungspläne überwachen Register VI

4 2 2 Ansatz und Vorgehen Es gibt eine Reihe von Büchern und Veröffentlichungen, die sich mit dem Thema Kapazitätsplanung und -Management für Computersysteme beschäftigen. Viele bleiben jedoch im theoretischen Ansatz stecken oder vergnügen sich mit ausschweifenden mathematischen Theorien und Herleitungen. Mit dem vorliegenden Buch wollen wir praktische Mittel und Wege aufzeigen, um Capacity Management und insbesondere Performance Monitoring und Forecasting in das tägliche Support-Geschäft zu integrieren. Das bedeutet keineswegs, dass mathematische Methoden unberücksichtigt bleiben. Im Gegenteil: sie sind ein hervorragendes Mittel, um innerhalb kurzer Zeit und mit wenig Kosten zuverlässige Vorhersagen zu treffen. Aus diesem Grund erläutern wir mathematische Methoden ausführlich und stellen sie anhand praktischer Beispiele dar. Weil es immer auch um die Anwendbarkeit der Theorie geht, beginnen wir mit der Frage, wie Sie ein Capacity Management für Oracle Datenbanken im täglichen Betrieb wirksam einsetzen. Wenn Sie im Support-Umfeld tätig sind, wissen Sie, wie dynamisch man auf Probleme reagieren muss und wie kurzfristig Entscheidungen umgesetzt werden müssen, ohne alle Auswirkungen berücksichtigen zu können. So wird eine Datenbank aus den unterschiedlichsten Gründen mit einer Vielzahl von Änderungsanträgen konfrontiert. Treten Sie einen Schritt zurück, und versetzen Sie sich in die Lage der Datenbank, die natürlich immer bemüht ist, jede Anforderung mit dem geringstmöglichen Aufwand an Ressourcen und in kürzester Zeit abzuarbeiten. 2.1 Einflüsse auf die Performance Eine Datenbank unterliegt während ihres Lebenszyklus ständigen Veränderungen. Diese Änderungen sind zu einem Großteil geplant, wenige sind ungewollt. Trotzdem bewirken sie über kurz oder lang, dass sich die Performance verschlechtert und möglicherweise kritische Ausmaße annimmt. Aus der Perspektive der Datenbank sind das einfach eine Vielzahl von Ereignissen und Änderungen: 5

5 2 Ansatz und Vorgehen Datenbank-Upgrades und -Patches Änderung der Applikationen Änderungen im SQL- und PL/SQL-Code Veränderte Datenmenge Wachstum der Datenbank Veränderte Daten-Histogramme Anpassung der Schema-Objekte wie Indexe oder partitionierte Tabellen Geänderte Datenbank-Parameter Entstehung von Hot Spots für Tabellen und Datenbank-Dateien Fragmentierung von Tabellen und Indexen Bugs Veränderte Hardware-Ressourcen Upgrades und Patches des Betriebssystems oder Storage-Subsystems Änderung der Belastung von geteilten Ressourcen Veränderte Anzahl von gleichzeitigen Benutzern. Anzahl Benutzer Upgrades Patches SQL und PL/SQL Änderungen OS Upgrades Änderungen der Applikation Geteilte Ressourcen Bugs Target- Datenbank Veränderte Datenmenge Wachstum der Datenbank Änderung von DB-Parametern Veränderte Daten-Histogramme Entstehung von Hotspots Fragmentierung Tabellen/Indexe Anpassung von Schema-Objekten Abbildung 2.1 Einflüsse auf die Datenbank-Performance Da Oracle interne Features wie den SQL-Optimizer ständig weiterentwickelt, führen Upgrades zu Veränderungen der Ausführungspläne. Möglicherweise wird nach einem Upgrade anstelle eines Index Scan ein Full Table Scan ausgeführt. Beim Upgrade auf die Version 10g konnte ein verändertes Verhalten im Ressourcen-Verbrauch bei parallelen SQL- Abfragen festgestellt werden. Plötzlich stieg die CPU-Auslastung bei Nested Loop-Plänen signifikant an. 6

6 2.1 Einflüsse auf die Performance Änderungen in der Applikation gehen nicht nur einher mit geänderten oder neuen SQL- Anweisungen. Auch veränderte Terminpläne nehmen Einfluss auf die Performance. Wenn plötzlich Batch Jobs oder Backups in den Tag hineinlaufen, nehmen sie Ressourcen weg, welche die Benutzer für ihre Online-Abfragen benötigen. Eine temporäre Änderung in der Menge der zu verarbeitenden Daten und das Wachstum der Datenbank tragen einen großen Anteil an einer Verschlechterung der Performance. Sicherlich kennen Sie aus der Praxis die SQL-Anweisungen, die mit kleinen bis mittelgroßen Tabellen noch akzeptabel laufen, ab einer gewissen Tabellengröße jedoch Probleme verursachen. Auch eine Veränderung in den Histogrammen der Daten können den Optimizer veranlassen, Ausführungspläne zu verändern. Aber auch Verschiebungen in der Index- Struktur, Veränderungen des Layouts von partitionierten Tabellen oder Materialized Views in Zusammenhang mit dem Summary Management können zu erhöhtem Ressourcen- Verbrauch und verminderter Performance führen, ohne dass Änderungen im SQL-Quelltext selbst erfolgen. Die Oracle-Datenbank ist bekannt für eine Vielzahl von änderbaren Parametern. So kann es als Folge einer Parameteränderung zu einer Verbesserung bei Online-Abfragen kommen, und gleichzeitig laufen die Batch Jobs aus dem Zeitplan hinaus. Außerdem gibt es die Kategorie von Einflüssen, die einfach dadurch entstehen, dass die Datenbank ohne Wartung über einen gewissen Zeitraum läuft. Dazu gehören die Fragmentierung von Tabellen und Indexen sowie das Entstehen von Hot Spots. Bugs sind besonders kritisch, da sie häufig nur in bestimmten Situationen auftreten und schwer zu identifizieren sind. Aber auch Upgrades oder Parameter-Änderungen im Betriebssystem oder Storage-Bereich können zu erheblichen Veränderungen in der Ressourcen-Bereitstellung führen. Unterschätzt wird häufig der Sachverhalt, dass sich Datenbanken Ressourcen teilen, ohne dass ein Ressource Manager eingesetzt wird. Das gilt insbesondere für Storage-Systeme oder wenn sich Datenbanken einen Server teilen. Ähnlich wie das Wachstum der Datenbank ist eine steigende Anzahl von gleichzeitigen Benutzern Hauptursache für einen plötzlichen Performance-Einbruch. Ich erinnere mich an einen Fall, als die Benutzeranzahl verdoppelte wurde und der Einfluss auf die Performance der Datenbank als gering eingeschätzt wurde, da die Benutzer-Sitzungen einen großen Anteil an Inaktivität auswiesen. Man hatte dabei vergessen, dass jeder Benutzer einen Serverprozess erzeugt, was letztendlich das Betriebssystem zum Paging veranlasste. Sicher haben nicht alle Ereignisse einen negativen Einfluss auf die Performance oder führen zu einer signifikanten Verschlechterung. Die Praxis beweist jedoch, dass je länger eine Datenbank diesen Einflüssen unkontrolliert unterliegt, desto größer ist die Wahrscheinlichkeit, dass die Performance in den kritischen Bereich übergeht. Es stellt sich die Frage: Ist es bei dieser Vielzahl von Einflüssen und der Komplexität des Datenbank-Betriebssystems überhaupt möglich, zuverlässige Vorhersagen zur Performance zu erstellen? Diese Frage wird in den folgenden Abschnitten untersucht. 7

7 2 Ansatz und Vorgehen 2.2 Trennung von Change und Capacity Management Eine saubere Trennung von Change und Capacity Management ist die erste und wichtigste Maßnahme für zuverlässige Performance-Vorhersagen. Ich erhielt kürzlich eine Anfrage mit der Aufgabe, eine Performance-Vorhersage zu erstellen. Der Kunde hatte ein Datenbank-Upgrade geplant und wollte wissen, wie die Performance der Applikation unter der neuen Version sein würde. Diesen Auftrag musste ich ablehnen, da es sich hierbei eindeutig um eine Aufgabe für das Change Management und nicht für das Capacity Management handelte. Halten Sie sich stets vor Augen, dass Vorhersagen immer auf einem Modell basieren. Modelle sind allerdings keine Eins-zu-eins-Abbildungen der Natur, sondern stellen eine Vereinfachung dar, in der die wichtigsten Einflussfaktoren berücksichtigt werden. Die internen Strukturen und Prozesse des Datenbank-Betriebssystems sind viel zu komplex, um in vertretbarer Zeit ein zuverlässiges Modell zu erstellen, das die Veränderungen eines Upgrades widerspiegelt. Generell lässt sich sagen, dass der Einfluss durch Änderungen, die dem Change Management entstammen, effektiver, kostengünstiger und schneller durch reale Tests herausgefunden werden kann. Viele Firmen praktizieren dieses Vorgehen bereits, indem sie so genannte UAT-Datenbanken betreiben und vor der Implementierung in der Produktion die Auswirkungen auf die Applikation testen. Die Abkürzung UAT steht für User Acceptance Testing. Auch Oracle hat Bedeutung und Notwendigkeit eines solchen Vorgehens erkannt und in der Version 11g mit dem neuen Feature Real Application Testing darauf reagiert. Wir wollen uns an dieser Stelle jedoch nicht zu weit vom Thema entfernen. Der Einfluss von durch das Change Management verursachten Änderungen ist jedoch real. Es stellt sich damit die Frage nach der Gültigkeit bereits gebildeter Prognosen, wenn Änderungen in der Datenbank im Rahmen des Change Managements vorgenommen werden. Generell lässt sich sagen, dass Prognosen ihre Gültigkeit behalten, solange die Änderungen keinen Einfluss auf den Workload haben. Die Überwachung des Workloads ist also ein wichtiger Bestandteil der fortlaufenden Validierung von Forecasts. Jede Vorhersage basiert auf einer Baseline, die einen bestimmten Workload der Datenbank charakterisiert. Eine Veränderung der Baseline macht eine Neuberechnung der Vorhersage erforderlich. Das stellt insofern kein Problem dar, da die Neuberechnung mit mathematischen Methoden nicht aufwendig ist und in kurzer Zeit erfolgen kann. Allerdings müssen für die neue Prognose aktuelle Workload-Statistiken herangezogen werden. Viele Datenbanken lassen sich nach dem Prinzip Und täglich grüßt das Murmeltier betrachten. Die Workload- Charakteristik wiederholt sich alle 24 Stunden, und damit können innerhalb von 24 Stunden die Statistiken für eine neue Baseline gesammelt werden. Für Datenbanken, die am Wochenende oder Monatsende spezifische Workloads ausweisen, gibt es Methoden, die Statistiken anzupassen, ohne auf Ergebnisse eines Langzeit-Sammelprozesses warten zu müssen. Durch eine klare Trennung von Change Management und Capacity Management verringert sich die in Abbildung 2.2 dargestellte Komplexität von Einflussfaktoren entscheidend, und das Thema Performance Forecast wird insofern beherrschbar. 8

8 2.3 Die Bedeutung von Workload-Statistiken Capacity Management Target- Datenbank - Datenmenge und Wachstum - Daten-Histogramme - Benutzer und Mandanten - Hardware-Ressourcen - Workload Change Management Abbildung 2.2 Trennung von Change Management und Capacity Management Die Trennung von Change und Capacity Management bedeutet nicht, dass die Änderungen, die aus dem Change Management kommen, ignoriert werden. Durch den Einsatz von UAT-Datenbanken und Real Application Testing werden die Auswirkungen auf den Workload vorab bestimmt. Gleichzeitig garantiert das Workload Monitoring, dass Auswirkungen, die durch das Change Management entstehen, nicht unentdeckt bleiben. 2.3 Die Bedeutung von Workload-Statistiken Workload-Statistiken sind eine notwendige Voraussetzung für das Erstellen von Performance Forecasts. Jede Prognose wird auf Basis einer Baseline gebildet. Eine Baseline ist ein charakteristischer Workload im betrachteten Zeitfenster. Die Statistiken bilden außerdem die Basis für die Schwellenwerte des Workload Monitoring. Forecast und Monitoring bedingen einander. Während ein Forecast die Werte für die erwartete Entwicklung des Workloads an das Monitoring liefert, sendet das Monitoring Warnungen und Alarmsignale über Abweichungen vom erwarteten Workload an den Forecast. Der Validierungsprozess untersucht die Abweichungen und stellt die Ursachen fest. Abweichungsursachen können zum Beispiel aus dem Change Management kommen oder durch ein überplanmäßiges Wachstum der Datenbank ausgelöst werden. Hinweis Auch wenn Sie für bestimmte Datenbanken keine Performance Forecasts erstellen wollen, können Sie das Performance Monitoring einsetzen, in dem Sie Vorgaben für den erwarteten Workload machen. Vom Monitoring erhalten Sie Alerts, wenn es zu Abweichungen kommt, und Sie können die Ursachen ermitteln und entsprechende Maßnahmen einleiten. Die frühzeitige Erkennung von Abweichungen unterstützt die Einhaltung von Performance-Vorgaben und Service Level Agreements. Gleichzeitig charakterisiert das Monitoring den Einfluss der Änderungen im Rahmen des Change Managements auf den Workload. 9

9 Register A Abhängigkeit lineare 21, 22, 75 Linearität der 78 Abweichung durchschnittliche 73 quadratische 72, 73 Active Session History 67 Active Workload Repository 66 Agenten 42 Amdahl sches Gesetz 30, 31, 165, 171 Ankunftsrate 111, 112 durchschnittliche 107 ANOVA-Tabelle 87 Anteil paralleler 165 serieller 165 Antwortzeit 16, 26, 113 Applikations-Monitoring 62 Applikations-Profil 62, 117, 118, 161 Applikations-Statistik 139 Applikations-Überwachung 66 Applikations-Workload 41, 135 Arrival Process 108 Auslastung des Systems 112 Auslastungsgrad 114 Ausreißer 81 Authentifizierungsprozess 43 Automatic Database Diagnostic Monitor 17 Automatic Workload Repository 48, 173 AWR-Report 17 B Baseline 8, 9, 183, 206 Abweichung von der 191 Fixed 186 Moving Window 186 Repeating 186 Basic Relation Model 72 Benchmark 114 Benchmark Utility für Oracle-Datenbanken 146, 147 Benchmarks, Skalierung 161 Benchmark-Modell 20, 21, 29, 39, 145 Berichterstellung 193 Bestimmtheitskoeffizient 78, 80 Bestimmungskoeffizient 85, 86, 100 Betriebssystem-Authentifizierung 44 Betriebssystem-Ebene 47 Betriebssystem-Statistik 189 Budgetplanung 2 Buffer Cache Hit Ratio 171 Buffer Gets 18, 116 C Capacity Management 2, 3, 4, 5, 8, 105, 148, 184 Capture-Prozess 149, 151 Change Management 4, 8 Coherency 168 Coherency-Faktor 170, 177 Concurrency 137, 140, 141, 168, 199 Concurrency-Probleme 32, 168 Contention 168 Contention-Faktor 169, 170, 177 Continuity Management 3 207

10 Register Correlation Coefficient 77 Covariance 77 CPU-Auslastung 47 Abhängigkeit von 12 CPU-Statistiken 47 CPU-Verbrauch 158 CPU-Warteschlangen 113 D Data Dictionary 43, 67, 137 Data Warehouse 114 Database Replay 29, 148 Datei-Layout 130 Dateiverteilung, zufällige 133, 134 Datenbank, Wachstum 6, 17, 158, 183 Datenbank-Applikationen, Entwickler 181 Datenbank-Benchmark 161 Datenbank-Layout 124 Datenbank-Links 42, 45 Datenbank-Metriken 200 Datenbank-Parameter 6 Datenbank-Snapshots 42 Datenbank-Upgrades 6 Daten-Histogramme 6 Device 125 Dichtefunktion 108 DUPLICATE DATABASE-Feature 146 Durchsatzrate 123 E Einführungsphase 168 Einspar-Effekt 168 Enterprise Manager 137, 155, 200 Explanatory Variables 74 Exponentialfunktion 111 Exponentialverteilung 108 F Fehleranalyse 99 Fehlerbetrachtung 129, 135 der Stichprobe 92 Fehlereinschätzung 73 Fehlergrafik 23, 24 Fehlerhistogramm 20, 25, 82, 85, 86 Fehlerminimierung 76 Fehlerquadrate Methode der kleinsten 22, 23 Summe der 76 Fehlerquelle 73 First Come First Served 106 Forecast-Bericht 23, 92, 118 Forecast-Genauigkeit 71 Forecast-Modell 19, 20 mathematisches 20, 21, 69 Fragmentierung von Tabellen 6, 7 Freiheitsgrad 87 Fremdrechenzentrum 168 F-Test 87 Full Index Scan 17 Full Table Scan 6, 17, 53, 157, 160 Funktionsparameter, unabhängige 71 G Gammaverteilung 110 Geschäftsprozesse, Behinderung 160 Gleichungssystem, lineares 25, 96 Glockenkurve 25, 82 Gustafson 31 Gustafson-Gesetz 166 H Hash-Wert 63 Histogramme 7 Hot Spots 7 für Tabellen 6 I I/O-Durchsatz 27, 47 I/O-Operationen, physikalische 17 I/O-Statistik 41, 125 I/O-Subsystem 109 Forecast für 123 Independent Variables 74 Inferenz, statistische 87 Inferenz-Methode 89 Intercept 75, 77 iostat 42, 52 iostat-kommando

11 Register IT-Budget 2, 27, 144 IT-Infrastruktur 3 K Key Performance Indicators 193 King-Kong-Effekt 78 Kipp-Effekt 16, 171 Konfidenzanalyse 92 Konfidenzintervall 22, 23, 88, 100, 103 Korrelationskoeffizient 77 Kostenfaktor 147 Kostenmodelle 2 L Little s Law 107, 112 Locking-Probleme 178 Locking-Verhalten 62, 65 Logical Volume 123 Long Duration-Metriken 55 M M/M/1 Queue 108, 120 M/M/k-Queue 120 Management Summary 93 Mean Square Deviation 72, 73 MEMORY_MAX_TARGET 52 Metadata-Informationen 153 Methode der kleinsten Quadrate 76 Mittelwert, statistischer 13, 14 Monitoring, mehrstufiges 36, 183, 184 Monitoring-Stufen 189, 190 Multiple Server Queue 107 N Netzwerkpläne 107 Normalverteilung 25, 99 Normalverteilungskurve 82 O OLTP-Systeme 114 Optimizer 62, 185 Optimizer-Statistik 206 Ordinary Least Squares 84 Original-Workload 146 P Paging-Aktivität 52 Parallelisierung 30, 31 Parallelisierungsgrad 31, 32, 171 Parallel-Server-Prozesse 107 partitionierte Tabellen 6, 7 Performance-Gewinn 134 Performance Management 4 Performance Monitoring 5, 16, 35, 183 Performance-Probleme 3, 21, 113 Vorhersage 194 Performance-Verlust 185 Performance-Vorgaben 16, 183 Performance-Vorhersage 8 Physical Reads 62 Physical Writes 62 Planstabilität 62 Poisson Arrivals 109 Poisson Service Times 109 Poisson-Verteilung 109 Präzision des Forecasts 120 Produktions-Workload 97 Q Quantil der t-verteilung 90, 192, 193 Queue, Ende 113 Queuing-Modell 21, 26, 27, 105, 197 Queuing-Netzwerk 107, 108 Queuing-Theorie 21, 23, 24, 26, 105, 136 R Real Application Testing 8, 146, 148 Redo Log-Aktivitäten 132, 133 Regression Analysis, Simple 75 Regression Forecast, Simple 86 Regression Model Multiple 74, 95 Simple 74 Regressions-Analyse 20, 23, 24, 74, 103 Regressions-Methode, lineare 22 Regressions-Modell lineares 21, 74 multiples lineares 25 Regressions-Verfahren

12 Register Replay-Clients 154 Replay-Prozess 150, 153 Residual-Grafik 85 Residuals 80 Ressourcen-Auslastung 53, 74 Risk Management 1 Rohdaten 12, 35, 37, 47 Aufbereitung 187 Sammeln 39 Runqueue 16, 23 S Sammelprozess 37 sar 42 Scatterplot-Grafik 15 Schätzformel 102 Schätzvektor 97 Schätzwert 76 Schwellenwerte des Workload Monitoring 9 Schwellwerte 190 Schwellwert-Statistik 202 Schwellwert-Verletzung 194 SELECT_CATALOG_ROLE 46, 67 Service Level Agreement 1, 2, 50, 183 Service Process 108 Servicerate 112, 113 Servicezeit 26, 112 ungewichtet 129 Short Duration-Metriken 55 Signifikanz 87 statistische 191 Signifikanzniveau 189, 190 Signifikanztest 192 Single Server Queue 106 Skalierung 29, 30, 162, 163 Skalierungsfaktor 166, 173 Skalierungsgrad 169, 170 Skalierungsmethoden 20 Skewness 78, 80 Slope 77 Snapshot-Intervall 48, 52, 53, 66, 179 Speedup 30, 31, 165 SQL-Anweisungen, TOP 62 SQL-Ausführungspläne 205 Monitoring 200 SQL-Optimizer 6, 148 SQL Performance Analyzer 148 SQL Tuning Advisor 206 SQL-Tuning-Maßnahmen 158, 159 SQL-Überwachung 42, 64 Squared Errors, Sum of 76 Standardabweichung 73, 192 Standardfehler 88 Statistiken auf Datenbank-Ebene 52 mathematische 20, 21, 69 Statistik-Paare 75 Stichprobe 22, 95 Auswertung 19 Qualität 21 Signifikanz 20 Summary Management 7 Super-Serial-Methode 32 Super-Serial-Skalierung 168 System-Forecast 136 System-Integratoren 148 T Target-Datenbank 19 TPC-Organisation 145 TPCC 145 TPCH 145 Transaktion in einer Queue 113 Transaktionsaufkommen 58 Transaktions-Statistik 57 U Upgrades 6 User Acceptance Testing 8 V vmstat 42, 52 v$metric_history 54 v$sessmetric 59 v$sesstat 59 v$sqlarea

13 Register v$sysmetric 54, 131 v$sysmetric_history 54 v$sysmetric_summary 54 V$-Views 43, 173 Variance explained 80 total 80 Varianz 73 Verteilung asymmetrische 78, 80 deterministische 108 Erlang- 108, 110 geplante 130 Markov'sche 108 negative 110 Verteilungsbild 24 Verweildauer, durchschnittliche 107 vmstat-kommando 16 Vorhersage, Zuverlässigkeit 145 W Wachstum der Datenbank 7 Wahrscheinlichkeitsrechnung 20, 21 Waiting Line 106 Waiting Room 106 Wait-Klassen 195 Wartesituationen 137 Wartezeit 26 Workload der Datenbank 8, 41 Workload-Erhöhung 141, 142, 144 Workload-Perspektiven 36, 47 Workload Preprocessing 149, 153 Workload Repository 19, 37, 44, 183, 185 Eigentümer 46 Workload-Simulation 146 Workload-Statistiken 9, 35 Qualität 36 Sammeln von 11 wrc-programm 154 Z Zufallsvariablen