Performance-Stabilisierung beim Upgrade

01.
Dezember
2017
Veröffentlicht von: Katja Werner

Dieser Monatstipp beschreibt aus der Sicht eines Datenbankadministrators, wie man an ein Upgrade herangehen kann und welche Schritte erforderlich sind, um es erfolgreich durchzuführen. Besonderer Wert wird dabei auf die Sicherstellung der Performance gelegt. Nicht eingegangen wird auf konkrete Upgrade-Strategien.

UPGRADE? – WARUM?

Meist wird ein Upgrade als lästige Aufgabe gesehen, die vor allem deshalb erledigt werden muss, um weiterhin Support und Bugfixes von Oracle zu bekommen. Ein weiterer Grund für ein Upgrade ist, dass Features eingesetzt werden sollen, die nur in einer höheren Version verfügbar sind. Manchmal wird auch für ein Upgrade in der Hoffnung plädiert, dass die neuere Datenbankversion performanter ist – was im Übrigen in der Praxis nicht per se der Fall ist.
Auch wenn es sich anbietet, das Datenbank-Upgrade mit dem Tuning der Performance oder der Einführung neuer Features zu verknüpfen, tut man sich in der Vorbereitung deutlich leichter, wenn man diese drei Aufgabenbereiche gedanklich voneinander trennt. Nichtsdestotrotz kann die hier vorgestellte Herangehensweise auch für das Performance-Tuning oder die Sicherstellung der Performance bei der Implementierung neuer Features verwendet werden.

WANN IST EIN UPGRADE ERFOLGREICH?

Für die Mehrheit der Datenbankadministratoren ist ein Upgrade dann erfolgreich, wenn sich die Performance der Datenbank nicht verschlechtert. Der Endanwender soll nicht spüren, dass es an der Datenbank Änderungen gab. Ausgenommen sind natürlich Änderungen zum Guten wie zum Beispiel Performance-Verbesserungen. 
Die Vorbereitung des Upgrades zielt also im Wesentlichen darauf ab, eine stabile Performance zu gewährleisten.

WIE STELLE ICH ES AN?

Möglichst alle negativen Auswirkungen des anstehenden Datenbank-Upgrades im Voraus erkennen und beheben – dies ist Grundlage für ein erfolgreiches Upgrade. Worauf genau sollte ich bei einem Upgrade achten? – Darauf gehen die kommenden Abschnitte ein.

 INIT.ORA PARAMETER

Interessant für ein Upgrade sind immer die neu hinzukommenden Parameter oder auch Änderungen ihrer Defaults. Ein Vergleich der Parameter in der alten und neuen Datenbankversion hilft, besser zu verstehen, welche Komponente sich nach einem Upgrade anders verhalten kann.
Lassen Sie sich nicht durch die Anzahl der Parameter verunsichern. Oft gibt es einige wichtige, die ohnehin bereits innerhalb der Oracle Community, im My Oracle Support oder auf diversen Websites oder in Zeitschriften (zum Beispiel Muniqsoft Newsletter oder DOAG News) diskutiert werden. Auf diese sollte man sich zu Beginn konzentrieren.
Mit folgendem SQL lassen sich alle init.ora-Parameter aus der Datenbank direkt herausspoolen:

set pagesize 100 linesize 200
col name format a40
col value format a30
col default_value format a30
col isdeprecated format a30

select name, value, default_value, isdeprecated
from v$parameter
order by name;

Anschließend können diese Parameter für beide (oder mehrere) Oracle Versionen leicht in einem Excelsheet nebeneinander gestellt, sortiert und verglichen werden. So lassen sich Unterschiede ausgezeichnet erkennen.
Zum Beispiel kann man folgende Parameter erkennen, die für die Version 12.2.0.1 im Vergleich mit Oracle 12.1.0.2 hinzukamen und Auswirkungen auf das Verhalten des Optimizers und damit auf die Performance der SQL-Statements haben:

optimizer_adaptive_plans
optimizer_adaptive_statistics
parallel_adaptive_multi_user
parallel_min_time_threshold

