Behandlung extrem großer Datenmengen

Val Matison

- Die ultimative Power und Geschwindigkeit von VFP -
Immer, wenn man mit Kunden über ein Projekt spricht, taucht die Frage auf, wieviele Daten die größte Tabelle und die komplette Datenbank enthalten werden. Dieser Artikel behandelt die Probleme, die auftauchen, wenn der Kunde erklärt, daß einzelne Tabellen größer als 2 GB werden und die gesamte Datenbank viele Gigabyte an Informationen enthalten wird. Die Ideen, die hier behandelt werden, sind beim Design der weltweit größten Datenbank, die von einer einzelnen FoxPro-Anwendung verwaltet wird, umgesetzt worden. Diese Datenbank wird beim Eurotunnel eingesetzt und enthält 128 GB Informationen (auf Seite 8 finden Sie im Extrakasten weitere Informationen über den Eurotunnel).

FoxPro beschränkt die Größe einer einzelnen Tabelle auf maximal 2 GB. Diese Beschränkung wird aber nicht durch das Betriebssystem auferlegt. Auch wenn Sie Ihre Daten unter einem Betriebssystem speichern, das große Dateien verwalten kann (z.B. Unix oder Windows NT mit NTFS), ist die Größe von FoxPro-Tabellen auf 2 GB beschränkt.

Da die Größe der einzelnen Tabelle auf einen maximalen Wert limitiert ist, besteht praktisch eine Einschränkung der Anzahl der Datensätze, die eine Tabelle enthalten kann. Die Größe einer Tabelle ergibt sich aus der Anzahl der Datensätze in der Tabelle und der physikalischen Größe der Datensätze. FoxPro erlaubt bis zu 2 Milliarden Datensätze je Tabelle. Das ergibt nicht viel Sinn, da diese Tabelle auf ein einzelnes Feld mit einem Byte Länge beschränkt wäre, also nur 256 unterschiedliche Werte enthalten könnte. Eine praxisnähere Einschränkung der Menge der Daten einer einzelnen Tabelle sind 15 bis 20 Millionen Datensätze mit einer durchschnittlichen Länge von 100 bis 150 Bytes. Informationen können auch in Memofeldern gespeichert werden. Dadurch erhält man zusätzliche 2 GB je Tabelle, da das Memo in einer separaten Tabelle gespeichert wird.

Große logische Partitionen

Manchmal ist es notwendig, eine logische Datei zu erstellen, die größer als 2 GB ist, und die Daten in physikalische Dateien aufzuteilen, so daß deren Größe sowohl von FoxPro als auch vom Betriebssystem akzeptiert wird. Das beinhaltet, daß eine Methode existiert, die Daten so integriert, daß der Anwender weiterhin mit seinen vertrauten Formularen arbeiten kann. Eine Abfrage zum Beispiel muß aufgrund der Partitionierung auf mehreren Tabellen arbeiten und, wenn nötig, die Resultate kombinieren.

Die Segmentierung kann überall auftreten, wo Daten physikalisch getrennt werden, sowohl in einer logischen Relation als auch dort, wo Daten in vertikale Partitionen geteilt werden. Eine physikalische Trennung ist erforderlich, wenn die 2 GB-Grenze erreicht wird und eine neue Datei erzeugt werden muß, um weitere Informationen aufnehmen zu können. Der logische Blick auf diese Daten ist lediglich eine Vereinigung zweier Tabellen. Dieser Typ der Segmentierung sollte in einer Transaktionsumgebung benutzt werden, wo Daten zur Archivierung gesammelt, also selten geändert werden. Dies ist beim Sammeln wissenschaftlicher Daten der Fall. Abbildung 1 skizziert drei physikalische Dateien, die zusammen eine logische Tabelle ergeben.

Abbildung 1:
Horizontale Partitionierung
Drei physikalische Tabellen können horizontal partitioniert werden, so daß sie eine logische Tabelle ergeben.

