DE602004005050T2

DE602004005050T2 - Verfahren, vorrichtung und computerprogramm zum verarbeiten einer warteschlange von nachrichten

Info

Publication number: DE602004005050T2
Application number: DE602004005050T
Authority: DE
Inventors: Stephen James Todd
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2003-08-02
Filing date: 2004-06-16
Publication date: 2007-08-09
Anticipated expiration: 2024-06-17
Also published as: JP2007501449A; GB0318196D0; KR20060118393A; IL173424A; EP1654646B1; DE602004005050D1; CN1829964A; CA2529138A1; IL173424A0; US20060085462A1; WO2005085998A1; CN100410883C; EP1654646A1; ATE355556T1; BRPI0413267A; US20060136367A1

Description

Technisches Gebiet
Die Erfindung betrifft Datenverarbeitungssysteme und insbesondere die Verarbeitung einer Warteschlange von Nachrichten durch ein solches System.
Stand der Technik
Oftmals ist es notwendig, eine Folge von Vorgängen in einer Datenbank oder einem anderen System (beispielsweise einem Nachrichtenübermittlungssystem) „wiederzugeben".
Die Folge kann auf verschiedenen Ebenen dargestellt werden, z.B. Protokollwiedergabe (log replay) (wie sie bei der Wiederherstellung verwendet wird), Transaktionsänderungswiedergabe (wie sie bei der Datenbankreplikation verwendet wird) oder Anrufwiedergabe (eines Protokolls von ausgeführten Anrufen, vielleicht auf der SQL-Ebene oder auf der Ebene der gespeicherten Prozeduren oder sogar auf einer höheren Anwendungsebene).
Oftmals verläuft die Ausführung der ursprünglichen Maßnahmen in hohem Maße parallel zu Datenbanktransaktions- und Sperrverfahren (locking techniques), wodurch eine logische Reihenfolge sichergestellt wird (manchmal nur eine teilweise Reihenfolge). Diese Parallelität war notwendig, um eine gute Systemleistung zu erzielen.
Die durch die Datenbanktransaktions- und Sperrverfahren gewährleistete logische Reihenfolge wird in der wiederzugebenden Folge dargestellt. Das Problem besteht darin, dass die Wiedergabe so schnell wie möglich erfolgen muss, und dies erfordert auch einen gewissen Grad an Parallelität. Jedoch ist es dennoch notwendig, die ursprüngliche logische Folge beizubehalten.
Beispielhaft wird ein System betrachtet, in dem die wiederzugebende Folge als eine Warteschlange von Arbeitselementen dargestellt wird. Jedes Arbeitselement stellt eine ursprüngliche Transaktion dar und enthält eine Liste von auszuführenden Aktualisierungen an Datensätzen auf der Datenbankebene.
(Der Begriff Aktualisierung beinhaltet gemäß der vorliegenden Verwendung jeden Vorgang, der die Datenbank ändert, darunter zumindest die Anweisungen SQL INSERT, DELETE und UPDATE, und auch alle anderen Aktualisierungen, beispielsweise Aktualisierungen an Datendefinitionen.)
Die natürliche (sehr vereinfachte) Ausführung hiervon ist ein einzelnes ausführbares „Transaktions-Programmhauptsegment" (,master transaction' thread):
//Ausführbares Transaktions-Programmhauptsegment für jedes Arbeitselement// d.h. ursprüngliche Transaktion Arbeitselement abrufen (d.h, lesen)
für jede Datensatzaktualisierung im Arbeitselement Aktualisierung anwenden// z.B. Aktualisierung auf Datensatzebene
Ende für jede Aktualisierung
Festschreiben (Arbeitselement-Lesevorgang und
Datenbankaktualisierungsvorgang)
Ende für jedes Arbeitselement
Jedes „Aktualisierung anwenden" (was im Allgemeinen das Abrufen (d.h. Lesen) des entsprechenden Datensatzes der Datenbank erforderlich macht, bevor die Aktualisierung angewandt werden kann) benötigt wahrscheinlich Daten, die zum gegenwärtigen Zeitpunkt nicht in einem der Datenbank zugeordneten Puffer zwischengespeichert sind, folglich wird die Verarbeitung verzögert (stalled), wobei der Abruf der benötigten Daten ausstehend ist. Folglich besteht insofern ein Problem, als der Verarbeitungsdurchsatz erheblich beeinträchtigt werden kann.
Selbstverständlich gibt es kein entsprechendes Problem beim tatsächlichen Speichern der Aktualisierung auf der Datenbankplatte, da verzögerte Schreibverfahren (lazy write techniques) für Standarddatenbanken verwendet werden können.
Dieses Problem kann zwar bei Nachrichtenübermittlungssystemen vorkommen, aber es ist dort weniger kritisch. Da der Hauptteil der Warteschlangenaktivität an den Enden der Warteschlangen vorhersagbar ist, kann ein Pufferpool von zu lesenden Nachrichten entsprechend vorhersehbar vorabgerufen werden. Mit anderen Worten, die Warteschlange wird normalerweise in einer FIFO-Reihenfolge gelesen und kann folglich vorhersehbar und sequenziell vorabgerufen werden.
Viel schwieriger ist es, solche Vorhersagen in Datenbanksystemen zu machen. Der Grund hierfür besteht darin, dass sequenziell aus einer Datenbank gelesene Datensätze normalerweise über die gesamte Datenbankplatte verstreut sind und es unwahrscheinlich ist, dass für die Arbeit an einer Datenbank sequenziell (d.h. zusammenhängend) gespeicherte Datensätze benötigt werden.
Die US-Patentschrift 6 092 154 beschreibt ein Verfahren zum Vorab-Zwischenspeichern (pre-caching) von Daten unter Verwendung von Programmsegmentlisten (thread lists) in einer Multimediaumgebung. Eine Liste von benötigten Daten (Leseanforderungen) wird von einer Hostanwendung an eine Datenspeichereinheit geleitet. In einer Multimediaumgebung können die infolge einer Leseanforderung benötigten Daten jedoch problemlos von der Hostanwendung angegeben werden. In einer Datenbankumgebung kennt die Hostanwendung möglicherweise nicht die Art und Weise, wie die Daten gespeichert sind, oder selbst wenn sie diese kennt, ist sie möglicherweise nicht in der Lage, dies entsprechend an die Datenspeichereinheit weiterzugeben. Folglich ist es möglich, dass einige der von einem nachfolgenden Vorgang benötigten Daten nicht verfügbar sind.
Die US-Patentschrift 6 449 696 beschreibt außerdem das Vorabrufen von Daten von einer Platte auf der Grundlage des Inhalts von Listen mit Leseanforderungen.
Beschreibung der Erfindung
Dementsprechend stellt die Erfindung ein Verfahren zum Verarbeiten einer Warteschlange von Nachrichten bereit, wobei jede Nachricht mindestens eine Anforderung nach einer Aktualisierung einer Datenbank darstellt, wobei das Verfahren die folgenden Schritte umfasst: Durchsuchen einer Nachricht; Entnehmen einer Aktualisierungsanforderung aus einer durchsuchten Nachricht; und Übertragen einer Aktualisierungsvorgabe-Anforderung an ein Datenbankverwaltungssystem (DBMS), das für die zu aktualisierende Datenbank zuständig ist, wobei die Aktualisierungsvorgabe-Anforderung eine Meldung umfasst, die anzeigt, dass das DBMS die Aktualisierung nicht ausführen muss, sondern Daten abrufen muss, die benötigt werden, wenn vorab eine entsprechende tatsächliche Aktualisierung angefordert wird.
Vorzugsweise wird die Aktualisierungsvorgabe-Anforderung in eine Vorabrufanforderung umgesetzt; und benötigte Daten werden vorabgerufen.
Vorzugweise wird nachfolgend eine tatsächliche Aktualisierungsanforderung eingeleitet, wobei diese zur Ausführung vorabgerufene Daten verwendet. Vorzugsweise wird die die Aktualisierung umfassende Nachricht aus der Warteschlange abgerufen und gleichzeitig gelöscht. Vorzugsweise wird das Abrufen und gleichzeitige Löschen mit der tatsächlichen Datenbankaktualisierung koordiniert (Zwei-Phasen-Festschreibung), so dass eine Kopie der Nachricht erst gelöscht wird, wenn eine Bestätigung der Aktualisierung(en) tatsächlich empfangen wurde.
In einer Ausführungsform führt ein ausführbares Programmhauptsegment den Schritt des Einleitens einer Aktualisierungsanforderung aus, und ein oder mehrere ausführbare Vorauslese-Programmsegmente (read ahead threads) führen den Schritt des Durchsuchens einer Nachricht aus.
Vorzugsweise wird der Verarbeitungsumfang des ausführbaren Programmhauptsegmentes so festgelegt, dass er geringer als derjenige eines ausführbaren Vorauslese-Programmsegmentes bleibt.
Dieser Verarbeitungsumfang könnte in Form von Nachrichten, Aktualisierungen usw. gemessen werden und hilft dabei sicherzustellen, dass Daten bei Bedarf im Speicher vorhanden sind. Falls das ausführbare Programmhauptsegment zu nahe herankommt, besteht die Gefahr, dass benötigte Daten möglicherweise nicht im Speicher vorhanden sind, wenn sie für eine auszuführende Aktualisierungsanforderung benötigt werden. Falls andererseits das ausführbare Programmhauptsegment zu weit zurückfällt, so besteht die Gefahr, dass der Speicher voll wird, und dies dazu führt, dass noch nicht verwendete Daten überschrieben werden müssen.
In einer Ausführungsform liegt die Vorabrufanforderung in einer festgelegten Form vor, die beibehalten wird und der ein Kennzeichner zugeordnet wird, so dass die beibehaltene festgelegte Form gekennzeichnet und bei der nachfolgenden Ausführung der tatsächlichen Aktualisierungsanforderung verwendet werden kann. Vorzugsweise wird der Kennzeichner auf die Aktualisierungsvorgabe-Anforderung hin rückübertragen.
In einer Ausführungsform wird die Aktualisierungsvorgabe-Anforderung in eine Vorabrufanforderung in einer festgelegten Form umgesetzt, und dieser wird vom DBMS ein Kennzeichner zugeordnet. Der Kennzeichner wird vom DBMS empfangen und beim Ausgeben einer tatsächlichen Aktualisierungsanforderung verwendet.
Vorzugsweise wird auf das Verwenden vorabgerufener Daten für eine Aktualisierungsanforderung hin eine Speicherverwaltungseinrichtung benachrichtigt, dass die verwendeten vorabgerufenen Daten aus dem Speicher gelöscht werden können. Dies ist hilfreich, um zu vermeiden, dass der Speicher übervoll wird.
Unter einem Aspekt wird ein Verfahren zum Vorverarbeiten von Aktualisierungsanforderungen in einem Datenbankverwaltungssystem (DBMS) an eine vom DBMS gesteuerte Datenbank bereitgestellt, wobei das Verfahren Folgendes umfasst: Empfangen einer Aktualisierungsanforderung im DBMS; Empfangen einer Meldung im DMBS, die anzeigt, dass die Aktualisierungsanforderung eine Aktualisierungsvorgabe-Anforderung ist und das DBMS die Aktualisierung folglich nicht ausführen muss, sondern Daten vorabrufen muss, die benötigt werden, wenn eine entsprechende tatsächliche Aktualisierung angefordert wird; Umsetzen der Aktualisierungsvorgabe-Anforderung in eine Vorabrufanforderung; und Vorabrufen von benötigten Daten auf der Grundlage der Vorabrufanforderung.
Vorzugweise wird nachfolgend eine tatsächliche Aktualisierungsanforderung empfangen, und bereits vorabgerufenen Daten werden zum Ausführen der tatsächlichen Aktualisierungsanforderung verwendet.
In einer Ausführungsform liegt die Vorabrufanforderung in einer festgelegten Form vor, die beibehalten wird. Der beibehaltenen festgelegten Form wird sodann vorzugsweise ein Kennzeichner zugeordnet, so dass die beibehaltene festgelegte Form gekennzeichnet und in einer nachfolgenden Ausführung der tatsächlichen Aktualisierungsanforderung verwendet werden kann. Vorzugsweise wird der Kennzeichner auf die Aktualisierungsvorgabe-Anforderung hin rückübertragen.
In einer Ausführungsform wird der Kennzeichner mit einer tatsächlichen Aktualisierungsanforderung empfangen und bei deren Ausführung verwendet.
Unter einem anderen Aspekt wird eine Vorrichtung zum Verarbeiten einer Warteschlange von Nachrichten bereitgestellt, wobei jede Nachricht mindestens eine Anforderung nach einer Aktualisierung einer Datenbank darstellt, wobei die Vorrichtung Folgendes umfasst: ein Mittel zum Durchsuchen einer Nachricht; ein Mittel zum Entnehmen einer Aktualisierungsanforderung aus einer durchsuchten Nachricht; und ein Mittel zum Übertragen einer Aktualisierungsvorgabe-Anforderung an ein Datenbankverwaltungssystem (DBMS), das für die zu aktualisierende Datenbank zuständig ist, wobei die Aktualisierungsvorgabe-Anforderung eine Meldung umfasst, die anzeigt, dass das DBMS die Aktualisierung nicht ausführen muss, sondern Daten vorabrufen muss, die benötigt werden, wenn eine entsprechende tatsächliche Aktualisierung angefordert wird.
Unter einem anderen Aspekt wird eine Vorrichtung in einem Datenbankverwaltungssystem (DMBS) zum Vorverarbeiten von Aktualisierungsanforderungen an eine vom DBMS gesteuerte Datenbank bereitgestellt, wobei die Vorrichtung Folgendes umfasst: ein Mittel zum Empfangen einer Aktualisierungsanforderung im DBMS; ein Mittel zum Empfangen einer Meldung im DMBS, die anzeigt, dass die Aktualisierungsanforderung eine Aktualisierungsvorgabe-Anforderung ist und das DBMS die Aktualisierung folglich nicht ausführen muss, sondern Daten vorabrufen muss, die benötigt werden, wenn eine entsprechende tatsächliche Aktualisierung angefordert wird; ein Mittel zum Umsetzen der Aktualisierungsvorgabe-Anforderung in eine Vorabrufanforderung; und ein Mittel zum vorabrufen von benötigten Daten auf der Grundlage der Vorabrufanforderung.
Unter einem anderen Aspekt wird ein Computerprogramm zum Verarbeiten einer Warteschlange von Nachrichten bereitgestellt, wobei jede Nachricht mindestens eine Anforderung nach einer Aktualisierung einer Datenbank darstellt, wobei das Computerprogramm ein Programmcodemittel umfasst, das bei Ausführung in einem Computer zum Ausführen eines Verfahrens geeignet ist, das die folgenden Schritte umfasst: Durchsuchen einer Nachricht; Entnehmen einer Aktualisierungsanforderung aus einer durchsuchten Nachricht; und Übertragen einer Aktualisierungsvorgabe-Anforderung an ein Datenbankverwaltungssystem (DBMS), das für die zu aktualisierende Datenbank zuständig ist, wobei die Aktualisierungsvorgabe-Anforderung eine Meldung umfasst, die anzeigt, dass das DBMS die Aktualisierung nicht ausführen muss, sondern Daten vorabrufen muss, die benötigt werden, wenn eine entsprechende tatsächliche Aktualisierung angefordert wird.
Unter einem anderen Aspekt wird ein Computerprogramm zum Vorverarbeiten von Aktualisierungsanforderungen in einem Datenbankverwaltungssystem (DBMS) an eine vom DBMS gesteuerte Datenbank bereitgestellt, wobei das Computerprogramm ein Programmcodemittel umfasst, das die folgenden Verfahrensschritte ausführen kann, wenn es auf einem Computer abläuft : Empfangen einer Aktualisierungsanforderung im DBMS; Empfangen einer Meldung im DMBS, die anzeigt, dass die Aktualisierungsanforderung eine Aktualisierungsvorgabe-Anforderung ist und das DBMS die Aktualisierung folglich nicht ausführen muss, sondern Daten vorabrufen muss, die benötigt werden, wenn eine entsprechende tatsächliche Aktualisierung angefordert wird; Umsetzen der Aktualisierungsvorgabe-Anforderung in eine Vorabrufanforderung; und Vorabrufen von benötigten Daten auf der Grundlage der Vorabrufanforderung.
Kurze Beschreibung der Zeichnungen
1 zeigt ein Datenbanksystem gemäß dem Stand der Technik;
2 veranschaulicht die Verarbeitung der vorliegenden Erfindung gemäß einer bevorzugten Ausführungsform; und
3 veranschaulicht weiter die Verarbeitung der vorliegenden Erfindung gemäß einer bevorzugten Ausführungsform.
Modus der Erfindung
1 zeigt ein Datenbanksystem gemäß dem Stand der Technik. Ein System 10 hat eine Warteschlange von Arbeitselementen (Nachrichten) 20 zur Verarbeitung. Jedes Arbeitselement stellt mindestens eine Aktualisierung an einem Datensatz in einer Datenbank 30 dar.
Die Warteschlange 20 von Verarbeitungsvorgängen (queue of work) wird von rechts nach links gelesen (FIFO-Reihenfolge), und die aus der Datenbank 30 benötigten Daten können folglich als Datenelemente (Datensätze) A, B, C, D gesehen werden. (Es sei darauf hingewiesen, dass jedes Arbeitselement mehr als eine Aktualisierung darstellen kann und daher möglicherweise mehr als einen Datensatz aus der Datenbank 30 benötigt.)
Die Anwendung 40 liest aus der Warteschlange 20 und fordert (über die Datenbankschnittstelle 45) die entsprechenden Daten vom Datenbankverwaltungssystem (DBMS) 70 an. Das DBMS enthält einen Abfrageprozessor 50 (der einen Analysealgorithmus (parser) beinhaltet), der über die Pufferpool-Verwaltungseinrichtung (nicht gezeigt) Daten aus dem Pufferpool 60 (flüchtiger Speicher) anfordert. Falls die Daten im Pufferpool nicht gefunden werden, was wahrscheinlich der Fall ist, müssen die Daten aus der Datenbank selbst abgerufen werden. Da die Datenbank möglicherweise Tausende von Datensätzen auf Platte speichert und da die Daten wahrscheinlich nicht in einer vorhersagbaren Reihenfolge gespeichert sind, kann der Systemdurchsatz während des Abrufens der benötigten Daten in den Pufferpool 60 erheblich beeinträchtigt werden. In diesem Beispiel benötigt die Warteschlange 20 von Verarbeitungsvorgängen den Abruf der Datensätze A, B, C und D in dieser Reihenfolge, die Platte speichert solche Datensätze jedoch in einer völlig anderen Reihenfolge (A, C, D, B). Aus diesem Grund ist es zwecklos, dass die Datenbank Datensätze in einer vorhersehbaren Reihenfolge vorabruft (d.h., normalerweise in sequenzieller Reihenfolge) – z.B. Abrufen von C nach dem Lesen von A.
Die vorliegende Erfindung geht dieses Problem an. 2 veranschaulicht die Verarbeitung der vorliegenden Erfindung gemäß einer bevorzugten Ausführungsform und muss in Verbindung mit 1 gelesen werden.
Ein ausführbares Vorauslese-Programmhauptsegment in der Anwendung 40 durchsucht jedes Arbeitselement aus der Warteschlange 20 (Schritt 100). Wie zuvor erläutert wurde, umfasst jedes Arbeitselement mindestens eine angeforderte Aktualisierung der Datenbank 30. Für jede solche angeforderte Aktualisierung wird ein wegbereitendes ausführbares Aktualisierungs-Programmsegment (pioneer update thread) erzeugt (Schritt 110). Jedes wegbereitende ausführbare Aktualisierungs-Programmsegment leitet (über das DBMS 50) das Abrufen von benötigten Daten in den Pufferpool 60 ein, so dass die entsprechende Aktualisierung bei Anforderung auf die Datenbank 30 angewandt werden kann (Schritt 120).
Die wegbereitenden ausführbaren Aktualisierungs-Programmsegmente nehmen keine Änderungen an den Datenbanken selbst vor (sie lesen lediglich die Daten) und können folglich problemlos parallel angewandt werden. Diese Parallelität ermöglicht der Datenbank die Optimierung ihres E/A-Musters (auf dieselbe Weise wie während einer parallelen Ausführung der ursprünglichen Transaktionen).
Eine komplette Ausführung eines wegbereitenden Aufrufs stellt vorzugsweise sicher, dass alle entsprechenden Daten sowohl für den Datensatz als auch Indizes in den Pufferpool gelesen werden. Beispielsweise wird eine Aktualisierung betrachtet, die das Gehalt von Personalnummer 1234 auf 50.000 setzt. Dies beinhaltet wahrscheinlich den Datensatz der Person selbst und den Index in die Personentabelle zur Personalnummer. Falls es einen Index zum Gehalt gibt, wird dieser vorzugsweise ebenfalls vorabgerufen.
Es gibt drei Mechanismen, durch die die wegbereitenden Aktualisierungen (Aktualisierungsvorgabe) ausgeführt werden können:

