SQL-Tuning als iterativer Prozess

Tuning als iterativer Prozess

Unter Tuning wird hier die zielgerichtete Verbesserung von Eigenschaf-
ten des Gesamtsystems aus Datenbank und Anwendung verstanden.
Tuning ist ein Teil der Performancesicherung und immer aufgabenbe-
zogen. Es endet mit dem Erreichen des gesetzten Ziels oder der Fest-
stellung, dass das Ziel mit den gegebenen Ressourcen nicht erreicht
werden kann.

Tuning – egal in welcher Umgebung – ist ein iterativer Prozess.

• Es ist wichtig, die einzelnen Tuningschritte nacheinander auszufüh-
  ren und zu bewerten. Eine Datenbank mit den darauf laufenden An-
  wendungen kann als ein (relativ) komplexes System angesehen
  werden. Um Aussagen über die Relevanz eines Einflussparameters
  zu erhalten, müssen während der Messung die anderen Parameter
  gleich gehalten werden.


• 
  Nach jedem Tuningschritt wird geprüft, ob das Ergebnis den definier-
  ten Zielen genügt. Falls nicht, wird eine weitere Iteration vorgenom-
  men.
  Der Nachweis über eine Verbesserung kann nur durch Messungen er-
  bracht werden. Verschiedene Varianten können nur über Messungen
  verglichen werden. Die Messungen sollen Dokumentiert werden, damit
  sie miteinander verglichen werden können.
  

Girokontovergleich

Performanceengpässe und Antwortzeiten

Performanceengpässe werden in der Mehrzahl der Fälle an der Ant-
wortzeit fest gemacht.

Im Allgemeinen wird unter Antwortzeit die Latenz zwischen dem Ab-
senden eines Requests durch den User und der Reaktion durch das
Anwendungssystem verstanden. Dies ist die abstrakte Antwortzeit aus
Usersicht. Auf technischer Ebene muss diese Zeitspanne als Summe
mehrerer Teilkomponenten betrachtet werden:

Programmzeit Client
+ Netztransfer zur DB
+ Datenbankzeit
+ Netztransfer zum Client
+ Programmzeit Client
---------------------------------
= Antwortzeit User

Oftmals wird die Datenbank zu Unrecht für unbefriedigende Antwortzei-
ten verantwortlich gemacht. Punktuelle Netzüberlastung und langwieri-
ge Folgeaktionen im Client-Programm (z. B. Umsetzen der Ergebnis-
menge in eine GUI-Darstellung) gehen in die Antwortzeit ein, sind je-
doch mit den Mitteln der Datenbankoptimierung nicht beeinflussbar.
Zur Gewinnung exakter Angaben über die Laufzeiten von Statements
sollten deshalb alle anderen Teilkomponenten ausgeschlossen werden.
Zeitmessungen innerhalb des SQL-Optimierung erfolgen idealerweise
direkt auf dem Datenbankserver.

Das Messen und Dokumentieren der Antwortzeiten ist wesentlich für
ein qualifiziertes Vorgehen bei der Optimierung. Für jeden DBA oder
Entwickler ist es frustrierend, sich mit der „gefühlten“ Antwortzeit der
Enduser („ist irgendwie langsam“, „könnte manchmal schneller sein“)
auseinanderzusetzen.

Performancesichernde Maßnahmen

Performancesichernde Maßnahmen

Im Allgemeinen sollen potentielle Engpässe früh erkannt und Entwick-
lungskosten reduziert werden.
Die Aufgaben und die Ziele performancesichernder Maßnahmen variie-
ren je nach Projektfortschritt. Im Folgenden sind einige Punkte darge-
stellt.

• Während der Designphase
⇒ Vergleichsmessungen zur Ermittlung der optimalen Architektur- /
Implementierungsvarianten,
⇒ Bestimmung des zu erwartenden Lastmodells als Grundlage für
Entscheidungen.
• Vor der Produktionseinführung
⇒ Bestimmung des später zu erwartenden Antwortzeitverhaltens,
⇒ Bestimmung des mit dem gegebenen Umfeld realisierbaren
Transaktionsdurchsatzes,
⇒ Lasttest zum ultimativen Nachweis der Erfüllung der Performan-
cevorgaben.
• Nach der Produktionseinführung
⇒ Verbesserung des realen Antwortzeitverhaltens,
⇒ Vorbeugen von Problemen aus dem Anwachsen des Datenbe-
standes.

