News zu Servicewelten

Tipps und Tricks zum Patchen von Datenbanken:
Ist eine Downtime immer nötig?

“Ich würde ja meine Datenbanken patchen, aber ich bekomme kein Zeitfenster für eine Downtime!” Diesen Satz hören wir leider viel zu oft. Aber: Muss Patchen denn immer mit einer Downtime verbunden sein? Wenn du dir diese Frage auch schon gestellt hast, dann solltest du unbedingt weiter­lesen. Im Rahmen unserer mehrtei­ligen Blogpost-Serie “Tipps und Tricks zum Thema Patchen” beschäf­tigen wir uns im heutigen Beitrag nämlich genau damit. 

Dazu haben wir mit einigen Spezialisten aus den Teams Oracle, MS SQL und PostgreSQL bei ASPICON gesprochen und sie gefragt, warum Downtimes für viele Kunden eigentlich ein Problem sind und was du tun kannst, um sie möglichst klein zu halten oder gar zu vermeiden. Die Besonderheiten der einzelnen Welten haben wir dann nochmal übersichtlich für dich zusammengefasst.

Das böse “D”-Wort: Warum Downtimes für viele Kunden ein Problem sind

Zunächst sei kurz geklärt: Wenn wir im Folgenden von “Downtime” sprechen, dann meinen wir die gezielte und planmäßige Abschaltung eines Datenbankservers im Rahmen des Patchens, wodurch es in der Regel zu Ausfällen der Anwendungen kommt. Das ist auch genau der Grund, wieso Downtimes weder bei den IT-Verantwortlichen noch bei der Geschäftsleitung sonderlich beliebt sind. Denn die Anwender können während dieser Zeit ihrer Arbeit meist nicht nachgehen oder ganze Produktionsprozesse müssen ruhen. Deshalb ist es für viele Firmen sowie Einrichtungen noch immer ein schwie­riges und zum Teil auch ungeliebtes Thema. Sie nehmen ein erhöhtes Sicherheitsrisiko – was von ungepatchten Systemen ausgeht – in Kauf. Dabei lassen sich Downtimes sowohl gut planen als auch erheblich reduzieren oder sogar ganz vermeiden.

Hinweis:

Die Planbarkeit variiert natürlich von Hersteller zu Hersteller. Oracle z.B. veröf­fent­licht viermal im Jahr ein großes Critical Patch Update (CPU). Die Termine werden jeweils ein Jahr im Voraus bekannt gegeben. Ähnlich ist es bei PostgreSQL. Auch hier kommen die Major Version Releases quartals­weise raus und werden recht­zeitig angekündigt. In der MS SQL Welt hängen die Abstände zwischen dem Erscheinen einzelner Patches von der Lebensdauer des jewei­ligen Produkts ab. Eine Übersicht dazu findest du » hier

Was du tun kannst, um die Downtime deiner Datenbank möglichst klein zu halten

Ein “normaler” Patchablauf bei einem Single Host sieht in der Regel folgen­der­maßen aus: Die Datenbank wird herun­ter­ge­fahren, der Patch einge­spielt und die Datenbank wird auf der gepatchten Software wieder hochge­fahren. Je nach Datenbank, Datenbankgröße und Leistungsfähigkeit der Systeme beträgt die Dauer der Downtime meist eine halbe bis eine Stunde für ein bis zwei Datenbanken. Als Faustregel gilt: Je unregel­mä­ßiger Patches einge­spielt werden, umso länger sind die Downtimes. Regelmäßiges Patchen hilft also auch, die Ausfallzeit zu reduzieren.

Durch den Einsatz von hochver­füg­baren Systemen oder einer zweiten Instanz deiner Software kannst du die Downtime aller­dings darüber hinaus noch erheblich reduzieren. Hier einige Beispiele dazu aus der Oracle und MS SQL Welt:

Downtime reduzieren dank Failover Cluster

Mit dem Failover Cluster von Oracle kannst du die Downtime auf ca. fünf Minuten pro Datenbank reduzieren. Hier hast du zwei oder mehr Hosts, auf denen die Datenbanken verteilt laufen. In dem Fall kannst du die Clusterknoten, die leerlaufen, schon mal aktua­li­sieren und musst im Wartungsfenster nur noch die Datenbank auf den aktua­li­sierten Host schwenken sowie die Änderungen im Dictionary vornehmen.

Kürzere Downtimes dank Standby-Datenbank mit Dbvisit bzw. DataGuard

Eine weitere Möglichkeit bieten sogenannte “Standby-Datenbanken”. Aufgrund der Verteilung der Primärdatenbank und der Standby-Datenbank auf zwei unter­schied­liche Hosts kannst du die Standby-Seite schon vor dem eigent­lichen Wartungsfenster aktua­li­sieren. Im Wartungsslot musst du nur noch die Datenbank schwenken und die Einträge im Dictionary vornehmen. Im Standard Edition Bereich bietet sich hier Dbvisit an. Mit der » Dbvisit Standby MP v11 z.B. lassen sich Standby-Datenbanken für Oracle und MS SQL Server aufbauen und betreiben. Da das Schwenken hier etwas länger dauert beträgt die Downtime im Schnitt ca. zehn Minuten.