Mechanismus A: Das ausführbare Aktualisierungs-Programmsegment setzt eine Aktualisierungsanforderung in eine zugeordnete Vorabrufanforderung um, die eine Anfrage ist (d.h., eine Anfrage zum Abrufen der entsprechenden Daten anstelle eines tatsächlichen Ausführens der Aktualisierung selbst), und gibt diese Anforderung an die Datenbank aus. Folglich wird der wegbereitende Aufruf mit einer Anfrage zur Personalnummer 1234 simuliert.
Mechanismus B: Die Datenbankschnittstelle 45 wird erweitert, um es dem wegbereitenden ausführbaren Programmsegment zu ermöglichen, die Datenbank zu informieren, dass der Aufruf ein wegbereitender Aufruf (Aktualisierungsvorgabe-Anforderung) und keine „tatsächliche" Aktualisierung ist. Ein wegbereitendes ausführbares Programmsegment entnimmt eine Aktualisierungsanforderung aus einem Arbeitselement (Schritt 200 von 3); überträgt die Aktualisierungsanforderung an das DBMS (Schritt 210); und benachrichtigt das DBMS (über eine Meldung mit der Aktualisierungsanforderung), dass dies eine Aktualisierungsvorgabe-Anforderung ist, so dass das DBMS die Aktualisierungsvorgabe-Anforderung in eine Vorabrufanforderung zum Abrufen benötigter Daten umsetzen kann (Schritt 220).
Mechanismus C: Die Datenbankschnittstelle 45 wird weiter erweitert, so dass die Aufrufe vom wegbereitenden ausführbaren Programmsegment (das Vorabrufanforderungen einleitet) und vom ausführbaren Transaktions-Programmhauptsegments (d.h., dem ausführbaren Programmsegment, das anschließend die angeforderten Aktualisierungen ausführt) ausdrücklich zugeordnet werden; z.B. durch Weiterleiten eines Token (Kennzeichner) für die Aktualisierung zwischen den Aufrufen. Es sei darauf hingewiesen, dass der Mechanismus C vorzugsweise eine Erweiterung des Mechanismus B ist.