Eine logische Trennung zusammengehörender Daten ist leicht zu implementieren, da die meisten großen Datenmengen es förmlich anbieten, sich gruppenweise trennen zu lassen. Es kann sich dabei um geographische, demographische, chronologische oder andere logische Gruppierungen handeln, die innerhalb der Daten existieren. Ein Vorteil dieser Methode, Daten zu teilen, ist, daß kleinere Anwendergruppen nur auf einer bestimmten Tabelle arbeiten, wodurch die Systemleistung optimiert wird.

Viele alltägliche Kommandos von FoxPro, zum Beispiel SEEK oder LOCATE, arbeiten nicht mit Daten, die in dieser Art geteilt sind, und SQL-Abfragen müssen vorsichtig formuliert werden, damit UNIONS zwischen allen physikalischen Tabellen erzeugt werden, die eine logische Einheit bilden. Man kann mit einer solchen Lösung aber arbeiten, da Abfragen häufig nur bestimmte Teile der Daten benötigen. Informationen werden häufig für eine gegebene Region abgefragt, so daß die regulären FoxPro-Kommandos gut arbeiten. Wenn alle Informationen benötigt werden, können Abfragen auf den einzelnen Tabellen ausgeführt werden, und wenn alle Unterabfragen erledigt sind, werden die Daten integriert.

Bei der vertikalen Partitionierung einer Tabelle werden die Daten in mehrere Dateien verteilt, wobei ein oder mehrere Schlüsselfelder in der einen Tabelle verbleiben, während die andere Tabelle die übrigen Informationen enthält (vgl. Abbildung 2). Für jeden Datensatz in der linken Tabelle existiert ein eindeutiger Schlüssel, der einem Fremdschlüssel der rechten Tabelle entspricht. Diese Partitionierungsmethode unterstützt Systeme, bei denen Abfragen nur auf indizierten Feldern ausgeführt werden und die Ergebnisdatensätze nur empfangen werden, wenn die Abfrage beendet ist. Die Tabelle und die dazugehörige Indexdatei können auf einer sehr schnellen Festplatte gespeichert sein, und der Rest der Information kann sich auf einer CD-ROM oder einem MO-Laufwerk befinden. Eine Abfrage wird auf der linken Tabelle ausgeführt, und ein Teil des Datensatzes wird zurückgegeben. Will der Anwender den gesamten Datensatz sehen, wird der eindeutige Schlüssel benutzt, um auf den entsprechenden Datensatz auf der CD-ROM zuzugreifen. Diese Methodik ist sinnvoll, wenn Abbildungen oder andere Daten in Memofeldern gespeichert werden. Die benötigten Verwaltungsinformationen beschränken sich auf die Schlüsselfelder, die die beiden Tabellen logisch verbinden.

Abbildung 2: Vertikale Partitionierung
Zwei physikalische Dateien sind vertikal partitioniert. Jeder Datensatz in der Tabelle A ist durch einen eindeutigen Schlüssel mit dem entsprechenden Datensatz in Tabelle B verbunden.

Die Idee, eine Tabelle vertikal zu splitten, ist ein Schritt auf dem Weg, Referenzen auf mehrere verbundene Tabellen zu erstellen. Die Haupttabelle enthält nicht ausschließlich die Schlüsselwerte, sondern auch Informationen über den Laufwerksbezeichner, den Pfad und den Alias-Namen der untergeordneten Tabelle, die die Detailinformationen für einen bestimmten Datensatz enthält (dargestellt in Abb. 3). Die Informationen können aufgrund logischer Werte wie Gegend, Monat oder Altersgruppen auf die Tabellen verteilt sein.

Abbildung 3: Partitionierung über Pointer
Jeder Datensatz in Tabelle A enthält eine logische Referenz auf den Namen der Tabelle, die die detaillierten Daten enthält und wie in Abbildung 2 einen eindeutigen Schlüssel. Bei Tabelle C kann es sich wie in Abbildung 2 um eine Partition oder um eine Memodatei handeln.

