kentoh - Fotolia

Datenbank-Modernisierung: aufgeschoben ist nicht aufgehoben

Firmen sollten ihre Datenbanken aktuell halten. Das ist häufig schwieriger als erwartet. Mehrere Tipps, damit die Modernisierung zum Erfolg wird.

„Warum müssen wir denn die Datenbank modernisieren – sie läuft doch?“ Mit dieser Frage sehen sich viele IT-Verantwortliche konfrontiert. Natürlich funktioniert die Datenbank, und das bisweilen auch zuverlässig. Das ist schließlich der Grund, weshalb man sich ursprünglich für dieses Produkt entschieden hat. Warum sollte man genau jetzt Ressourcen in eine Modernisierung investieren?

Datenbanken bilden in der heutigen Zeit das Herzstück jedes Unternehmens. Sie speichern und verarbeiten wichtige Informationen und stellen sie jederzeit von überall zum Abruf bereit. Dennoch behandeln viele Unternehmen diese wichtige Kernkomponente stiefmütterlich. Erst, wenn die Datenbank tatsächlich ausfällt, nehmen sie Geld in die Hand, um die Systeme und alle damit verbundenen Services wieder zum Laufen zu bringen. Das kann teuer werden. Denn wenn wichtige Buchungs- oder Produktionsdaten verloren gehen, erhöht das die Kosten und verursacht Ärger und Stress.

Erschwerend kommt hinzu, dass Datenbanksysteme meist nur wenig bis gar nicht dokumentiert sind. Oft ist derjenige, der alles eingerichtet und konfiguriert hat, gerade nicht da oder gar nicht mehr im Unternehmen. Für gewöhnlich wird ein Datenbankserver nach der Implementierung nur selten verändert. Nach einer gewissen Zeit kann niemand mehr nachvollziehen, warum der damals verantwortliche Kollege die eine oder andere Entscheidung getroffen hat. Deshalb ist eine durchdachte Dokumentation wichtig. Administratoren müssen sie sauber pflegen und aktualisieren, wenn sie die Konfiguration der Datenbank einmal anpassen. Nur so lassen sich Änderungen auch später noch nachvollziehen.

Eine Modernisierung ist ein guter Schritt, um Frühjahrsputz im Datenbanksystem zu machen und gleichzeitig den Support durch den Hersteller zu wahren. Denn auch dieser läuft irgendwann ab.

Systeme konsolidieren: Weniger Kosten, mehr Zeit

Der Frühjahrsputz ist eine gute Gelegenheit, auch andere vorhandenen Systeme zu konsolidieren. Meist gibt es neben der Datenbank, die gerade auf den neusten Stand gebracht werden soll, noch weitere Anwendungen, die eine Wartung nötig haben. Mit einer Konsolidierung sparen Unternehmen Zeit und Kosten. Denn es ist einfacher, wenige, gut dokumentierte Server zu administrieren, als viele, bei denen niemand mehr die Historie kennt. Im Idealfall müssen Administratoren nur noch einen zentralen Server patchen und überwachen.

Je mehr Datenbankserver es in einem Unternehmen gibt, desto mehr unterschiedliche Versionen und Editionen entstehen. Durch neue Anforderungen kommen im Laufe der Zeit immer wieder neue Implementierungen dazu. Das stellt hohe Anforderungen an den Administrator, denn er muss sich mit allen Versionen sehr gut auskennen. Zudem treibt die Zahl der Systeme auch die Lizenz- und Compute-Kosten in die Höhe.

Konsolidierung muss gut geplant sein

Eine Konsolidierung kann allerdings auch Probleme mit sich bringen. Denn wenn alle Anwendungen auf einen zentralen Datenbankserver zugreifen, sind sie auch alle betroffen, wenn es einmal zu Ausfällen kommt oder eine Wartung nötig ist. Um das zu vermeiden, brauchen Unternehmen Hochverfügbarkeit, wie beispielsweise bei einem Failover Cluster oder einer Microsoft SQL Server High Availability Group.

Hochverfügbarkeit? Das kostet doch nur unnötig Geld!

Eine Hochverfügbarkeit der Daten muss nicht unbedingt teurer sein. Microsoft SQL Server beispielsweise bietet je nach Lizenzmodel die Möglichkeit, neben dem aktiven Datenbankserver einen weiteren Passiv-Knoten auf einer im Idealfall räumlich getrennten Hardware kostenneutral parallel zu betreiben. Kommt es zum Ausfall der aktiven Seite oder muss diese gepatcht werden, so kann der Anwender auf den passiven Datenbankserver schwenken und umgekehrt. Es ist also immer nur eine Seite aktiv. Je nach Lizenzmodel fallen dementsprechend auch nur Kosten für einen Knoten an. So lässt sich bei einem tatsächlichen Ausfall eine Downtime mit möglichem Datenverlust vermeiden.