Der Mechanismus A beinhaltet keine Änderung an der Datenbank. Er beinhaltet jedoch mehr Verarbeitungsvorgänge vom Anwendungsprogramm 40 bei der Umsetzung der Aktualisierung in eine entsprechende Anfrage. Außerdem besteht die Möglichkeit, dass die Anfrage die Datenbank nicht unbedingt veranlasst, alle entsprechenden Daten in den Pufferpool zu lesen; im Beispiel kann der entsprechende Teil des Indexes auf das Gehalt wohl nicht vorabgerufen werden. Der Grund hierfür besteht darin, dass das Anwendungsprogramm möglicherweise nicht völlig versteht, wie die Datenbank ihre Daten speichert oder es möglicherweise schwierig findet, eine entsprechende Anforderung an das DBMS zu übertragen. Diese Probleme werden beim Mechanismus B gelöst.
Im Mechanismus B wird die Aktualisierungsvorgabe-Anforderung in eine Vorabrufanforderung umgesetzt und zum Abrufen von Daten verwendet, die benötigt werden, wenn eine entsprechende tatsächliche Anforderung ausgeführt wird. Da das DBMS die Vorabrufanforderung erzeugt, ist es viel wahrscheinlicher, dass alle benötigten Daten für eine bestimmte tatsächliche Aktualisierungsanforderung vorabgerufen werden. Das DBMS kennt die Art und Weise, wie die Daten gespeichert werden, und kann dies erfolgreich in eine entsprechende Vorabrufanforderung umsetzen.
Zur vollständigeren Erläuterung von Mechanismus C wird eine wegbereitende Aktualisierungsanforderung nach deren Erzeugung durch das Anwendungsprogramm an den Abfrageprozessor übertragen, damit dieser die Aktualisierungsanforderung syntaktisch in eine interne (festgelegte) Form bringt. Diese interne Form wird verwendet, um festzustellen, welche Daten aus der Datenbank abgerufen werden müssen. Sobald die Daten abgerufen wurden, könnte diese interne Form gelöscht werden. Wenn das ausführbare Programmhauptsegment die tatsächliche Aktualisierung ausführen möchte, muss die Aktualisierungsanforderung in diesem Fall jedoch erneut syntaktisch analysiert werden.
Zum Einsparen von Zeit und Verarbeitungsleistung kann der Prozessor eine syntaktisch analysierte interne Form, die sich aus einer wegbereitenden Aktualisierungsanforderung ergibt, speichern und dieser ein Token zuordnen, das an das Anwendungsprogramm zurückgeleitet wird. Wenn das ausführbare Transaktions-Programmhauptsegment die Aktualisierungsanforderung ausführen möchte, kann dasselbe Token vom Anwendungsprogramm an das DBMS geleitet und anschließend zum Feststellen der entsprechenden syntaktisch analysierten, internen Form dieser Anforderung verwendet werden. Durch diese Verbesserung fällt die Notwendigkeit einer doppelten syntaktischen Analyse weg.
Außerdem wird das Abfrage-Token des Mechanismus C vorzugsweise von einer Pufferpool-Verwaltungseinrichtung (nicht gezeigt) verwendet, um festzustellen, ob ein vorabgerufenes Datenelement nicht mehr benötigt wird. Wenn das Token vom Anwendungsprogramm zurück an das DBMS geleitet wird, damit eine Aktualisierung angewandt werden kann, werden die entsprechenden Daten aus dem Pufferpool abgerufen, und anschließend wird das Token vorzugsweise an die Pufferpool-Verwaltungseinrichtung geleitet, um dieser anzuzeigen, dass die dem Token zugeordneten Daten aus dem Pufferpool entfernt werden können. Nur unter solchen Bedingungen werden Daten vorzugsweise aus dem Pufferpool entfernt.
Dies verringert das Risiko, dass vorabgerufene Daten bereits aus dem Pufferpool entfernt werden, bevor sie benötigt werden, oder aber zum Nachteil anderer Daten zu lange im Pufferpool zwischengespeichert werden.
Es sei darauf hingewiesen, dass die Mechanismen B und C Änderungen an der Datenbankschnittstelle und -ausführung erforderlich machen, wohingegen der Mechanismus A ohne Änderungen an der Datenbankausführung oder -schnittstelle vom Anwendungsprogramm ausgeführt werden kann.
Wie oben erwähnt, ist das ausführbare Vorauslese-Programmhauptsegment in Bezug auf die Verarbeitung einem ausführbaren Transaktions-Programmhauptsegment (das ebenfalls im Anwendungsprogramm 40 ausgeführt wird) voraus. Das ausführbare Transaktions-Programmhauptsegment ruft jedes Arbeitselement auf dieselbe Weise wie zuvor das ausführbare Vorauslese-Programmsegment ab, dieses Mal wird das Arbeitselement jedoch tatsächlich aus der Warteschlange entfernt, um eine angeforderte Aktualisierung tatsächlich auszuführen. Da das ausführbare Vorauslese-Programmsegment (und wegbereitende ausführbare Programmsegmente) die vom ausführbaren Transaktions-Programmhauptsegment benötigten Daten im Voraus festgestellt hat, müssen die benötigten Daten bereits in den Pufferpool 60 abgerufen worden sein. Folglich muss die Pufferpool-Verwaltungseinrichtung in der Lage sein, die vom ausführbaren Transaktions-Programmhauptsegment angeforderten Daten aus dem Pufferpool 60 abzurufen, damit die angeforderte Aktualisierung ausgeführt werden kann. Da die angeforderten Daten unmittelbar verfügbar sind, wird die Ein-/Ausgabe nicht verzögert, und folglich wird die Leistung erheblich verbessert. (Wie zuvor dargelegt wurde, können verzögerte Standardschreibverfahren verwendet werden, um die aktualisierten Daten tatsächlich zurück auf die Platte zu übertragen).
Aus Gründen der Leistungsfähigkeit ist es wichtig, dass das ausführbare Transaktions-Programmhauptsegment nicht zu nahe an das ausführbare Vorauslese-Programmhauptsegment herankommt oder zu weit hinter dieses zurückfällt. (Falls das ausführbare Programmhauptsegment zu weit zurückfällt, wird der Pufferpool womöglich mit neuen Daten überschrieben, wenn die alten Daten noch nicht verwendet wurden; falls das ausführbare Programmhauptsegment zu nahe an das ausführbare Vorauslese-Programmsegment herankommt, wurden die Daten möglicherweise nicht ordnungsgemäß in den Pufferpool vorabgerufen, bevor sie benötigt werden.)
Folglich wird es bevorzugt, dass es eine Form von Signalübertragung zwischen dem ausführbaren Vorauslese-Programmhauptsegment und dem ausführbaren Transaktions-Programmhauptsegment gibt, um zu verhindern, dass dies geschieht.
Vorzugsweise darf das ausführbare Vorauslese-Programmhauptsegment (und folglich seine wegbereitenden Programmsegmente) daher dem ausführbaren Transaktions-Programmhauptsegment nicht mehr als einen festgelegten Verarbeitungsumfang (requiredReadahead) voraus sein (z.B. gemessen in verarbeiteten Arbeitselementen, verarbeiteten Aktualisierungen oder verarbeiteten Bytes.)
Folglich hat die Anwendung 40 zwei Zähler, readaheadAmountProcessed und masterAmountProcessed. In der bevorzugten Ausführungsform wird der Wert von „requiredReadahead" in Form von verarbeiteten Arbeitselementen gemessen. Jedes Mal, wenn ein ausführbares Vorauslese-Programmsegment zum nächsten Arbeitselement übergeht, wird readaheadAmountProcessed erhöht. Jedes Mal, wenn die Verarbeitung eines Arbeitselementes vom ausführbaren Programmhauptsegment ausgeführt worden ist, wird masterAmountProcessed erhöht. Das ausführbare Vorauslese-Programmhauptsegment beinhaltet eine Inaktiviätsschleife (sleep loop), die alle vom ausführbaren Vorauslese-Programmsegment gesteuerten wegbereitenden Programmsegmente veranlasst, ebenfalls inaktiv zu sein:
while (readaheadAmountProcessed – masterAmountProcessed > requiredReadahead) sleep (10)
Auf diese Weise ist das ausführbare Vorauslese-Programmsegment dem ausführbaren Programmhauptsegment nicht zu weit voraus. Dies ist wichtig, da andernfalls die Gefahr besteht, dass der Pufferpool 60 voll wird, wodurch das Entfernen von möglicherweise noch nicht verwendeten Daten aus diesem erforderlich wird.
Das ausführbare Programmhauptsegment beinhaltet ebenfalls eine Inaktivitätsschleife:
while (readaheadAmountProcessed – masterAmountProcessed < requiredReadahead) sleep (10)
Dadurch wird sichergestellt, dass das ausführbare Programmhauptsegment das ausführbare Vorauslese-Programmhauptsegment nicht überholt.
Es sei darauf hingewiesen, dass die Ausführung von Vorauslese-Elementen nicht auf eine geordnete Weise erfolgt, folglich ist es schwierig, genau zu definieren, wie weit das Vorauslesen fortgeschritten ist. Folglich könnte diese Signalübertragung aufwändiger gestaltet werden, um eine genaue Angabe zu ermöglichen, welche wegbereitenden Aktualisierungen ausgeführt worden sind.
Es sei darauf hingewiesen, dass Aktualisierungen in bestimmten Fällen auf eine solche Weise voneinander abhängig sind, dass die Ausführung der ersten Aktualisierung die Daten ändert, die gelesen werden müssen, um die spätere Aktualisierung auszuführen. Beispielsweise:

