DE69724554T2

DE69724554T2 - Datenübertragungsmechanismus

Info

Publication number: DE69724554T2
Application number: DE69724554T
Authority: DE
Inventors: Arthur George Sandback Cheshire Sealby; Lawrence Gregory West Didsbury Manchester Griffiths
Original assignee: Fujitsu Services Ltd
Current assignee: Fujitsu Services Ltd
Priority date: 1996-11-12
Filing date: 1997-10-24
Publication date: 2004-08-05
Anticipated expiration: 2017-10-25
Also published as: EP0841626B1; EP0841626A1; DE69724554D1; US5890159A; GB9623472D0

Description

Hintergrund der Erfindung
Die Erfindung bezieht sich auf einen Datenübertragungsmechanismus. Insbesonderes, jedoch nicht ausschließlich, betrifft die Erfindung einen Datenübertragungsmechanismus zum Übertragen von Daten zwischen in Beziehung miteinander stehenden Datenbanken an Kunden- und Server-Einrichtungen.
Herkömmliche Techniken zum Übertragen von Daten zwischen zwei miteinander in Beziehung stehenden Datenbanken machen es erforderlich, dass die Daten zuerst aus der Quellen-Datenbank in eine flache Datei eingelesen und dann von der flachen Datei in die Ziel-Datenbank übertragen werden. Ein Problem hierbei besteht jedoch darin, dass dieser Vorgang langsam abläuft, so dass eine zu hohe Zeitdauer erforderlich ist, um große Mengen an Daten zu verarbeiten.
EP-A- 0 586 158 beschreibt ein System, bei dem Aufzeichnungen in unabhängigen Datenbanken an unterschiedlichen Knoten gespeichert werden. Jeder Knoten weist eine Datenbank-Schnittstelle auf, die zwischen unterschiedlichen Aufzeichnungsformaten, die in den Datenbanken vorhanden sind, und einem gemeinsamen standardisierten Aufzeichnungsformat, das zum Kommunizieren von Aufzeichnungen zwischen den Knoten verwendet wird, übersetzt. Dadurch wird das Problem unterschiedlicher Datenbank-Aufzeichnungsformate angesprochen, nicht aber das einer effezienten Datenübertragung.
„OS/2 Notebook – The Best of IBM Personal Systems Developer" 1990, ed. Dick Conklin, Microsoft Press, Seiten 348 bis 358 beschreibt die Verwendung einer bezeichneten Pipe in einem Server-Rechner für Zweiwege-Übertragung von Daten veränderlicher Länge zwischen einem Kunden-Vorgang und einem Server-Vorgang, der entfernt davon abläuft. Dieses Dokument beschreibt jedoch nicht das Problem der effizienten Datenübertragung von einer ersten Datenbank auf einem ersten Rechner an eine zweite Datenbank auf einem zweiten Rechner.
Aufgabe der Erfindung ist, einen neuartigen Datenübertragungsmechanismus vorzuschlagen, um Daten von einer ersten Datenbank an einem ersten Rechner auf eine zweite Datenbank an einem zweiten Rechner in effizienter Weise zu übertragen.
Kurzbeschreibung der Erfindung
Gemäß der Erfindung wird ein Rechnersystem mit einem ersten Rechner, der eine erste Datenbank enthält, einem zweiten Rechner, der eine zweite Datenbank enthält, und einen Datenübertragungsmechanismus zum Übertragen von Daten von der ersten Datenbank auf die zweite Datenbank vorgeschlagen, der sich dadurch auszeichnet, dass der Datenübertragungsmechanismus im ersten Rechner eine Pipe, einen Entladevorgang zum Auslesen von Daten aus der ersten Datenbank in die erste Pipe und einen Sendevorgang zum Auslesen von Daten aus der ersten Pipe und zum Senden der Daten an den zweiten Rechner und im zweiten Rechner eine zweite Pipe, einen Empfangsvorgang zum Einschreiben von aus dem ersten Rechner aufgenommenen Daten in die zweite Pipe, und einen Ladevorgang zum Einschreiben von Daten von der zweiten Pipe in die zweite Datenbank aufweist.
Kurzbeschreibung der Zeichnungen
1 ist ein schematisches Blockschaltbild eines Rechnersystems mit Kunden- und Server-Maschinen;
2 ist ein schematisches Blockschaltbild, das Software-Komponenten-darstellt, die in der Kunden-Maschine laufen;
3 ist ein schematisches Blockschaltbild, das Software-Komponenten zeigt, die in der Server-Maschine laufen;
4 ist eine Flussschaltbild, das den Betrieb einer generischen Kunden-Komponente zeigt;
5 ist eine Flussschaltbild, das den Betrieb einer generischen Server-Komponente zeigt.
Beschreibung eines Ausführungsbeispiels der Erfindung
Eine Ausführungsform der Erfindung wird nachstehend anhand eines Beispiels in Verbindung mit der zugehörigen Zeichnung erläutert.
In 1 zeigt ein Computersystem mit einer Kunden-Maschine 10 und einer Server-Maschine 11, die über ein Netzwerk 12 miteinander verbunden sind. In dem vorliegenden Beispiel sind die Kunden- und Server-Maschinen beides UNIX-Maschinen. Beispielsweise kann die Server-Maschine eine ICL-Goldrush-Maschine sein. Das Netzwerk kann das Standard TCP/IP-Protokoll benutzen.
UNIX ermöglicht die Verwendung von bezeichneten Pipes. Eine bezeichnete Pipe ist ein Standard-UNIX-Mechanismus zum Umleiten des Ausgangs eines Prozesses auf den Eingang eines zweiten Prozesses. Pipes werden als normale Dateien von UNIX behandelt: Sie können durch einen Code benutzende Standard-IO-System-Anrufe zugegriffen werden.
Nach 2 weist die Kunden-Maschine ein relationales Datenbank-Management-System (RDBMS) 20 und eine Kunden-Anwendung 21 auf. Das RDBMS kann bei spielsweise eine Ingres- oder Orakle-Datenbank enthalten. Die Kunden-Anwendung kann eine beliebige Anwendung sein, die das RDBMS benutzt.
Nach 3 besitzt die Server-Maschine auch ein RDBMS 30. Der Server RDBMS 30 kann der gleiche sein wie der Kunden-RDBMS 20, er kann jedoch auch anders ausgebildet sein. Beispielsweise können beide Ingres-Datenbanken sein, oder der Kunden-RDBMS kann eine Ingres-Datenbank und der Server RDBMS kann eine Orakle-Datenbank sein. Es wird unterstellt, dass es erforderlich ist, Daten von dem Kunden-RDBMS 20 zum Server-RDBMS 30 zu übertragen.
Nach 2 weist die Kunden-Maschine einen schnellen Pipe-Mechanismus 22 zur effizienten Übertragung von Daten von dem Kunden-RDBMS zum Server-RDBMS auf. Der schnelle Kunden-Mechanismus besteht aus zwei Komponenten, einer datenbankspezifischen Komponente 23 und einer generischen Kunden-Komponente 24. Die datenbankspezifische Komponente 23 ist spezifisch für den speziellen Kunden RDBMS und der Kunde kann verschiedene unterschiedliche datenbankspezifische Komponenten für unterschiedliche RDBMS-Typen enthalten. Beispielsweise kann eine spezifische Komponente für Ingres und eine andere für Orakle vorgesehen sein. Die generische Kunden-Komponente 24 andererseits ist generisch für alle RDBMS-Typen.

