Oracle 12c - Das umfassende Handbuch

367

Kapitel 16

Upgrade und Patching

Ein Upgrade auf eine neue Datenbankversion ist mit vielen Unsicherheiten ver-

bunden. Am Anfang steht die Auswahl des Upgrade-Pfads und der Upgrade-

Methode. Vor dem eigentlichen Upgrade der produktiven Datenbank sollte die

gesamte Prozedur auf einer Testdatenbank praktiziert und validiert werden. Darü-

ber hinaus stellt sich die Frage, wie das Upgrade die Performance der Applikation

respektive der SQL-Anweisungen verändert. Mit dem Feature »Real Application

Testing« ist es zum Beispiel möglich, das Verhalten der Datenbank nach dem

Upgrade genau zu bestimmen.

16.1 Ein Upgrade umfassend planen

Für ein Upgrade stehen verschiedenen Methoden und Vorgehensweisen zur Ver-

fügung. Für die Planung sollten in erster Linie die Rahmenbedingungen und Vor-

gaben der Applikation berücksichtigt werden. So bedingen zum Beispiel das zur

Verfügung stehende Fenster und die Vorgabe einer Downtime bestimmte Metho-

den und schließen andere aus. Für eine Entscheidungsfindung ist es notwendig,

dass technische Basisdaten wie Größe der Datenbank oder Basisversion auf dem

Tisch liegen.

Zu den wichtigsten Vorgaben aus Applikations- und Business-Sicht gehören:

쐽 Maximale Downtime für die Applikation(en)

쐽 Abhängigkeiten zu anderen Datenbanken oder Applikationen

쐽 Risikobetrachtungen

쐽 Anforderungen an die Testverfahren

Tipp

Zu jedem Upgrade-Plan gehört eine Fallback-Strategie. Gehen Sie stets davon aus,

dass ein Upgrade aus den unterschiedlichsten Gründen misslingen und eine

Rückkehr zur Originalversion erforderlich sein kann. Planen Sie auch die für das

Fallback erforderliche Zeit mit in das zur Verfügung stehende Fenster ein.

Kapitel 16

Upgrade und Patching

368

쐽 Ist die Zielversion durch die Applikation zertifiziert?

쐽 Testanforderung für Funktionalität und Performance

Folgende technische Aspekte spielen eine wichtige Rolle bei der Auswahl des Ver-

fahrens:

쐽 Größe der Datenbank

쐽 Ausgangsversion und Patch Level

쐽 Möglicher Wechsel des Betriebssystems und des Endian-Formats

쐽 Verbindung des Upgrades mit einem Hardwaretausch

쐽 Migration von Dateisystem nach ASM

쐽 Upgrade von Grid Infrastructure und ASM erforderlich?

쐽 Einschränkungen durch die vorhandene Infrastruktur

쐽 Backout-Optionen

쐽 Verhalten der SQL-Anweisungen in der Zielversion

Für die Auswahl des Verfahrens müssen sowohl die Business- als auch die tech-

nische Sicht herangezogen werden. Es ist zum Beispiel möglich, für kleine

Datenbanken, die keine besonderen Features sowie ausschließlich Standard-

objekte in der Datenbank verwenden, ein blindes Upgrade durchzuführen. Es

besteht kein Performance-Risiko, und die Wahrscheinlichkeit ist gering, in Pro-

bleme oder verändertes Verhalten zu laufen. Steht das Upgrade einer großen

Datenbank an, besteht ein höheres Risiko, dass zum Beispiel Ausführungspläne

kippen und es zu negativen Auswirkungen auf die Performance der Applikation

kommt.

Wichtig für die Planung ist auch, dass sich alle eingespielten Patches und Bugfixes

in der Zielversion wiederfinden. In der Regel sind Bugs in der höheren Version

beseitigt. Dies ist jedoch nicht zwangsläufig der Fall. Überprüfen Sie vor dem

Upgrade, ob ein Patch in der Zielversion zur Verfügung steht. Im Fall eines Platt-

formwechsels kann es vorkommen, dass der Patch für die neue Plattform nicht vor-

handen ist. Je nach Kritikalität kann dieser Umstand zu einem Show-Stopper

werden.

Tipp

Verbinden Sie das Upgrade einer großen Datenbank mit einem Hardware-

tausch. Damit besteht die Möglichkeit, zum Beispiel unter Einsatz von »Real

Application Testing« das Verhalten der Applikation und der SQL-Anweisungen

in der neuen Version real zu testen.