Die beiden erstgenannten Parameter ersetzen den erst in Oracle 12.1. eingeführten Parameter optimizer_adaptive_features. Für ein Upgrade lautet unsere Empfehlung diesbezüglich: ist dieser Parameter in der Datenbank auf FALSE gesetzt, sollten auch die Parameter  optimizer_adaptive_plans und optimizer_adaptive_statistics im ersten Schritt auf FALSE gesetzt werden.
Auch bezüglich der In-Memory Option gibt es einige neue Parameter, die Hinweise auf Verbesserung und Änderungen im zu erwartenden Verhalten der Datenbank geben:

inmemory_adg_enabled
inmemory_expressions_usage
inmemory_virtual_columns

Darüber hinaus gibt es einige Parameter, die auf verbesserte und neue Features hindeuten. In der Version 12.2.0.1 kamen viele Parameter hinzu, die die Multitenant Option betreffen. Ein weiteres Beispiel ist der Parameter encrypt_new_tablespaces, der sicherlich in vielen Umgebungen sinnvoll einsetzbar ist.
Was die einzelnen Parameter bedeuten, kann meist der Oracle Reference entnommen werden. Dort, wo es keine Dokumentation in der Oracle Reference gibt, helfen der sprechende Name des Parameters oder eine Suche im My Oracle Support weiter.

BUGS UND PATCHES

Dass das aktuellste Patchset implementiert ist, sollte selbstverständlich sein. Zudem lohnt sich eine Suche in der Knowledge-Base und der Bugliste im My Oracle Support (siehe Bild). Die Ergebnisse müssen dahingehend geprüft werden, was für die eigene Umgebung relevant sein könnte.
 



KRITISCHE SQL-STATEMENTS

Es gilt, sich aus der Vielzahl von Statements, die auf einer Datenbank laufen, diejenigen herauszupicken, die sich nach einem Upgrade nicht performant verhalten werden. Wie findet man aber diese Statements? Dafür gibt es drei Möglichkeiten:

  1. Zuallererst sollten Statements, die bereits in der bestehende Oracle Datenbankversion eine lange Laufzeit haben, auf ihr Verhalten in der neuen Datenbankversion hin geprüft werden. Sehr gut kann man diese Top SQL-Statements im STATSPACK- oder AWR-Report erkennen. Sie sind – unter anderem – sortiert nach Elapsed Time, CPU-Verbrauch oder Summe an I/O. Eine weitere Quelle ist die Summe der ELAPSED_TIME_DELTA-Werte aus der DBA_HIST_SQLSTAT-View, aufsummiert und gruppiert nach SQL_ID. Die Nutzung des AWR-Reports, ebenso wie die Abfrage der DBA_HIST_*-Views bleibt nur Nutzern, die das Diagnostic Pack lizenziert haben, vorbehalten. Allen anderen bleibt der Weg, die V$SQL regelmäßig in eine separate Tabelle abzuziehen und hier nach den SQL-Statements mit den längsten ELAPSED_TIMEs zu suchen.

  2. Top Statements in der neuen Oracle Version sind natürlich ebenfalls sehr wichtig. Diese können sich aufgrund von geändertem Optimizer-Verhalten oder anderen Bugs durchaus von den Statements aus Punkt 1 unterscheiden. Sie finden diese Statements mit genau denselben Methoden, nur dass Sie eben auf einer Testdatenbank mit der höheren Oracle Version suchen.

  3. Weitere Statements, die beachtet werden sollten, sind die, die schon in der aktuellen Version häufig mit unterschiedlichen Ausführungsplänen ausgeführt werden. Dies sind Statements, bei denen der Cost Based Optimizer Probleme hat, einen oder zwei „richtige“ Ausführungspläne zu ermitteln. Kommen nun noch die Änderungen am Optimizer-Verhalten  in der neuen Oracle Datenbankversion hinzu, sind solche Statements besonders anfällig für Performance-Verschlechterungen. Häufig fällt so etwas auch erst in der produktiven Umgebung auf, denn dort laufen die Applikationen mit unterschiedlicher Last und das Problem mit unterschiedlichen Ausführungsplänen, kommt dadurch verstärkt zum Tragen.

Finden kann man diese „Art“ Statements, indem man die im ersten Punkt genannten Views der aktuell produktiven Umgebung nach SQL_ID und Anzahl unterschiedlicher PLAN_HASH_VALUEs selektiert:

