Anwender von SAP-Software konsolidieren ihre Systemlandschaften, migrieren ERP-Releases und führen Netweaver ein. Dabei spielen Datenbanken eine wichtige Rolle. Firmen tauschen sowohl aus technischen als auch aus wirtschaftlichen Gründen ihre Datenbanksoftware aus. Bei den Kosten sind jedoch nicht nur die reinen Lizenzpreise entscheidend: Viel wichtiger sind die laufenden Ausgaben, die sich unter anderem aus Wartung, Betrieb und der Weiterbildung der Mitarbeiter zusammensetzen. Die Wahl eines geeigneten Datenbanksystems hängt vom Einsatzzweck der SAP-Lösung, dem Datenaufkommen sowie branchenspezifischen Bestimmungen zur Aufbewahrung von Informationen ab.

SAP hat seine Software an verschiedene Datenbanken angepasst. Deren Freigaben für den produktiven Einsatz erfolgen spezifisch nach Datenbank- und Betriebssystem-Stand. Wer diesen Aspekt nicht berücksichtigt, muss unter Umständen bei einem Datenbankwechsel zusätzlich noch eine neue Betriebssystem-Version einspielen.

Features nicht entscheidend

Während Microsofts "SQL Server" Windows voraussetzt, unterstützen die Produkte "DB2 Universal Database" von IBM, "Max DB" und Oracle 10.2 die Betriebssysteme AIX, HP-UX, Microsoft und Linux (siehe Tabelle "Betriebssystem- und Datenbankkombinationen"). Max DB (vormals "SAP DB") ist eine Weiterentwicklung der SAP-eigenen Datenbank und wird von dem Open-Source-Datenbankanbieter MySQL AB wiederverkauft.

Abgesehen von wenigen Funktionen für Datenbanksicherheit und -pflege spielen die mittlerweile sehr umfangreichen Feature-Listen der Datenbankhersteller für den Betrieb von SAP-Systemen eine untergeordnete Rolle. Früher beharrte SAP auf eigenen Lösungen für die Datensicherheit. Dies hat sich - insbesondere auf Wunsch der Kunden - grundlegend geändert.

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.

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.

Batch-only-Verarbeitung

Mit der Software "Oracle Data Guard" ist der Betrieb einer Standby-Datenbank für Oracle weitestgehend automatisierbar. Eine logische Standby-Datenbank ermöglicht eine weitere Backup-Variante, bei der sich direkt die SQL-Statements auf die Standby-Seite übertragen lassen. Diese Instanz kann dann sogar in einem reinen Lesemodus arbeiten. So lässt sich ein eingeschränktes System für die Batch-Verarbeitung aufbauen, wodurch sich die Last auf der produktiven Datenbank reduziert.

Max DB erlaubt sowohl den Standby- als auch den Hot-Standby-Betrieb. Bei beiden Konzepten verfügen die Datenbanken über einen eigenen Datenbereich. Im Standby-Betrieb überträgt die Lösung Logs vom Quellsystem auf die Schattendatenbank. Im Hot-Standby-Modus wird dagegen auf einen gemeinsamen Logbereich zugegriffen. Dies ermöglicht es, SAP-Transaktionen mit einer frei konfigurierbaren Verzögerung zu buchen, ohne dass ein Log komplett abgeschlossen sein muss. Somit verringert sich bei einem Ausfall der produktiven Datenbank der potenzielle Datenverlust erheblich.

Die Version 8.2 von DB2 UDB High Availability Disaster Recovery (HADR) hält die Log-Dateien lokal gespeichert und bucht SAP-Transaktionen über Protokolldateien. Das System arbeitet mit einer synchronen oder einer asynchronen Datenübertragung. Der synchrone Modus vollzieht Transaktionen in der produktiven Instanz erst dann, wenn die Datei auch auf der Standby-Instanz geschrieben wurde, um die Synchronität beider Systeme zu garantieren. Die hierfür notwendige Übertragungszeit beeinflusst jedoch die Datenbank-Performance. Im asynchronen Modus wird systemseitig nur die Übergabe der Protokolldatei an das Netzwerk überprüft. Diese Betriebsart wirkt sich nicht auf die Performance der Datenbanken aus.

Master und Standby

DB2 und Oracle bieten darüber hinaus die Möglichkeit, zwischen Master- und Standby-Datenbank umzuschalten. Die beiden Datenbanken tauschen dann lediglich die Rollen. Durch diese Funktion ergeben sich zusätzliche Wartungsfenster, die die Online-Zeit der Anwendung nicht beeinträchtigen. Auch benötigt dieser Wechsel keinerlei nachträglichen Aufwand wie beispielsweise für eine Rücksicherung. Somit lässt sich die Systemverfügbarkeit auch ohne Betriebssystem-Cluster erhöhen.

