Unser Newsletter rund um technische Themen,
das Unternehmen und eine Karriere bei uns.

3 Minuten Lesezeit (617 Worte)

Patchen mit Zero Downtime – geht das? Oracle Rolling Patches


Patches sind im Alltag eines Oracle DBAs ein immer wiederkehrender Vorgang. Aber wie lässt sich dieser effizienter und sicherer gestalten? In folgenden Beitrag wird besprochen, was Rolling Patches sind, und welche Vor- und Nachteile diese für den Alltag des Patchens darstellen.


Was sind rolling patches und wozu dienen sie?

Rolling Patches sind eine Patching-Strategie, bei der ein Software- sowie ein Datenbank-Patch rollierend eingespielt werden. Diese Strategie wurde erstmals in der Version 11g Release 1 in der Oracle Maximum Availability Architecture empfohlen. Mittlerweile gibt es mehrere Möglichkeiten, wie Rolling Patches durchgeführt werden können. Zwei dieser Verfahren werden wir uns in diesem Blogbeitrag genauer anschauen.

Grundsätzlich besteht ein Rolling Patch aus mehreren Phasen, welche der Abbildung entnommen werden können:

  1. Aufbau einer Physical-Standby-Datenbank (falls nicht vorhanden)
  2. Konvertierung der Physical-Standby- in eine Logical-Standby-Datenbank
  3. Patchen der Standby-Umgebung mit anschließendem Switchover
  4. Mischbetrieb und Testen des neuen Patches
  5. Patchen der Primärumgebung mit anschließendem Switchover
  6. Konvertieren der Logical-Standby-Datenbank in eine Physical-Standby-Datenbank
Konzept Rolling Patches

Welche Methoden gibt es? 

Grundvoraussetzung für Rolling Patches ist eine Data Guard Konfiguration mit einer physikalischen Standby-Datenbank. Im Rahmen meiner Bachelorthesis wurde der Fokus auf ein manuelles und ein halbautomatisiertes Verfahren gelegt, namentlich "Transient Logical Standby" und "DBMS_ROLLING". 

Transient Logical standby 

Transient Logical Standby ist ein Verfahren, welches ohne weitere Lizenzkosten verwendet werden kann, um eine minimale Downtime bei einem Patch-Vorgang zu erreichen. Dabei werden die einzelnen Schritte manuell durchgeführt. Wie der Name bereits sagt, wird eine transiente logische Datenbank aufgebaut, welche dann gepatcht werden kann. Währenddessen kann der Betrieb auf der Primärdatenbank wie gewohnt weiterlaufen. Durch einen Switchover werden dann die Rollen der Datenbanken getauscht. Dabei entsteht eine "minimale" Downtime für Applikationen. Oracle selbst beschreibt in der High Availability Overview, dass ein solcher Switchover eine Downtime von Sekunden bis hin zu wenigen Minuten verursachen kann.

Für diese Methode ist das Know-how des DBAs wichtig. Nicht nur, dass jeder Schritt genauestens überwacht werden muss. Er sollte sich ebenfalls gut mit dem Data-Guard-Konstrukt und dem Broker auskennen, um Fehler und damit einhergehende, ungeplante Ausfallzeiten verhindern zu können. 

DBMS_ROLLING 

Eine weitere Möglichkeit ist das PL/SQL-Package DBMS_ROLLING. Die verwendeten Prozeduren automatisieren einen Großteil der Schritte, welche bei Transient Logical Standby manuell durchgeführt werden. Nachdem ein Plan initialisiert und gebaut wurde, werden die nachfolgenden Jobs in drei Kategorien unterteilt: „START", „"SWITCHOVER" und „FINISH". Lediglich das Patchen der Datenbank muss hierbei manuell durchgeführt werden. Bei einem Fehler ist die Verfügbarkeit weiterhin gesichert. Außerdem können die Jobs in den meisten Fällen nach der Fehlerbeseitigung neu gestartet werden.

Bei dieser Methode ist jedoch darauf zu achten, dass bei Verwendung des Packages die Oracle-Active-Data-Guard-Lizenz aktiviert wird. 

Patchen mit Zero Downtime – geht das? 

Ganz ohne Downtime können wir allein mithilfe dieser Verfahren noch nicht patchen. Um eine Zero-Downtime zu erreichen, wird ebenfalls Oracle Golden Gate benötigt. Dabei entstehen nicht unerhebliche Mehrkosten. Eines kann jedoch festgehalten werden: Wenn die Hochverfügbarkeit während des Patch-Vorgangs gesichert werden soll und die Zeit außerdem knapp ist, sind diese Methoden ein guter Schritt in die richtige Richtung.

In einer Testreihe im Rahmen meiner Bachelorthesis stellte sich heraus, dass die geplante Downtime bei den rollierenden Verfahren etwa um den Faktor 15 schneller war als die Testreihe mit einem Primary- oder Standby-First-Patch.


Quellen: 

Oracle White – Oracle Database Rolling Upgrades (Online unter: https://www.oracle.com/technetwork/database/availability/database-rolling-upgrade-3206539.pdf)

Oracle Database 19c – High Availability Overview (Online unter: https://docs.oracle.com/en/database/oracle/oracle-database/19/haovw/ha-planned-downtime.html)

Justine Baier - Patching-Verfahren bei Oracle Datenbanken - ein Vergleich von manuellen und halbautomatisierten Verfahren im Hinblick auf Hochverfügbarkeit und Kosten

 

Kommentare

Derzeit gibt es keine Kommentare. Schreibe den ersten Kommentar!
Sonntag, 22. Dezember 2024

Sicherheitscode (Captcha)

×
Informiert bleiben!

Bei Updates im Blog, informieren wir per E-Mail.