Hochverfügbarkeit lohnt sich für geschäfts- oder produktionskritische Systeme, denn wenn sie ausfallen, kostet das jede Minute spürbar Geld. Bei der Modernisierung sollten Unternehmen in Betracht ziehen, die Daten, gegebenenfalls partiell, in die Cloud auszulagern. Das spart effektiv Lizenz- und administrative Kosten.

Public Cloud? Viel zu unsicher, ich habe doch SLAs einzuhalten!

Die Microsoft Azure Cloud bietet den SQL Server als Platform as a Service (PaaS). Er ermöglicht Point-in-Time Recovery, das heißt Daten lassen sich auf die Millisekunde genau wiederherstellen. Wem dies nicht genügt, der kann zusätzlich eine Georeplikation einrichten. Die Datenbank wird dadurch in mehrere Data Center an verschiedenen Standorten auf der Welt repliziert. Das bringt neben der Datenredundanz den Vorteil, dass sich Zugriffszeiten aus dem Ausland verringern. Eine Georeplikation erfordert minimalen Administrationsaufwand und ist mit wenigen Klicks konfiguriert.

Wie aber steht es um die Sicherheit, wenn Daten nicht mehr im eigenen Rechenzentrum liegen? Microsoft SQL Server verfügt über umfangreiche Verschlüsselungsmöglichkeiten, darunter die transparente Datenverschlüsselung. Selbst Microsoft kann verschlüsselte Daten nicht mitlesen.

Wie läuft so eine Modernisierung nun ab?

Zunächst sollten Administratoren prüfen, ob die bestehenden Systeme noch aktuell sind und den Best-Practice-Empfehlungen entsprechen. Es empfiehlt sich, dafür ein Assessment mit dem Microsoft Data Migration Assistent (DMA) zu machen. Er kann Diskrepanzen zwischen alten und neuen Datenbankversionen aufdecken. Außerdem erkennt er Besonderheiten bei veralteten Datenbanken und macht auf diese aufmerksam. Um eine reibungslose Migration zu gewährleisten, sollten Administratoren auftretende Warnungen in der bestehenden Umgebung bereinigen.

Es ist ratsam, den neuen SQL Server zunächst separat nach der Best-Practice-Empfehlung von Microsoft aufzusetzen und zu konfigurieren. Über den DMA migriert man anschließend Daten auf das Testsystem. Administratoren müssen nun prüfen, ob die Migration erfolgreich war. Erst, wenn sie dies validiert haben, kann die eigentliche Live-Datenmigration beginnen. Dabei ist es wichtig, auch die Dokumentation der Systeme nicht zu vernachlässigen.

Es ergibt sich der folgende Ablauf:

  1. Definition der zu migrierenden und modernisierenden Daten;
  2. Bewertung der Daten;
  3. Definition des Ziel-Designs (Hochverfügbarkeit planen);
  4. Migration der Daten auf ein Testsystem; Test dieser Daten und die anschließende Validierung;
  5. Migration der Live-Daten.

Das Thema Hochverfügbarkeit sollte gleich zu Beginn betrachtet und eingeplant werden.

Vorgehensweise bei Migrationen.
Abbildung 1: Vorgehensweise bei Migrationen.

IT-Verantwortliche sollten vorab klar definieren, welche Ziele sie mit der Modernisierung anstreben. Sonst stehen sie in wenigen Jahren wieder vor denselben Problemen wie zuvor. Wichtige Fragen sind: Welche Daten habe ich? Sollen alle Daten auf dasselbe System? Gibt es Besonderheiten? Wie hoch muss die Performance sein? Kann ich diese auf den vorhandenen Systemen zunächst messen?

Außerdem gilt es zu klären, wie das Ziel-Design aussehen kann, damit auch in Zukunft eine stabile Umgebung besteht. Fehler in den vorhandenen Systemen dürfen nicht wiederholt werden. Erst dann können erste Tests zur Umsetzung beginnen.

Gab es während des Betriebes des Altsystems Bottlenecks?

Ein häufiger Fehler in bestehenden Datenbanksystemen sind Konfigurationen, die zu Bottlenecks führen. Solche Engpässe entstehen zum Beispiel, wenn der SQL-Server zu wenig Arbeitsspeicher zur Verfügung hat. Oder aber der SQL-Server ist nach „Werkseinstellungen“ konfiguriert und greift dadurch auf den gesamten Arbeitsspeicher zu. Wenn dieser nicht ausreicht, beginnt das Betriebssystem Auslagerungsdateien zu befüllen und die Festplatten als Arbeitsspeichererweiterung zu verwenden. Klar, dass die Festplatten nur einen Bruchteil der Geschwindigkeit eines Arbeitsspeichers bieten können.

Das führt auch dazu, dass der SQL-Server den gesamten verfügbaren Arbeitsspeicher belegt und dem Betriebssystem nicht genügend RAM zur Verfügung lässt. Folglich wird es langsam und kann abstürzen. Das wiederum generiert eine Wechselwirkung zwischen Betriebssystem und SQL-Server mit weitgehenden Folgen, zum Beispiel einem Absturz des gesamten SQL-Servers.