Die Aufnahme der Werte für den Pfad ist kritisch, da dadurch die Datenpflege vereinfacht wird. Sowohl NetWare als auch NT ermöglichen die logische Zuweisung von Laufwerksbezeichnern. Auch die Information, welcher Alias-Name verwendet wird, ist wichtig, da der Name der physikalischen Datei geändert werden kann. Die Benutzung einer Tabelle zur Datenbankadministration oder eines Data-Dictionary vereinfacht die Verwendung dieser logischen Namen - die physikalische Speicherung jeder Datei im System ist im Data-Dictionary gespeichert.

Nun wird es schon klarer, wie eine extrem große Datenbank erstellt werden kann. Die Primärtabelle könnte in ihren 2 GB 15 Millionen Datensätze mit eindeutigen Schlüsseln enthalten. Nehmen wir an, die Detaildatensätze haben mit ihren Daten in den Feldern und Memos jeweils eine Größe von 50 Kilobyte. Jede Detailtabelle kann also 40.000 Datensätze fassen. Die komplette Datenbank kann also 375 GB groß werden!

Die physikalische Datenhaltung

Während der Entwicklung wissen Sie wahrscheinlich noch nicht, wo Ihre Dateien letztendlich liegen werden. In einer Netzwerkumgebung werden die Daten im Normalfall auf einem einzelnen Laufwerk im Netz gespeichert, und auf der lokalen Platte des Anwenders werden die temporären Dateien abgelegt, die während der Ausführung von Abfragen, der Indexerstellung und anderer Operationen erstellt werden.

Eine Datenbank, die sehr große Tabellen enthält, muß sich eventuell über mehrere Laufwerke erstrecken, die aber mit einem einzigen Laufwerksbezeichner angesprochen werden. Dies ist möglich, da die Laufwerke in einem Netzwerk zu einem logischen Laufwerk zusammengefaßt werden können. Es ist einfacher, mit einem einzigen logischen Laufwerksbezeichner zu arbeiten, allerdings sind die Performance und Fehlertoleranz besser, wenn für große Systeme mehrere Laufwerksbezeichner verwendet werden.

Das Risiko, die gesamte Datenbank nicht mehr ansprechen zu können, wenn ein einzelnes Laufwerk ausfällt, wird minimiert, wenn die Tabellen über mehrere Partitionen verteilt sind. Sind mehrere Laufwerke zu einer logischen Partition zusammengefaßt und ein Laufwerk fällt aus, kann unabhängig von den darauf gespeicherten Daten auf die gesamte logische Partition nicht mehr zugegriffen werden.

Große Partitionen, und mit denen beschäftigen wir uns hier, benötigen für eine Reparatur mehr Zeit, da die gesamte Partition repariert werden muß und nicht nur ein einzelnes Laufwerk.

Es gibt noch einen anderen Vorteil, mit mehreren Partitionen zu arbeiten - auf diese Weise ist es einfacher, den Zugriff auf bestimmte Tabellen zu beschränken, da Sie lediglich mit den Laufwerksbezeichnern arbeiten müssen. In diesem Fall entsprechen die Partitionen 1:1 den Festplatten.

Die Performance wird auch gesteigert, wenn die Tabellen den Festplatten und die Indizes einem alternativen Laufwerk zugeordnet sind. Die Leseköpfe der Festplatte müssen dann nicht erst nach dem Indexeintrag und anschließend nach den Daten suchen. Zuguterletzt sollte Ihre Partitionierung der Daten sicherstellen, daß mit den meisten Netzwerksystemen gearbeitet werden kann, da Windows NT und Novell unterschiedlich auf die Daten zugreifen.

Freien Plattenplatz reservieren

Viele wichtige Verwaltungsprozeduren wie Backup und Restore, Sortierung von Tabellen, Reservierung neuen Speicherplatzes usw. benötigen viel freien Plattenplatz. Der hierfür benötigte Platz auf der Festplatte kann mehrere Gigabyte groß werden. Die Größe des dafür zur Verfügung stehenden Platzes sollte sich an der größten Datei orientieren. Wenn Sie die Bedingungen für die Speicherung in großen Systemen planen, sollten Sie mehrere Gigabyte freien Platzes nur für die Verwaltungsfunktionen vorsehen.

