Editorial 03.fm

DB2 Data Sharing und SAPs MCOD
Namik Hrle, Johannes Schützner
DB2 Data Sharing und SAPs MCOD
Die MCOD-Initiative der SAP hat als
Ziel, mehrere SAP-Systeme in einer Datenbank zu konsolidieren. Dadurch ergeben sich jedoch neue Herausforderungen
an die Datenbank. Neben Skalierungsfähigkeiten und erhöhter Verfügbarkeit der
Datenbank ist weiter fundamental, dass
sie gemäß den Anforderungen der Applikationen auch mehrfach parametrisierbar ist. Dieser Artikel beschreibt am konkreten Beispiel von SAPs MCOD wie
Landschaften mit mehreren Applikationen innerhalb derselben Datenbank von
DB2 UDB für OS/390 und z/OS und dabei
insbesondere von Data Sharing profitieren können.
1
Einleitung
Vorbei sind die Zeiten, in denen sich Unternehmen auf ein ERP (Enterprise Resource Planning)-System wie SAP R/3
konzentrieren konnten, um die betrieblichen Abläufe abzubilden. Die Proliferation von CRM (Customer Relationship
Management)- und SCM (Supply Chain
Management)-Systemen sowie die zunehmende Bedeutung von Data Warehouse haben zur Folge, dass Unternehmen gezwungen sind, eine steigende
Anzahl von Datenbanken zu betreiben,
welche darüber hinaus oft semantisch in
Beziehung stehende Daten beinhalten.
Da neben Produktiv- auch noch Entwicklungs-, Test- und Schulungssysteme vonnöten sind, ist leicht ersichtlich, dass die
Betriebskosten zur Verwaltung solcher
komplexer Landschaften nicht unerheblich sind.
Aus diesem Grund entstand bei SAP
die MCOD (Multiple Components in One
Database)-Initiative, welche es ermöglicht, mehrere SAP-Systeme innerhalb
desselben Datenbankmangementsystems
(DBMS) zu betreiben. Dadurch entstehen
jedoch neue Herausforderungen an die
Datenbank. Dieser Artikel beschreibt, inwiefern DB2 UDB für OS/390 und z/OS
diese Herausforderungen meistert und
sich für MCOD-Landschaften qualifiziert. Die einzelnen Punkte beziehen sich
dabei auf SAP und MCOD. Sie sind jedoch allgemein auch auf Konsolidierun-
Datenbank-Spektrum 3/2002
gen anderer Applikationen in einer Datenbank anwendbar.
Der Rest des Artikels ist wie folgt
strukturiert: Nachdem kurz auf die datenbankspezifischen Eigenschaften von
SAP-Systemen eingegangen wird sowie
die Ziele von MCOD dargelegt werden,
stellt Abschnitt zwei die Anforderungen
vor, welche sich aus MCOD ergeben. Abschnitt drei geht auf die Realisierung von
MCOD mit DB2 ein. In Abschnitt vier
wird erörtert, auf welche Weise DB2 die
MCOD-Anforderungen erfüllt, bevor
Abschnitt fünf auf offene Probleme eingeht. Der letzte Abschnitt fasst den Artikel zusammen.
Zur Nomenklatur sei noch erwähnt,
dass in diesem Artikel mit DB2 DB2
UDB für OS/390 und z/OS und mit z/OS
sowohl das Betriebssystem OS/390 als
auch dessen Nachfolger z/OS gemeint ist.
Die Begriffe Datenbank und DBMS werden synonym verwendet. Eine Instanz
von DB2 wird üblicherweise als DB2Subsystem bezeichnet.
1.1 Datenbankspezifische Eigenschaften
von SAP-Systemen
SAP-Systeme besitzen eine dreistufige
Client/Server-Architektur aus Datenbank-, Applikations- und Präsentationsserver [Kemper et al. 1998]. Die Applikationsserver verfügen über eine fixe
Anzahl von Workprozessen, welche die
Endanwender bedienen [Will 1999]. Je-
dem Workprozess ist ein DatenbankThread zugeordnet, welcher im Prinzip so
lange existiert wie der zugehörige Applikationsserver.
Ein klassisches SAP R/3-System
stellt aufgrund der folgenden Eigenschaften hohe Anforderungen an das zugrunde
liegende DBMS:
• eine umfangreiche Datenmenge
• eine Vielzahl von Tabellen (SAP R/3
Release 4.6 enthält ca. 20000 Tabellen und 23000 Indizes)
• eine große Anzahl von gleichzeitig
aktiven Endbenutzern
• eine hohe Nebenläufigkeit von DDL
und DML
• die fast ausschließliche Verwendung
von dynamischem SQL
• hohe Anforderungen an den Hauptspeicher
Neuere Applikationen wie SAP CRM und
SAP BW (Business Information Warehouse) bauten zunächst auf R/3 auf und besaßen damit die identischen Eigenschaften. Da man für diese Systeme jedoch auf
die Anwendungsmodule des R/3 wie Human Resources oder Material-Management verzichten kann, gibt es inzwischen
R/3-Basissysteme. Diese besitzen dieselbe
Basistechnologie, lassen sich jedoch auf
bis etwa 6000 Tabellen verkleinern.
Weiter ist zu erwähnen, dass keinerlei
referenzielle Integritätsbeziehungen auf
Datenbankebene definiert werden. Diese
Information ist allein in der jeweiligen
Applikationslogik enthalten. Daher ist
ein Recovery im Allgemeinen nur auf Gesamtsystemebene sinnvoll.
Spezifisch für DB2 als Plattform ist,
dass abgesehen von kleinen Tabellen je-
Data-Sharing-Gruppe
SAP AppServer
DB2P-Subsystem
Thread
Workprozess
Tablespace 1
SAP AppServer
Tabelle
T1
DB2F-Subsystem
Workprozess
Thread
Abb. 1: DB2 Data Sharing ermöglicht Failover
27
DB2 Data Sharing und SAPs MCOD
der Tablespace eine einzige Tabelle beheimatet.
Außerdem können Applikationsserver im Fehlerfall mittels eines flexiblen
Failover-Mechanismus zu einem anderen
Data-Sharing-Member wechseln. Mit
Data Sharing realisiert DB2 eine SharedDisk-Architektur [Härder & Rahm 1999].
Die DB2-Subsysteme einer Data-Sharing-Gruppe werden als deren Member
bezeichnet. In das Themengebiet Data
Sharing führt in diesem Heft [Krishnan
2002] ein.
Abbildung 1 stellt ein Beispiel dar, in
dem die Applikationsserver eines SAPSystems mit dem Subsystem DB2P konnektiert sind. DB2P und DB2F bilden
eine Data-Sharing-Gruppe und sind somit
deren Member. Im Fehlerfall würden die
Applikationsserver zu DB2F umgelenkt
und so auf dieselben Tabellen zugreifen
können.
1.2 Ziele von SAPs MCOD
Die beiden Hauptziele von MCOD sind
konsistentes Recovery über SAP-Systemgrenzen hinweg sowie eine Vereinfachung der Datenbank-Systemadministration. Dabei ist zu vermeiden, dass SAPSysteme durch die Platzierung in ein
MCOD-DBMS im Vergleich zu einem
dedizierten DBMS benachteiligt werden.
Auch für heterogene Lösungen, die Komponenten von unterschiedlichen Herstellern beinhalten, sind die genannten Ziele
relevant. MCOD adressiert jedoch nur
Landschaften, die ausschließlich SAPSysteme beinhalten.
Das erste Ziel dient dazu, logisch zusammengehörende Systeme wie beispielsweise R/3 und CRM auf einfache
Art auf einen gemeinsamen konsistenten
Stand zurücksetzen zu können (Prior
point in time). In einem Unternehmen
können Aufträge zum Beispiel über ein
CRM-System eingegangen, dann an R/3
weitergereicht und dort bearbeitet worden sein. Wenn dieser Gesamtvorgang
später rückgängig gemacht werden soll,
müssen selbstverständlich beide Teilvorgänge annulliert werden. Theoretisch
spricht zwar auch heute nichts gegen eine
datenbankübergreifende Wiederherstellung, doch ist solch ein Vorgang äußerst
kompliziert und zeitintensiv.
Durch eine Reduktion der Anzahl der
DBMS in einer SAP-Systemlandschaft
soll die Datenbankadministration verein-
28
facht und dadurch die Total Cost of Ownership gesenkt werden. Bei der Datenbankverwaltung von Systemen mit hohen
Anforderungen an die Verfügbarkeit gehen Untersuchungen von einem Einsparungspotenzial von bis zu 40% aus. Deutlich wird dies besonders bei Unternehmen, die bisher verschiedene DBMS einsetzen. Zu beachten ist, dass semantisch
unabhängige SAP-Systeme durchaus
auch Kandidaten für die Konsolidierung
in eine Datenbank sein können, beispielsweise Testsysteme. Der Fokus liegt jedoch nicht auf solchen Konsolidierungen.
2
MCOD-Anforderungen
MCOD stellt im Wesentlichen die folgenden Anforderungen an DBMS:
Es muss in besonderem Maße Kriterien der Skalierbarkeit erfüllen. Dazu gehört, dass sowohl die CPU-Leistung als
auch die Hauptspeichernutzung skaliert.
Wichtig ist, dass einzelne SAP-Systeme
in der Nutzung von gemeinsamen Ressourcen wie Bufferpools, Dynamic Statement Cache oder dem Datenbanklog
nicht benachteiligt werden. Diese Gefahr
besteht, wenn sich SAP-Systeme mit unterschiedlich großer Datenmenge und
Aktivität ein DBMS »teilen« und die kleineren Systeme zum Beispiel durch LRUAlgorithmen den Kürzeren ziehen.
Uneingeschränkte Verfügbarkeit ist
eine weitere Anforderung. Geplante und
ungeplante Auszeiten sollten minimiert
werden und, wenn sie auftreten, nicht die
Gesamtheit der SAP-Systeme, sondern
idealerweise nur einzelne Systeme betreffen. Ein Upgrade auf ein höheres DBMSRelease, der für ein bestimmtes SAP-System wichtig ist, sollte beispielsweise
nicht zu Auszeiten der übrigen SAP-Systeme führen. In diesem Zusammenhang
ebenfalls erforderlich ist, dass sich Recovery-Zeiten durch die insgesamt größere
Datenmenge im Vergleich zu isolierten
Systemen nicht verlängern.
Auch SAP-Systeme lassen sich kategorisieren in OLTP (Online Transaction
Processing)- und OLAP (Online Analytical Processing)-Systeme. Da für adäquate
Performanz im Allgemeinen unterschiedliche Parametereinstellungen für Systeme
dieser Kategorien erforderlich sind, ist
eine weitere, fundamentale Anforderung,
dass die Datenbank je SAP-System parametrisierbar ist. Damit wird sicherge-
stellt, dass OLAP- und OLTP-Systeme im
selben DBMS betrieben werden können.
Die einzelnen SAP-Systeme sollten idealerweise auch separat wiederhergestellt
werden können, etwa für den Fall, dass
sich Fehlersituationen auf ein System
einschränken lassen. Diese Anforderung
komplementiert die Zielsetzung, ein Recovery über Systemgrenzen hinweg anzubieten.
Die Erfahrung zeigt, dass es recht
häufig nötig ist, den Datenbankstand eines SAP-Systems zu kopieren. Dies ist
der Fall, wenn etwa aus einem Produktivsystem mehrere Trainingssysteme aufgebaut werden sollen. Im Zusammenhang
mit MCOD gilt es, diese Fähigkeit nicht
einzuschränken. Dies führt zur Anforderung, effizientes Kopieren sowohl individueller SAP-Systeme aus einem MCODVerbund als auch dessen Gesamtheit zu
ermöglichen.
Schließlich erfordern ein praktikables
Datenbank-Performance-Tuning
und
eine einfache Problemdiagnostik, dass
sich relevante Performance-Indikatoren
und Informationen über Datenbankprobleme wie Deadlocks dem zugehörigen
SAP-System zuordnen lassen.
Auf einen Nenner gebracht lässt sich
zusammenfassen, dass als Hauptanforderung SAP-Systemen in einer MCODLandschaft dieselbe Flexibilität und Leistungsfähigkeit der Datenbank zur Verfügung steht wie mit einer dedizierten Datenbank.
3
Technische Realisierung von
MCOD mit DB2
Im Rahmen von MCOD findet keinerlei
Konsolidierung von Basisfunktionalität
verschiedener SAP-Systeme statt. Dies
gilt auch für die Tabellen der Systeme,
welche strikt voneinander separiert bleiben. Auf diese Weise werden keine Abhängigkeiten zwischen einzelnen SAPSystemen eingeführt. Unterschiedliche
Releasestände und separate Upgradevorgänge von SAP-Systemen werden somit
weiterhin uneingeschränkt unterstützt.
Technische Grundlage von MCOD ist
das Konzept, Datenbankobjekte wie Tabellen mit mehrstufigen Namen zu versehen. Jedem SAP-System wird ein eigener
Schemaname zugeordnet, welcher das
Präfix des eigentlichen Tabellennamens
bildet. Der vollqualifizierte Name der po-
Datenbank-Spektrum 3/2002
DB2 Data Sharing und SAPs MCOD
pulären SAP-Tabelle SVERS lautet zum
Beispiel bei einem System mit Schema
SAPR3 »SAPR3.SVERS« und bei einem
anderen System mit Schemanamen SAPCRM »SAPCRM.SVERS«.
Zugriffsrechte auf die Tabellen benachbarter Systeme in derselben Datenbank werden im Allgemeinen nicht gewährt, um die existierenden Sicherheitsmechanismen nicht zu unterwandern. Die
traditionellen Zugriffsmethoden zwischen SAP-Systemen, welche auf dem
ABAP-RFC (Remote Function Call) basieren, sind daher auch mit MCOD weiterhin die einzige Möglichkeit, auf die Daten fremder SAP-Systeme zuzugreifen.
Eine weitere Änderung besteht in der
Anpassung der Namenskonvention für
Zugriffspläne und Packages, mit denen
SAP-Applikationsserver an DB2 gebunden werden. Die neue Konvention nimmt
Bezug auf den Namen des SAP-Systems,
um Eindeutigkeit zu gewährleisten.
Mit VCAT (Volume Catalog) wird bei
z/OS die erste Komponente eines Datasetnamens bezeichnet (Dataset entspricht
in der z/OS-Welt etwa einer Datei in
UNIX oder Windows). Für jedes SAPSystem wird ein separater VCAT reserviert. Dadurch lassen sich einerseits Datasets auf Betriebssystemebene eindeutig
dem zugehörigen SAP-System zuordnen.
Das ist vorteilhaft, da jedem Table- und
Indexspace auf z/OS-Ebene ein Dataset
entspricht und es daher tausende von Datasets pro System gibt. Andererseits wird
so auf Betriebssystemebene der Zugriff
auf die Datasets beschleunigt, da er mit
unterschiedlichen VCATs effizienter gestaltet und so ein Nadelöhr vermieden
werden kann.
Sicherheitskopien werden mittels
SAP-Tools nur für die Gesamtheit der
SAP-Systeme inklusive DB2-Katalog
unterstützt. Damit wird der Tatsache
Rechnung getragen, dass ein Recovery eines isolierten SAP-Systems normalerweise nicht sinnvoll ist.
Diese Erläuterungen führen zur
Schlussfolgerung, dass sich das technische »Enabling« der SAP-Basistechnologie offenbar als einfach, wenn nicht gar
trivial herausstellt. Komplexe Restrukturierungen und Entwurfsänderungen des
SAP-Codings sind nicht erforderlich. Das
Basis-»Enabling« ermöglicht nun eine
Vielzahl verschiedener Konfigurationsmöglichkeiten, SAP-Systeme auf DB2-
Datenbank-Spektrum 3/2002
DB2-Subsystem
DSC
SAP
Database
SAP
SAP
BPs
SAP
SAP
Database
SAP
Database
Abb. 2: Einzelnes DB2-Subsystem bedient mehrere SAP-Systeme
Subsysteme abzubilden. Der folgende
Abschnitt geht auf dieses Thema ein. Anhand der Konfigurationen wird später erörtert, wie sich die MCOD-Anforderungen erfüllen lassen.
3.1 Spezielle Konfigurationen
Die einfachste Konfiguration besteht aus
einem einzelnen DB2-Subsystem, das
eine Menge von SAP-Systemen bedient.
In dieser Konfiguration verfügen die
SAP-Systeme über dieselben Installationsparameter und über gemeinsame Ressourcen wie den Dynamic Statement
Cache (DSC, vgl. Abb. 2). Tablespaces
lassen sich unabhängig vom zugehörigen
SAP-System gemäß ihren Zugriffseigenschaften einem Bufferpool (BP) zuordnen, wie es in der Abbildung dargestellt
ist. Eine Variante dieser Konfiguration
teilt die Gesamtheit der Bufferpools (außer den Katalog-Bufferpools) in disjunkte Teilmengen auf und weist jedem SAPSystem eine dieser Teilmengen zu, so
dass jeder Bufferpool ausschließlich einem System zur Verfügung steht. Diese
Variante vermindert die potenzielle gegenseitige Einflussnahme von SAP-Systemen auf die Performanz.
Die zweite grundsätzliche Konfiguration beinhaltet eine DB2-Data-SharingGruppe, bei der ein Data-Sharing-Member gleichzeitig mehr als einem SAPSystem zur Verfügung steht. Vorteilhaft
ist dabei, dass sich Applikationsserver
zum Beispiel bei Wartungsarbeiten an einem Member zu einem anderen Member
rekonnektieren können. Außerdem lässt
sich die Gesamtlast auf mehrere Member
verteilen. Der zusätzliche CPU- und
Hauptspeicherverbrauch, der durch die
im Vergleich zur ersten Konfiguration zusätzlichen DB2-Subsystemen entsteht,
ist vernachlässigbar [SAPDB2 2001].
Die beiden Bufferpool-Varianten der ersten Konfiguration sind auch hier gültig.
Wenn also auch die Bufferpools auseinander gesteuert werden können, ist weiterhin nachteilig, dass sich SAP-Systeme
die übrigen gemeinsamen DB2-Ressourcen teilen müssen.
Hier setzt die dritte Konfiguration an,
die in Abbildung 3 veranschaulicht wird.
Sie stellt für jedes SAP-System ein dediziertes Member zur Verfügung. Dynamic
Statement Cache, Sortierpools, Workfiles
und Logging-Engines unterliegen damit
keinen Verdrängungsmechanismen zwischen SAP-Systemen. Auch die Bufferpools können wie oben beschrieben aufgeteilt werden, so dass zwei Systeme keinen Bufferpool außer den Bufferpools
des Katalogs gemeinsam verwenden. Ein
Failover von Applikationsservern zu einem anderen Data-Sharing-Member ist
hier möglich, doch würde ein solcher
Vorgang DB2 zwingen, gemeinsame Ressourcen wieder zwischen SAP-Systemen
aufzuteilen.
Wenn solch ein Verhalten inakzeptabel ist, kann man zur Erlangung größtmöglicher Flexibilität jedem SAP-System eine dedizierte Menge von DataSharing-Membern zuweisen. Innerhalb
solch einer Menge arbeitet jedes DB2Subsystem auf denselben Bufferpools.
Diese vierte Konfiguration ist ziemlich
genau das Äquivalent zu einer Menge von
separaten SAP-Systemen, die als Datenbank jeweils eine DB2-Data-SharingGruppe verwenden.
29
DB2 Data Sharing und SAPs MCOD
Data-Sharing-Gruppe
DB2A-Subsystem
DSC
SAP
BPs
DB2B-Subsystem
DSC
SAP
BPs
SAP
Database
DB2C-Subsystem
DSC
SAP
SAP
Database
BPs
SAP
Database
Abb. 3: Affinität zwischen DB2-Member und SAP-System
4
Data Sharing als Schlüssel zu
MCOD
Da nun die Anforderungen von MCOD
postuliert und mögliche Topologien dargelegt sind, lässt sich untersuchen, inwiefern und auf welche Weise sich diese Anforderungen mit DB2 erfüllen lassen.
Grundlage der Argumentation ist dabei
die vierte der soeben beschriebenen Konfigurationen mit einer dedizierten Menge
von Membern je SAP-System und jeweils
eigenen Bufferpools.
4.1 Skalierbarkeit
Der Schlüssel zur Gewährleistung skalierbarer Performanz ist Data Sharing.
Engpässe in CPU- und Hauptspeicherkapazität können damit vermieden werden,
da sich je nach Bedarf zusätzliche DataSharing-Member hinzufügen lassen. Die
Member können auf jeweils separaten
S/390-Maschinen laufen und damit hardwareseitig neue Kapazitäten zur Verfügung stellen.
Bei der Verteilung von CPU- und
Hauptspeicherleistung besteht größtmögliche Flexibilität, weil man pro Data-Sharing-Member individuell die verfügbaren
Ressourcen spezifizieren kann. Sowohl
eine Gleichbehandlung der Member mit
identischen Kapazitäten an Ressourcen
als auch eine explizite Präferenz einzelner Member kann so realisiert werden.
Die inhärente Benachteiligung bei dem
Konkurrieren um globale Ressourcen, der
kleinere Systeme leicht ausgesetzt sein
30
können, ist nicht gegeben. Die Hauptnutzer des Hauptspeichers wie der Dynamic
Statement Cache, Bufferpools und Sortpools sind jeweils getrennt. Da das Logging auf Memberebene stattfindet, wird
durch MCOD auch bei Update-intensiven
Vorgängen wie etwa Batch-Programmen
kein Flaschenhals erzeugt. Strenge Monotonie der Sequenz von Log-Einträgen
innerhalb einer Data-Sharing-Gruppe
wird über eindeutige Zeitstempel des
Sysplex Timers erreicht [DaSh 2001].
Beim Einsatz von MCOD ist also mit keinem Overhead zu rechnen, der durch
Synchronisation von Log-Einträgen verursacht wird.
Ein nennenswerter Overhead durch
den Einsatz von Data Sharing ist genauso
wenig gegeben. Die SAP-Systeme einer
MCOD-Landschaft referenzieren alle unterschiedliche Tabellen. Dadurch ergibt
sich nicht die Notwendigkeit, die Zugriffe
mehrerer DB2-Subsysteme auf diese Tabellen zu synchronisieren. Inter-DB2
Read/Write-Interest bezeichnet den
gleichzeitigen Zugriff mehrerer Member
auf eine Tabelle, wobei mindestens ein
Member schreibend zugreift. Es entstehen geringfügig mehr Zugriffe als bei einer Data-Sharing-Gruppe mit nur einem
SAP-System. Ursache für diesen leichten
Anstieg sind explizite Zugriffe von SAPSystemen auf den DB2-Katalog. Diese
Zugriffe finden jedoch selten statt.
Der Upgrade eines SAP-Systems auf
einen höheren Releasestand beinhaltet
eine große Menge von DDL-Operationen
in einer relativ kurzen Zeitspanne. Auf
die Objekte der anderen SAP-Systeme
hat dies bei DB2 keinen Einfluss, da jeder
Tablespace in einer eigenen Database
liegt und auf dieser Ebene DDL-Operationen verarbeitet werden. Aufgrund des
gemeinsamen Katalogs ergeben sich nur
sehr limitierte Auswirkungen auf die anderen SAP-Systeme.
4.2 Verfügbarkeit
Die Anforderungen im Bereich Verfügbarkeit werden ebenfalls hauptsächlich
mittels Data Sharing erfüllt
Auch mit MCOD ist die Fähigkeit des
Failovers zu einem anderen Member ein
entscheidender Faktor zum Erreichen hoher Verfügbarkeit. Falls ein DB2-Subsystem abbricht, stehen andere Subsysteme
bereit, die Arbeit zu übernehmen.
Wenn jedes SAP-System über eine
dedizierte Menge von DB2-Subsystemen
oder auch nur über ein dediziertes Subsystem verfügt, stellen Wartungsarbeiten
an weiteren Membern der Data-SharingGruppe keine Herausforderung dar.
Selbst eine Migration auf ein höheres
DB2-Release, das für ein einzelnes SAPSystem vorausgesetzt wird, ist hierbei
kein Hindernis [DaSh 2001].
Beim Zugriff mehrerer DBMS auf
dieselben Daten besteht generell die Gefahr, dass ein DBMS abnormal endet,
während es Sperren auf Daten hält. Im
Zusammenhang mit DB2 Data Sharing
werden diese Sperren mit »Retained
Locks« bezeichnet. Eine Gelegenheit, die
Sperren durch ein Zurücksetzen der
Transaktion (ROLLBACK WORK) oder
gar dessen Beendigung (COMMIT
WORK) freizugeben, ist nicht mehr gegeben. Konsequenz dessen ist nun, dass
die gesperrten Daten auch für die übrigen
Member der Data-Sharing-Gruppe gesperrt bleiben. Aus zweierlei Gründen
sind Retained Locks für MCOD jedoch
von geringer Relevanz. Da die Tabellen
der SAP-Systeme disjunkt sind, betreffen
Retained Locks auf Anwendungstabellen
immer ausschließlich ein SAP-System.
Nur Retained Locks auf dem Katalog
könnten auch weitere SAP-Systeme tangieren. Da auf den Katalog aber nur selten
zugegriffen wird und wenn dann zumeist
nur lesend mit der Isolationsstufe »Uncommitted Read«, ist man einem minimalen Risiko ausgesetzt. Darüber hinaus
kann ein DB2-Subsystem mit der Option
»Light« gestartet werden. Das bedeutet,
Datenbank-Spektrum 3/2002
DB2 Data Sharing und SAPs MCOD
dass es angestartet wird mit dem alleinigen Ziel, Retained Locks freizugeben.
Die dazu erforderlichen Ressourcen sind
im Vergleich zu einem regulären Startvorgang gering.
Eine prophylaktische Freigabe möglicher Retained Locks nach einem Absturz
lässt sich automatisieren und die Lebensdauer der Retained Locks auf eine sehr
kurze Zeitspanne reduzieren. Dazu bieten sich die auf der z/OS-Plattform erhältlichen Automatisierungstools im Bereich
Systemmanagement an. Für das Tool
»System Automation for OS/390« existieren beispielsweise speziell auf die
SAP-Lösung zugeschnittene Regeln, die
definieren, wie auf die Terminierung einer Komponente des SAP-Applikationsservers oder eines DB2-Subsystems reagiert wird [SysAuto 2000].
Da solch ein Tool mehrere z/OSImages als Domäne besitzen kann, befähigt es darüber hinaus zum automatischen Anstarten neuer Data-SharingMember auf einem weiteren Image, sobald ein aktives Member endet. Damit
lassen sich selbst recht konstruierte Fälle
abdecken wie der folgende: Nachdem ein
DB2-Subsystem terminiert, die SAPWorkprozesse auf ein anderes Member
»umgezogen« und zwei Subsysteme aufgrund von Problemen der zugrunde liegenden z/OS-Images nicht verfügbar
sind, besitzt in einer Konfiguration mit
vier Membern pro SAP-System das übrig
gebliebene Member kein Backup mehr.
Um auch dieses Szenario abzudecken,
könnte man die Anzahl der Member vergrößern. Vorteilhafter ist es aber sicherlich, ein neues Member einfach bei Bedarf vom Automatisierungstool starten zu
lassen. Ein geeignetes z/OS-Image kann
zum erforderlichen Zeitpunkt dann dynamisch bestimmt werden. Dieser Ansatz
ist speziell für MCOD von Nutzen, da es
hilft, die Gesamtanzahl der Member pro
MCOD-Landschaft zu reduzieren.
Die Verfügbarkeit von Daten wird
auch durch den Zeitraum beeinflusst,
welcher benötigt wird, um die Daten im
Fehlerfall auf den aktuellen oder einen
früheren Zeitpunkt wiederherzustellen.
Während dieses Zeitraums sind die betroffenen Daten nicht verfügbar. MCOD
verlängert diesen Zeitraum praktisch
nicht. Das für das Wiederherstellen von
Daten verantwortliche DB2-Utility »RECOVER« arbeitet auf der Granularität ei-
Datenbank-Spektrum 3/2002
nes Tablespaces. Das Wiederherstellen
eines SAP-Systems umfasst daher das
Wiederherstellen dessen Gesamtheit an
Tablespaces sowie des DB2-Katalogs. In
MCOD-Landschaften lässt sich dies parallelisieren, so dass die Tablespaces der
SAP-Systeme parallel wiederhergestellt
werden und der Zeitbedarf konstant
bleibt. Wie bei einem singulären SAPSystem wird zunächst der Katalog wiederhergestellt. Da dort eine größere Anzahl von Objekten verwaltet wird, dauert
diese Operation geringfügig länger.
Auf dieselbe Weise lassen sich auch
die übrigen Werkzeuge zur Datenbankadministration wie beispielsweise zum Aktualisieren der Statistiken parallelisieren.
4.3 Parametrisierbarkeit je SAP-System
Abgesehen von einigen Ausnahmen wie
Sicherheitseinstellungen können die Installationsparameter der Member einer
Data-Sharing-Gruppe unabhängig voneinander gewählt werden [DaSh 2001].
Die Parameter, welche für OLTP- und
OLAP-Systeme unterschiedlich sind, gehören zu den frei wählbaren. Diese betreffen hauptsächlich die Verwendung
von Star-Join als Verbundmethode
[SAPDB2 2001]. Bei einer Abbildung
der SAP-Systeme auf überlappungsfreie
Mengen von Membern können OLTPund OLAP-Systeme daher gemeinsam in
einer Data-Sharing-Gruppe betrieben
werden. Die Anforderung nach individueller Parametrisierbarkeit ist erfüllt.
Eine allgemein mögliche Konfiguration besteht darin, dass zwei oder mehr
DB2-Subsysteme, die jeweils ein SAPSystem enthalten, im selben z/OS-Image
beheimatet sind. Durch den WLM
(Workload-Manager) kann nun jene Arbeit, welche für ein bestimmtes SAP-System verrichtet wird, bevorzugt werden.
Diese Flexibilität besteht mit MCOD
weiterhin. Bei einer Affinität von SAPSystem zu DB2-Subsystem geschieht
dies wie gehabt. Falls mehrere SAP-Systeme im selben Subsystem residieren, so
erfolgt die Identifizierung der Arbeit auf
Thread-Ebene. Die Grundlage dafür bilden die Identifikatoren der DB2-Threads,
die das zugehörige SAP-System spezifizieren.
4.4 Effizientes Kopieren
Sowohl komplette MCOD-Landschaften
als auch individuelle SAP-Systeme aus
einer MCOD-Landschaft können kopiert
werden.
Das Kopieren einer MCOD-Landschaft kann sehr effizient erreicht werden,
indem mittels DB2-Utilities der gesamte
Datenbestand des DB2-Subsystems bzw.
der Data-Sharing-Gruppe physisch kopiert wird. Der innere Aufbau der Tablespaces oder die Konsistenz mit dem DB2Katalog braucht dabei nicht berücksichtigt zu werden.
Das Kopieren von einzelnen SAPSystemen funktioniert auf diese Weise
nicht, da die Folge sonst Inkonsistenzen
zwischen Katalog und SAP-Tablespaces
wären. Dafür lassen sich solche Kopien
mit Hilfe von SAP-Tools anfertigen. Da
diese Tools aber auf logischer Ebene arbeiten, können sie nicht die Effizienz eines physischen Kopiervorgangs erreichen.
4.5 Monitoring
DB2 ermöglicht es, eine Korrelation zwischen Performance-Indikatoren und dem
zugehörigen SAP-System herzustellen.
Die im Zusammenhang mit SAP sehr bedeutsamen Informationen über den Dynamic Statement Cache stellen einen Bezug
zwischen SQL-Anweisungen und SAPSystem her. Da eine Vielzahl der SQLAnweisungen identisch für alle SAP-Systeme sind, wird die Bedeutung dieser Fähigkeit offensichtlich. Analog verhält es
sich mit den DB2-Threads. Sie lassen
sich genauso zum passenden SAP-System zuordnen und so zielgerichtet analysieren. Von Thread-Performance-Statistiken abgeleitete Werte wie globale
Zeitverteilungen (Gesamtzeit in der
DB2-Engine, interne Wartezeiten auf bestimmte Ereignisse wie synchrones Lesen
von der Festplatte etc.) können auf diese
Weise auf der Granulatität von SAP-Systemen bestimmt werden.
Orthogonal dazu steht die Eigenschaft, mittels eines einzelnen Performance-Monitors alle Member einer DataSharing-Gruppe überwachen zu können.
Dies befähigt auf einfache Weise beispielsweise die Korrektheit der Installationsparameter einer Gruppe zu überprüfen
oder Bufferpool-Trefferraten in einer globalen Sicht zu untersuchen.
31
DB2 Data Sharing und SAPs MCOD
DB2 stellt außerdem eine Reihe von
Alerts bereit, welche ausgelöst werden,
sobald ein kritischer Zustand erreicht ist.
Alerts betreffen unter anderem Timeouts,
Deadlocks, die Anzahl der physischen
Extents zu einem Table- oder Indexspace
sowie langlaufende Transaktionen. All
diese Informationen lassen sich einzelnen
SAP-Systemen zuordnen. Administratoren eröffnet dies die Sicht auf den generellen Zustand der Datenbank in Bezug
auf ein bestimmtes SAP-System.
4.6 Komplikation der Administration?
Alles in allem eröffnet DB2 Data Sharing
eine für MCOD angemessene Leistungsfähigkeit und Flexibilität. Nun liegt jedoch die Frage nahe, ob der Aufbau und
Betrieb von Data-Sharing-Gruppen dem
Ziel widerspricht, die Administrationskosten nachhaltig zu reduzieren.
Selbstverständlich bringt Data Sharing höheren Aufwand mit sich. Allerdings treten diese Aufwände hauptsächlich bei der Installation auf und sind
einmalige Tätigkeiten. Für den täglichen
Betrieb sollten sich für MCOD nur
geringfügig größere Aufwände ergeben,
insbesondere angesichts der unterstützenden Automatisierungstools und der Fähigkeit, mit einem einzelnen Performance-Monitor gesamte Data-SharingGruppen zu überwachen. Des Weiteren
liegt es am Kunden zu entscheiden, welche Leistung und Flexibilität jedem
einzelnen SAP-System bereitgestellt
werden. Dazu steht das vorgestellte breite
Spektrum an Topologien zur Verfügung.
5
Offene Probleme
Die offenen Probleme umfassen die performante Kopie sowie die Wiederherstellung eines einzelnen SAP-Systems aus
einer MCOD-Landschaft.
Wie beschrieben existiert für das Kopieren einzelner SAP-Systeme ein Verfahren, welches jedoch nicht effizient ist.
Die Ursache der Problematik liegt in der
Tatsache begründet, dass der Datenbestand eines SAP-Systems sowie dessen
Metadaten im Katalog konsistent gehalten werden müssen, andererseits aber die
Tablespaces des Katalogs nur als Ganzes
kopiert werden können. Der Fall, dass das
Zielsystem bereits eine MCOD-Landschaft beinhaltet, ist dabei schwieriger zu
lösen als das Kopieren in ein leeres DB2Subsystem.
32
Mit der Wiederherstellung eines einzelnen SAP-Systems aus einer MCODLandschaft verhält es sich ähnlich. Da der
DB2-Katalog nur insgesamt zurückgesetzt werden kann, sind alle SAP-Systeme betroffen. Allerdings ist die Forderung nach Wiederherstellbarkeit einzelner Systeme nicht stark, da das Hauptaugenmerk der Konsolidierung von semantisch in Beziehung stehenden Systemen gilt. Nur in Spezialfällen können
SAP-Systeme dort individuell zurückgesetzt werden. Um die Einschränkung
abzubauen, ist eine Wiederherstellung
von Untermengen von Tabellen des Katalogs vonnöten.
6
ation System. Tutorial for the ACM SIGMOD
Conference on Management of Data, Seattle,
USA, Juni 1998.
[Krishnan 2002] Krishnan, G.: IBM Mainframe
Database Overview and Evolution of DB2 as
Web Enabled Scalable Servers. In: Datenbank-Spektrum, 2. Jg., 2002, Heft 3.
[SAPDB2 2001] SAP on DB2 UDB for OS/390
and z/OS: Planning Guide SAP Web Application Server 6.10. IBM Publikation Nr. SC337959-00, Juni 2001.
[SysAuto 2000] System Automation for OS/390
– General Information Version 2 Release 1.
IBM Publikation Nr. GC33-7036-00, Oktober 2000.
[Will 1999] Will, L.: SAP R/3 Systemadministration, Basiswissen für das R/3-Systemmanagement. Galileo Press, Bonn, 1999.
Zusammenfassung
In diesem Artikel wurde dargestellt, dass
sich DB2 eignet, komplexe Landschaften
wie MCOD zu konsolidieren. Dazu wurden zunächst die Anforderungen formuliert, welche sich aus MCOD ergeben.
Daraufhin ist die technische Umsetzung
von MCOD mit DB2 skizziert worden. Je
nach Zielsetzung von Kunden können damit verschiedene Topologien aufgebaut
werden – von einem einzelnen DB2-Subsystem, das eine Menge von Testsystemen konsolidiert, bis zu Hochverfügbarkeitskonfigurationen, die für jedes SAPSystem eine dedizierte Teilmenge der
Data-Sharing-Gruppe bereitstellt. Anschließend wurde dargelegt, dass sich mit
DB2 die durch MCOD gestellten Anforderungen erfüllen lassen. Im Kern werden dabei viele der Anforderungen durch
die Fähigkeit zum Data Sharing erfüllt.
Abschließend wurde auf offene Probleme
eingegangen.
Die Vision des »Universal Storage«
bezeichnet die integrierte Speicherung
und Verwaltung aller Daten in einem
DBMS, auch der unstrukturierten [Härder & Rahm 1999]. DB2 Data Sharing
und SAPs MCOD rücken sie etwas näher.
Namik Hrle ist Senior Technical Staff Member
im Bereich eServer Software Development des
Böblinger IBM-Entwicklungslabors und ein Mitglied des IBM Technical Experts Council. Er ist
zur Zeit der Chief Database Architect in der Entwicklung von SAP on DB2 for z/OS and OS/390.
Literatur
Johannes Schützner ist Software-Entwickler im
Bereich eServer Software Development des Böblinger IBM-Entwicklungslabors. Er beschäftigt
sich mit Fragestellungen der Performanceoptimierung von DB2 und neuerdings mit SAPs
MCOD Initiative.
[DaSh 2001] DB2 Universal Database for OS/
390 and z/OS – Data Sharing: Planning and
Administration Version 7. IBM Publikation
Nr. SC26-9935-01, März 2001.
[Härder & Rahm 1999] Härder, T.; Rahm, E.: Datenbanksysteme: Konzepte und Techniken
der Implementierung. Springer-Verlag, Berlin, 1999.
[Kemper et al. 1998] Kemper, A.; Kossmann, D.;
Matthes, F.: SAP R/3: A Database Applic-
M. Sc. Namik Hrle
Dipl.-Inform. Johannes Schützner
IBM Deutschland Entwicklung GmbH
zSeries Software Development
Schönaicherstr. 220
71032 Böblingen
{<namik_hrle> <schuetzner>}@de.ibm.com
http://www.ibm.com
Datenbank-Spektrum 3/2002