Ein weiteres Problem, das immer wieder zu beobachten ist: Das Backup funktioniert nicht. Das liegt meist daran, dass die Festplatte für das Backup voll ist. Dadurch vergrößert sich das Log der Datenbank in bestimmten Fällen immer weiter und wird nicht geleert. Meist wird dieser Fehler jedoch erst offensichtlich, wenn es schon zu spät ist und man ein Backup dringend braucht. Mit einem sauberen Monitoring der SQL-Systeme können Administratoren solche Probleme dagegen bereits im Vorfeld vermeiden.

Auch die Wartung der Datenbank kann größtenteils automatisiert werden. Dafür bietet sich ein zeitgesteuerter Agent an, der die Integrität und Konsistenz der Daten prüft und die Indizes regelmäßig defragmentiert.

Abhängigkeiten der bestehenden Versionen umgehen

Administratoren sollten stets versuchen, Abhängigkeiten von einer Datenbank zu vermeiden. Denn je mehr die eigenen Anwendungen mit den besonderen Techniken einer Datenbank verknüpft sind, desto teurer und aufwändiger wird ein späterer Umstieg – sei es, dass man von einer Version auf die nächste aktualisieren will oder auf eine Datenbank eines anderen Herstellers migrieren möchte.

Wer auf eine neue Datenbank wechseln will, sollte sein System so gestalten, dass es sich möglichst schnell an neue Gegebenheiten anpassen lässt. So kann man den Wechsel mit geringem Kostenaufwand vollziehen. Das gilt für jede Anwendung und jede Datenbank. Es ist unvorteilhaft, sich mit einer Anwendung von einer Datenbank abhängig zu machen. Stattdessen sollte man die Funktionalitäten außerhalb der Datenbank halten und die Datenbank lediglich dafür einsetzen, die zugehörigen Daten zu verwalten. Funktionalitäten innerhalb der Datenbank sollten auf ein Minimum reduziert werden.

„IT-Verantwortliche sollten vorab definieren, welche Ziele sie mit der Modernisierung anstreben. Sonst stehen sie in wenigen Jahren wieder vor denselben Problemen.“

Pascal Poletto, Axians IT Solutions

Eine positive Funktion in Datenbanken sind sogenannte Trigger. Doch auch diese lassen sich nicht ohne Weiteres von Datenbank A auf Datenbank B übertragen. Dies schafft eine gewisse Abhängigkeit. Handelt es sich um eine Anwendung, die lokal auf einem Server betrieben wird, mag das zwar noch umsetzbar sein.

Bei einer Anwendung, die an mehreren Stellen ausgeliefert wurde, ist die Sache schon komplizierter. In der Regel muss der Administrator dann bei allen Umzügen ein Update einspielen, um eine Migration auszuführen. Das führt dazu, dass er immer wieder mit Altlasten kämpft. Wenn Anwendungen jedoch datenbankunabhängig sind, kann er frei entscheiden, welches System er einsetzen will.

Fazit: Vorteile, die auf der Hand liegen

Die Modernisierung und Konsolidierung von Datenbanksystemen bringt viele Vorteile: Unternehmen profitieren von einer höheren Verfügbarkeit der Daten, einer besseren Dokumentation und mehr Übersichtlichkeit. Die Komplexität nimmt ab und der administrative Aufwand sinkt. Dadurch sparen IT-Verantwortliche nicht nur Nerven und Zeit, sondern auch Geld. Solange sie den Ablauf im Vorfeld genau planen und die wichtigsten Punkte berücksichtigen, steht einer reibungslosen Modernisierung nichts im Weg.

Über den Autor:
Pascal Poletto ist seit 2008 in der IT tätig und hat schon während seiner Ausbildung als Anwendungs- und Datenbankentwickler gearbeitet. Dabei war er mit verschiedenen Techniken im Microsoft- und mobilen Umfeld für die Planung und Umsetzung von Projekten zuständig. Seine Schwerpunkte lagen hauptsächlich bei SQL, Reporting und Mobile Web Development sowie der Anwendungsentwicklung mit Delphi. Seit 2016 ist Pascal Poletto bei der Axians IT Solutions als Microsoft SQL System Engineer tätig, als Microsoft Certified Solution Expert (MCSE) ausgezeichnet und begleitet Kunden bei der Migration und Modernisierung von Datenbanken.

Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+, Xing und Facebook!

Nächste Schritte

Die Funktionen des In-Memory-Datenbanksystems SAP HANA.

Die Funktionen des Datenbank-Management-Systems Oracle Database 12c.

Die Funktionen der Graphdatenbank von Neo4j.

Die Funktionen des Open-Source-Datenbanksystems MySQL.

Die Funktionen des NoSQL-Datenbank-Management-Systems (DBMS) MongoDB.

Artikel wurde zuletzt im August 2017 aktualisiert

Erfahren Sie mehr über Datenbank-Management-Systeme (DBMS)

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchDataCenter.de

Close