Auswahltipps für SAP-Datenbanken

12.09.2006
Von Axel Szelepusa

Sicherung der ERP-Datenbank

Die vom Anwender gewünschte Form der Datensicherung hat Einfluss auf die Datenbankauswahl. Banken und Versicherungen beispielsweise haben deutlich höhere Anforderungen zu erfüllen als Branchen, in denen keine so strengen gesetzlichen Auflagen gelten. Wer eine vollständige Datensicherung benötigt, also kein Incremental-Backup verwendet, kann dies in einer Online- oder einer Offline-Variante realisieren. Dabei ist zu beachten, dass das System auch die Transaction- oder Redo-Logs sichert, um den exakten Zeitpunkt der wiederhergestellten Daten für ein Disaster Recovery bestimmen zu können.

Betriebssystem- und Datenbankkombinationen*

Windows

AIX

HP-UX

Linux

Solaris

OS/400

OS/390

Microsoft SQL Server 2000 und 2005

X

-

-

-

-

-

-

Max DB 7.6

X

X

X

X

X

-

-

Oracle 10.2

X

X

X

X

X

-

-

DB2, IBM zOS 9

-

-

-

-

-

-

x

IBM DB2 - AS400 v5R3 und v5R4

-

-

-

-

-

X

-

IBM DB2 UDB 8.2

X

X

X

X

X

-

-

*ab Netweaver 2004 SP1 ohne Applikaitons-Server

SAP gibt Datenbanklösungen spezifisch nach Datenbank- und Betriebssystem-Stand frei. Wer hier nicht aufpasst, muss gegebenenfalls beim Datenbankwechsel eine neue Betriebssystem-Version installieren.

Bei einem Voll-Backup speichern SQL Server, Max DB und DB2 den tatsächlichen Inhalt der Datenbank, während Oracle die komplette Datenbank auf das Backup-System kopiert. Oracle-Backups benötigen dadurch weniger Zeit, mit dem Nachteil, dass unter Umständen mehr Speicherplatz notwendig ist. Die speichersparende Vorgehensweise von Microsoft beispielsweise bedarf jedoch einer Strukturanalyse vor jedem Backup, was bei komplexen Systemen die Performance negativ beeinträchtigen kann. Somit muss das Anwenderunternehmen auch hier abwägen, was wichtiger ist - Schnelligkeit oder niedriger Ressourcenbedarf.

Bei einem Incremental- oder Delta-Backup muss das System zunächst die Unterschiede zu der letzten Vollsicherung ermitteln, was ebenfalls zeitaufwändig sein kann. Dadurch geht unter Umständen der Zeitgewinn verloren, den diese Form des Backups verspricht. Zumindest bei großen Datenbanken lohnt sich der Ansatz, da Anwender so weniger Speicherplatz auf dem Backup-System benötigen. Pauschal kann man sagen, je größer die Datenbank, desto größer ist die Platzeinsparung, da ja nur der Zuwachs zum letzten Backup gesichert wird. Das Verhältnis des Datenvolumens zum täglichen Wachstum kann schon mal 1000 zu eins ausmachen.

Oracle RMAN

Während für SQL Server, Max DB und DB2 die speziellen Backup-Tools des Datenbankherstellers zum Einsatz kommen, muss für Oracle das komplette Backup-Verfahren für "Oracle RMAN" konfiguriert sein. Aus der reinen Kopie der Daten-Files ist es hier nicht möglich, ein Delta zu ermitteln. Für ein Disaster Recovery müssen Anwender daher immer das letzte Voll-Backup und das letzte Incremental-Backup heranziehen.

Für eine hohe Verfügbarkeit der Datenbanksysteme sorgen "Standby-" oder "Schattendatenbanken". Eine Schattendatenbank ist als identische Kopie der produktiven Datenbank auf einer zweiten Hardwarelösung realisiert. Diese Kopie wird mit den gleichen Daten aktualisiert wie die produktive Datenbank. Fällt die primäre Umgebung aus, kann die Schattendatenbank den produktiven Betrieb beinahe unterbrechungsfrei übernehmen. Eine Standby-Datenbank bucht die Transaktionen asynchron. Anders eine Hot-Standby-Lösung, die arbeitet synchron.