Basis einer Performanceuntersuchung müssen immer quantifizierbare
Ziele sein. Schwammige Anforderungen, wie z.B.: „Datenbank optimal
aufsetzen“ „CPU-Zeit sparen“ sind wenig hilfreich.
CPU, I/O oder Speicher sparen
Es fehlt die Quantität. Wann ist dieses Ziel je erreicht? Irgendwo fin-
det sich immer eine Verbesserungsmöglichkeit. Aber wie steht es mit
Aufwand / Nutzen?

„Datenbank optimal aufsetzen“
Es gibt keine optimale Datenbank oder optimale Applikation. Das
“Optimum” ist immer an eine konkrete Umgebung und an die Bedürf-
nisse des Anwenders gebunden

Wichtig ist das Setzen von Tuningzielen der Art:
⇒ Wir müssen 500 Buchungen je Minute schaffen.
⇒ Zum Monatsende müssen je Stunde 100.000 Rechnungen erstellt
werden.
⇒ Die Instanz muss 5 Reports parallel verarbeiten können.
⇒ Der Programmzweig „Buchen Zahlungseingang / -ausgang“ darf bei
Volllast (100 Transaktionen / Sekunde) maximal 50 % der Anlagen-
CPU binden.
Auf derartige Ziele lässt sich zielstrebig hinarbeiten. Nach dem Errei-
chen des quantifizierten Ziels kann die Entwicklerkapazität an anderer
Stelle eingesetzt werden.

Performancesicherung als Prozess

Performancesicherung als Prozess

Performance wird oftmals direkt an den Begriff Tuning gebunden. Der
Begriff Tuning wiederum steht in der Praxis viel zu häufig für den Ver-
such, zu retten was zu retten ist. Das Motto lautet: „Erst einmal pro-
grammieren, und am Ende kümmern wir uns um die Performance“.
Dieses Vorgehen reduziert Performancesicherung unzulässig auf das
nachträgliche Optimieren von Abläufen und Strukturen.

In späten Projektphasen sind die Freiheitsgrade für Änderungen gering.
Architekturentscheidungen beispielsweise können nur mit enormem
Aufwand geändert werden.

Performancesicherung ist ein Prozess! Er beginnt spätestens mit
der Entscheidung für die Realisierung. Performancesicherung ist
Qualitätssicherung!

Eine durchgehende Performancesicherung erfordert die Kooperation der an Entwicklung und Betrieb beteiligten Personen. Eine Auswahl an Aktionen sollte dabei immer unter allen Mitwirkenden diskutiert werden.

SQL und seine Laufzeitumgebungen

SQL und seine Laufzeitumgebungen

SQL ist nicht gleich SQL. Je nach Umgebung variiert, welcher methodi-
sche Ansatz als „gut“ oder „ungünstig“ angesehen wird.
Im Rahmen des Kurses geht es um „zweckmäßiges“ SQL. Aufbauend
auf dem syntaktischen und theoretischen Basiswissen soll jeder Teil-
nehmer für seine Umgebung entscheiden können, welche konkrete
Ausprägung von SQL-Varianten in seinem Projektumfeld günstig ist.
SQL-Statements lassen sich nach unterschiedlichen Gesichtspunkten
kategorisieren. Dabei finden technische und organisatorische Aspekte
Berücksichtigung:

• Unterscheidung nach Art der Generierung:

⇒ statisches SQL:
select count(*) from emp where deptno = :nr

⇒ dynamisches (natives) SQL:
execute immediate ’select count(*) from emp
where deptno = 10’

• Unterscheidung nach dem Umfeld

⇒ Data Warehouse (DWH) / Decision Support Service (DSS):
select produkt, region, zeitraum, sum(betrag)
from verkauf, produkt, region, zeit where ...
group by produkt, region, zeitraum

• Unterscheidung nach der Ablaufumgebung:

⇒ Interaktiv:
Direkter Datenzugriff durch geschulte Nutzer über interaktive
Front Ends,

⇒ Embedded SQL (ESQL) / OCI:
Datenbankaufrufe aus einer 3GL Programmiersprache, meistens
C oder Cobol,

⇒ ODBC / JDBC:
Kommunikation über datenbankherstellerunabhängige Stan-
dards,