Wenn ein Partitionsschema wie das oben beschriebene verwendet wird, muß der Datenbankadministrator die Entscheidung treffen, wann den Arbeitstabellen neuer Platz zugeordnet wird. Der aktuell vorhandene freie Speicherplatz muß überprüft werden, bevor größere Mengen neuer Daten in die Tabelle eingefügt werden. Da sich dabei die Tabelle vergrößert, muß sichergestellt sein, daß kein anderer Prozeß Plattenplatz auf der Festplatte, mit der Ihre Datenbank arbeitet, benötigt. Anders als mit Oracle oder Sybase kann bei FoxPro kein freier Plattenplatz automatisch reserviert werden.

Manchmal ist es notwendig, Platz für binäre Daten zu reservieren. Wenn Ihr System die Daten in normalen Feldern speichert, kann jeder Datensatz maximal 65 KB groß sein. Wenn Sie Felder der Typen Memo oder Objekt verwenden, liegt das Problem anders. Ein einziger Datensatz kann bis zu 2 Gigabyte groß werden. Der Datenbankadministrator muß in diesem Fall aktiv den verfügbaren Speicherplatz überwachen, um Fehlern durch fehlenden Platz auf der Festplatte vorzubeugen.

Es gibt mehrere Methoden, den benötigten Raum für Ihre Daten sicherzustellen. Die einfachste Methode ist, den Anwendern den Plattenzugriff zu verweigern, wenn sie nicht mit der Datenbank arbeiten. Das ist auch die Methode, die ich verwende. Sie können sie mit einem Script des Betriebssystems des Netzwerks verwirklichen. Leider ist dieses Vorgehen nicht immer möglich, so daß Sie auf ein anderes Vorgehen ausweichen müssen.

Da FoxPro mit festen Feldlängen arbeitet, können wir mit gelöschten leeren Datensätzen den benötigten Platz auffüllen. Es ist einfach, eine Methode zu entwickeln, die den nächsten gelöschten Datensatz sucht und ihn benutzt, um neue Daten zu speichern. Viele Entwickler benutzen bereits eine solche Methode, um nicht mehr benötigte Datensätze aus ihrer Datenbank zu entfernen. Der Nachteil dabei ist, daß Ihre Tabellen ständig die maximale Größe haben, unabhängig von der tatsächlich benötigten Größe. Zusätzlich erleidet das System Geschwindigkeitseinbußen. Eventuell müssen Sie die aktuelle Anzahl der Datensätze zusätzlich protokollieren, da RECCOUNT() auch die gelöschten Datensätze zählt.

Eine andere Möglichkeit, freien Platz zu reservieren, besteht darin, einige Dateien auf das Laufwerk zu schreiben, die nichts anderes tun als Platz zu belegen. Wenn die FoxPro-Applikation mehr Platz benötigt, löscht sie einzelne Dateien. Eine Partition von 2 GB kann mit zwanzig 100-MB-Dateien reserviert werden. Das kann aber Probleme mit dem Betriebssystem des Netzwerks hervorrufen, da durch dieses Vorgehen Ressourcen für die Verzeichnisverwaltung und nach dem Löschen der Dateien für ein eventuelles Wiederherstellen gebraucht werden. Die Probleme werden sichtbar, wenn Sie ein Backup ausführen wollen und die Backup-Software hat einen ungenügenden Cache für die Ausführung. Bei einem Test, den ich kürzlich ausführte, ist dieses Problem aufgetreten.

Geschwindigkeit