Im Enterprise Edition Bereich von Oracle liefert DataGuard entspre­chende Möglichkeiten. Das Wartungsfenster reduziert sich hier auf ca. fünf Minuten. In beiden Fällen hast du den großen Vorteil, dass böse Überraschungen auf der primären Seite der Datenbank verhindert werden, da der Patch zunächst auf der Standby-Seite einge­spielt wird.

Hinweis:

Unabhängig von den Vorteilen, die ein Failover Cluster bzw. eine Standby-Datenbank für das Patchen und die Reduzierung der Downtimes haben, empfehlen wir den Einsatz einer solchen Lösung immer im Sinne der Hochverfügbarkeit und Ausfallsicherheit deiner Datenbanken.

Wie du Downtimes vermeiden kannst

Meist ist für unsere Kunden aber nicht die Länge der Downtime entscheidend, sondern die Tatsache, dass es überhaupt eine gibt. Denn dadurch müssen oftmals Prozesse runter­ge­fahren, danach wieder angefahren und geprüft werden. So wird aus einer halben Stunde Downtime für die eigent­liche Wartung schnell ein zweistün­diger Slot nötig, bis alles wieder ordnungs­gemäß läuft. Leider ist das der Hauptgrund dafür, dass manche Kunden sich vom Patchen distan­zieren – was aus sicher­heits­tech­ni­scher Sicht natürlich verhee­rende Folgen haben kann.

Falls für dich auch eine kurze Downtime zum Problem werden kann, solltest du dir die folgenden Konzepte und Lösungen anschauen, um Ausfälle gänzlich zu vermeiden:

Oracle Application Continuity

Im Enterprise Edition Bereich von Oracle bietet dir eine zusätz­liche Lizenzierung für “Application Continuity” die Möglichkeit, (meist) ganz ohne Downtime zu patchen. Hier sorgt eine zusätz­liche Treiberschicht dafür, dass die Transaktionen für die Zeit der Wartung gepuffert und anschließend nachge­fahren werden. Die Anwendung spürt davon im Idealfall nichts. Das Konzept ist aller­dings ziemlich aufwändig, mit zusätz­lichen Lizenzkosten verbunden und in manchen Fällen trotzdem mit einer kleinen Downtime verbunden.

Oracle Real Application Cluster (RAC) mit Fast Connection Failover (FCF)

Auch diese Möglichkeit setzt die Enterprise Edition von Oracle mit zusätz­licher RAC Option voraus. Die Datenbank läuft in dem Fall nicht nur auf einem Clusterknoten, sondern auf allen. Du kannst also jeden Clusterknoten einzeln updaten und hast dadurch keine Downtime. Dafür muss deine Java Anwendung mit dem Oracle Notification Service (ONS) kommu­ni­zieren. Das hat den Vorteil, dass die bestehenden Anwendungssession neu aufgebaut, Transaktionen zurück­ge­rollt und in einer neuen Session nochmals ausge­führt werden. Somit bemerkt der User nichts von der Wartung. Dies muss aller­dings von der jewei­ligen Anwendung unter­stützt werden. Ist das nicht der Fall, kannst du auch einfach die Clusterknoten nach und nach leer räumen, runter­fahren und updaten. Die Usersessions werden in der Zwischenzeit auf die anderen Clusterknoten ausgelagert.

MS SQL Server “Always On”

Auch Microsoft bietet im Rahmen der Hochverfügbarkeitsumgebung “Always On” die Möglichkeit, ganz ohne Downtime zu patchen. Dank mehrerer Datenbankserver kann einer herun­ter­ge­fahren, gepacht und danach wieder hochge­fahren werden. Anschließend folgt der Schwenk auf den gepatchten Server. Hierbei werden sämtliche Sitzungen zu Client-Anwendungen beendet, was aller­dings im überwie­genden Teil aller Fälle von den ODBC-Treibern abgefangen wird. Du und deine Anwender sollten diesen Moment des Wechsels in der Regel nicht bemerken.

PostgreSQL Server inklusive n‑Knoten-Cluster

Den wohl kosten­güns­tigsten und einfachsten Weg, ohne Downtime zu patchen, bietet zweifelsohne das Open-Source Datenbankmanagementsystem PostgreSQL. Dank einge­bautem Replikationsprotokoll ist ein Cluster mit mehreren Knoten gleich mit im Gepäck. Bei der Clusterverwaltung helfen kosten­freie Werkzeuge, die neben einer einfachen Einrichtung auch Switch- und Failover-Funktionen bereit­stellen. Im Idealfall kann die Anwendung die Datenbank-Connections selbst verwalten und Daten cachen, sodass der User auch vom Schwenken rein gar nichts mitbe­kommt. Aber auch hier können frei verfügbare Werkzeuge aus der PostgreSQL-Welt helfen.

Möglichkeiten zum Reduzieren und Vermeiden von Downtimes im Überblick