select sql_id, plan_hash_value, count(*)
from v$sql
group by sql_id, plan_hash_value
order by 3
/

Nun haben wir eine Liste von SQL_IDs mit ihren PLAN_HASH_VALUEs, auf die während der Tests und des Upgrades besonderes Augenmerk gelegt werden muss. Je nach zur Verfügung stehender Zeit, können mehr oder weniger Statements betrachtet werden, solange man immer bei den kritischsten beginnt.

TESTEN, TESTEN, TESTEN

Nichts gibt ein ruhigeres Gefühl für ein Upgrade als das vorhergehende Testen. Das Testen Ihrer Applikationen auf der neuen Oracle Version ist existentiell, um die zukünftige Performance beurteilen oder frühzeitig auf Bugs stoßen zu können. Die Tests sollten immer auf einer Umgebung (Datenbank, Maschine, Applikationsversion) erfolgen, die vergleichbar mit der Produktionsumgebung ist. Die Maschine muss nicht ganz so leistungsfähig sein, aber zumindest die Software, die auf der Datenbank läuft, sollte eine vergleichbare Last wie in Produktion erzeugen können. Wenn dies nicht der Fall ist, sind zumindest Aussagen zur zukünftigen Performance schwerer zu treffen.


Die Testläufe werden zuerst in der aktuellen Datenbankversion durchführt. Die Ergebnisse – Laufzeiten, Top SQL, Ausführungspläne, I/O, Load usw. – werden mit dem aktuellen Verhalten in Produktion verglichen. So bekommt man einen Eindruck, inwieweit das Testsystem das Verhalten auf dem produktiven System widerspiegelt. Und damit auch, inwieweit der Upgrade der Testumgebung Rückschlüsse auf den zu erwartenden Verlauf des Upgrades in der produktiven Umgebung zulässt.


Erst dann wird ein Upgrade der Testumgebung durchgeführt und dieselben Testläufe werden wiederholt. Besondere Aufmerksamkeit gilt hier auch den SQL-Statements, die im Schritt 3 als kritisch für das Upgrade eingestuft wurden. Die Laufzeiten und Ausführungspläne der Statements werden verglichen und auf mögliche Verschlechterung geprüft. Auf dieser Grundlage erfolgen eine zielgerichtete Anpassung von Parametern sowie das Performance-Tuning. Durch die erneute Wiederholung der Testläufe wird sichergestellt, dass die Änderungen tatsächlich hilfreich sind. Alle Anpassungen von Parametern und Statements müssen auch später beim produktiven Upgrade erfolgen.


Wichtig ist die Dokumentation und Aufbewahrung von Testläufen. Dafür werden die AWR- oder STATSPACK-Reports, die während der Tests auf der alten und der neuen Oracle Datenbankversion erzeugt wurden, aufbewahrt. Auch gesetzte init.ora-Parameter, SQL-Statements, Laufzeiten sowie Ausführungspläne gehören in die Dokumentation. Dieselben Daten werden für die produktive Umgebung gesammelt. Dies alles kann später, beim Upgrade der Produktionsumgebung für Vergleiche hinzugezogen werden und erleichtert das Beheben von Performance-Verschlechterungen ungemein.

UND WAS GIBT’S NOCH?

An diesem Punkt ist ein Upgrade so gut vorbereitet, dass keine Performance-Verschlechterungen zu erwarten sind bzw. diese schnell korrigiert werden können.
Abgesehen von der Sicherstellung der Performance müssen für ein Upgrade natürlich noch viele andere, wesentliche Themen geklärt werden. So zum Beispiel:

  • Upgrade-Pfad
  • Fallback-Möglichkeiten
  • Möglichkeiten zur Stabilisierung der Performance (SQL Plan Baselines, SQL Profile, SQL Patches, Hints, Stored Outlines)
  • Kompatibilität von Applikationen, 3rd Party Tools, Infrastruktur

Sollten Sie hierzu Fragen haben, Öffnet internen Link im aktuellen Fenstersprechen Sie uns an.

Upgrade DBA Tuning Performance

Jede Menge Know-how für Sie!

In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.