DBMS
PDM
den des letzten Backups erfordert und je nach gewählter Backup-Stra-tegie bereits mit unwiederbringlichen Datenverlusten einer bestimmten Zeitdauer verbunden sein kann.
Die dritte Fehlerklasse und damit der schlimmste Problemfall über-haupt sind Media-Fehler im Volume-Bereich, wo die Files eingekapsel-ter Fremdapplikationen (CAx, DTP) gespeichert sind. Hier muss ebenfalls der letzte Backup zurückgeladen werden, womit aufgrund fehlender Datenbankfunktionalität jedoch in der Regel zwingend ein Rücksetzen auf den Stand des Backup-Datums verbunden ist, was unwiederbringliche Datenverluste bedeutet.
Tabelle T007dbtZ gibt einen zusammenfassenden Überblick über die Fehlerklassen von PLM-Applikationen. Zusätzlich zu den bereits erwähnten Fehlerklassen eins bis drei sind auch Transaktionsfehler angeführt, die durch einen Deadlock, Applikationsfehler (z.B. Divisions durch 0) oder Benutzerfehler entstehen. Obwohl Transaktionsfehler sehr häufig auftreten, stellen sie für den Endanwender einer Daten-bank-Applikation kein Problem dar. Da sie als „innerer“ Fehler von der Transaktionsverwaltung erkannt werden, können sie durch einen Roll-back (UNDO) behoben werden, ohne einen manuellen Eingriff zu erfordern.
Fehlerklassen von PLM-Applikationen Fehlerklasse Ursache Häufigkeit Massnahme 0.
• Zurücksetzen (Rollback) einer Transaction (mittels UNDO).
1. System-fehler
Absturz PLM ,DBMS, OS
• Zurücksetzen (Rollback) aller nicht abgeschlossenen Trans-aktionen (mittels UNDO).
• Wiederholen aller abge-schlossenen Transaktionen (mittels REDO).
Tabelle (T007dbtZ) Übersicht über Fehlerklassen von PLM-Applikationen
Das Pendant eines Backups im Fehlerfalle wird als Recovery bezeich-net. Unter Recovery versteht man das Wiederherstellen eines konsis-tenten Datenbankzustandes nach dem Eintreten eines Fehlers. Die Grundlage hierfür ist Redundanz in Form eines Backups der Daten-bank sowie der Protokollierung sämtlicher Vorgänge in Log-Dateien.
Dadurch wird gewährleistet, dass bereits abgeschlossene Transaktio-nen dauerhaft gespeichert bleiben und dass nicht beendete Transakti-onen keine (dauerhaften) Spuren in der Datenbank hinterlassen. Bild B016dbtZ verdeutlicht das Prinzip der Protokollierung in Datenbank-systemen mittels Log-Dateien.
2.Media-Fehler im DB-Bereich
Speicherfeh-ler durch z.B.
Head Crash, irrtümlich gelöschte Files, korrup-tes Filesystem oder höhere Gewalt durch Feuer, Was-serschaden etc.
jährlich Media Recovery (nur DB-seitig)
• Zurückladen des zuletzt gesi-cherten DB-Zustandes mittels Archiv-DB (vom Band).
• Wiederholen aller abge-schlossenen Transaktionen (REDO) zwischen Backup-Da-tum und Fehlerzeitpunkt durch „Vorwärtsrollen“ mit-tels Log-Dateien (auf Disk) und ggf. Archiv-Log (vom Band).
• *Bei richtiger Backup-Strate-gie KEIN Datenverlust!
3.
Head Crash, irrtümlich durch Feuer, Wasserscha-den etc.
jährlich Media Recovery (gesamthaft)
• Zurückladen des zuletzt gesi-cherten DB-Zustandes mittels Archiv-DB (vom Band).
• Zurückladen des zuletzt gesi-cherten Volume-Zustandes mittels Archiv-Volume (vom Band).
• *Da zwingend auf den Stand des letzten Volume-Backups zurückgegangen werden muss, ist kein „Vorwärtsrol-len“ möglich. Ein gewisser Datenverlust (i.d.R. 1 Tag) ist unumgänglich!
Fehlerklassen von PLM-Applikationen Fehlerklasse Ursache Häufigkeit Massnahme
Tabelle (T007dbtZ) Übersicht über Fehlerklassen von PLM-Applikationen
Bild (B016dbtZ) Protokollierung in Datenbanksystemen als Grundlage der Recovery
Im Hauptspeicher werden in einem sogenannten DB-Puffer möglichst sämtliche benötigten Datenbankinhalte geführt, um Operationen direkt im Hauptspeicher ausführen zu können. Dadurch werden die erheblich langsameren Sekundärspeicherzugriffe (Disk-I/O) reduziert und schlussendlich die Performance erheblich gesteigert. Da das Zurückschreiben auf Platte hierbei asynchron zu unbekannten Zeit-punkten erfolgt (Prozess: DBWR), resultiert daraus eine gewisse Unsi-cherheit über den Datenbankzustand auf dem Sekundärspeicher-medium. Einerseits kann je nach Systemauslastung eine abgeschlos-sene Transaktion vom DB-Puffer im Hauptspeicher noch nicht auf die Platte zurückgeschrieben sein, andererseits kann die Notwendigkeit bestehen, eine noch nicht beendete Transaktion bereits auf Platte her-auszuschreiben. Um dies hinsichtlich der obigen Zielsetzung handha-ben zu können, wird für jede Operation im DB-Puffer ein zugehöriger Log-Satz im Log-Puffer abgelegt. Dieser beinhaltet sowohl UNDO- als auch REDO-Informationen, um jederzeit ein Rücksetzen oder Wieder-holen der Transaktionen gewährleisten zu können. Im Gegensatz zum
Client
DBMS
Log-Datei DB
Disk 1
Offline-Speicher /ArchivSekundärspeicher/DiskHauptspeicher/RAM
Disk 2
ARCH
Archiv-DB
Archiv-Log LOG Puffer DB Puffer
ARCH
DBWR LGWR
DBSERV
Transfer zwischen DB-Puffer und DB ist die Übertragung vom Log-Puf-fer zur Log-Datei (Prozess: LGWR) „sicherer“ geregelt gemäss folgen-den zwei Regeln:
• Atomaritätsregel:
Bevor eine Veränderung (einzelne Aktion(en) einer Transaktion) in die persistente Datenbank (DB auf Platte) eingebracht wird, muss die zugehörige UNDO-Information in die Log-Datei (DB-Log auf Platte) gezwungen werden („WAL“-Prinzip: Write Ahead Log).
• Persistenzregel:
Vor dem Commit einer Transaktion müssen alle zugehörigen REDO-Informationen in die Log-Datei (DB-Log auf Platte) gezwungen werden.
Sowohl von der Datenbank als auch von den Log-Dateien wird perio-disch ein Backup auf einen Offline-Speicher gezogen (Prozess: ARCH), woraus die sogenannte Archiv-DB und das Archiv-Log entstehen.
Im Falle eines Systemfehlers muss grundsätzlich mit folgender Aus-gangslage gerechnet werden:
• Sämtliche Hauptspeicherinhalte sind flüchtig und gehen verlo-ren (DB-Puffer, Log-Puffer).
• Die auf Sekundärspeicher befindliche Datenbank ist in einem inkonsistenten Zustand.
Abhilfe schafft hier die sogenannte Crash Recovery, wodurch die Datenbank (DB) mittels der Log-Datei(en) einem globalen UNDO/
REDO unterzogen wird. Resultat ist ein wiederum konsistenter Zustand und im Falle des Betriebes im sogenannten Archiv-Modus kei-nerlei Datenverlust.
Im Falle eines Media-Fehlers der Datenbank muss diese mittels der Archiv-Dublikate (Archiv-DB und Archiv-Log) wieder hergestellt wer-den. In der Regel werden zudem noch die Log-Dateien verfügbar sein, welche idealerweise auf separaten und gespiegelten Medien vorliegen und infolgedessen ebenfalls als „sicher“ anzusehen sind. Mittels der sogenannten Media Recovery-Funktionalität von Datenbanksystemen kann auch in diesem Fehlerfalle wieder ein konsistenter Datenbankzu-stand hergestellt werden - ohne Datenverluste, falls der Archiv-Modus betrieben wird.
Für den Backup eines PLM-Systems kommt zur DB-Thematik die Volume-Problematik hinzu, wofür entweder zwei separate Backup Prozeduren (eine für die Datenbank und eine für das Volume) durch-geführt werden oder es ist eine Utility erforderlich, die für beide Kom-ponenten einen Backup erstellt. In jedem Fall muss unbedingt beachtet werden, dass Volume und Datenbank korrespondieren
müs-sen, d.h. deren Backup zur gleichen Zeit erfolgen muss. Dies impli-ziert, dass vom Beginn des Backups an Volume und/oder Datenbank bis zum Ende des Backups (welcher für Volume und Datenbank allge-mein verschiedene Dauern haben wird) keine Veränderungen durch Schreiboperationen erfolgen.
Im Fehlerfall müssen Volume und Datenbank nach einem Reco-very-Prozess ebenfalls wieder auf einem identischen Aktualitätsstand sein. Hervorzuheben ist hierfür die Diskrepanz von Volume und Daten-bank bezüglich ihrer Recovery-Funktionalität:
• Volume-Recovery:
„Point-in-time“-Charakteristik, d.h. im Fehlerfall kann immer nur auf das Datum des letzten Backups zurückgegangen wer-den, was in der Regel immer mit einem Datenverlust verbunden ist.
• Datenbank-Recovery:
„Point-of-failure“-Charakteristik, d.h. im Fehlerfall kann der Datenbankzustand wieder bis zum Zeitpunkt des Fehlers rekon-struiert werden, wodurch Datenverluste in der Regel ausge-schlossen werden können.
Da Volume und Datenbank normalerweise auf unterschiedlichen Maschinen, zumindest jedoch auf unterschiedlichen Disks gehalten werden, ist die Wahrscheinlichkeit relativ gross, dass nur eine der bei-den Komponenten ausfällt. Ein gleichzeitiger Media-Ausfall beider Komponenten kann z.B. in einem Katastrophenfall ebenfalls eintreten.
Der mit einem Systemfehler einhergehende Datenverlust ist von vielerlei Faktoren abhängig und umgekehrt proportional zu den Vor-sorge-Massnahmen und insbesondere dem Backup-Aufwand. Die Recovery-Funktionalität von DB-Systemen mit ihrer „Point-of-failure“-Charakteristik ist jedoch ein ganz entscheidender Vorteil und zugleich eine zwingende Voraussetzung, um Business-kritische Prozesse auf sogenannte „Mission critical“ IT-Lösungen abbilden zu können, deren Verfügbarkeit garantiert werden muss.
6. Verteilung in PLM-Systemen
Globale Unternehmen, virtuelle Fabriken und eine Reihe weiterer aktueller Schlagwörter verdeutlichen den Trend zur verteilten Produkt-entwicklung über mehrere Standorte hinweg, die mittels moderner Informationstechnologien zusammenarbeiten und koordiniert wer-den. Immer häufiger finden sich Beispiele für standortübergreifende Produktentwicklungsprozesse, in welchen örtlich getrennte Projekt-teams gemeinsam ein rechnerinternes Produktmodell erstellen, obwohl sie eventuell über grosse Entfernungen auseinander liegen oder gar auf unterschiedlichen Kontinenten beheimatet sind. Seinen Anfang nahm diese Entwicklung in der örtlichen Trennung von Ent-wicklungs- und Produktionsstandorten, um letztere in Billiglohnländer auslagern zu können. Mittlerweile finden sich zunehmend auch inner-halb der Entwicklung örtliche Aufsplittungen oder auch Zusammen-schlüsse, wo einzelne Prozessschritte (z.B. Produktkonstruktion mittels CAD und CAM-Herstellprozessdefinition) an verschiedenen Standor-ten erfolgen und rein digital koordiniert werden [Mar-97]. Anhand verteilter PLM-Systeme können hierbei die Rationalisierungsmöglich-keiten durch örtliche Trennungen bzw. Zusammenschlüsse genutzt werden, ohne die rechnerinternen Produktinformationen - und damit das Know-how - aus der Hand zu geben. Da dies eine interessante Chance darstellt, um Industriestandorte, wie beispielsweise die Schweiz, trotz hohem Lohnniveau langfristig zu sichern, sollen nach-folgend die Konzepte der Verteilung in PLM-Systemen vorgestellt wer-den, wofür zunächst die diesbezüglichen Anforderungen zu klären sind.