Wenn im Betrieb die Kunden-Anwendung 21 erforderlich macht, Daten von dem Kunden-RDBMS auf das Server-RDBMS zu übertragen, führt sie einen Anruf zur datenbankspezifischen Komponente 23 aus. Die Ruf-Schnittstelle zu dieser Komponente hat Parameter, die spezifisch für die Entlade-Programme sind, die von dem Kunden-RDBMS angeboten werden und für die Lade-Programme, die von dem Server-RDBMS angeboten werden. Anhand eines Ausführungsbeispieles ergibt die datenbankspezifische Komponente, die für Ingres-Datenbanken spezifisch ist, einen Befehl „ingtooracle" zum Übertragen einer Tabelle von einer Ingres-Datenbank an eine Orakle-Datenbank. Dieser Befehl hat folgende Parameter:

ppathname	Der Pfadname des Servers (d. h. die Netzwerk-Adresse der Server-Maschine).
srows	(Wahlweise). Die Anzahl von Reihen, die vom Beginn der Tabelle an nicht in die Server-Datenbank geladen werden. Dies ist zweckmäßig, wenn es erforderlich ist, eine Last aufrecht zu er halten, die aus irgendeinem Grund unterbrochen worden war.
ddirectory	(Wahlweise). Der Name eines Inhaltsverzeichnisses, das „copydb" Skript-Dateien hält.
userid	Der Benutzername/das Passwort des Benutzers, das das Laden auf die Server-Maschine ausführt.
dbname	Der Name der Datenbank an der Kunden-Maschine, die die zu übertragende Tabelle enthält.
tablename	Der Name der Tabelle in der speziellen Datenbank, der übertragen werden soll.