⇒ PL/SQL:
Aufruf von Statements aus Serverprozeduren, welche i. d. R.
wiederum in Applikationen eingebettet sind.
Je nach konkreter Ausprägung der Umgebung treten unterschiedliche
Aspekte der Verarbeitung und Optimierung in den Vordergrund. Diese
Sichtweise wird im Verlauf des Kurses immer wieder aufgenommen.

SQL und Performancesicherung

SQL und Performancesicherung

Das Ablegen von Informationen in der Datenbank ist kein Selbstzweck.
Die Daten sollen bei Bedarf zeitnah am Bildschirm bzw. im Programm
zur Verfügung stehen. Das Bereitstellen der Daten übernimmt der Orac-
le-Server. Jeder Zugriff ist mit Kosten in Form von CPU-Zeit und Plat-
tenzugriffen verbunden.

Wenn Datenbank oder Anwendung nicht performant laufen, sehen wir
die Erscheinungen:

• „Lange Antwortzeit“,


• „Datenbankmaschine ist CPU-bound“ oder auch
  


• „IO Subsystem ist überlastet“.
  

Die Ursache, vorausgesetzt das System ist hardwareseitig plausibel
dimensioniert, sind jedoch die Kosten der SQL-Anweisungen oder
Mängel in der Konfiguration. Dabei darf SQL nicht auf „Select“ reduziert
werden, auch DML und periodisch wiederkehrende DDL-Anweisungen
müssen berücksichtigt werden.

Angesichts dieser Betrachtung lässt sich leicht zugespitzt behaupten:
Datenbankoptimierung besteht im Wesentlichen aus 3 Schritten:

1. SQL Optimierung


2. SQL Optimierung


3. SQL Optimierung

SQL-Optimierung kann – je nach konkretem Umfeld und Statement –
eine Reduzierung des Ressourcenverbrauchs um Faktor 100, Faktor
1000 oder noch mehr nach sich ziehen. Derartige Steigerungen sind mit
den Mitteln des Instanztunings nicht erreichbar.
Tuningmaßnahmen können sich auf einzelne SQL-Statements oder auf
eine gesamte Applikation erstrecken.

Bei der Auswahl der Aktivitäten ist immer zu berücksichtigen, dass inef-
fiziente Statements im Mehrbenutzerbetrieb auch das Antwortzeitver-
halten anderer User negativ beeinflussen.

Einflussfaktoren auf SQL-Performance

Einflussfaktoren auf SQL-Performance

SQL ist mehr als „das Statement an sich“. Unbedingt mitbetrachtet wer-
den muss das Konzept des Datenzugriffs. Die von einem Programm
abgesetzten Statements können für sich performant sein, trotzdem
werden ggf. Ressourcen unnötig beansprucht. Typische Fälle ineffizien-
ter Zugriffe sind z. B. in Einzeltabellenzugriffe aufgelöste Joins.

Von großer Bedeutung ist natürlich das logische Datenmodell: Sind die
Informationen und ihre Beziehungen zueinander klar strukturiert? Müs-
sen u. U. wegen Designfehlern Redundanzen verwaltet werden? Ande-
rerseits kann es sein, dass durch bewusste Verletzung der Normalisie-
rungsregeln (und planmäßiger Verwaltung von Redundanzen) komple-
xe Aktionen sehr viel effizienter ausgeführt werden können.

Nicht zu unterschätzen ist der Einfluss des physischen Datenmodells.
Theoretisch kann eine Kredit-Datenbank von 100 GB auf einer Platte abgelegt
werden. Aber kann eine solche Umgebung 50 konkurrierende User zu-
frieden stellen? Die relativen Kosten eines Plattenzugriffs sind hier sehr
hoch. Verschiedene der im Kurs vorgestellten Features können in einer
solchen Umgebung gar nicht sinnvoll eingesetzt werden.

ORACLE Hacker ist online

ORACLE Hacker zeigt dir wie man mit ORACLE arbeitet.
Hole Dir täglich eine Lektion ORACLE auf deinen Computer.
Follow uns bei Twitter.

Wer ist ORACLE Hacker:
ORACLE Hacker sind EX-ORACLE Mitarbeiter aus den Bereichen Datenbank Programmierung, PL/SQL, XML Publisher, SQL und ORACLE Finance. Wenn du also wirklich was über ORACLE lernen willst, dann bist du hier genau richtig.

Alle ORACLE Hacker Autoren sind mehrfach von ORACLE Zertifiziert. OCA, OCP, OCM ....

Viel Spaß bei ORACLE Hacker