OK, ich weiß, was Sie jetzt denken: Es ist möglich, eine wirklich große Datenbank zu erstellen, aber wie schnell kann in dieser Datenbank auf die Daten zugegriffen werden? Gerade hier hat FoxPro seine Stärke. Abfragen, die sich auf indizierte Felder beziehen, sind sehr schnell - auch in Tabellen mit 10 Millionen Datensätzen. Die Abfragen müssen natürlich Rushmore-optimiert sein, aber der wirklich kritische Faktor ist die Art, wie die Daten auf der Festplatte gespeichert sind. Antwortzeiten sind direkt davon abhängig, wie die Daten in der Tabelle physikalisch sortiert sind, nicht nur vom Index. Die Daten sollten entsprechend dem am häufigsten benutzten Index sortiert sein. Die Antwortzeiten für einen einfachen Test sind in Abbildung 4 (siehe nächsten Seite) dargestellt. Dieser Test mißt die Zeit, die notwendig ist, um eine Tabelle mit zwei Millionen Datensätzen zu durchsuchen. Die kurzen Balken zeigen die Zeiten bei Tabellen an, die sortiert waren, der große Balken die Zeit auf einer Tabelle, in die die Daten in zufälliger Reihenfolge eingegeben wurden.

Abbildung 4

Abbildung 5: Verbinden großer Tabellen

Die physikalische Sortierung macht gewaltige in der Geschwindigkeit der Abfragen.

Abbildung 5 zeigt die Zeiten einer Abfrage über zwei verbundene Tabellen, von denen eine 100.000, die andere zwei Millionen Datensätze enthält. Das Abfrageergebnis war 100.000 Datensätze groß. Beachten Sie, daß, wenn beide Tabellen physikalisch entsprechend dem Index sortiert sind, sich die Antwortzeit fast um den Faktor 10 verkürzt.

Datenkomprimierung

Wir benutzen häufig hausgemachte Algorithmen für die Datenkompression, um die Tabellengröße zu minimieren. Datenkomprimierung läßt sich nur bei Daten, die in Memofeldern gespeichert sind, anwenden. Für Daten, die in Feldern enthalten sind, ist einfach der Overhead zu groß. Gebräuchliche Programme für die Echtzeit-Datenkomprimierung wie DblSpace oder Stacker muß man aus Geschwindigkeitsgründen und aus Gründen der Fehlertoleranz, die diesen Technologien eigen ist, ausschließen. Software, die bei Bedarf ausgeführt wird, wie lha oder PkZip, kann eingesetzt werden, da sie auf der Basis Datei-für-Datei arbeitet und die Speicherung der Daten auf der Festplatte nicht verändert.

Die Datenkompression kann sehr effektiv eingesetzt werden, wenn man die Natur der gespeicherten Daten verstanden hat. Das Wissen über ein Muster oder eine definierte Struktur kann benutzt werden, um die effizienteste Komprimierungsmethode für diese Daten einzusetzen. Man muß dann bei Benutzung der Komprimierung lediglich einen Kompromiß bei der Geschwindigkeit der Lese- und Schreibzugriffe eingehen, und exportierte Daten sind nicht lesbar, wenn sie nicht vorher dekomprimiert werden. Der Vorteil des Gebrauchs einer eigenen Datenkomprimierung liegt darin, daß man die volle Kontrolle über sie hat. Die Komprimierung kann geändert werden, wenn sich die Daten ändern, und sie kann beliebig aktiviert oder deaktiviert werden. Außerdem sind Sie nicht auf die manchmal merkwürdigen Einfälle von Betriebssystem- oder Third-Party-Anbietern angewiesen.

Datenzugriff

Routinen zum Öffnen von Dateien müssen robust sein und die Angabe des vollständigen Pfades jeder einzelnen Datei ermöglichen. Laufwerksbezeichner und Pfad sollten getrennt abgelegt sein und erst während der Laufzeit zur Ermittlung des korrekten Pfades der Datei miteinander verbunden werden. Das ist mit Hilfe eines Data-Dictionary oder einer Tabelle zur Daten-Administration am einfachsten durchzuführen. Novell ermöglicht es Ihnen, dynamisch logische Laufwerksbezeichner zu erstellen. Diese Möglichkeit können Sie für die Administration ausnutzen.