Die datenbankspezifische Komponente verifiziert die Parameter des Anrufes und konstruiert dann einen „fastpipe" Anruf zu der generischen Kunden-Komponente 24, die die folgenden Parameter enthält:

ppathname	Der Pfadname des Servers.
hheader	Eine Kopfzeile (siehe unten).
fdata_filename	Dies spezifiziert den Namen einer Pipe, die zum Übertragen von Daten aus der Kunden-Datenbank benutzt werden soll.
ssgl_filename	Der Name einer Datei, die einen SQL-Skript enthält, der von
	dem Ladeprogramm im Server benötigt wird.
client_command_line	Eine Befehlsleitung zur Ausführung durch den Kunden.

Die Kopfzeile ist im „tld" (Typ, Länge, Daten) Format und weist die folgenden Informationen auf:

– Einen Wert, der angibt, ob die zu übertragenden Daten formatiert oder nicht formatiert sind.
– Der SQL-Skript-Dateiname (wenn einer spezifiziert worden ist). Dies dupliziert die Informationen im Parameter -ssgI_Dateiname. Eine Länge von 0 gibt an, dass kein SQL-Skript eingespeist worden ist.
– Eine Server-Befehls-Leitung zur Ausführung durch den Server.
– Einen Pipe-Namen zur Verwendung durch den Server.

Wenn die generische Kunden-Komponente diesen Anruf empfängt, führt sie die folgenden Aktionen aus, wie in 4 gezeigt: (Schritt 41) Die generische Kunden-Komponente kreiert eine bezeichnete Pipe 25 mit dem Namen -fdata filename.
(Schritt 42) Die generische Kunden-Komponente sendet dann den Kopfteil über das Netzwerk 12 an den Server, wobei der spezifizierte -ppathname als Netzwerk-Bestimmungsadresse verwendet wird.
(Schritt 43) Wenn ein SQL-Skript-Dateiname spezifiziert worden ist, führt die generische Kunden-Komponente einen Zugriff zu diesem Skript aus und sendet ihn an den Server, unmittelbar im Anschluss an das Kopfteil.
(Schritt 44) Die generische Kunden-Komponente führt dann die Kunden-Befehlsleitung aus. Dadurch wird das Daten-Entlade-Programm des Kunden-RDBMS aufgerufen, wobei die bezeichnete Pipe 25 als die Ausgangs-Datei spezifiziert wird. Das Entlade-Programm beginnt dann, die gewünschten Daten von der Kunden-Datenbank zu entladen und sie in die bezeichnete Datei 25 einzuschreiben.
(Schritt 45) Dieser Schritt beginnt mit einem Sendevorgang 26. Dieser liest die Daten von der bezeichneten Pipe 25 aus, kopiert sie in einen Puffer und, wenn der Puffer voll ist, sendet die Daten über das Netzwerk an den Server.
Nach 3 weist die Server-Maschine eine generische Server-Komponente 31 auf. Diese nimmt den Kopfteil auf, der durch den Kunden gesendet worden ist, ferner auch einen beliebigen SQL-Skript, und führt die folgenden Vorgänge durch, wie in 5 gezeigt:
(Schritt 51) Die generische Server-Komponente entnimmt den Pipe-Namen aus dem Kopfteil und benutzt diesen zum Kreieren einer bezeichneten Pipe 32.
(Schritt 52) Die generische Server-Komponente entnimmt anschließend den SQL-Skript-Dateinamen (falls vorhanden) aus dem Kopfteil und benutzt diesen, um den spezifizierten SQL-Skript zu laden und zu betreiben.
(Schritt 53) Die generische Server-Komponente entnimmt dann die Server-Befehls-Zeile, die aus dem Kopfteil entnommen worden ist und führt sie aus. Dies bringt das Daten-Ladeprogramm in den Server RDBMS, wobei die bezeichnete Pipe 33 als die Eingangs-Datei spezifiziert wird. In dem Fall, in dem der Server RDBMS eine Orakle-Datenbank ist, enthält die Server-Befehlszeile den userid-Parameter als ein Passwort, damit er die erforderlichen Tabellen zugreift.
(Schritt 51) Wenn die Daten aus dem Netzwerk ankommen, schreibt die generische Server-Komponente diese Daten in die Pipe 32 ein. Das Lade-Programm liest dann diese Daten aus der Pipe 32 aus und schreibt sie in die Datenbank ein.
Daraus ergibt sich, dass die Verwendung der Pipes 25, 32 auf diese Weise ermöglicht, den Prozess 26 zu senden, um eine Übertragung von Daten über das Netzwerk zu beginnen, sobald Daten in der Pipe 25 zur Verfügung stehen, ohne dass gewartet werden muss, bis die gesamte Tabelle entladen ist. Des weiteren beginnt der Ladevorgang an der entfernten Server-Maschine, sobald die Pipe 32 das erste Paket von Daten aus dem Netzwerk aufgenommen hat. Somit erfolgen alle Entlade-, Übertragungs- und Lade- Vorgänge gleichzeitig (oder parallel). Dadurch wird die Effizienz des Übertragungsmechanismus entscheidend verbessert.
Einige mögliche Modifikationen
Es gibt viele Modifikationen, die an dem vorbeschriebenen System vorgenommen werden können, ohne dass vom Schutzumfang der Erfindung in der beanspruchten Form abgewichen wird. Beispielsweise können Kompressions- und Dekompressions-Techniken für die Übertragung der Daten verwendet werden.