[0] Zu Beginn befindet sich Fred in der Abteilung Y.
[1] Fred in die Abteilung X versetzen.
[2] Den Leiter von Freds Abteilung zu Bill überwechseln

Die wegbereitende Ausführung von [1] liest Daten für Fred in den Pufferpool. Diese Daten werden später verwendet, wenn das ausführbare Transaktions-Programmhauptsegment [1] ausgeführt wird. Die wegbereitende Ausführung von [2] kann vor dieser Aktualisierung erfolgen und liest daher Daten für die Abteilung Y (Freds alte Abteilung) in den Pufferpool. Die tatsächliche Ausführung von [2] erfordert das Vorhandensein von Daten für die Abteilung X (Freds neuer Abteilung) im Pufferpool.
In diesen Fällen kann das ausführbare Transaktions-Programmhauptsegment verzögert werden, während die entsprechende tatsächliche Aktualisierung ausgeführt wird (d.h., da die benötigten Daten sich nicht im Pufferpool befinden). Dadurch wird die Leistungsfähigkeit in geringem Maße beeinträchtigt, im Allgemeinen ist die Leistungsfähigkeit dennoch wesentlich besser gegenüber Verfahren nach dem Stand der Technik. Es sei darauf hingewiesen, dass dies nicht zu fehlerhaften Ergebnissen führt (wie es bei einer Verarbeitung der Transaktionen selbst in der falschen Reihenfolge der Fall gewesen wäre).
Verbesserungen/Änderungen
Nun werden einige Verbesserungen/Änderungen an der oben beschriebenen grundlegenden Idee erläutert.
Die bisher beschriebene Ausführungsform verwendet ein einzelnes ausführbares Vorauslese-Programmsegment, wobei für jede wegbereitende Aktualisierung ein neues ausführbares Programmsegment erzeugt und nach Ausführung seines Arbeitsvorgangs beendet wird.
Die Erzeugung/Beendigung eines ausführbaren Programmsegments ist jedoch ein aufwändiger Prozess. Folglich kann stattdessen ein Pool von ausführbaren Programmsegmenten verwendet werden. In dieser Ausführungsform ist ein Pool von ausführbaren Programmsegmenten für wegbereitende Aktualisierungen ständig verfügbar, und wenn deren Verarbeitungsvorgänge erledigt sind, kehren sie zur erneuten Verwendung zu einem späteren Zeitpunkt in den Pool zurück.
Eine andere Möglichkeit (die in Verbindung mit dem Pool von ausführbaren Programmsegmenten verwendet werden kann) ist das Vorliegen von mehr als einem ausführbaren Vorauslese-Programmsegment und eine Arbeitsteilung zwischen diesen. In einer Ausführungsform wird auch ein Pool von ausführbaren Vorauslese-Programmsegmenten verwendet.
Außerdem setzen vorzugsweise die mehreren ausführbaren Vorauslese-Programmsegmente einander in Kenntnis, für welche Arbeitselemente sie zuständig sind. Auf diese Weise versucht ein ausführbares Vorauslese-Programmsegment nicht, Verarbeitungsvorgänge zu erledigen, die bereits von einem anderen ausführbaren Vorauslese-Programmsegment ausgeführt wurden (oder gerade ausgeführt werden) – d.h., der Aufwand wird nicht unnötigerweise verdoppelt.
In einer sehr einfachen Ausführung ist das erste ausführbare Vorauslese-Programmsegment für die Arbeitselemente 1, 4 und 7 zuständig; ein zweites ausführbares Vorauslese-Programmsegment durchsucht die Arbeitselemente 2, 5 und 8; und ein drittes ausführbares Vorauslese-Programmsegment ist für die Arbeitselemente 3, 6 und 9 zuständig.
Eine weitere Verbesserung des grundlegenden Prinzips ist die Verwendung einer Stapelverarbeitung (batching). Die ursprünglichen Transaktionen werden parallel ausgeführt, folglich kann eine parallele Stapelverarbeitung ihrer Protokollvorgänge (zu Sicherungszwecken) erfolgen. Dies ist hilfreich, solange der Protokollzwang prozessorintensiv ist und andere Verarbeitungsvorgänge bis zum Erreichen der Vollständigkeit verzögert.
Das ausführbare Transaktions-Programmhauptsegment ist ein einzelner Prozessstrang (single threaded) (dies ist wichtig, um die logische Reihenfolge einzuhalten), und folglich kann keine parallele Stapelverarbeitung (boxcaring) angewandt werden. Eine Transaktionsstapelverarbeitung kann jedoch mit einem Festschreibungsvorgang verwendet werden, der nur ausgeführt wird, nachdem eine gewisse Menge an Verarbeitungsvorgängen ausgeführt wurde (gemessen in Form von Zeit, Anzahl von Nachrichten, Anzahl von Aktualisierungen, Anzahl von Bytes). Da jeder Festschreibungsvorgang auch zwangsläufig einen Protokollvorgang bewirkt, ermöglicht eine Transaktionsstapelverarbeitung die Verarbeitung einer größeren Datenmenge in einem Durchlauf an Stelle der ständigen Unterbrechung des ausführbaren Transaktions- Programmhauptsegments von mehreren (zeitaufwändigen) zwangsläufigen Protokollvorgängen.
Eine andere Möglichkeit ist die Verwendung von paarweise ausführbaren Transaktions-Programmhauptsegmenten. Bei einem einzelnen ausführbaren Transaktions-Programmhauptsegment würde dieses ausführbare Programmsegment einen Stapel von Aktualisierungen zur Verarbeitung an das DBMS und anschließend einen Festschreibungsvorgang (oder einen Beendigungsbefehl (finalise command)) an dieses übertragen. Das ausführbare Transaktions-Programmhauptsegment würde sich sodann während der Übertragung der Aktualisierung durch das DBMS auf die Datenbankplatte im Wartezustand befinden. Während des Wartens auf die Rückübertragung der Steuerung vom ausführbaren Programmhauptsegment (von der Festschreibung) wird es bevorzugt, dass ein anderes ausführbares Programmsegment einen weiteren Stapel von Aktualisierungen verarbeitet – z.B. erfolgt der Protokollvorgang von jedem Stapel parallel zur Verarbeitung des nachfolgenden Stapels.