SQL Server 2005 offeriert ebenfalls eine Hot-Standby-Lösung. Äquivalent zu den anderen Datenbanken - wenn auch mit anderer Technik - gibt es synchrone und asynchrone Transfer-Mechanismen. Für die vollautomatisierte Übernahme des "Mirror" (Ersatzsystem) von dem "Principal" (Produktivsystem) muss der Systemverantwortliche allerdings noch einen "Witness Server" konfigurieren, der dem Ersatzsystem den Ausfall des produktiven Systems bestätigt.

Auch für IBMs Großrechnerdatenbank "DB2/390" lässt sich eine Hot-Standby-Lösung konfigurieren. Der asynchrone Standby-Betrieb ist für DB2 auf System i5 (vormals iSeries) ebenfalls möglich. Für alle Konzepte gilt: Je höher der Grad der Synchronität zwischen der Quelldatenbank und der Standby-Datenbank ist, desto länger die Transaktionslaufzeiten.

Datenbanken lassen sich heute mit den verschiedenen Cluster-Lösungen der Betriebssystem-Hersteller kombinieren. Max DB, Oracle und IBM DB2 UDB lassen sich ebenso auf einem Microsoft-Cluster betreiben wie auch auf Cluster-Lösungen von HP, IBM, Sun und Steel Eye. Für SQL Server ist hingegen ausschließlich Microsofts Cluster-Technik verfügbar.

Verteilte DB-Server

Oracle sticht mit seiner eigenen Lösung, dem "Real Application Cluster" (RAC), gegenüber den anderen Datenbanken etwas hervor. Oracle RAC bietet die Möglichkeit, die Datenbank-Server-Software selbst auf mehrere Server zu verteilen und somit die Datenbank hochverfügbar zu betreiben. Auch die Datenlast lässt sich auf mehrere Server verteilen.

Auswirkungen auf die Datenbank hat auch der Unicode-Betrieb von SAP-Lösungen. Während DB2 und Oracle intern mit einer UTF-8-Codepage arbeiten, nutzen andere UTF-16, was den Platzbedarf deutlich ansteigen lässt. Der Anstieg hängt dabei von der Art der Daten ab sowie von den verwendeten Zeichen. Max DB arbeitet bereits an einer Umstellung auf eine UTF-8-Codepage, die diesen Nachteil ausgleichen soll. Eine Unicode-Migration eines bestehenden SAP-Systems kann bei Oracle und DB2 die Datenbanksegmente verändern: Nach dem Re-Import der Informationen kann das Datenvolumen sogar geringer sein als vorher. Die Speicherlogik der anderen Datenbanken lässt das nicht zu; Lücken, die durch Archivierungen oder Löschung entstanden sind, werden sofort wieder genutzt.

SQL Server 2005 partitioniert

Tabellenpartitionierung sorgt für mehr Performance. Bisher konnten nur Anwender von Oracle-Datenbanken dieses Feature beim Betrieb des Business Information Warehouse nutzen. Mit der Version 2005 des SQL Server geht dies künftig auch: Die Software gestattet es, Fact- und PSA-Tabellen zu partitionieren. Die Ramp-up-Phase wird voraussichtlich bis Ende 2006 beendet sein.

Sind in der IT-Infrastruktur noch weitere unterschiedliche Datenbankanwendungen im Betrieb, werden oft auch die SAP-Datenbanken direkt über den Datenbankhersteller lizenziert. Dies kann sogar kostengünstiger sein, hat aber den Nachteil der engeren Bindung an den Hersteller.

Neben den technischen Eigenschaften hat natürlich auch der Preis Einfluss auf die Wahl der SAP-Datenbank. Kunden können die Datenbanklizenzen pauschal über SAP abrechnen. Der für die Datenbank zu entrichtende Betrag errechnet sich als Aufschlag auf den SAP-Anwendungswert. Er beträgt etwa drei Prozent für Max DB, acht Prozent für Microsoft SQL Server und DB2 UDB sowie jeweils elf Prozent für Oracle und DB2/OS390. Für die Nutzung von "Oracle RAC" berechnet SAP nochmals einen Aufschlag von drei Prozent. Unter dem SAP-Anwendungswert ist die Summe der Listenpreise für definierte Nutzer und Ergänzungsprodukte zu verstehen. Davon ausgenommen sind diejenigen Positionen, die laut SAP-Preisliste nicht zum SAP-Anwendungswert zählen. (fn)