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.
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.
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.
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.
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.
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:
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.
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.
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:
Sollten Sie hierzu Fragen haben, sprechen Sie uns an.
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.