Claims

Verfahren zum Verarbeiten einer Wartschlange von Nachrichten (20), wobei jede Nachricht mindestens eine Anforderung nach einer Aktualisierung einer Datenbank darstellt, wobei das Verfahren die folgenden Schritte umfasst: Durchsuchen einer Nachricht; Entnehmen einer Aktualisierungsanforderung aus einer durchsuchten Nachricht; und Übertragen einer Aktualisierungsvorgabe-Anforderung an ein Datenbankverwaltungssystem DBMS (70), das für die zu aktualisierende Datenbank zuständig ist, wobei die Aktualisierungsvorgabe-Anforderung eine Meldung umfasst, die anzeigt, dass das DBMS (70) die Aktualisierung nicht ausführen muss, sondern Daten abrufen muss, die benötigt werden, wenn vorab eine entsprechende tatsächliche Aktualisierung angefordert wird.
Verfahren nach Anspruch 1, das den folgenden Schritt umfasst: Umsetzen der Aktualisierungsvorgabe-Anforderung in eine Vorabrufanforderung; und Vorabrufen benötigter Daten.
verfahren nach Anspruch 2, wobei die Vorabrufanforderung in einer festgelegten Form vorliegt, wobei das Verfahren außerdem den folgenden Schritt umfasst: Beibehalten der festgelegten Form; Zuordnen eines Kennzeichners zu der beibehaltenen festgelegten Form, so dass die beibehaltene festgelegte Form identifiziert und in einer nachfolgenden Ausführung der tatsächlichen Aktualisierungsanforderung verwendet werden kann; und Rückübertragen des Kennzeichners auf die Aktualisierungsvorgabe-Anforderung hin.
Verfahren nach Anspruch 1, 2 oder 3, das den folgenden Schritt umfasst: Einleiten einer tatsächlichen Aktualisierungsanforderung durch Abrufen und gleichzeitigem Löschen einer Nachricht, die die Aktualisierungsanforderung umfasst, wobei die tatsächliche Aktualisierungsanforderung vorabgerufene Daten verwendet.
verfahren nach Anspruch 4, wobei ein ausführbares Programmhauptsegment (master thread) den Schritt des Einleitens einer tatsächlichen Aktualisierungsanforderung ausführt und wobei ein oder mehrere ausführbare Vorauslese-Programmsegmente (read ahead threads) den Schritt des Durchsuchens einer Nachricht ausführen.
Verfahren in einem Datenbankverwaltungssystem (70) zum Vorverarbeiten von Aktualisierungsanforderungen an eine vom DBMS (70) gesteuerte Datenbank, wobei das Verfahren Folgendes umfasst: Empfangen einer Aktualisierungsanforderung im DBMS (70); Empfangen einer Meldung im DMBS (70), die anzeigt, dass die Aktualisierungsanforderung eine Aktualisierungsvorgabe-Anforderung ist und das DBMS (70) die Aktualisierung folglich nicht ausführen muss, sondern Daten abrufen muss, die benötigt werden, wenn eine entsprechende tatsächliche Aktualisierung angefordert wird; Umsetzen der Aktualisierungsvorgabe-Anforderung in eine Vorabrufanforderung; und Vorabrufen von benötigten Daten auf der Grundlage der Vorabrufanforderung.
Verfahren nach Anspruch 6, wobei die Vorabrufanforderung in einer festgelegten Form vorliegt, wobei das Verfahren außerdem die folgenden Schritt umfasst: Beibehalten der festgelegten Form; Zuordnen eines Kennzeichners zu der beibehaltenen festgelegten Form, so dass die beibehaltene festgelegte Form gekennzeichnet und in einer nachfolgenden Ausführung der tatsächlichen Aktualisierungsanforderung verwendet werden kann; und Rückübertragen des Kennzeichners auf die Aktualisierungsvorgabe-Anforderung hin.
Verfahren nach Anspruch 6 oder 7, das den folgenden Schritt umfasst: Empfangen einer tatsächlichen Aktualisierungsanforderung; und Verwenden bereits vorabgerufener Daten zum Ausführen der tatsächlichen Aktualisierungsanforderung.
Vorrichtung, die ein Mittel umfasst, das beim Betrieb zum Ausführen des Verfahrens nach irgendeinem der Ansprüche 1 bis 8 geeignet ist.
Computerprogramm, das ein Computerprogrammcodemittel umfasst, das zum Ausführen des Verfahrens nach irgendeinem der Ansprüche 1 bis 8 geeignet ist, wenn das Programm in einem Computer ausgeführt wird.