Die folgende Übersicht fasst die Möglichkeiten zum Reduzieren und Vermeiden von Downtimes im Zuge des Patchens von Datenbanken nach Herstellern noch einmal zusammen:

Oracle
MS SQL
PostgreSQL
Downtimes reduzieren
Failover Cluster:
reduziert Downtimes auf ca. 5 Minuten pro Datenbank

Standby-Datenbank
mit Dbvisit Standby MP:

für Standard Edition; reduziert Downtimes auf ca. 10 Minuten pro Datenbank

Standby-Datenbank
mit DataGuard:

für Enterprise Bereich; reduziert Downtimes auf ca. 5 Minuten pro Datenbank

Außerdem:
regel­mäßig Patchen; gute Vorbereitung der Patches 
Dbvisit Standby MP:
für Standard Edition; reduziert Downtimes auf ca. 30 Minuten pro Datenbank

Außerdem:
regel­mäßig Patchen; gute Vorbereitung der Patches












n‑Knoten-Cluster:
im Standard enthalten; kosten­freie Zusatztools machen das Handling bequemer

Außerdem:
regel­mäßig Patchen; gute Vorbereitung der Patches











Downtimes vermeiden
Application Continuity:
für Enterprise Bereich

Active Active Cluster mit Fast Connection Failover:
für Enterprise Bereich mit RAC Option 
Always On:
Hochverfügbarkeit durch redun­dante SQL Server auf unter­schied­lichen Hosts



n‑Knoten-Cluster:
im Standard enthalten; kosten­freie Zusatztools machen das Handling bequemer


Oracle
MS SQL
PostgreSQL
Downtimes reduzieren
Failover Cluster:
reduziert Downtimes auf ca. 5 Minuten pro Datenbank

Standby-Datenbank mit Dbvisit Standby MP:
für Standard Edition; reduziert Downtimes auf ca. 10 Minuten pro Datenbank

Standby-Datenbank mit DataGuard:
für Enterprise Bereich; reduziert Downtimes auf ca. 5 Minuten pro Datenbank

Außerdem:
regel­mäßig Patchen; gute Vorbereitung der Patches 
Dbvisit Standby MP:
für Standard Edition; reduziert Downtimes auf ca. 30 Minuten pro Datenbank

Außerdem:
regel­mäßig Patchen; gute Vorbereitung der Patches 
n‑Knoten-Cluster:
im Standard enthalten; kosten­freie Zusatztools machen das Handling bequemer

Außerdem:
regel­mäßig Patchen; gute Vorbereitung der Patches 
Downtimes vermeiden
Application Continuity:
für Enterprise Bereich

Active Active Cluster mit Fast Connection Failover:
für Enterprise Bereich mit RAC Option 
Always On:
Hochverfügbarkeit durch redun­dante SQL Server auf unter­schied­lichen Hosts 
n‑Knoten-Cluster:
im Standard enthalten; kosten­freie Zusatztools machen das Handling bequemer 

Hinweis:

Die Übersicht erhebt keinen Anspruch auf Vollständigkeit. Sie spiegelt lediglich die Erfahrungen unserer Datenbankspezialisten mit ausge­wählten Lösungen wieder. Das gilt auch für die Zeitangaben, welche je nach IT-Umgebung und Voraussetzungen variieren können.

Fazit

Um die Frage eingangs noch einmal deutlich zu beant­worten: Nein, ein Patchen der Datenbanken ist nicht zwingend immer mit einer Downtime verbunden. Einige Möglichkeiten der einzelnen Hersteller, mit denen wir bereits gute Erfahrungen gemacht haben und mit denen Downtimes vermieden werden können, haben wir dir oben zusammengefasst. 

Wichtig ist aus unserer Sicht aber auch immer die offene Kommunikation. Auch wenn du ein Konzept wählst, bei dem ohne Downtime gepatcht werden kann, sollte im Vorfeld eine Ankündigung bei den Anwendern statt­finden. Falls es eine Downtime gibt, sollte diese in jedem Falle realis­tisch, besten­falls etwas großzü­giger kommu­ni­ziert werden. Hier spielen Erfahrungswerte eine große Rolle. Unsere Datenbankprofis haben über die Jahre ein gutes Gefühl dafür entwi­ckelt, wie lange die Wartungsarbeiten bei bestimmten Voraussetzungen dauern werden. Eine zuneh­mende Verquickung zwischen den Datenbankinterna und den Anwendungsdaten führt dazu, dass auch die Datenbankgröße immer stärker an Bedeutung gewinnt für die Dauer der Downtime.

Du hast Fragen dazu oder möchtest das Thema Patchen ohne Downtime für deine IT-Umgebung prüfen? Dann sprich uns gern an! Gemeinsam schauen wir, welche Lösung am besten zu deinen Anforderungen und in deine Umgebung passt.

Patch-Hotline: +49.371.909515–100

Hier findest du weitere Infos zu den vergan­genen und aktuellen Patch Updates aus unserem News und Insights Bereich.

icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook 
Twitter 
LinkedIn 
XING 
WhatsApp 
Email