Für den Fall, daß sich Probleme mit einem Laufwerk ankündigen, haben Sie die Möglichkeit, die Daten auf ein anderes Laufwerk zu kopieren - dies kann sowohl von Band als auch vom aktuellen Laufwerk geschehen - und anschließend den Laufwerksbezeichner Ihrer Dateiöffnungsroutine zu ändern. Mit dieser Technik können Sie Ihre Daten auch auf einem anderen Fileserver wiederherstellen. Alternativ dazu können Sie auch Alias-Namen benutzen, um auf eine andere Kopie Ihrer Daten zuzugreifen.

Die Dateiöffnungsroutinen sollten auch die Intelligenz eingebaut haben, Ihren Anwender über den aktuellen Status einer Datei zu informieren. Das ist kein Problem, wenn der Zugriff auf die Daten möglich ist, aber für den Fall, daß im Moment eine Datensicherung oder -wiederherstellung stattfindet, sollten Sie den Anwender darüber informieren, daß zur Zeit Teile der Datenbank nicht genutzt werden können. Nachdem die Daten im System wieder verfügbar sind, sollte der Anwender die Möglichkeit haben, die Tabelle nachträglich zu öffnen.

Verwaltung

Datenbanksysteme erfordern eine regelmäßige Verwaltung. Es könnte vorkommen, daß Strukturen geändert werden müssen, Daten könnten auf eine schnellere Hardware verlagert werden oder Informationen müssen gesichert werden. Ein gut geplantes System führt Verwaltungsaufgaben durch und läßt währenddessen den Anwender so weit wie möglich weiterarbeiten - auch bei Verwaltungsaufgaben, die nicht regelmäßig durchgeführt werden. Ein Schalter in der Datenbankadministrationstabelle kann Dateien, die für das System verfügbar sind, markieren und den Status der übrigen Dateien anzeigen. Ihr System sollte also den Anwender mit Teilen der Applikation weiterarbeiten lassen, auch wenn einige Tabellen nicht verfügbar sind. Es ist unwahrscheinlich, daß Ihre Anwender jederzeit den Zugriff auf sämtliche Daten benötigen. Daher ist die teilweise Abschaltung der Applikation akzeptabel.

Es ist wichtig, zu verstehen, wie Ihre Applikation die Dateien wie Memofelder oder Indizes behandelt. Indizes wachsen, wenn ein neuer Datensatz angelegt wird. Sie wachsen auch, wenn ein Teil des Schlüssels, der im Indexausdruck verwendet wird, sich ändert. Viele Entwickler recyceln gelöschte Datensätze, indem sie jedes Feld des gelöschten Satzes mit Leerzeichen auffüllen. Dieser Datensatz wird dann erneut verwendet, wenn ein neuer Datensatz in das System eingefügt wird. Bei jedem Aufruf von DELETE und REPLACE wächst der Index. Um den kleinstmöglichen Index zu erhalten, stellen Sie sicher, daß Ihre Daten in der gleichen Reihenfolge sortiert sind wie der Indexausdruck.

Wenn ein PC Verwaltungsaufgaben ausführt, muß er über eine ausreichend große Festplatte, einen schnellen Prozessor und genügend Arbeitsspeicher verfügen, um Höchstleistung zu vollbringen. Wenn Indizes für Tabellen mit Millionen Datensätzen erstellt werden, haben wir ein Problem, falls einige unserer Festplatten nicht über genügend Platz für die temporären Dateien verfügen, die während der Indizierung entstehen.

Backup und Restore

Murphys Gesetz ist in Computersystemen immer präsent. Es kann immer etwas schiefgehen; darum ist es wichtig, daß Sie ein Backup Ihrer Daten besitzen. Die beste Methode, ein Backup zu erstellen ist, die Anwender sich aus dem System abmelden zu lassen und anschließend die Backup-Software aufzurufen. So erhalten Sie ein Backup, bei dem alle Transaktionen abgeschlossen, die Indizes upgedatet und die Relationen zwischen den Tabellen aktuell sind. Der Nachteil dieses Vorgehens ist, daß die Anwender während des Backup-Prozesses unproduktiv sind und warten. Dieses Szenario des Backup ist nicht akzeptabel, wenn ein System ständig verfügbar sein muß.