Claims

Rechnersystem mit einem ersten Rechner (10), der eine erste Datenbank (20) enthält, einem zweiten Rechner (11), der eine zweite Datenbank (30) enthält, und einen Datenübertragungsmechanismus zum Übertragen von Daten von der ersten Datenbank in die zweite Datenbank, dadurch gekennzeichnet, dass der Datenübertragungsmechanismus aufweist a) im ersten Rechner eine erste Pipe (25), einen Entladevorgang zum Auslesen von Daten aus der ersten Datenbank in die erste Pipe, und einen Sendevorgang (26) zum Auslesen von Daten aus der ersten Pipe und zum Senden der Daten an den zweiten Rechner, und b) im zweiten Rechner eine zweite Pipe (32), einen Empfangsvorgang (31) zum Einschreiben von aus dem ersten Rechner aufgenommenen Daten in die zweite Pipe, und einen Ladevorgang zum Einschreiben von Daten von der zweiten Pipe in die zweite Datenbank.
System nach Anspruch 1, bei dem der Datenübertragungsmechanismus aufweist a) im ersten Rechner eine Vorrichtung (23), die erste und zweite Befehlsleiter kreiert, eine Vorrichtung (44), die bewirkt, dass der erste Befehlsleiter durch den ersten Rechner ausgeführt wird, um den Entladevorgang einzuleiten, und eine Vorrichtung (42) zum Senden des zweiten Befehlsleiters an den zweiten Rechner, und b) im zweiten Rechner eine Vorrichtung (53) zum Ausführen des zweiten Befehlsleiters, um den Ladevorgang einzuleiten.
Rechnersystem nach Anspruch 1, bei dem a) der erste Rechner (10) eine erste Vorrichtung (41) zum Kreieren des ersten Leiters (25), eine Vorrichtung (42) zum Senden einer den zweiten Leiter (32) spezifizierenden Nachricht an den zweiten Rechner (11), und eine Vorrichtung (44) zum Anrufen des Entladevorganges, der den ersten Leiter als einen Ausgang spezifiziert, und b) der zweite Rechner (11) eine Vorrichtung (51), die auf die Nachricht zum Kreieren des zweiten Leiters (32) im zweiten Rechner anspricht, und eine Vorrichtung (53) aufweist, um den Ladevorgang anzurufen, der den zweiten Leiter als einen Eingang spezifiziert.
Verfahren zum Übertragen von Daten zwischen einer ersten Datenbank auf einem ersten Rechner und einer zweiten Datenbank auf einem zweiten Rechner, dadurch gekennzeichnet, dass a) eine erste Pipe im ersten Rechner kreiert wird, b) eine Nachricht an den zweiten Rechner gesendet wird, der spezifiziert, dass ein zweiter Leiter in dem zweiten Rechner kreiert wird, c) der zweite Leiter in dem zweiten Rechner kreiert wird, d) im ersten Rechner Daten aus der ersten Datenbank in den ersten Leiter umgeladen werden, e) im ersten Rechner Daten aus der ersten Pipe ausgelesen und die Daten an den zweiten Rechner gesendet werden, f) die Daten in dem zweiten Rechner aufgenommen und die Daten in den zweiten Leiter eingeschrieben werden, und g) in dem zweiten Rechner Daten aus dem zweiten Leiter ausgelesen und in die zweite Datenbank geladen werden.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass a) erste und zweite Befehlsleiter im ersten Rechner kreiert werden, b) der erste Befehlsleiter veranlaßt wird, dass er durch den ersten Rechner ausgeführt wird, und ein Umladen von Daten aus der ersten Datenbank in die erste Pipe eingeleitet wird, c) der zweite Befehlsleiter in den zweiten Rechner gesendet wird, und d) der zweite Befehlsleiter im zweiten Rechner ausgeführt wird, um ein Laden von Daten in die zweite Datenbank zu beginnen.