Die folgende Betrachtung geht davon aus, daß eine Kommunikation zwischen der Datenbank und der Backup-Software möglich ist. Es müssen Kommandos gesendet und empfangen werden, um das Backup zu starten oder zu stoppen und den Status des Backup-Prozesses zu erhalten. Die Möglichkeit, Dateinamen mit ihrem vollen Pfad auszutauschen, ist von äußerster Wichtigkeit. Alle Transaktionen zwischen der Backup-Software und der Datenbankapplikation müssen von beiden Systemen protokolliert werden. Ist ein Restore notwendig, sollten sich mit Hilfe des Log-Systems das entsprechende Band und die passende Backup-Session leicht herausfinden lassen. Wird ein Backup oder ein Restore ausgeführt, muß dies für die FoxPro-Applikation sichtbar sein.

Es ist problematisch, wenn Sie ein Backup eines arbeitenden Systems erstellen. Die Backup-Software überspringt offene Dateien, um es später noch einmal mit diesen Dateien zu versuchen. Dateien, die immer noch geöffnet sind, werden vollständig ausgelassen. Daher würden Sie ein unvollständiges Backup der Datenbank erhalten. Eine einfache und effektive Lösung dieses Problems lautet, einen zweiten, identischen Datenbestand zu erstellen, solange das System arbeitet. Ein temporärer Arbeitsbereich wird ausschließlich für Backup- und Restore-Prozeduren angelegt. Mit FoxPro werden Daten Satz für Satz in diesen Arbeitsbereich kopiert, so daß die normalen Arbeiten mit den Tabellen weiterhin möglich sind. Wenn die Kopie vollständig ist, wird ein Kommando an die Backup-Software geschickt, die die Daten der Kopie statt der des Originals auf Band schreibt.

Diese Backup-Methode ist nicht narrensicher. Durch das Kopieren der Daten Satz für Satz unter Verwendung der entsprechenden Datensatzsperren erhalten Sie lediglich den Status der Datenbank zu einem bestimmten Zeitpunkt. Unvollständige Transaktionen werden dabei nicht berücksichtigt. Das ist alles, was man von einer Backup-Software erwarten kann, die arbeiten muß, während die Tabellen geöffnet sind. Immer, wenn Daten in Tabellen häufig aktualisiert werden, kann es passieren, daß dauernd unvollständige Transaktionen vorliegen. Echtzeit-Backups, wie sie mit Oracle oder dem SQL-Server eingesetzt werden, ergeben nur teilweise ein besseres Ergebnis, wenn gleichzeitig mit dem System gearbeitet wird. In unseren Systemen benutzen wir unterschiedliche Stufen der Redundanz, um sicherzustellen, daß, wenn während des Backup-Prozesses Daten geändert werden, irgendwo im System ein Datensatz mit dieser Aktivität existiert. Damit ist gemeint, daß ein korrektes Backup der Daten zu einem definierten Zeitpunkt erstellt werden kann.

Wie ich bereits früher ausgeführt habe, ist die beste Methode, ein Backup zu erstellen, die Anwender abzumelden und anschließend das Backup auszuführen. Warum nicht die Anwender, statt sie aus dem gesamten System abzumelden, nur aus einem Teil der Datenbank entfernen? Eine Datenbank kann aus vielen Teilen bestehen, und eine Tabelle kann aus vielen Partitionen bestehen. Wenn, wie bereits beschrieben, eine Tabelle für die Datenbankadministration benutzt wird, kann der Datenbankadministrator einzelne Tabellen für die Anwender sperren. Die Tabelle wird mit dem entsprechenden Flag als inaktiv gekennzeichnet und so vor dem Zugriff durch die Anwender geschützt. Die Backup-Software erhält das Kommando, die Tabelle zu sichern. Nach der Beendigung dieser Aktion wird die Tabelle wieder als aktiv markiert.

Das Restore arbeitet dementsprechend. Die Daten werden zunächst in einem temporären Arbeitsbereich zurückgeschrieben. Die FoxPro-Applikation überprüft die Daten, mit denen sie arbeitet, und entscheidet Satz für Satz, wie die zurückgeschriebenen Informationen der aktiven Tabelle hinzugefügt werden.

Datenintegrität

FoxPro ist ein stabil laufendes Produkt. Trotzdem können defekte Tabellen auftreten - obwohl dies unwahrscheinlich ist -, häufig ohne Ihr Wissen. Auch eine perfekte Applikation kann beschädigte Daten enthalten. Meine Erfahrung hat gezeigt, daß eine Beschädigung der Daten in der Regel das Ergebnis inkompatibler Treiber, defekter Hardware oder gleichgültiger Anwender ist. Nur die ersten zwei Ursachen defekter Daten unterliegen Ihrer Kontrolle.

Kompatible Versionen der Treiber sind in einer Netzwerkumgebung besonders wichtig, und mit einem kompletten Testen stellen Sie sicher, daß Sie ein stabiles System entwickelt haben, da Probleme häufig nicht direkt sichtbar sind. Es existieren Treiber für das Netzwerk, die Grafikkarte, das Betriebssystem der Workstation, die Festplatte der Workstation, die Festplatte des Netzwerks, das Bandlaufwerk usw. Das Erstellen eines stabilen Systems kann zu einem Abenteuer werden, da es selten vorkommt, daß der Hersteller einer installierten Komponente alle Kombinationen anderer Komponenten kennt, die mit den seinen zusammenarbeiten. Die Installation einer neuen Version einer Komponente führt häufig zu Problemen mit dem Rest des Systems, so daß eine ganzheitliche Herangehensweise an das Problem zu empfehlen ist. Es ist ratsam, ein neues Servicepack für das Betriebssystem erst auf einem Testsystem zu erproben, bevor Sie alle Ihre PCs upgraden. Neue Versionen beseitigen einige Probleme, können aber auch neue hervorrufen.

Defekte Hardware ist in der Regel einfacher festzustellen und zu reparieren, obwohl auch manche Hardwarefehler schwierig festzustellen sind. Defekte Netzwerkkarten können dazu führen, daß falsche Datenpakete versandt oder empfangen werden. Meine Erfahrung mit Treibern und Hardware ist, daß man ausschließlich Markenprodukte verwenden sollte, und sei es nur, um besseren technischen Support zu erhalten. Die Verkabelung ist von höchster Wichtigkeit. Es ist unerläßlich, die korrekten Kabeltypen für Ihr Netzwerk zu verwenden. Auch die Verkabelung in Ihrem PC und dem Server ist wichtig. SCSI-Kabel sind häufig die Quelle für Fehler bis hin zum Ausfall sämtlicher Netzwerklaufwerke. Einer meiner Kunden hat die billigen SCSI-Kabel, die mit seinem Laufwerk geliefert wurden, durch Markenkabel ausgetauscht, und seine Rechner laufen seitdem fehlerfrei.

Valdis Matison leitet seit über 10 Jahren die Matison Consulting Group, eine Beratergruppe in Kanada mit dem Schwerpunkt auf Anwendungsprogrammierung unter Visual FoxPro und anderen Programmiersprachen. Er organisiert die kanadische FoxPro-Entwicklerkonferenz "FoxTeach" sowie weitere Konferenzen zu Access, VB und anderen Produkten und außerdem selbst Redner auf verschiedenen Konferenzen. Schwerpunkte sind u.a. große Datenbanken und Data-Warehousing. Valdis Matison erreichen Sie per eMail unter webmaster@dbcentral.com oder 70632.317@compuserve.com.