DE112021003031T5

DE112021003031T5 - Archivieren von nur-beschleuniger-datenbanktabellen

Info

Publication number: DE112021003031T5
Application number: DE112021003031.0T
Authority: DE
Inventors: Felix Dörre; Luis Eduardo Oliveira Lizardo; Sascha Laudien; Knut Stolze
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2020-07-10
Filing date: 2021-07-09
Publication date: 2023-03-16
Also published as: GB202301442D0; CN115803725A; US20220012217A1; GB2611968A; US11500833B2; JP2023534656A; WO2022009162A1

Abstract

Ein DBMS verwaltet eine beschleunigte Hochleistungs-Datenbank, welche mit einer herkömmlichen Client-Datenbank synchronisiert ist. Die beschleunigte Datenbank (440) enthält sowohl „reguläre“ beschleunigte Tabellen, welche jeweils eine Tabelle der Client-Datenbank (410) duplizieren, als auch Nur-Beschleuniger-Tabellen (AOTs), welche für die beschleunigte Datenbank (440) einzigartig sind und welche für analytische Zwecke verwendet werden können. AOT-Reihen werden archiviert, indem die Reihen in ein dafür vorgesehenes Nur-Beschleuniger-Archiv verschoben werden, das in der beschleunigten Datenbank (440) gespeichert ist. Wenn bei einer Benutzerabfrage (400) versucht wird, auf Nur-Beschleuniger-Daten zuzugreifen, schreibt das DBMS die Abfrage neu, um die angeforderten Operationen an die partitionierte Archiv/Nicht-Archiv-Struktur der beschleunigten Datenbank (440) anzupassen. Die neu geschriebene Abfrage spezifiziert Schritte zum Zugreifen auf archivierte und nicht-archivierte Nur-Beschleuniger-Daten, ohne das DBMS-Front-End (420) zu zwingen, eine zusammengeführte Ansicht archivierter und nicht-archivierter Nur-Beschleuniger-Daten zu erzeugen. Wenn die Nur-Beschleuniger-Archive in einem Nur-Lese-Format gespeichert sind, werden durch das Neuschreiben außerdem prädiktive Operationen hinzugefügt, welche verhindern, dass Abfragen die Archive verändern.

Description

HINTERGRUND
Die vorliegende Erfindung betrifft allgemein Datenbank-Verwaltungssysteme (Database Management Systems, DBMSs) und insbesondere das Archivieren von beschleunigten Datenbanktabellen.
Archivieren ist der Prozess des Verschiebens von „kalten“ Daten, welche nicht mehr aktiv verwendet werden, in ein dafür vorgesehenes Archivspeicher-Repository. Archivierte Datenbanktabellen werden im Allgemeinen in Datenarchiven gespeichert, getrennt von Primärproduktions-Datenbanktabellen, welche aktive Daten enthalten, wobei die archivierten Tabellen indiziert werden und von DBMS-Nutzern durchsuchbar sind.
Das Verschieben von Archivdaten, auf die selten zugegriffen wird, auf ein preisgünstigeres Speichermedium verringert den Verbrauch eines teureren Hauptspeichers durch ein DBMS und vereinfacht Sicherungsprozeduren. Diese Vorteile entstehen, wenn ein DBMS effektiv seine aktuell aktiven Daten erfassen kann, um die besten Kandidaten zum Archivieren zu identifizieren. Einige Archivierungssysteme schützen archivierte vor einer Modifikation, indem sie in einem Nur-Lese-Format gespeichert werden, andere ermöglichen Benutzern jedoch, archivierte Tabellen zu modifizieren.
Einige DBMSs unterstützen ein zweites „beschleunigtes“ Datenbanksystem, welches in der Lage ist, die Hochleistungsreaktion mit niedriger Latenzzeit zu liefern, die für Operationen wie das Erzeugen einer Echtzeit-Online-Analyse erforderlich ist. Eine beschleunigte Datenbank kann sowohl synchronisierte Duplikate von aktiven Tabellen, die in einer Produktionsdatenbank enthalten sind, als auch „Nur-Beschleuniger“-Tabellen („Accelerator-Only“ Tables, AOTs) umfassen, welche nur in der beschleunigten Datenbank vorhanden sind.
KU RZDARSTELLU NG
Ausführungsformen der vorliegenden Erfindung umfassen Systeme, Verfahren und Computerprogrammprodukte zum Erzeugen und Verwalten von AOTs einer beschleunigten Hochleistungs-Datenbank, welche archivierte Daten enthalten. Ein DBMS verwaltet die beschleunigte Datenbank und synchronisiert bestimmte „reguläre“ Tabellen der beschleunigten Datenbank mit identischen Tabellen einer herkömmlichen „Client“-Datenbank. Zusätzlich zu den regulären Tabellen enthält die beschleunigte Datenbank auch AOTs, die für die beschleunigte Datenbank spezifisch sind und eine Hochgeschwindigkeitsleistung bereitstellen, die ausreichend ist, um den Anforderungen von Echtzeitanwendungen zu genügen. AOT-Reihen werden archiviert, indem die Reihen in eine dafür vorgesehene Archivtabelle oder Partition verschoben werden, die in der beschleunigten Datenbank gespeichert sind. Wenn durch eine Benutzerabfrage oder eine andere Datenzugriffsanforderung versucht wird, auf Nur-Beschleuniger-Daten zuzugreifen, schreibt das DBMS die Abfrage neu, um die angeforderten Operationen an die partitionierte Archiv-/Nicht-Archiv-Struktur der beschleunigten Datenbank anzupassen. Die neu geschriebene Abfrage spezifiziert Schritte zum Zugreifen auf archivierte und nicht-archivierte Nur-Beschleuniger-Daten, ohne das DBMS dazu zu zwingen, eine ressourcenintensive UNION-ALL-Operation durchzuführen, um eine zusammengeführte Ansicht archivierter und nicht-archivierter Daten zu erzeugen. Wenn die Nur-Beschleuniger-Archive in einem Nur-Lese-Format gespeichert sind, werden durch das Neuschreiben außerdem prädiktive Operationen hinzugefügt, welche verhindern, dass durch Abfragen versucht wird, die Archive zu ändern.
Figurenliste

1 zeigt eine Cloud-Computing-Umgebung gemäß einer Ausführungsform der vorliegenden Erfindung.
2 zeigt Abstraktionsmodellschichten gemäß einer Ausführungsform der vorliegenden Erfindung.
3 zeigt die Struktur eines Computersystems und Computerprogrammcode, der verwendet werden kann, um ein Verfahren zum Archivieren von Nur-Beschleuniger-Datenbanktabellen gemäß Ausführungsformen der vorliegenden Erfindung zu realisieren.
4 ist ein Ablaufplan, welcher Schritte eines Verfahrens zum Archivieren von Nur-Beschleuniger-Datenbanktabellen gemäß Ausführungsformen der vorliegenden Erfindung veranschaulicht.
5 ist ein Ablaufplan, welcher Schritte eines Verfahrens zum Reagieren auf eine Anforderung, neue Daten in ein Nur-Lese-Nur-Beschleuniger-Archiv einzufügen, gemäß Ausführungsformen der vorliegenden Erfindung veranschaulicht.
6 ist ein Ablaufplan, welcher Schritte eines Verfahrens zum Reagieren auf eine Anforderung, Daten aus einem Nur-Lese-Nur-Beschleuniger-Archiv zu löschen, gemäß Ausführungsformen der vorliegenden Erfindung veranschaulicht.
7 ist ein Ablaufplan, welcher Schritte eines Verfahrens zum Aktualisieren einer beschleunigten Datenbank, in welcher archivierte Nur-Beschleuniger-Daten Nur-Lese-Daten sind, gemäß Ausführungsformen der vorliegenden Erfindung veranschaulicht.
8 ist ein Ablaufplan, welcher Schritte eines Verfahrens zum Reagieren auf eine Anforderung, neue Daten in ein Nur-Beschleuniger-Lese/Schreib-Archiv einzufügen, gemäß Ausführungsformen der vorliegenden Erfindung veranschaulicht.
9 ist ein Ablaufplan, welcher Schritte eines Verfahrens zum Reagieren auf eine Anforderung, Daten aus einem Nur-Beschleuniger-Lese/Schreib-Archiv zu löschen, gemäß Ausführungsformen der vorliegenden Erfindung veranschaulicht.
10 ist ein Ablaufplan, welcher Schritte eines Verfahrens zum Aktualisieren von Nur-Beschleuniger-Daten, wo archivierte Nur-Beschleuniger-Daten in einem Lese/Schreib-Format gespeichert sind, gemäß Ausführungsformen der vorliegenden Erfindung veranschaulicht.

DETAILLIERTE BESCHREIBUNG
Ausführungsformen der vorliegenden Erfindung verbessern bekannte DBMSs durch Bereitstellen eines effizienteren Wegs zum Archivieren von Datenbanktabellen, die nur in einer beschleunigten Datenbank vorhanden sind, und zum anschließenden Zugreifen darauf.
Ein DBMS, welches eine herkömmliche Client-Datenbank verwaltet, auf die durch Benutzer und das DBMS-Standard-Front-End direkt zugegriffen werden kann, kann auch eine eigenständige „beschleunigte“ Datenbank unterhalten, auf welche durch eine Beschleunigerkomponente des DBMS exklusiv zugegriffen werden kann. Wenn durch eine SQL-Abfrage oder eine andere Datenzugriffsanforderung versucht wird, auf beschleunigte Daten zuzugreifen, leitet das DBMS die Anforderung an den Beschleuniger weiter, welcher bestimmt, wie am besten auf die angeforderten Daten zuzugreifen ist. Wenn zum Beispiel ein Administrator eine Echtzeit- oder Nahezu-Echtzeit-Statistik über die Inhalte oder die Verwendung der Client-Datenbank anfordert, wird diese Anforderung an den Beschleuniger weitergeleitet, um die Latenzzeit der Reaktion des Systems zu verringern.
Eine beschleunigte Datenbank enthält „reguläre“ beschleunigte Tabellen, welche entsprechende Tabellen der herkömmlichen Client-Datenbank duplizieren und damit synchronisiert werden. Diese Synchronisation ermöglicht dem Beschleuniger, Statistiken und Analyseberichte über die Inhalte der Datenbank des Client genauer zu erzeugen, und kann auch die Zeit zum Abrufen und Aufbereiten großer Mengen von Modellierungs-Eingabedaten verringern, die für eine prädiktive Modellierungsoperation benötigt werden.
Beschleunigte Datenbanken können außerdem „Nur-Beschleuniger“-Tabellen (AOTs) enthalten, welche für die beschleunigte Datenbank exklusiv sind und kein Analogon in der Client-Datenbank aufweisen. AOTs können für Funktionen wie das Speichern von Metadaten oder Nutzungsstatistiken verwendet werden, welche Eigenschaften der Client-Datenbank beschreiben. Benutzer können gegebenenfalls Abfrageergebnisse auf lediglich reguläre beschleunigte Tabellen oder lediglich AOTs begrenzen.
Im Allgemeinen kann eine AOT durch Datenbearbeitungsanweisungen (DML-Anweisungen) (wie eine Structured-Query-Language-INSERT- (SQL-INSERT-), UPDATE- und DELETE-Anweisung) einer Abfrage modifiziert werden, die durch die dafür vorgesehene Beschleunigerkomponente ausgeführt werden. Beschleuniger können jedoch nicht direkt DML-Anweisungen an Reihen regulärer beschleunigter Tabellen ausführen, da dadurch die bearbeiteten Reihen die Synchronisation mit analogen Reihen in der Client-Datenbank verlören.
Wie bei anderen Datenbanktabellen können „kalte“ Reihen einer regulären beschleunigten Tabelle archiviert werden, um durch Verringern der Gesamt-Datenbankgröße die Leistungsfähigkeit zu verbessern. Wenn eine Tabellenreihe in der Client-Datenbank archiviert wird, wird deren analoge Reihe in der regulären beschleunigten Tabelle in gleicher Weise archiviert, um die Synchronität zwischen den beiden zu bewahren.
AOT-Reihen können durch von der Realisierung abhängige Kriterien, die von den Inhalten der Client-Datenbank unabhängig sind, zum Archivieren ausgewählt werden, da AOTs keine entsprechenden Tabellen in der Client-Datenbank aufweisen. Benutzer, welche eine beschleunigte Datenbank abfragen, können einen Zugriff lediglich auf archivierte Reihen, lediglich auf nicht-archivierte Reihen oder auf beide anfordern.
Anders als bei herkömmlichen Datenbanken archivieren bekannte beschleunigte Datenbanken AOTs nicht. Das Archivieren einer herkömmlichen Client-Tabelle umfasst im Allgemeinen ein Verschieben von Reihen der Tabellendaten in ein eigenständiges Archiv-Repository, welches im Allgemeinen auf einem weniger leistungsfähigen, weniger teuren Speicher realisiert ist. Dies verringert die Menge an höherpreisigem Speicher, der benötigt wird, um die aktiveren Teile der Datenbank zu speichern, und erhöht die Leistungsfähigkeit, da bei Abfragen, bei denen auf heiße Daten der Client-Datenbank zugegriffen wird, keine archivierten Daten durchsucht werden müssen.
Diese Vorteile entstehen jedoch nicht auf die gleiche Weise, wenn AOTs archiviert werden. AOTs laufen auf einer spezialisierten Plattform ab, die von der der Client-Datenbank getrennt ist, daher würde durch ein Archivieren von Nur-Beschleuniger-Daten auf einem Speichermedium mit geringerer Leistungsfähigkeit nicht den Platzbedarf oder die Reaktionszeit des Speichers der Client-Datenbank verringert. Ferner benötigen sogar kalte AOT-Daten im Allgemeinen schnellere Verarbeitungszeiten, als es möglich wäre, wenn archivierte AOT-Reihen auf ein Medium mit niedrigerer Leistungsfähigkeit verschoben würden, z.B. auf eine optische Platte oder eine Festplatte mit geringerer Geschwindigkeit. Auf dem Fachgebiet hat es daher keine Motivation dafür gegeben, Systeme zu realisieren, welche AOTs archivieren.
Wie nachstehend beschrieben wird, verbessert die vorliegende Erfindung diesen Mechanismus, durch welchen Nur-Beschleuniger-Daten verwaltet werden, durch Verschieben von archivierten Reihen einer AOT in eine eigenständige AOT oder eine Partition, welche in einigen Ausführungsformen in einem Nur-Lese-Format gespeichert ist. Dieses Verfahren unterscheidet sich auch von dem Archivierungsmechanismus, der durch bekannte nicht-beschleunigte Client-Datenbanken angewendet wird, da das Nur-Beschleuniger-Archiv der vorliegenden Erfindung innerhalb einer Partition der beschleunigten Datenbank verbleibt, anstatt in eine Partition verschoben zu werden, die sich auf einem Speicher mit niedrigeren Kosten befindet. Obwohl sie nicht die gleichen Arten von Vorteilen bereitstellt, die durch Auslagern von Archiven einer herkömmlichen Client-Datenbank entstehen, verringert diese neue Struktur Aufwand und Komplexität innerhalb der beschleunigten Datenbank, wenn bei einer Abfrage archivierte AOT-Daten angefordert werden, ungeachtet dessen, ob bei der Abfrage auch nicht-archivierte AOT-Daten angefordert werden. Wenn zum Beispiel bei einer Abfrage nur archivierte AOT-Daten oder nur nicht-archivierte AOT-Daten angefordert werden, erfordert das Verarbeiten der Abfrage lediglich ein Durchsuchen von Partitionen, welche die einzige gewünschte Datenklasse enthalten. Die resultierenden Leistungsverbesserungen sind besonders wichtig für beschleunigte Systeme, welche ausdrücklich dafür ausgestaltet sind, für die Leistungsfähigkeit entscheidende Funktionen zu bedienen.
Das Front-End des Client-DBMS empfängt alle eingehenden Abfragen und analysiert sie syntaktisch, ungeachtet dessen, ob bei einer Abfrage Zugriff auf Client-Daten oder lediglich auf beschleunigte Daten angefordert wird. Auf beschleunigte Tabellen, archiviert oder nicht, kann jedoch direkt lediglich durch das Beschleunigermodul der beschleunigten Datenbank zugegriffen werden. Das DBMS-Front-End leitet syntaktisch analysierte Anforderungen von Nur-Beschleuniger-Daten an den Beschleuniger weiter, welcher dann die angeforderten Operationen an der beschleunigten Datenbank ausführt.
Wenn AOTs in archivierte und nicht-archivierte Partitionen aufgeteilt sind, könnte eine Abfrage, bei welcher sowohl auf archivierte als auch auf nicht-archivierte beschleunigte Daten zugegriffen wird, erfordern, dass das DBMS-Front-End zuerst eine UNION-ALL-Operation ausführt, welche archivierte und nicht-archivierte Daten zu einer einzigen durchsuchbaren Ansicht oder Domäne zusammenführt. Die resultierende Ansicht könnte dann ermöglichen, dass Abfragen durch den Beschleuniger vollständig innerhalb der beschleunigten Datenbank durchgeführt werden. Diese UNION-Operation kann jedoch ressourcenintensiv sein, wenn, wie oft in diesem Fall, große Datenmengen zusammengeführt werden müssen.
Schlimmer noch, Abfragen, welche sowohl reguläre beschleunigte Tabellen als auch AOTs durchsuchen, erfordern zusätzliche Filterprädikate, um zwischen den zwei Datentypen zu unterscheiden. Beispielsweise muss eine Abfrage, bei welcher nur archivierte AOT-Daten angefordert werden, aber Bedingungen spezifiziert werden, die von vorhandenen archivierten AOT-Reihen nicht erfüllt werden können, fehlschlagen. Ferner können DML-Abfragefunktionen, die von einem Beschleuniger an einer beschleunigten Datenbank ausgeführt werden, Daten bearbeiten, die nur in AOTs gespeichert sind, da durch ein Modifizieren einer regulären beschleunigten Tabelle, ohne auch eine entsprechende Tabelle in der Client-Datenbank zu modifizieren, die zwei desynchronisiert würden. Das Verarbeiten einer Abfrage erfordert deswegen, dass der Beschleuniger zusätzliche Prädikate erzeugt, welche Reihen, die zu regulären beschleunigten Tabellen gehören, von Reihen unterscheiden, die zu AOTs gehören, vor und/oder nach dem Durchführen der Abfrage. Aus diesem Grund muss bei einer Abfrage, bei welcher entweder archivierte oder nicht-archivierte Daten aus AOTs ausgewählt werden, außerdem eine zusätzliche Filterung durchgeführt werden, um archivierte Tabellenreihen von nicht-archivierten Reihen zu unterscheiden.
Auf diese Weise verbessern Ausführungsformen der vorliegenden Erfindung die Leistungsfähigkeit bekannter Beschleunigerdatenbanken, indem sie einen effizienteren Mechanismus zum Archivieren von Nur-Beschleuniger-Daten und zum Bedienen von Abfragen bereitstellen, bei denen auf AOTs zugegriffen wird. Diese Ausführungsformen nutzen die Funktion des syntaktischen Analysierens und die Funktion des Neuschreibens von Abfragen der Zwei-Datenbanken-Architektur, um die zusätzlichen Filterprädikate zu eliminieren, die von bekannten Beschleunigern erzeugt werden, wenn auf AOT-Daten zugegriffen wird.
Zunächst einmal umfassen Ausführungsformen ein neues Verfahren zum Archivieren von Aufzeichnungen oder Tabellen einer AOT. Anstatt eine AOT oder eine Aufzeichnung einer AOT lediglich als archiviert zu markieren, wird bei der vorliegenden Erfindung der archivierte Inhalt in eine zweite AOT, gespeichert auf der beschleunigten Datenbank, verschoben, welche als nur archivierte Nur-Beschleuniger-Daten enthaltend vorgesehen ist. Dadurch wird das Erfordernis beseitigt, Adhoc-Filterprädikate zu erzeugen und an AOT-Tabellen auszuführen, um zwischen archivierten und nicht-archivierten Aufzeichnungen zu unterscheiden.
Ausführungsformen nutzen auch die Tatsache, dass die Client-Datenbank bereits ein Front-End beinhaltet, welches in der Lage ist, eingehende Datenzugriffsanforderungen syntaktisch zu analysieren. Die vorliegende Erfindung führt das Front-Ende des Client-DBMS dazu, neue Schritte des Neuschreibens bestimmter Anweisungen einer Abfrage, mit welcher Zugriff auf eine AOT angefordert wird, vor dem Weiterleiten der modifizierten Abfrage an den Beschleuniger durchzuführen. Der Beschleuniger wendet dann bekannte Verfahren an, um die modifizierte Abfrage an der beschleunigten Datenbank durchzuführen.
Anders als bei derzeitigen DBMS-Realisierungen ermöglicht diese Verbesserung, dass alle Funktionen, welche „heißen“ und „kalten“ (also nicht-archivierten und archivierten) Reihen von AOT-Daten unterscheiden, durch den Beschleuniger innerhalb der beschleunigten Datenbank durchgeführt werden. Dadurch wird das Erfordernis beseitigt, dass das Front-End des Client-DBMS Filterprädikate erzeugt, welche zwischen archiviertem und nicht-archiviertem Nur-Beschleuniger-Inhalt unterscheiden, um eine vorübergehende zusammengeführte Ansicht zu erzeugen, indem es eine UNION-ALL-Operation an dem abgefragten Inhalt der beschleunigten Datenbank durchführt, und um dann den Beschleuniger dazu zu führen, die Abfrage gegen die Inhalte der zusammengeführten Ansicht auszuführen. Diese Verbesserungen verbessern die Leistungsfähigkeit, vereinfachen die Abfrageverarbeitung und verringern die Sperrzeit, während der die abgefragten Datenbanktabellen oder Partitionen nicht verfügbar sind, während eine komplexe Abfrage bedient wird.
Diese Verbesserungen ändern nur jene Operationen des Client-DBMS-Systems, welche Abfragen von AOT-Daten bedienen. Das Realisieren der Neuschreibprozedur macht keine Modifikationen an dem Anwendungscode des DBMS zum syntaktischen Analysieren und Bedienen von Abfragen erforderlich, mit welchen nur auf Client-Datenbank-Tabellen oder reguläre Tabellen der beschleunigten Datenbank zugegriffen wird. Diese Verbesserungen beseitigen außerdem das Erfordernis, dass das Front-End des Client-DBMS Filterprädikate erzeugt, welche eine UNION-ALL-Operation durchführen, um eine zusammengeführte Ansicht zu erzeugen und dann archivierte von nicht-archivierten Nur-Beschleuniger-Daten innerhalb dieser Ansicht zu unterscheiden. Schließlich kann, da in Ausführungsformen der vorliegenden Erfindung archivierte und nicht-archivierte beschleunigte Daten in eigenständigen beschleunigten Tabellen und Partitionen gespeichert werden, ein konformer Beschleuniger Anforderungen zum Zugreifen auf lediglich archivierte AOT-Daten oder lediglich nicht-archivierte Daten bedienen, ohne zuerst zu bestimmen, welche Reihen jeder AOT archivierte Daten enthalten.
Es versteht sich, dass das Umsetzen der hierin angeführten Lehren nicht auf eine Cloud-Computing-Umgebung beschränkt ist, obwohl diese Offenbarung eine ausführliche Beschreibung von Cloud-Computing umfasst. Vielmehr können Ausführungsformen der vorliegenden Erfindung in Verbindung mit jeder beliebigen Art von jetzt bekannter oder später entwickelter Datenverarbeitungsumgebung umgesetzt werden.
Cloud-Computing ist ein Dienstbereitstellungsmodell zum Ermöglichen eines problemlosen bedarfsgesteuerten Netzwerkzugriffs auf einen gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen (z.B. Netzwerke, Netzwerkbandbreite, Server, Verarbeitung, Hauptspeicher, Speicher, Anwendungen, virtuelle Maschinen und Dienste), die mit minimalem Verwaltungsaufwand bzw. minimaler Interaktion mit einem Anbieter des Dienstes schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Eigenschaften, mindestens drei Dienstmodelle und mindestens vier Einsatzmodelle umfassen.
Bei den Eigenschaften handelt es sich um die Folgenden:

On-Demand Self-Service: Ein Cloud-Nutzer kann einseitig automatisch nach Bedarf für Datenverarbeitungsfunktionen wie Serverzeit und Netzwerkspeicher sorgen, ohne dass eine menschliche Interaktion mit dem Anbieter des Dienstes erforderlich ist.
Broad Network Access: Es sind Funktionen über ein Netzwerk verfügbar, auf die durch Standardmechanismen zugegriffen wird, welche die Verwendung durch heterogene Thin- oder Thick-Client-Plattformen (z.B. Mobiltelefone, Laptops und PDAs) unterstützen.
Resource-Pooling: Die Datenverarbeitungsressourcen des Anbieters werden zusammengeschlossen, um mehreren Nutzern unter Verwendung eines Multi-Tenant-Modells zu dienen, wobei verschiedene physische und virtuelle Ressourcen dynamisch nach Bedarf zugewiesen und neu zugewiesen werden. Es gibt eine gefühlte Standortunabhängigkeit, da der Nutzer allgemein keine Kontrolle oder Kenntnis über den genauen Standort der bereitgestellten Ressourcen hat, aber in der Lage sein kann, einen Standort auf einer höheren Abstraktionsebene festzulegen (z.B. Land, Staat oder Rechenzentrum).
Rapid Elasticity: Funktionen können für eine schnelle horizontale Skalierung (Scale out) schnell und elastisch bereitgestellt werden, in einigen Fällen auch automatisch, und für ein schnelles Scale in schnell freigegeben werden. Für den Nutzer erscheinen die für das Bereitstellen verfügbaren Funktionen häufig unbegrenzt und sie können jederzeit in jeder beliebigen Menge gekauft werden.
Measured Service: Cloud-Systeme steuern und optimieren die Verwendung von Ressourcen automatisch, indem sie eine Messfunktion auf einer gewissen Abstraktionsebene nutzen, die für die Art von Dienst geeignet ist (z.B. Speicher, Verarbeitung, Bandbreite sowie aktive Benutzerkonten). Die Nutzung von Ressourcen kann überwacht, gesteuert und gemeldet werden, wodurch sowohl für den Anbieter als auch für den Nutzer des verwendeten Dienstes Transparenz geschaffen wird.

Bei den Dienstmodellen handelt es sich um die Folgenden:

Software as a Service (SaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, die in einer Cloud-Infrastruktur ablaufenden Anwendungen des Anbieters zu verwenden. Die Anwendungen sind über eine Thin-Client-Schnittstelle wie einen Web-Browser (z.B. auf dem Web beruhende E-Mail) von verschiedenen Client-Einheiten her zugänglich. Der Nutzer verwaltet oder steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter das Netzwerk, Server, Betriebssysteme, Speicher oder sogar einzelne Anwendungsfunktionen, mit der möglichen Ausnahme von eingeschränkten benutzerspezifischen Anwendungskonfigurationseinstellungen.
Platform as a Service (PaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, durch einen Nutzer erstellte oder erhaltene Anwendungen, die unter Verwendung von durch den Anbieter unterstützten Programmiersprachen und Tools erstellt wurden, in der Cloud-Infrastruktur einzusetzen. Der Nutzer verwaltet oder steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter Netzwerke, Server, Betriebssysteme oder Speicher, hat aber die Kontrolle über die eingesetzten Anwendungen und möglicherweise über Konfigurationen der Application Hosting Environment.
Infrastructure as a Service (laaS): Die dem Nutzer bereitgestellte Funktion besteht darin, Verarbeiten, Speicher, Netzwerke und andere grundlegende Datenverarbeitungsressourcen bereitzustellen, wobei der Nutzer in der Lage ist, beliebige Software einzusetzen und auszuführen, zu der Betriebssysteme und Anwendungen gehören können. Der Nutzer verwaltet oder steuert die zugrunde liegende Cloud-Infrastruktur nicht, hat aber die Kontrolle über Betriebssysteme, Speicher, eingesetzte Anwendungen und möglicherweise eine eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z.B. Host-Firewalls).

Bei den Einsatzmodellen handelt es sich um die Folgenden:

Private Cloud: Die Cloud-Infrastruktur wird einzig und allein für eine Organisation betrieben. Sie kann durch die Organisation oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.
Community Cloud: Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine spezielle Benutzergemeinschaft, die gemeinsame Angelegenheiten hat (z.B. Mission, Sicherheitsanforderungen, Richtlinien sowie Überlegungen bezüglich der Einhaltung von Vorschriften). Sie kann durch die Organisationen oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.
Public Cloud: Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Industriegruppe zur Verfügung gestellt und sie gehört einer Cloud-Dienste verkaufenden Organisation.
Hybrid Cloud: Die Cloud-Infrastruktur ist eine Zusammensetzung aus zwei oder mehreren Clouds (Private, Community oder Public), die zwar einzelne Einheiten bleiben, aber durch eine standardisierte oder proprietäre Technologie miteinander verbunden sind, die Daten- und Anwendungsportierbarkeit ermöglicht (z.B. Cloud-Bursting für den Lastenausgleich zwischen Clouds).

Eine Cloud-Computing-Umgebung ist dienstorientiert mit Fokus auf Statusunabhängigkeit, geringer Kopplung, Modularität und semantischer Interoperabilität. Im Zentrum von Cloud-Computing steht eine Infrastruktur, die ein Netzwerk aus zusammengeschalteten Knoten umfasst.
Nun Bezug nehmend auf 1, ist dort die veranschaulichende Cloud-Computing-Umgebung 50 abgebildet. Wie dargestellt, umfasst die Cloud-Computing-Umgebung 50 einen oder mehrere Cloud-Computing-Knoten 10, mit denen von Cloud-Nutzern verwendete lokale Datenverarbeitungseinheiten wie ein elektronischer Assistent (PDA, Personal Digital Assistant) oder ein Mobiltelefon 54A, ein Desktop-Computer 54B, ein Laptop-Computer 54C und/oder ein Automobil-Computersystem 54N Daten austauschen können. Die Knoten 10 können miteinander Daten austauschen. Sie können physisch oder virtuell in ein oder mehrere Netzwerke wie Private, Community, Public oder Hybrid Clouds gruppiert werden (nicht dargestellt), wie vorstehend beschrieben, oder in eine Kombination daraus. Dies ermöglicht es der Cloud-Computing-Umgebung 50, Infrastructure, Platform und/oder Software as a Service anzubieten, für die ein Cloud-Nutzer keine Ressourcen auf einer lokalen Datenverarbeitungseinheit vorhalten muss. Es sei darauf hingewiesen, dass die Arten der in 1 dargestellten Datenverarbeitungseinheiten 54A bis N lediglich veranschaulichend sein sollen und dass die Datenverarbeitungsknoten 10 und die Cloud-Computing-Umgebung 50 über eine beliebige Art von Netzwerk und/oder über eine beliebige Art von über ein Netzwerk aufrufbarer Verbindung (z.B. unter Verwendung eines Web-Browsers) mit einer beliebigen Art von computergestützter Einheit Daten austauschen können.
Nun Bezug nehmend auf 2, ist dort ein Satz von funktionalen Abstraktionsschichten dargestellt, die durch die Cloud-Computing-Umgebung 50 (1) bereitgestellt werden. Es versteht sich, dass die in 2 dargestellten Komponenten, Schichten und Funktionen lediglich veranschaulichend sein sollen und Ausführungsformen der Erfindung nicht darauf beschränkt sind. Wie abgebildet, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt:
Eine Hardware- und Software-Schicht 60 umfasst Hardware- und Software-Komponenten. Zu Beispielen für Hardware-Komponenten gehören: Mainframe-Computer 61; auf der RISC-Architektur (Reduced Instruction Set Computer Architecture) beruhende Server 62; Server 63; Blade-Server 64; Speichereinheiten 65; und Netzwerke sowie Netzwerkkomponenten 66. In einigen Ausführungsformen umfassen Software-Komponenten eine Netzwerk-Anwendungsserver-Software 67 und eine Datenbank-Software 68.
Eine Virtualisierungsschicht 70 stellt eine Abstraktionsschicht bereit, aus der die folgenden Beispiele für virtuelle Einheiten bereitgestellt werden können: virtuelle Server 71, virtueller Speicher 72, virtuelle Netzwerke 73, darunter virtuelle private Netzwerke; virtuelle Anwendungen und Betriebssysteme 74; und virtuelle Clients 75.
In einem Beispiel kann die Verwaltungsschicht 80 die nachstehend beschriebenen Funktionen bereitstellen. Ressourcen-Bereitstellung 81 sorgt für die dynamische Beschaffung von Datenverarbeitungsressourcen sowie anderen Ressourcen, die zum Durchführen von Aufgaben innerhalb der Cloud-Computing-Umgebung verwendet werden. Messen und Preisfindung 82 sorgt für die Kostenverfolgung beim Verwenden von Ressourcen innerhalb der Cloud-Computing-Umgebung sowie die Abrechnung oder Rechnungsstellung für den Verbrauch dieser Ressourcen. In einem Beispiel können diese Ressourcen Anwendungs-Software-Lizenzen umfassen. Sicherheit sorgt für die Identitätsüberprüfung für Cloud-Nutzer und Aufgaben sowie Schutz für Daten und andere Ressourcen. Benutzerportal 83 stellt Nutzern und Systemadministratoren den Zugang zu der Cloud-Computing-Umgebung bereit. Dienstumfangsverwaltung 84 sorgt für die Zuordnung und Verwaltung von Cloud-Computing-Ressourcen, so dass die benötigten Dienstumfänge erreicht werden. Planen und Erfüllen von Vereinbarungen zum Dienstumfang (SLA, Service Level Agreement) 85 sorgt für eine Vorab-Einrichtung und Beschaffung von Cloud-Computing-Ressourcen, für die ein zukünftiges Erfordernis vorausgesehen wird, gemäß einer SLA.
Eine Arbeitslastschicht 90 stellt Beispiele für die Funktionalität bereit, für welche die Cloud-Computing-Umgebung verwendet werden kann. Zu Beispielen für Arbeitslasten und Funktionen, die von dieser Schicht bereitgestellt werden können, gehören: Abbildung und Navigation 91; Software-Entwicklung und Lebenszyklusverwaltung 92; Bereitstellung von Ausbildung in virtuellen Klassenzimmern 93; Datenanalytikverarbeitung 94; Transaktionsverarbeitung 95; und Orchestrierung von komplexen Aufgaben zum Archivieren von Nur-Beschleuniger-Datenbanktabellen 96.
Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt in jeder möglichen technischen Integrationsstufe handeln. Das Computerprogrammprodukt kann ein computerlesbares Speichermedium (oder -medien) mit computerlesbaren Programmanweisungen darauf umfassen, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
Bei dem computerlesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch ein System zur Ausführung von Anweisungen behalten und speichern kann. Bei dem computerlesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste speziellerer Beispiele des computerlesbaren Speichermediums gehören die Folgenden: eine auswechselbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein auswechselbarer Compact-Disk-Nur-Lese-Speicher (CD-ROM), eine Digital Versatile Disk (DVD), ein Speicher-Stick, eine Diskette, eine mechanisch codierte Einheit wie zum Beispiel Lochkarten oder erhabene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination daraus. Ein computerlesbares Speichermedium soll in der Verwendung hierin nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. Lichtwellenleiterkabel durchlaufende Lichtimpulse) oder durch einen Draht übertragene elektrische Signale.
Hierin beschriebene, computerlesbare Programmanweisungen können von einem computerlesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetzwerk und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Router, Firewalls, Switches, Gateway-Computer und/oder Edge-Server umfassen. Eine Netzwerkadapterkarte oder Netzwerk-Schnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt computerlesbare Programmanweisungen aus dem Netzwerk und leitet die computerlesbaren Programmanweisungen zur Speicherung in einem computerlesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
Bei computerlesbaren Programmanweisungen zum Ausführen von Operationen der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten, Konfigurationsdaten für integrierte Schaltungen oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o.ä. sowie herkömmliche prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die computerlesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetzwerk (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, vor Ort programmierbare Gate Arrays (FPGA, Field Programmable Gate Arrays) oder programmierbare Logik-Arrays (PLA, Programmable Logic Arrays) die computerlesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der computerlesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
Aspekte der vorliegenden Erfindung sind hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es versteht sich, dass jeder Block der Ablaufpläne und/oder der Blockschaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaubildern mittels computerlesbarer Programmanweisungen realisiert werden können.
Diese computerlesbaren Programmanweisungen können einem Prozessor eines Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die über den Prozessor des Computers oder der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen Mittel zur Umsetzung der in dem Block oder den Blöcken der Ablaufpläne und/oder der Blockschaubilder festgelegten Funktionen/Handlungen erzeugen. Diese computerlesbaren Programmanweisungen können auch auf einem computerlesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, so dass das computerlesbare Speichermedium, auf dem Anweisungen gespeichert sind, ein Herstellungsprodukt umfasst, welches Anweisungen umfasst, welche Aspekte der in dem Block oder den Blöcken des Ablaufplans und/oder der Blockschaubilder festgelegten Funktion/Handlung umsetzen.
Die computerlesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer oder der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen auf einem Computer realisierten Prozess zu erzeugen, so dass die auf dem Computer, der anderen programmierbaren Vorrichtung oder der anderen Einheit ausgeführten Anweisungen die in dem Block oder den Blöcken der Ablaufpläne und/oder der Blockschaubilder festgelegten Funktionen/Handlungen umsetzen.
Die Ablaufpläne und die Blockschaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Realisierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zur Ausführung der spezifizierten logischen Funktion(en) umfassen. In einigen alternativen Ausführungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren dargestellt stattfinden. Zwei nacheinander dargestellte Blöcke können zum Beispiel in Wirklichkeit als ein Schritt, gleichzeitig, im Wesentlichen gleichzeitig, teilweise oder vollständig zeitlich überlappend ausgeführt werden oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaubilder und/oder des Ablaufplans sowie Kombinationen aus Blöcken in den Blockschaubildern und/oder dem Ablaufplan durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die festgelegten Funktionen oder Handlungen durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
3 zeigt eine Struktur eines Computersystems und eines Computerprogrammcodes, die verwendet werden können, um ein Verfahren zum Archivieren von Nur-Beschleuniger-Datenbanktabellen gemäß Ausführungsformen der vorliegenden Erfindung zu realisieren. 3 bezieht sich auf die Objekte 301 bis 315.
In 3 weist das Computersystem 301 einen Prozessor 303 auf, der durch eine oder mehrere I/O-Schnittstellen 309 mit einer oder mehreren Hardware-Datenspeichereinheiten 311 und einer oder mehreren I/O-Einheiten 313 und 315 verbunden ist.
Die Hardware-Datenspeichereinheiten 311 können, ohne darauf beschränkt zu sein, Magnetband-Laufwerke, feste oder entfernbare Festplatten, optische Platten, mit Speicher ausgestattete mobile Einheiten und Halbleiter-Direktzugriffs- oder Nur-Lese-Speichereinheiten umfassen. I/O-Einheiten können, ohne darauf beschränkt zu sein, umfassen: Eingabeeinheiten 313 wie z.B. Tastaturen, Scanner, Telekommunikations-Handgeräte, berührungsempfindliche Anzeigevorrichtungen, Tablets, biometrische Lesegeräte, Joysticks, Trackballs oder Computer-Mäuse; und Ausgabeeinheiten 315, welche, ohne darauf beschränkt zu sein, Drucker, Plotter, Tablets, Mobiltelefone, Anzeigevorrichtungen oder tonerzeugende Einheiten umfassen können. Datenspeichereinheiten 311, Eingabeeinheiten 313 und Ausgabeeinheiten 315 können entweder lokal oder an entfernt angeordneten Stellen angeordnet sein, von welchen sie über eine Netzwerk-Schnittstelle mit der I/O-Schnittstelle 309 verbunden sind.
Der Prozessor 303 kann auch mit einer oder mehreren Speichereinheiten 305 verbunden sein, welche, ohne darauf beschränkt zu sein, Dynamischen RAM (DRAM), Statischen RAM (SRAM), Programmierbaren Nur-Lese-Speicher (PROM), vor Ort Programmierbare Gate-Arrays (FPGAs), Secure-Digital-Speicherkarten, SIM-Karten oder andere Arten von Speichereinheiten umfassen können.
Mindestens eine Speichereinheit 305 enthält gespeicherten Computerprogrammcode 307, welcher ein Computerprogramm ist, das von einem Computer ausführbare Anweisungen aufweist. Der gespeicherte Computerprogrammcode umfasst ein Programm, welches ein Verfahren zum Archivieren von Nur-Beschleuniger-Datenbanktabellen gemäß Ausführungsformen der vorliegenden Erfindung realisiert, und kann andere Ausführungsformen realisieren, die in dieser Beschreibung beschrieben sind, einschließlich der Verfahren, die in 1 bis 10 veranschaulicht sind. Die Datenspeichereinheiten 311 können den Computerprogrammcode 307 speichern. Der Computerprogrammcode 307, der in den Speichereinheiten 311 gespeichert ist, ist dafür konfiguriert, über die Speichereinheiten 305 von dem Prozessor 303 ausgeführt zu werden. Der Prozessor 303 führt den gespeicherten Computerprogrammcode 307 aus.
In einigen Ausführungsformen kann der gespeicherte Computerprogrammcode 307, anstatt dass er auf einer Festplatte, einer optischen Platte oder einer anderen beschreibbaren, überschreibbaren oder entfernbaren Hardware-Speichereinheit 311 gespeichert ist oder davon abrufbar ist, auf einem statischen, nicht-entfernbaren Nur-Lese-Speichermedium gespeichert sein, wie z.B. einer Nur-Lese-Speichereinheit (ROM-Einheit) 305, oder er kann durch den Prozessor 303 direkt von einem solchen statischen, nicht-entfernbaren Nur-Lese-Medium 305 abrufbar sein. In ähnlicher Weise kann in solchen Ausführungsformen der gespeicherte Computerprogrammcode 307 als computerlesbare Firmware gespeichert sein oder er kann durch den Prozessor 303 direkt von solcher Firmware abgerufen werden, anstatt von einer dynamischeren oder entfernbaren Hardware-Speichereinheit 311, wie z.B. einem Festplattenlaufwerk oder einer optischen Platte.
Somit offenbart die vorliegende Erfindung einen Prozess zum Unterstützen einer Computer-Infrastruktur, Integrieren, Hosten, Unterhalten und Einsetzen von computerlesbarem Code in das/in dem Computersystem 301, wobei der Code in Kombination mit dem Computersystem 301 in der Lage ist, ein Verfahren zum Archivieren von Nur-Beschleuniger-Datenbanktabellen durchzuführen.
Jede der Komponenten der vorliegenden Erfindung könnte durch einen Dienstanbieter erzeugt, integriert, gehostet, unterhalten, eingesetzt, verwaltet, bedient, unterstützt usw. werden, welcher anbietet, ein Verfahren zum Archivieren von Nur-Beschleuniger-Datenbanktabellen zu ermöglichen. Somit offenbart die vorliegende Erfindung einen Prozess zum Einsetzen oder Integrieren von Computer-Infrastruktur, umfassend Integrieren von computerlesbarem Code in das Computersystem 301, wobei der Code in Kombination mit dem Computersystem 301 in der Lage ist, ein Verfahren zum Archivieren von Nur-Beschleuniger-Datenbanktabellen durchzuführen.
Eine oder mehrere Datenspeichereinheiten 311 (oder eine oder mehrere weitere Speichereinheiten, die in 3 nicht dargestellt sind) können als eine computerlesbare Hardware-Speichereinheit verwendet werden, in welcher ein computerlesbares Programm verkörpert ist und/oder welche andere darin gespeicherte Daten aufweist, wobei das computerlesbare Programm den gespeicherten Computerprogrammcode 307 aufweist. Im Allgemeinen kann ein Computerprogrammprodukt (oder alternativ ein Herstellungsgegenstand) des Computersystems 301 die computerlesbare Hardware-Speichereinheit aufweisen.
In Ausführungsformen, welche Komponenten einer vernetzten Datenverarbeitungs-Infrastruktur, einer Cloud-Computing-Umgebung, einer Client-Server-Architektur oder anderer Arten von verteilten Plattformen aufweisen, kann eine Funktionalität der vorliegenden Erfindung allein auf einer Client- oder Benutzereinheit realisiert sein, allein auf einem entfernt angeordneten Server oder als ein Dienst einer Cloud-Computing-Plattform realisiert sein oder zwischen lokalen und entfernt angeordneten Komponenten aufgeteilt sein.
Obwohl es sich versteht, dass Programmcode 307 für ein Verfahren zum Archivieren von Nur-Beschleuniger-Datenbanktabellen durch manuelles Laden des Programmcode 307 direkt in Client-, Server- und Proxy-Computer (nicht dargestellt) eingesetzt werden kann, indem der Programmcode 307 in ein computerlesbares Speichermedium (z.B. die Computer-Datenspeichereinheit 311) geladen wird, kann der Programmcode 307 auch automatisch oder halbautomatisch in dem Computersystem 301 eingesetzt werden, indem der Programmcode 307 an einen zentralen Server (z.B. das Computersystem 301) oder eine Gruppe von zentralen Servern gesendet wird. Der Programmcode 307 kann dann auf Client-Computer (nicht dargestellt) heruntergeladen werden, welche den Programmcode 307 ausführen.
Alternativ kann der Programmcode 307 direkt per E-Mail an den Client-Computer gesendet werden. Der Programmcode 307 kann dann entweder auf ein Verzeichnis auf dem Client-Computer abgehängt werden oder durch eine E-Mail-Option, welche ein Programm auswählt, das den Programmcode 307 in das Verzeichnis abhängt, in ein Verzeichnis auf dem Client-Computer geladen werden.
Eine andere Alternative ist es, den Programmcode 307 direkt an ein Verzeichnis auf dem Festplattenlaufwerk des Client-Computers zu senden. Wenn Proxy-Server konfiguriert sind, wird bei dem Prozess der Proxy-Server-Code ausgewählt, bestimmt, auf welchen Computern der Code der Proxy-Server anzuordnen ist, der Proxy-Server-Code gesendet und anschließend der Proxy-Server-Code auf dem Proxy-Computer installiert. Anschließend wird der Programmcode 307 an den Proxy-Server gesendet und auf dem Proxy-Server gespeichert.
In einer Ausführungsform wird der Programmcode 307 für ein Verfahren zum Archivieren von Nur-Beschleuniger-Datenbanktabellen in eine Client-, Server- und Netzwerkumgebung integriert, indem dafür gesorgt wird, dass der Programmcode 307 gemeinsam mit Software-Anwendungen (nicht dargestellt), Betriebssystemen (nicht dargestellt) und Netzwerk-Betriebssystem-Software (nicht dargestellt) vorhanden ist, und anschließend der Programmcode 307 auf den Clients und Servern in der Umgebung installiert wird, wo der Programmcode 307 seine Funktion ausübt.
Der erste Schritt der vorstehend erwähnten Integration von Code, der im Programmcode 307 enthalten ist, besteht darin, jegliche Software auf den Clients und Servern, einschließlich des Netzwerk-Betriebssystems (nicht dargestellt), zu identifizieren, wo der Programmcode 307 eingesetzt wird, die von dem Programmcode 307 benötigt wird oder die in Verbindung mit dem Programmcode 307 arbeitet. Diese identifizierte Software umfasst das Netzwerk-Betriebssystem, wobei das Netzwerk-Betriebssystem Software aufweist, die ein Basisbetriebssystem durch Hinzufügen von Netzwerkmerkmalen verbessert. Als Nächstes werden die Software-Anwendungen und die Versionsnummern identifiziert und mit einer Liste von Software-Anwendungen und richtigen Versionsnummern verglichen, die getestet worden sind, dass sie mit dem Programmcode 307 funktionieren. Eine Software-Anwendung, welche fehlt oder welche keine richtige Versionsnummer aufweist, wird auf die richtige Version aktualisiert.
Eine Programmanweisung, welche Parameter aus dem Programmcode 307 an eine Software-Anwendung weiterleitet, wird geprüft, um sicherzustellen, dass die Parameterliste der Anweisung zu einer Parameterliste passt, die von dem Programmcode 307 benötigt wird. Ein Parameter hingegen, der von der Software-Anwendung an den Programmcode 307 weitergeleitet wird, wird geprüft, um sicherzustellen, dass der Parameter zu einem Parameter passt, der von dem Programmcode 307 benötigt wird. Die Client- und Server-Betriebssysteme, einschließlich der Netzwerk-Betriebssysteme, werden identifiziert und mit einer Liste von Betriebssystemen, Versionsnummern und Netzwerk-Software-Programmen verglichen, die getestet worden sind, dass sie mit dem Programmcode 307 funktionieren. Ein Betriebssystem, eine Versionsnummer oder ein Netzwerk-Software-Programm, welches zu keinem Eintrag der Liste getesteter Betriebssysteme und Versionsnummern passt, wird auf den Client-Computern auf das gelistete Niveau aktualisiert und wird auf den Server-Computern auf das gelistete Niveau aktualisiert.
Nach dem Sicherstellen, dass sich die Software, wo der Programmcode 307 einzusetzen ist, auf einer richtigen Versionsstufe befindet, die getestet worden ist, dass sie mit dem Programmcode 307 funktioniert, wird die Integration durch Installieren des Programmcode 307 auf den Clients und den Servern abgeschlossen.
Ausführungsformen der vorliegenden Erfindung können als ein Verfahren, welches von einem Prozessor eines Computersystems durchgeführt wird, als ein Computerprogrammprodukt, als ein Computersystem oder als ein von einem Prozessor durchgeführter Prozess oder Dienst zum Unterstützen einer Computer-Infrastruktur realisiert sein.
4 zeigt eine Topologie, die in Ausführungsformen der vorliegenden Erfindung beim Archivieren von AOTs genutzt wird. 4 zeigt Elemente 400 bis 460.
Bekannte DBMS, welche eine beschleunigte Datenbank beinhalten, speichern im Allgemeinen sowohl „reguläre“ beschleunigte Tabellen als auch AOTs. Reguläre Tabellen duplizieren jeweils eine entsprechende Tabelle in der „herkömmlichen“ nicht-beschleunigten Client-Datenbank des DBMS und werden damit synchronisiert.
In dem Beispiel der 4 zeigt eine Ausführungsform der vorliegenden Erfindung ein DBMS-System, welches eine Client-Datenbank 410 und eine beschleunigte Datenbank 440 aufweist. Wenn eine SQL-Abfrage oder eine andere Datenzugriffsanforderung 400 empfangen wird, analysiert das DBMS-Front-End 420 die Anforderung 400 syntaktisch und sendet sie an ein Beschleunigermodul 430 der beschleunigten Datenbank 440. Jeglicher Zugriff auf die beschleunigte Datenbank 440 wird von dem Beschleuniger 430 verwaltet.
Wenn ein DBMS-Modul bestimmt, dass eine nicht-beschleunigte Tabelle, eine Reihe einer nicht-beschleunigten Tabelle oder irgendeine andere Partition von Daten, die in der Client-Datenbank 410 gespeichert sind, archiviert werden sollte, werden die archivierten Daten auf ein eigenständiges Daten-Repository verschoben, welches für archivierte Daten vorgesehen ist.
Das DBMS führt dann den Beschleuniger 430 dazu, diese Operation an den entsprechenden regulären Tabellen der beschleunigten Datenbank 440 zu duplizieren. Auf diese Weise werden die in den regulären beschleunigten Tabellen gespeicherten Daten mit entsprechenden Daten in der Client-Datenbank 410 synchron gehalten.
Ein DBMS kann nicht eine ähnliche Prozedur anwenden, um Inhalte einer AOT zu archivieren, weil die AOT keine analoge Tabelle in der Client-Datenbank 410 aufweist. Deswegen muss, wenn bei einer Abfrage Zugriff auf archivierte und nicht-archivierte Reihen einer AOT angefordert wird, das DBMS-Front-End 420 zusätzliche Schritte durchführen, wie z.B. Zusammenführen von Tabellen oder Erzeugen von Filterprädikaten, mit welchen entweder archivierte oder nicht-archivierte Reihen ausgewählt werden.
Ausführungsformen der vorliegenden Erfindung verbessern bekannte AOT-Archivierungsprozesse durch Verschieben archivierter AOT-Reihen in eine eigenständige archivierte AOT-Tabelle 460. Nach einem Bestimmen, dass eine Reihe, eine Partition oder eine andere Komponente einer AOT 450 archiviert werden sollte, verschiebt der Beschleuniger 430 den Archivinhalt aus der nicht-archivierten AOT 450 in eine zweite AOT 460, die für archivierte Nur-Beschleuniger-Daten reserviert ist.
Wenn die beschleunigte Datenbank 440 eine horizontale Tabellenpartitionierung unterstützt, könnte jede Tabelle 450 und 460 oder jede Tabellenaufzeichnung, dargestellt als Partitionen 1 bis 4, eine physisch „reale“ Partition sein, die in einem eigenständigen Speicher-Repository gespeichert ist. In ähnlicher Weise könnte in anderen Realisierungen die beschleunigte Datenbank 440 die Partitionen 1 bis 4 als logische Partitionen realisieren, wobei individuelle Tabellenreihen auf Grundlage eines ausgewählten Prädikats oder einer Bedingung auf Partitionen abgebildet werden.
In einem Beispiel könnten Reihen zum Archivieren in Abhängigkeit davon ausgewählt werden, ob ein Datum, spezifiziert durch die Datumspalte jeder Reihe, ein ungeradzahliges Datum oder ein geradzahliges Datum enthält. Wenn alle Partitionen 1, 3 und 4 der 4 jeweils ein ungeradzahliges Datum spezifizieren, aber die Partition 2 ein geradzahliges Datum spezifiziert, würde bei einer Operation, bei welcher Aufzeichnungen mit geradzahligen Daten archiviert werden, die Partition 2 in das AOT-Archiv 460 verschoben werden.
Sobald bestimmt worden ist, dass die Partition 2 der AOT 450 archiviert werden sollte, verschiebt der Beschleuniger 430 die Partition 2 aus der nicht-archivierten AOT 450 in die Archiv-AOT 460. Wie nachstehend noch beschrieben wird, reagiert der Beschleuniger 430, wenn bei einer Abfrage oder einer Anwendung anschließend Zugriff auf die ursprünglichen Inhalte der Tabelle 450 angefordert wird, durch Zugriff auf die Inhalte einer oder beider der Tabellen 450 und 460. Wenn bei der Abfrage nur nicht-archivierte Beschleunigerdaten angefordert werden, greift der Beschleuniger 430 nur auf die nicht-archivierte AOT 450 zu. Wenn bei der Abfrage nur archivierte Beschleunigerdaten angefordert werden, greift der Beschleuniger 430 nur auf die archivierte AOT 460 zu. Wenn bei der Abfrage beide Klassen von Beschleunigerdaten angefordert werden, führt der Beschleuniger die AOT-Tabellen 450 und 460 zusammen und greift auf Reihen zu, die in der zusammengeführten Ansicht enthalten sind.
In allen Fällen analysiert das DBMS-Front-End 420 die Abfrage 400 syntaktisch, um zu bestimmen, ob bei der Abfrage 400 Zugriff auf eine AOT angefordert wird. Wenn bei der Abfrage Zugriff auf archivierte oder nicht-archivierte Nur-Beschleuniger-Daten angefordert wird, schreibt das Front-End 420 die Abfrage neu und leitet die modifizierte Abfrage an den Beschleuniger 420 weiter. Der Beschleuniger 420 greift unter Verwendung seiner Standard-Abfrageausführungsfunktionalität auf die richtigen AOTs gemäß dem Rahmen der 4 zu. Diese Schritte des Neuschreibens und die entsprechenden Datenzugriffsprozeduren werden nachstehend beschrieben.
5 ist ein Ablaufplan, welcher Schritte eines Verfahrens zum Reagieren auf eine Anforderung, neue Daten in ein Nur-Lese-Nur-Beschleuniger-Archiv einzufügen, gemäß Ausführungsformen der vorliegenden Erfindung veranschaulicht. 5 enthält die Schritte 500 bis 570.
In einigen Ausführungsformen sind AOTs, Partitionen und andere Arten von Nur-Beschleuniger-Archiven als Nur-Lese-Einheiten konfiguriert. Die Art und Weise, wie in Ausführungsformen Anforderungen bedient werden, DML-Operationen an einem Nur-Beschleuniger-Archiv durchzuführen, wird teilweise dadurch bestimmt, ob das Archiv ein Nur-Lese-Archiv ist.
5 bis 7 beschreiben Schritte, durch welche in Ausführungsformen auf Anforderungen reagiert wird, eine Einfüge-, Lösch- bzw. Aktualisierungs-DML-Operation an einem Nur-Lese-AOT-Archiv durchzuführen. 8 bis 10 beschreiben Schritte, durch welche in Ausführungsformen auf Anforderungen reagiert wird, eine Einfüge-, Lösch- bzw. Aktualisierungs-DML-Operation an einem Lese/Schreib-AOT-Archiv durchzuführen.
Insbesondere sendet der Beschleuniger 430 in Reaktion auf jede Abfrage, bei der versucht wird, Inhalte eines Nur-Lese-Nur-Beschleuniger-Archivs zu überarbeiten oder zu löschen, einen Fehler zurück. Aufzeichnungen, Reihen, Tabellen oder andere Arten von zulässigem Inhalt können in ein Nur-Lese-Nur-Beschleuniger-Archiv nur durch eine spezialisierte Prozedur (wie z.B. eine geplante Wartungsoperation) eingefügt werden, welche in einigen Ausführungsformen von dem DBMS-Front-End 420 und dem Beschleuniger 430 zusammen durchgeführt werden muss. Solche spezialisierten Prozeduren liegen außerhalb des Umfangs der vorliegenden Erfindung. Dieses Dokument beschreibt Prozeduren, mit denen kein neuer Inhalt in ein Nur-Lese-AOT-Archiv eingefügt werden kann.
Das Verfahren der 5 benötigt die Syntaxanalysekomponente eines Client-DBMS-Front-End 420 zum Neuschreiben von Anweisungen einer Abfrage, bei der versucht wird, neue Daten in eine vorhandene Nur-Lese-AOT einzufügen. Durch dieses Neuschreiben werden Prädikate hinzugefügt, welche bestimmen, ob welche der neuen Datenelemente eine Bedingung erfüllen, die erforderlich macht, dass die Elemente archiviert werden. Wenn sie an den Beschleuniger 430 weitergeleitet wird, führt die neu geschriebene Abfrage den Beschleuniger 430 dazu, eine solche Bestimmung vorzunehmen und einen Fehlerzustand zurückzusenden, wenn solche Elemente identifiziert werden.
In einem Beispiel archiviert ein DBMS normalerweise Reihen einer Nur-Beschleuniger-Sales.Logistics-Tabelle, welche Transaktionen identifizieren, die über ein Jahr alt sind. Wenn bei einer Abfrage die Hinzufügung von zehn neuen Reihen zu der Sales.Logistics-Tabelle angefordert wird, wird in dem Verfahren der 5 bestimmt, ob eine dieser zehn Reihen eine Transaktion identifiziert, die über ein Jahr alt ist. Wenn solche Reihen identifiziert werden, wird in dem Verfahren ein Fehlerzustand zurückgesendet, da ein vollständiges Bedienen der Abfrage ein Einfügen der identifizierten Reihen in ein Nur-Lese-Archiv mit sich bringen würde - eine Operation, die nicht zulässig ist.
Im Schritt 500 empfängt das DBMS-Front-End 420 eine Abfrage oder eine andere Datenzugriffsanforderung.
Im Schritt 510 analysiert das DBMS-Front-End 420 die empfangene Abfrage syntaktisch, um zu bestimmen, dass die Abfrage versucht, Datenbankreihen (oder in Abhängigkeit von Realisierungsdetails Tabellen, Aufzeichnungen oder eine andere Art von Datenelement) in eine AOT einzufügen.
Im Schritt 520 schreibt das DBMS-Front-End 420 die Abfrage neu, um Prädikate hinzuzufügen, welche bestimmen, wie viele der Reihen, die in eine AOT einzufügen sind, Bedingungen erfüllen, die erforderlich machen, dass diese Reihen in ein Nur-Beschleuniger-Archiv eingefügt werden.
Im Schritt 530 leitet das DBMS-Front-End 420 die neu geschriebene Abfrage an den Beschleuniger 430 weiter.
Im Schritt 540 beginnt der Beschleuniger 430 die Ausführung der neu geschriebenen Abfrage.
Im Schritt 550 bestimmt der Beschleuniger 430 als ein Ergebnis der Durchführung der neu geschriebenen Abfrage, ob welche der einzufügenden Reihen Bedingungen zum Archivieren erfüllen. Wenn keine der Reihen archiviert werden sollte, führt das System den Schritt 560 durch, um die angeforderten Reihen in geeignete nicht-archivierte AOTs einzufügen. Wenn jedoch welche der Reihen eine Bedingung erfüllen, wodurch Reihen zum Archivieren ausgewählt werden, führt das System stattdessen den Schritt 570 durch, wobei ein Fehlerzustand zurückgesendet wird, der durch einen Versuch verursacht wird, Daten unsachgemäß in ein Nur-Lese-Archiv einzufügen.
Es sei zum Beispiel eine SQL-Abfrage betrachtet, welche die folgenden Anweisungen enthält (Zeilennummern zu Referenzzwecken hinzugefügt):

          (1)INSERT INTO <AOT>
          (2)SELECT ... FROM <beliebige_andere_Tabelle> WHERE <zusätzliche_Prädikate>

Hier wird in Zeile (1) angefordert, dass Daten in eine AOT der Bezeichnung <AOT> eingefügt werden.

In Zeile (2) wird eine Teilauswahl der Daten getroffen, die aus einer Datenbanktabelle der Bezeichnung <beliebige_andere_Tabelle> einzufügen sind, unter Verwendung von Bedingungen, die durch die SQL-Prädikate <zusätzliche_Prädikate> spezifiziert werden.

Das DBMS-Front-End 420 reagiert auf die Erfassung dieser Anweisungen durch Neuschreiben der Anfrage, um die folgenden Anweisungen hinzuzufügen:

          (3)SELECT COUNT(*)
          (4)FROM (SELECT... FROM <beliebige_andere_Tabelle> WHERE
          <zusätzliche_Prädikate> )
          (5)WHERE <Archivierungsbedingungsprädikate>

In Zeile (3) wird die Anzahl der Elemente gezählt, die durch die Zeilen (4) und (5) zurückgesendet werden. In Zeile (4) wird spezifiziert, dass die zu zählenden Elemente aus der Ansicht entnommen werden, die durch die Teilauswahlbedingungen der Zeile (2) identifiziert wird. In Zeile (5) wird die Liste der Elemente, die durch die Zeile (4) zurückgesendet werden, weiter gefiltert, so dass sie nur Elemente umfasst, welche Archivierungskriterien erfüllen, die durch die SQL-Prädikate <Archivierungsbedingungsprädikate> spezifiziert werden. Mit anderen Worten, die Zeilen (3) bis (5) zählen die Anzahl der Datenelemente, die durch die Zeile (1) in ein Nur-Lese-AOT-Archiv eingefügt würden, anstatt in eine Nicht-Archiv-AOT.

In Zeile (3) bis (5) wird daher, wenn sie durch den Beschleuniger 430 ausgeführt werden, eine Nicht-Null-Zählung zurückgesendet, wenn bei der Abfrage versucht wird, Nur-Beschleuniger-Daten einzufügen, welche nach dem Einfügen archiviert werden müssen. Da das System nicht auf diese Weise die Inhalte des Nur-Lese-Archivs ändern darf, bewirkt die Nicht-Null-Zählung, dass die Abfrage fehlschlägt.

Beispiele und Ausführungsformen in diesem Dokument sollten nicht so ausgelegt werden, dass sie die Art der Datenzugriffsanforderungen auf Abfragen im SQL-Format beschränken. Die vorliegende Erfindung ist flexibel genug, um jede Art von SQL- oder Nicht-SQL-Datenzugriffsanforderung einzubeziehen, sofern das DBMS-Front-End 420 in der Lage ist, die Anforderung auf eine Weise, die der des obigen Beispiels funktional ähnlich ist, syntaktisch zu analysieren und dann neu zu schreiben.

6 ist ein Ablaufplan, welcher Schritte eines Verfahrens zum Reagieren auf eine Anforderung, Daten aus einem Nur-Lese-Nur-Beschleuniger-Archiv zu löschen, gemäß Ausführungsformen der vorliegenden Erfindung veranschaulicht. 6 enthält die Schritte 600 bis 670.

Im Schritt 600 empfängt das DBMS-Front-End 420 eine Abfrage oder eine andere Datenzugriffsanforderung.

Im Schritt 610 analysiert das DBMS-Front-End 420 die empfangene Abfrage syntaktisch, um zu bestimmen, dass die Abfrage versucht, Datenbankreihen (oder in Abhängigkeit von Realisierungsdetails Tabellen, Aufzeichnungen oder eine andere Art von Datenelement) aus einer AOT zu löschen.

Im Schritt 620 schreibt das DBMS-Front-End 420 die Abfrage neu, um Prädikate hinzuzufügen, welche bestimmen, wie viele der zu löschenden Reihen Bedingungen erfüllen, die erforderlich machen, dass diese Reihen aktuell in einem Nur-Beschleuniger-Archiv gespeichert werden.

Im Schritt 630 leitet das DBMS-Front-End 420 die neu geschriebene Abfrage an den Beschleuniger 430 weiter.

Im Schritt 640 beginnt der Beschleuniger 430 die Ausführung der neu geschriebenen Abfrage.

Im Schritt 650 bestimmt der Beschleuniger 430 als ein Ergebnis der Durchführung der neu geschriebenen Abfrage, ob welche der zu löschenden Reihen Bedingungen zum Archivieren erfüllen. Wenn keine der Reihen archiviert worden ist, führt das System den Schritt 660 durch, um die angeforderten Reihen aus den aktuellen Speicherstellen der Reihen in nicht-archivierten AOTs zu löschen. Wenn jedoch welche der Reihen eine Bedingung erfüllen, wodurch Reihen zum Archivieren ausgewählt werden, führt das System stattdessen den Schritt 670 durch, wobei ein Fehlerzustand zurückgesendet wird, der durch einen Versuch verursacht wird, Daten unsachgemäß aus einem Nur-Lese-Archiv zu löschen.

Es sei zum Beispiel eine SQL-Abfrage betrachtet, welche die folgenden Anweisungen enthält (Zeilennummern zu Referenzzwecken hinzugefügt):

          (1) DELETE FROM <AOT>
          (2)WHERE <zusätzliche_Prädikate>

Hier wird in Zeile (1) angefordert, dass Daten aus einer AOT der Bezeichnung <AOT> gelöscht werden.

In Zeile (2) wird eine Teilauswahl der zu löschenden Daten durch Auflisten von Bedingungen getroffen, die durch die SQL-Prädikate <zusätzliche_Prädikate> spezifiziert werden.

          (3)SELECT COUNT(*)
          (4)FROM (SELECT ... FROM <AOT> WHERE <zusätzliche_Prädikate> )
          (5)WHERE <Archivierungsbedingungsprädikate>

In Zeile (3) wird die Anzahl der Elemente gezählt, die durch die Zeilen (4) und (5) zurückgesendet werden. In Zeile (4) wird spezifiziert, dass die zu zählenden Elemente durch die Tabelle-<AOT>-Prädikate der Zeile (2) gefiltert werden. In Zeile (5) wird die Liste der Elemente, die durch die Zeile (4) zurückgesendet werden, weiter gefiltert, so dass sie nur Elemente umfasst, welche Archivierungskriterien erfüllen, die durch die SQL-Prädikate <Archivierungsbedingungsprädikate> spezifiziert werden. Mit anderen Worten, die Zeilen (3) bis (5) zählen die Anzahl der Datenelemente, die durch die Zeilen (1) und (2) aus einem Nur-Lese-AOT-Archiv gelöscht würden, anstatt aus einer Nicht-Archiv-AOT.

In Zeile (3) bis (5) wird daher, wenn sie durch den Beschleuniger 430 ausgeführt werden, eine Nicht-Null-Zählung zurückgesendet, wenn bei der Abfrage versucht wird, archivierte Nur-Beschleuniger-Daten aus einem Nur-Lese-AOT-Archiv zu löschen. Da das System keine Daten aus einem Nur-Lese-Archiv löschen darf, bewirkt die Nicht-Null-Zählung, dass die Abfrage fehlschlägt.

7 ist ein Ablaufplan, welcher Schritte eines Verfahrens zum Aktualisieren einer beschleunigten Datenbank, in welcher archivierte Nur-Beschleuniger-Daten Nur-Lese-Daten sind, gemäß Ausführungsformen der vorliegenden Erfindung veranschaulicht. 7 enthält die Schritte 700 bis 770.

Durchführen einer angeforderten UPDATE-Operation, welche ein Datenelement, das in einer nicht-archivierten AOT oder Partition gespeichert ist, derart ändert, dass das geänderte Datenelement Bedingungen zum Archivieren erfüllt. Diese Operation kann zu einer Nicht-Archiv-AOT oder einer Partition führen, welche Daten enthält, die in einem Nur-Lese-Archiv gespeichert sein sollten. In ähnlicher Weise Durchführen einer UPDATE-Operation, welche ein zuvor archiviertes Datenelement derart ändert, dass das geänderte Datenelement nicht mehr Bedingungen zum Archivieren in einem AOT-Archiv oder einer Partition erfüllt, die Daten enthält, die nicht archiviert werden sollten.

Eine Lösung ist es, Nur-Beschleuniger-Partitionen und -Tabellen mit einer Kombination der DELETE- und INSERT-Prozeduren zu aktualisieren, die in 5 und 6 beschrieben sind. Diese Prozedur funktioniert jedoch nur richtig, wenn eine einzelne Reihe aktualisiert wird.

Es sei beispielsweise eine Abfrage betrachtet, welche eine UPDATE-Anweisung enthält, mit welcher „Rabatt“-Spalten von Reihen aktualisiert werden, die „Alters“-Werte von nicht mehr als 30 speichern:

          (1)UPDATE Kunde
          (2)SET Rabatt = Rabatt - 10%
          (3)WHERE Alter <= 30

Diese Operation kann nicht richtig realisiert werden, indem die DELETE-Operation der 6, gefolgt von der INSERT-Operation der 5, durchgeführt wird. Das Löschen aller qualifizierten Reihen aus der Zieltabelle würde zusätzliche Schritte erforderlich machen, um den gelöschten Inhalt in einem Cache oder an einer anderen temporären Stelle zu speichern. Wenn keine solche Speicheroperation durchgeführt wird, wüsste das System nicht, welche Werte einzufügen sind, nachdem die ursprünglichen Reihen gelöscht wurden.

In ähnlicher Weise würden durch ein Durchführen des INSERT vor dem DELETE vorübergehend duplizierte Reihen zu der aktualisierten Tabelle hinzugefügt, wodurch möglicherweise Einzigartigkeits-Randbedingungen verletzt würden und zusätzlicher Code benötigt würde, um auszuwählen, welche Reihen während der DELETE-Operation zu löschen und welche zu behalten sind. Diese Probleme werden noch komplexer, wenn die zu aktualisierenden Spalten auch von Abfrageprädikaten genutzt werden, um zu bestimmen, ob durch ein Aktualisieren einer Reihe die Qualifikationen dieser Reihen zum Archivieren geändert werden.

Mit anderen Worten, eine UPDATE-Operation, welche bewirkt, dass ein Datenelement zum Archivieren qualifiziert wird, muss fehlschlagen, da die UPDATE-Operation keine Daten zu einem beschleunigten Nur-Lese-Archiv hinzufügen kann. In ähnlicher Weise muss ein Aktualisieren eines archivierten Datenelements auf Werte, die nicht mehr zum Archivieren qualifizieren, fehlschlagen, da die UPDATE-Operation dieses Element nicht aus einem beschleunigten Nur-Lese-Archiv löschen kann.

Entsprechend wird bei dem Verfahren der 7 vor dem tatsächlichen Aktualisieren einer Reihe eine Abfrage neu geschrieben, um zuerst zu bestimmen, ob die Aktualisierung den Archivstatus dieser Reihe ändern würde. Dies verhindert, dass das System Ergebnisse erzeugt, welche erforderlich machen würden, dass die Reihe in ein Nur-Lese-Nur-Beschleuniger-Archiv eingefügt oder aus diesem gelöscht wird.

Wie nachstehend beschrieben, baut das System die Prädikate der UPDATE-Anweisung (aus den Zeilen (2) und (3)) in eine SELECT-Anweisung ein, die ausgewertet werden kann, um die auszuwählenden Reihen und die Werte zu identifizieren, auf welche die ausgewählten Reihen aktualisiert würden. Die resultierenden Abfrageanweisungen können ungeachtet dessen durchgeführt werden, ob sich Werte oder Buchstabensymbole, die in den Zeilen (2) und (3) spezifiziert werden, auf Spalten beziehen, die von Prädikaten zum Identifizieren archivierter Reihen genutzt werden.

Entsprechend würde in dem aktuellen Beispiel das DBMS-Front-End 420 die übermittelte Abfrage neu schreiben, um die folgenden Anweisungen einzubeziehen:

          (4)SELECT COUNT(*)
          (5)FROM (SELECT Rabatt - 10% FROM Kunde WHERE Alter <= 30 > )
          (6)WHERE <Archivierungsbedingungsprädikate>

Wie bei den Verfahren der 5 und 6 wird in der Zeile (4) die Anzahl der Reihen gezählt, die durch die Zeile (5) als durch die ursprüngliche UPDATE-Anweisung erzeugt identifiziert werden, und anschließend wird in der Zeile (6) der Ergebnissatz so gefiltert, dass er nur aktualisierte Reihen umfasst, welche qualifiziert sind, archiviert zu werden. Der resultierende Code zeigt an, ob bei der UPDATE-Prozedur archivierte Reihen identifiziert würden, was dem System ermöglicht, einen Fehlerzustand zurückzusenden, wenn es einen Versuch gibt, Reihen in ein Nur-Lese-Archiv einzufügen oder Reihen daraus zu löschen.

Diese Prozedur wird in dem Verfahren der 7 detailliert dargestellt:

Im Schritt 700 empfängt das DBMS-Front-End 420 eine Abfrage oder eine andere Datenzugriffsanforderung.

Im Schritt 710 analysiert das DBMS-Front-End 420 die empfangene Abfrage syntaktisch, um zu bestimmen, dass die Abfrage versucht, Datenbankreihen (oder andere Arten von gespeichertem Datenbankinhalt) einer AOT oder einer Partition zu aktualisieren.

Im Schritt 720 schreibt das DBMS-Front-End 420 die Abfrage neu, um Anweisungen hinzuzufügen, welche bestimmen, wie viele der Reihen in Folge des Aktualisierens dann in ein Nur-Lese-Nur-Beschleuniger-Archiv verschoben werden müssten.

Im Schritt 730 leitet das DBMS-Front-End 420 die neu geschriebene Abfrage an den Beschleuniger 430 weiter.

Im Schritt 740 beginnt der Beschleuniger 430 die Ausführung der neu geschriebenen Abfrage.

Im Schritt 750 bestimmt der Beschleuniger 430 als ein Ergebnis der Durchführung der neu geschriebenen Abfrage, ob welche der zu aktualisierenden Reihen nach dem Aktualisieren Bedingungen zum Archivieren erfüllen würden. Wenn in den Zeilen (4) bis (6) eine Zählung Null zurückgesendet wird, führt das System den Schritt 760 durch, um die angeforderte UPDATE-Operation abzuschließen. Anderenfalls führt das System den Schritt 770 durch, wobei ein Fehler zurückgesendet wird, der durch einen Versuch verursacht wird, Daten unsachgemäß in einem Nur-Lese-Archiv zu aktualisieren.

8 bis 10 veranschaulichen Verfahren zum Durchführen von INSERT-, DELETE-, und UPDATE-DML-Operationen, welche die Inhalte von Lese/Schreib-Nur-Beschleuniger-Archiven beeinflussen.

8 ist ein Ablaufplan, welcher Schritte eines Verfahrens zum Reagieren auf eine Anforderung, neue Daten in ein Lese/Schreib-Nur-Beschleuniger-Archiv einzufügen, gemäß Ausführungsformen der vorliegenden Erfindung veranschaulicht. 8 enthält die Schritte 800 bis 860.

Im Schritt 800 empfängt das DBMS-Front-End 420 eine Abfrage oder eine andere Datenzugriffsanforderung.

Im Schritt 810 analysiert das DBMS-Front-End 420 die empfangene Abfrage syntaktisch, um zu bestimmen, dass die Abfrage versucht, Datenbankreihen (oder in Abhängigkeit von Realisierungsdetails Tabellen, Aufzeichnungen oder eine andere Art von Datenelement) in eine AOT einzufügen. Wie bei 5 ist ein Beispiel einer solchen Anweisung:

          (1)INSERT INTO <AOT>
          (2)SELECT ... FROM <beliebige_andere_Tabellen> WHERE
          <zusätzliche_Prädikate>

Im Schritt 820 schreibt das DBMS-Front-End 420 die Abfrage neu, so dass sie zwei eigenständige INSERT-Anweisungen enthält, eine, welche sich auf Reihen oder andere Datenelemente bezieht, die in ein AOT-Archiv einzufügen sind, und eine, welche sich auf Reihen oder andere Datenelemente bezieht, die in eine Nicht-Archiv-AOT einzufügen sind. Beispielsweise reagiert das Front-End 420 auf den Empfang der beispielhaften SQL-Anweisungen (1) und (2) durch Hinzufügen von:

          (3)INSERT INTO <Nicht-Archiv-AOT>
          (4)SELECT *
          (5)FROM (SELECT ... FROM <beliebige_andere_Tabellen> WHERE
          <zusätzliche_Prädikate> )
          (6)WHERE NOT( < Archivierungsbedingungsprädikate > )
          (7)INSERT INTO <Archiv-AOT
          (8)SELECT *
          (9)FROM (SELECT ... FROM <beliebige_andere_Tabellen> WHERE
          <zusätzliche_Prädikate> ) 



          (10) WHERE <Archivierungsbedingungsprädikate>

In diesem Beispiel werden in den Zeilen (4) bis (5) alle Reihen ausgewählt, die durch die Zeilen (1) und (2) einzufügen sind, indem die Ausdrücke und die Prädikate der Zeile (2) zitiert werden, wodurch einzufügende Reihen ausgewählt werden. In Zeile (6) werden die ausgewählten Reihen gefiltert, um Reihen zu löschen, welche zum Archivieren qualifiziert sind. In Zeile (3) wird somit in eine reguläre (d.h. nicht-archivierte) AOT oder Partition die Teilgruppe eingefügter Reihen eingefügt, die nicht archiviert werden sollten.

Wie in den Zeilen (4) bis (5) werden in den Zeilen (8) bis (9) alle Reihen ausgewählt, die durch die Zeilen (1) und (2) einzufügen sind. Die Zeile (10) filtert diese Gruppe von Reihen derart, dass sie nur Reihen umfasst, welche zum Archivieren qualifiziert sind. In der Zeile (7) werden dann die gefilterten Ergebnisse in ein AOT-Archiv eingefügt. Da in Ausführungsformen der vorliegenden Erfindung jede AOT in archivierte und nicht-archivierte Nur-Lese-Tabellen oder -Partitionen aufgeteilt worden ist, teilen die Anweisungen (4) und (8) die einzufügenden Reihen in zwei eigenständige Teilgruppen auf, von denen einer in eine Archiv-AOT eingefügt wird und einer in eine nicht-archivierte AOT eingefügt wird.

In einem anderen Beispiel werden bei einer Abfrage Reihen zum Einfügen mittels einer SQL-VALUES-Anweisung statt mittels einer Teilauswahl identifiziert:

          (1a) INSERT INTO <AOT>
          (2a) SELECT ... FROM TABLE (VALUES (...) ) AS t( <Spaltenbezeichnungen>

In solchen Fällen schreibt das Front-End 420 die Abfrage neu, um Anweisungen analog zu denen in Zeile (3) bis (8) hinzuzufügen, wobei wiederum Aufzeichnungen zum Einfügen durch Kopieren des ursprünglichen Verfahrens der Abfrage zum Erzeugen einer Ansicht ausgewählt werden:

          (3a) INSERT INTO <Nicht-Archiv-AOT>
          (4a) SELECT *
          (5a) FROM TABLE (VALUES (...) ) AS t( <Spaltenbezeichnungen>
          (6a) WHERE NOT( < Archivprädikate > )
          (7a) INSERT INTO <Archiv-AOT> 



          (8a) SELECT *
          (9a) FROM TABLE (VALUES (...) ) AS t( <Spaltenbezeichnungen>
          (10a) WHERE <Archivprädikate>

Im Schritt 830 leitet das DBMS-Front-End 420 die neu geschriebene Abfrage an den Beschleuniger 430 weiter.

Im Schritt 840 beginnt der Beschleuniger 430 die Ausführung der neu geschriebenen Abfrage.

Im Schritt 850 fügt der Beschleuniger 430, angeleitet durch die Zeilen (3) bis (6) oder (3a) bis (6a), Reihen, die nicht zum Archivieren qualifiziert sind, in geeignete Nicht-Archiv-AOTs oder -Partitionen ein.

Im Schritt 860 fügt der Beschleuniger 430, angeleitet durch die Zeilen (7) bis (10) oder (7a) bis (10a), Reihen, die zum Archivieren qualifiziert sind, in geeignete AOTs oder Partitionen ein, welche archivierte Daten speichern.

9 ist ein Ablaufplan, welcher Schritte eines Verfahrens zum Reagieren auf eine Anforderung, Daten aus einem Lese/Schreib-Nur-Beschleuniger-Archiv zu löschen, gemäß Ausführungsformen der vorliegenden Erfindung veranschaulicht. 9 enthält die Schritte 800 bis 950.

Anders als bei anderen Operationen, die in Ausführungsformen der vorliegenden Erfindung durchgeführt werden, erfordert die Verarbeitung einer Abfrage, bei welcher versucht wird, eine Operation des DELETE-Typs durchzuführen, nicht das Neuschreiben der Abfrage, solange die Nur-Beschleuniger-Archive des Systems beschreibbar sind (d.h. nicht Nur-Lese-Archive sind). In solchen Fällen nutzt das System die Aufteilung jeder AOT in archivierte und nicht-archivierte Tabellen oder Partitionen der Ausführungsform durch einfaches Durchführen eines eigenständigen Satzes von Löschungen für jede Datenklasse.

Im Schritt 900 empfängt das DBMS-Front-End 420 eine Abfrage oder eine andere Datenzugriffsanforderung.

Im Schritt 910 analysiert das DBMS-Front-End 420 die empfangene Abfrage syntaktisch, um zu bestimmen, dass die Abfrage versucht, Datenbankreihen (oder in Abhängigkeit von Realisierungsdetails Tabellen, Aufzeichnungen oder eine andere Art von Datenelement) aus einer oder mehreren AOTs zu löschen.

Im Schritt 920 leitet das DBMS-Front-End 420 die empfangene Abfrage an den Beschleuniger 430 weiter.

Im Schritt 930 beginnt der Beschleuniger 430 die Ausführung der weitergeleiteten Abfrage.

Im Schritt 940 löscht der Beschleuniger 430 aus nicht-archivierten AOTs der beschleunigten Datenbank einen ersten Teilsatz der Reihen, der durch die Abfrage spezifiziert wird. Das DBMS-Front-End 420 oder der Beschleuniger 430 werden durch bekannte Mittel identifiziert haben, dass jede Reihe des ersten Teilsatzes Daten enthält, die nicht archiviert werden sollten.

Im Schritt 950 löscht der Beschleuniger 430 aus den Lese/Schreib-AOT-Archiven der beschleunigten Datenbank einen zweiten Teilsatz der Reihen, der durch die Abfrage spezifiziert wird. Das DBMS-Front-End 420 oder der Beschleuniger 430 werden durch bekannte Mittel identifiziert haben, dass jede Reihe des ersten Teilsatzes Nur-Beschleuniger-Daten enthält, die archiviert werden sollten.

10 ist ein Ablaufplan, welcher Schritte eines Verfahrens zum Aktualisieren von Nur-Beschleuniger-Daten, wo archivierte Nur-Beschleuniger-Daten in einem Lese/Schreib-Format gespeichert sind, gemäß Ausführungsformen der vorliegenden Erfindung veranschaulicht. 10 enthält die Schritte 1000 bis 1080.

Wenn ein System, welches Lese/Schreib-Nur-Beschleuniger-Archive beinhaltet, eine AOT-UPDATE-Anforderung ausführt, sind vier Ergebnisse möglich:

i) ein archiviertes Datenelement wird auf Daten aktualisiert, die nicht mehr zum Archivieren qualifiziert sind; das aktualisierte Datenelement muss dann in eine Nicht-Archiv-AOT oder -Partition verschoben werden;
ii) ein nicht-archiviertes Datenelement wird auf Daten aktualisiert, die zum Archivieren qualifiziert sind; das aktualisierte Datenelement muss dann in eine archivierte AOT oder Partition verschoben werden;
iii) ein archiviertes Datenelement wird auf Daten aktualisiert, die immer noch zum Archivieren qualifiziert sind; das aktualisierte Datenelement wird nicht in eine andere Tabelle oder Partition verschoben; und
iv) ein nicht-archiviertes Datenelement wird auf Daten aktualisiert, die immer noch nicht zum Archivieren qualifiziert sind; das aktualisierte Datenelement wird nicht in eine andere Tabelle oder Partition verschoben.

Es ist jedoch nicht möglich, vier eigenständige UPDATE-Operationen durchzuführen, bei denen Folgendes geschehen würde:

(i) Durchführen einer UPDATE-Operation an nicht-archivierten Tabellen oder Partitionen für jede nicht-archivierte Reihe, die nach dem Aktualisieren nicht-archiviert bleibt;
(ii) Durchführen einer UPDATE-Operation an AOT-Archiven für alle archivierten Reihen, die nach dem Aktualisieren archiviert bleiben;
(iii) Durchführen einer INSERT/DELETE-Operation an nicht-archivierten Reihen, die nach dem Aktualisieren aus einer nicht-archivierten Tabelle oder Partition in ein Nur-Beschleuniger-Archiv verschoben werden müssen; bzw.
(iv) Durchführen einer INSERT/DELETE-Operation an archivierten Reihen, die nach dem Aktualisieren aus einem Nur-Beschleuniger-Archiv in eine nicht-archivierte Tabelle oder Partition verschoben werden müssen.

Das Problem bei diesem Ansatz ist, dass durch ein Modifizieren einer eigenständigen Reihe mehr als einmal während einer einzigen Abfrage aktualisierte Daten einer möglichen Korruption ausgesetzt werden, sofern nicht alle betroffenen Tabellen während der Dauer aller vier Sätze von Abfragen durch irgendeinen anderen Prozess vor einer gleichzeitigen Veränderung geschützt werden. Ferner kann, wie auf dem Fachgebiet bekannt ist, sogar die Reihenfolge, in welcher Reihen durch die obigen Operationen (i) bis (iv) aktualisiert werden, in einigen Fällen zu widersprüchlichen Ergebnissen führen.

Ausführungsformen der vorliegenden Erfindung gehen dieses Problem an, indem eine andere Folge von Operationen durchgeführt wird, welche vermeidet, eine eigenständige Reihe, die in einer eigenständigen Tabelle oder Partition gespeichert ist, mehr als einmal zu aktualisieren:

1) Durchführen einer UPDATE-Operation an allen Reihen nicht-archivierter Tabellen oder Partitionen
2) Durchführen einer UPDATE-Operation an allen Reihen archivierter Tabellen oder Partitionen
3) Verschieben aller archivierungsqualifizierenden Reihen aus den nicht-archivierten Tabellen oder Partitionen in die archivierten Tabellen oder Partitionen
4) Verschieben aller nicht-archivierungsqualifizierenden Reihen aus den archivierten Tabellen oder Partitionen in die nicht-archivierten Tabellen oder Partitionen

Hier werden die Operationen 1) und 2) an verschiedenen Tabellen durchgeführt und deswegen kann nicht dieselbe Reihe zweimal modifiziert werden. Bei den Operationen 3) und 4) werden lediglich Reihen aus einer Tabelle in eine andere verschoben und somit wird keine Reihe modifiziert. Durch diese Prozedur aus vier Operationen wird somit niemals dieselbe Reihe zweimal modifiziert.

Das Neuschreiben der Abfrage zum Hinzufügen von Anweisungen, welche diese Operationen zur Ausführung bringen, ist eine unkomplizierte Prozedur ähnlich jener der Beispiele der 5 bis 9. Beispielsweise können die Inhalte einer aktualisierten Reihe durch Anwenden derselben <Archivierungsbedingungsprädikate>, die in den vorhergehenden Figuren beschrieben werden, als zum Archivieren qualifiziert (oder nicht qualifiziert) identifiziert werden. Sobald ein Endziel einer Reihe identifiziert worden ist, kann das Verschieben der Reihe aus einer Tabelle oder Partition in eine andere durchgeführt werden, indem auf herkömmliche Weise eine INSERT-Operation und eine DELETE-Operation durchgeführt wird.

Diese Prozedur wird durch das Verfahren der 10 verallgemeinert:

Im Schritt 1000 empfängt das DBMS-Front-End 420 eine Abfrage oder eine andere Datenzugriffsanforderung.

Im Schritt 1010 analysiert das DBMS-Front-End 420 die empfangene Abfrage syntaktisch, um zu bestimmen, dass die Abfrage versucht, Datenbankreihen (oder in Abhängigkeit von Realisierungsdetails Tabellen, Aufzeichnungen oder eine andere Art von Datenelement) in einer AOT zu aktualisieren.

Im Schritt 1020 schreibt das DBMS-Front-End 420 die Abfrage neu, um die oben beschriebene Prozedur aus vier Schritten 1) bis 4) zu realisieren.

Im Schritt 1030 leitet das DBMS-Front-End 420 die neu geschriebene Abfrage an den Beschleuniger 430 weiter.

Im Schritt 1040 beginnt der Beschleuniger 430 die Ausführung der neu geschriebenen Abfrage.

Im Schritt 1050 führt der Beschleuniger 430 UPDATE-Operationen, die durch die neu geschriebene Abfrage spezifiziert werden, an allen Reihen durch, die aktuell in nicht-archivierten Tabellen oder Partitionen gespeichert sind.

Im Schritt 1060 führt der Beschleuniger 430 UPDATE-Operationen, die durch die neu geschriebene Abfrage spezifiziert werden, an allen Reihen durch, die aktuell in archivierten AOTs oder Partitionen gespeichert sind. In einigen Ausführungsformen können die Schritte 1050 und 1060 in umgekehrter Reihenfolge durchgeführt werden.

Im Schritt 1070 verschiebt der Beschleuniger 430 alle aktualisierten Reihen, die nun zum Archivieren qualifiziert sind und die aktuell in nicht-archivierten Tabellen oder Partitionen gespeichert sind, in ihre richtigen Nur-Beschleuniger-Archive.

Im Schritt 1080 verschiebt der Beschleuniger 430 alle aktualisierten Reihen, die nicht mehr zum Archivieren qualifiziert sind und die aktuell in einem Nur-Beschleuniger-Archiv gespeichert sind, in ihre richtigen nicht-archivierten Tabellen oder Partitionen. In einigen Ausführungsformen können die Schritte 1070 und 1080 in umgekehrter Reihenfolge durchgeführt werden.

Die Verfahren der 5 bis 10 können auf andere Arten von Abfragen ausgedehnt werden, die für eine Datenbank eingereicht werden, die der Topologie der 1 bis 4 entspricht. Beispielsweise würde eine Anforderung zum Zugreifen auf Nur-Beschleuniger-Daten, bei der nicht ausdrücklich archivierte Daten angefordert werden, gegen eine nicht-archivierte AOT ausgeführt, welche heiße Daten enthält. Aber eine Abfrage, welche Ergebnisse nicht auf nicht-archivierte Daten beschränkt, würde vom DBMS-Front-End 420 neu geschrieben, um eine UNION-ALL-Operation durchzuführen, bei welcher zunächst die Inhalte eines Archivs mit der entsprechenden nicht-archivierten Tabelle des Archivs zusammengeführt werden. Die obigen Verfahren garantieren, dass das zurückgesendete Ergebnis keine Duplikate enthält.

Beispiele und Ausführungsformen der vorliegenden Erfindung, die in diesem Dokument beschrieben werden, sind zu Veranschaulichungszwecken vorgestellt worden. Sie sollten nicht so ausgelegt werden, dass sie erschöpfend sind oder Ausführungsformen der vorliegenden Erfindung auf die hier beschriebenen Beispiele und Ausführungsformen beschränken. Dem Fachmann werden viele andere Modifikationen und Variationen der vorliegenden Erfindung ersichtlich sein, welche nicht vom Umfang und der Idee dieser Beispiele und Ausführungsformen abweichen. Die in diesem Dokument verwendete Terminologie wurde gewählt, um die Prinzipien, die diesen Beispielen und Ausführungsformen zugrunde liegen, bestmöglich zu erläutern, um praktische Anwendungen und technische Verbesserungen der vorliegenden Erfindung gegenüber bekannten Technologien und Produkten zu veranschaulichen und um fachkundigen Lesern zu ermöglichen, die hier offenbarten Beispiele und Ausführungsformen besser zu verstehen.

Claims

Datenbank-Verwaltungssystem (DBMS), welches einen Prozessor, einen mit dem Prozessor verbundenen Speicher und eine mit dem Prozessor verbundene computerlesbare Hardware-Speichereinheit aufweist, wobei die Speichereinheit Programmcode enthält, der dafür konfiguriert ist, durch den Prozessor über den Speicher ausgeführt zu werden, um ein Verfahren zum Archivieren von Nur-Beschleuniger-Datenbanktabellen zu realisieren, wobei das Verfahren umfasst: Bestimmen durch das DBMS, dass eine Reihe einer nicht-archivierten Nur-Beschleuniger-Tabelle (AOT) zum Archivieren qualifiziert worden ist, wobei das DBMS eine Client-Datenbank und eine beschleunigte Datenbank verwaltet, wobei die AOT in der beschleunigten Datenbank gespeichert ist, und wobei die AOT in der Client-Datenbank nicht dupliziert ist; und Verschieben der Reihe aus der AOT in ein Nur-Beschleuniger-Archiv, welches in der beschleunigten Datenbank gespeichert ist und welches von der AOT getrennt ist, durch das DBMS.
System nach Anspruch 1, wobei ein Front-End des DBMS Benutzeranforderungen, auf die Daten zuzugreifen, die in der beschleunigten Datenbank gespeichert sind, abfängt und syntaktisch analysiert und dann jede syntaktisch analysierte Anforderung an ein Beschleunigermodul des DBMS weiterleitet, welches die syntaktisch analysierte Anforderung gegen eine oder mehrere Reihen von Daten ausführt, die in der beschleunigten Datenbank gespeichert sind, und wobei das DBMS eine eingehende Anforderung empfängt, mit welcher eine Durchführung einer Datenbearbeitungsoperation an der einen oder den mehreren Reihen von Daten angefordert wird, die in der beschleunigten Datenbank gespeichert sind.
System nach Anspruch 2, wobei die Datenbearbeitungsoperation aus der Gruppe ausgewählt ist, bestehend aus: einer Einfügeoperation, mit welcher eine oder mehrere neue Reihen in eines oder beides aus der AOT und dem Nur-Beschleuniger-Archiv eingefügt werden, einer Löschoperation, mit welcher eine oder mehrere vorhandene Reihen aus einem oder beiden aus der AOT und dem Nur-Beschleuniger-Archiv gelöscht werden, und einer Aktualisierungsoperation, mit welcher Daten, die in einer oder mehreren vorhandenen Reihen von einem oder beiden aus der AOT und dem Nur-Beschleuniger-Archiv gespeichert sind, überarbeitet werden.
System nach einem der vorhergehenden Ansprüche, wobei das Nur-Beschleuniger-Archiv in einem Nur-Lese-Format gespeichert ist.
System nach einem der Ansprüche 2 bis 4, wobei die Datenbearbeitungsoperation eine Einfügeoperation ist, ferner umfassend: Neuschreiben der eingehenden Anforderung durch das DBMS, um Anweisungen hinzuzufügen, welche den Beschleuniger dazu führen, eine Anzahl von Reihen zu zählen, die durch die Einfügeoperation eingefügt würden und die zum Archivieren qualifiziert sind; Weiterleiten der neu geschriebenen Anforderung an das Beschleunigermodul durch das DBMS; und Zurücksenden einer Fehlermeldung durch das DBMS, wenn es eine Meldung von dem Beschleunigermodul empfängt, dass die Anzahl der Reihen größer als Null ist.
System nach einem der Ansprüche 2 bis 5, wobei die Datenbearbeitungsoperation eine Löschoperation ist, ferner umfassend: Neuschreiben der eingehenden Anforderung durch das DBMS, um Anweisungen hinzuzufügen, welche den Beschleuniger dazu führen, eine Anzahl von Reihen zu zählen, die durch die Löschoperation gelöscht würden und die zum Archivieren qualifiziert sind; Weiterleiten der neu geschriebenen Anforderung an das Beschleunigermodul durch das DBMS; und Zurücksenden einer Fehlermeldung durch das DBMS, wenn es eine Meldung von dem Beschleunigermodul empfängt, dass die Anzahl der Reihen größer als Null ist.
System nach einem der Ansprüche 2 bis 6, wobei die Datenbearbeitungsoperation eine Aktualisierungsoperation ist, ferner umfassend: Neuschreiben der eingehenden Anforderung durch das DBMS, um Anweisungen hinzuzufügen, welche den Beschleuniger dazu führen, eine Anzahl von Reihen zu zählen, die durch die Aktualisierungsoperation überarbeitet würden und die zum Archivieren qualifiziert würden, nachdem sie durch die Aktualisierungsoperation überarbeitet sind; Weiterleiten der neu geschriebenen Anforderung an das Beschleunigermodul durch das DBMS; und Zurücksenden einer Fehlermeldung durch das DBMS, wenn es eine Meldung von dem Beschleunigermodul empfängt, dass die Anzahl der Reihen größer als Null ist.
System nach einem der vorhergehenden Ansprüche, wobei das Nur-Beschleuniger-Archiv in einem Lese/Schreib-Format gespeichert ist.
System nach einem der Ansprüche 2 bis 8, wobei die Datenbearbeitungsoperation eine Einfügeoperation ist, ferner umfassend: Neuschreiben der eingehenden Anforderung durch das DBMS, um Anweisungen hinzuzufügen, welche den Beschleuniger zu Folgendem führen: Identifizieren, welche Reihen der Reihen, die durch die Einfügeoperation eingefügt würden, zum Archivieren qualifiziert sind, Einfügen jeder Reihe, die durch die neu geschriebene Anforderung als zum Archivieren qualifiziert identifiziert wird, in das Nur-Beschleuniger-Archiv, und Einfügen jeder Reihe, die durch die neu geschriebene Anforderung als nicht zum Archivieren qualifiziert identifiziert wird, in die AOT; und Weiterleiten der neu geschriebenen Anforderung an das Beschleunigermodul durch das DBMS.
System nach einem der Ansprüche 2 bis 9, wobei die Datenbearbeitungsoperation eine Löschoperation ist, ferner umfassend: Weiterleiten der eingehenden Anforderung an das Beschleunigermodul durch das DBMS.
System nach einem der Ansprüche 2 bis 10, wobei die Datenbearbeitungsoperation eine Aktualisierungsoperation ist, ferner umfassend: Neuschreiben der eingehenden Anforderung durch das DBMS, um die Datenbearbeitungsoperation durch Anweisungen zu ersetzen, welche den Beschleuniger zu Folgendem führen: Aktualisieren jeder Reihe, für die eine Aktualisierung durch die Aktualisierungsoperation angefordert ist, Verschieben jeder Reihe, die vor dem Aktualisieren nicht zum Archivieren qualifiziert ist, aber nach dem Aktualisieren zum Archivieren qualifiziert wäre, in das Nur-Beschleuniger-Archiv, und Verschieben jeder Reihe, die vor dem Aktualisieren zum Archivieren qualifiziert ist, aber nach dem Aktualisieren nicht mehr zum Archivieren qualifiziert wäre, in die AOT; und Weiterleiten der neu geschriebenen Anforderung an das Beschleunigermodul durch das DBMS.
Verfahren zum Archivieren von Nur-Beschleuniger-Datenbanktabellen, wobei das Verfahren umfasst: Bestimmen durch ein Datenbank-Verwaltungssystem (DBMS), dass eine Reihe einer nicht-archivierten Nur-Beschleuniger-Tabelle (AOT) zum Archivieren qualifiziert worden ist, wobei das DBMS einen Prozessor, einen mit dem Prozessor verbundenen Speicher und eine mit dem Prozessor verbundene computerlesbare Hardware-Speichereinheit aufweist, wobei die Speichereinheit Programmcode enthält, der dafür konfiguriert ist, durch den Prozessor über den Speicher ausgeführt zu werden, um das Verfahren zum Archivieren von Nur-Beschleuniger-Datenbanktabellen zu realisieren, wobei das DBMS eine Client-Datenbank und eine beschleunigte Datenbank verwaltet, wobei die AOT in der beschleunigten Datenbank gespeichert ist, und wobei die AOT nicht in der Client-Datenbank dupliziert ist; und Verschieben der Reihe aus der AOT in ein Nur-Beschleuniger-Archiv, das in der beschleunigten Datenbank gespeichert ist und das von der AOT getrennt ist, durch das DBMS.
Verfahren nach Anspruch 12, wobei ein Front-End des DBMS Benutzeranforderungen, auf die Daten zuzugreifen, die in der beschleunigten Datenbank gespeichert sind, abfängt und syntaktisch analysiert und dann jede syntaktisch analysierte Anforderung an ein Beschleunigermodul des DBMS weiterleitet, welches die syntaktisch analysierte Anforderung gegen eine oder mehrere Reihen von Daten ausführt, die in der beschleunigten Datenbank gespeichert sind, und wobei das DBMS eine eingehende Anforderung empfängt, mit welcher eine Durchführung einer Datenbearbeitungsoperation an der einen oder den mehreren Reihen von Daten angefordert wird, die in der beschleunigten Datenbank gespeichert sind, wobei die Datenbearbeitungsoperation aus der Gruppe ausgewählt ist, bestehend aus: einer Einfügeoperation, mit welcher eine oder mehrere neue Reihen in eines oder beides aus der AOT und dem Nur-Beschleuniger-Archiv eingefügt werden, einer Löschoperation, mit welcher eine oder mehrere vorhandene Reihen aus einem oder beiden aus der AOT und dem Nur-Beschleuniger-Archiv gelöscht werden, und einer Aktualisierungsoperation, mit welcher Daten, die in einer oder mehreren vorhandenen Reihen von einem oder beiden aus der AOT und dem Nur-Beschleuniger-Archiv gespeichert sind, überarbeitet werden.
Verfahren nach Anspruch 13, wobei das Nur-Beschleuniger-Archiv in einem Nur-Lese-Format gespeichert ist und wobei: wenn die Datenbearbeitungsoperation eine Einfügeoperation ist, das Verfahren ferner umfasst: Neuschreiben der eingehenden Anforderung durch das DBMS, um Anweisungen hinzuzufügen, welche den Beschleuniger dazu führen, eine Anzahl von Reihen zu zählen, die durch die Einfügeoperation eingefügt würden und die zum Archivieren qualifiziert sind; Weiterleiten der neu geschriebenen Anforderung an das Beschleunigermodul durch das DBMS; und Zurücksenden einer Fehlermeldung durch das DBMS, wenn es eine Meldung von dem Beschleunigermodul empfängt, dass die Anzahl der Reihen größer als Null ist; wenn die Datenbearbeitungsoperation eine Löschoperation ist, das Verfahren ferner umfasst: Neuschreiben der eingehenden Anforderung durch das DBMS, um Anweisungen hinzuzufügen, welche den Beschleuniger dazu führen, eine Anzahl von Reihen zu zählen, die durch die Löschoperation gelöscht würden und die zum Archivieren qualifiziert sind; Weiterleiten der neu geschriebenen Anforderung an das Beschleunigermodul durch das DBMS; und Zurücksenden einer Fehlermeldung durch das DBMS, wenn es eine Meldung von dem Beschleunigermodul empfängt, dass die Anzahl der Reihen größer als Null ist; und wenn die Datenbearbeitungsoperation eine Aktualisierungsoperation ist, das Verfahren ferner umfasst: Neuschreiben der eingehenden Anforderung durch das DBMS, um Anweisungen hinzuzufügen, welche den Beschleuniger dazu führen, eine Anzahl von Reihen zu zählen, die durch die Aktualisierungsoperation überarbeitet würden und die zum Archivieren qualifiziert würden, nachdem sie durch die Aktualisierungsoperation überarbeitet sind; Weiterleiten der neu geschriebenen Anforderung an das Beschleunigermodul durch das DBMS; und Zurücksenden einer Fehlermeldung durch das DBMS, wenn es eine Meldung von dem Beschleunigermodul empfängt, dass die Anzahl der Reihen größer als Null ist.
Verfahren nach einem der Ansprüche 13 bis 14, wobei das Nur-Beschleuniger-Archiv in einem Lese/Schreib-Format gespeichert ist und wobei: wenn die Datenbearbeitungsoperation eine Einfügeoperation ist, das Verfahren ferner umfasst: Neuschreiben der eingehenden Anforderung durch das DBMS, um Anweisungen hinzuzufügen, welche den Beschleuniger zu Folgendem führen: Identifizieren, welche Reihen der Reihen, die durch die Einfügeoperation eingefügt würden, zum Archivieren qualifiziert sind, Einfügen jeder Reihe, die durch die neu geschriebene Anforderung als zum Archivieren qualifiziert identifiziert wird, in das Nur-Beschleuniger-Archiv, und Einfügen jeder Reihe, die durch die neu geschriebene Anforderung als nicht zum Archivieren qualifiziert identifiziert wird, in die AOT; und Weiterleiten der neu geschriebenen Anforderung an das Beschleunigermodul durch das DBMS; wenn die Datenbearbeitungsoperation eine Löschoperation ist, das Verfahren ferner Weiterleiten der eingehenden Anforderung an das Beschleunigermodul durch das DBMS umfasst; und wenn die Datenbearbeitungsoperation eine Aktualisierungsoperation ist, das Verfahren ferner umfasst: Neuschreiben der eingehenden Anforderung durch das DBMS, um die Datenbearbeitungsoperation durch Anweisungen zu ersetzen, welche den Beschleuniger zu Folgendem führen: Aktualisieren jeder Reihe, für die eine Aktualisierung durch die Aktualisierungsoperation angefordert ist, Verschieben jeder Reihe, die vor dem Aktualisieren nicht zum Archivieren qualifiziert ist, aber nach dem Aktualisieren zum Archivieren qualifiziert wäre, in das Nur-Beschleuniger-Archiv, und Verschieben jeder Reihe, die vor dem Aktualisieren zum Archivieren qualifiziert ist, aber nach dem Aktualisieren nicht mehr zum Archivieren qualifiziert wäre, in die AOT; und Weiterleiten der neu geschriebenen Anforderung an das Beschleunigermodul durch das DBMS.
Verfahren nach einem der Ansprüche 12 bis 15, ferner umfassend Bereitstellen mindestens eines Unterstützungsdienstes für mindestens eines aus Erzeugen, Integrieren, Hosten, Unterhalten und Einsetzen von computerlesbarem Programmcode in dem Computersystem, wobei der computerlesbare Programmcode in Kombination mit dem Computersystem dafür konfiguriert ist, das Bestimmen und das Verschieben zu realisieren.
Computerprogrammprodukt für ein Datenbank-Verwaltungssystem (DBMS), wobei das Computerprogrammprodukt ein computerlesbares Speichermedium mit damit verkörperten Programmanweisungen aufweist, wobei die Programmanweisungen von einem Prozessor ausführbar sind, um zu bewirken, dass der Prozessor ein Verfahren zum Archivieren von Nur-Beschleuniger-Datenbanktabellen durchführt, wobei das Verfahren umfasst: Bestimmen durch ein Datenbank-Verwaltungssystem (DBMS), dass eine Reihe einer nicht-archivierten Nur-Beschleuniger-Tabelle (AOT) zum Archivieren qualifiziert worden ist, wobei das DBMS einen Prozessor, einen mit dem Prozessor verbundenen Speicher und eine mit dem Prozessor verbundene computerlesbare Hardware-Speichereinheit aufweist, wobei die Speichereinheit Programmcode enthält, der dafür konfiguriert ist, durch den Prozessor über den Speicher ausgeführt zu werden, um das Verfahren zum Archivieren von Nur-Beschleuniger-Datenbanktabellen zu realisieren, wobei das DBMS eine Client-Datenbank und eine beschleunigte Datenbank verwaltet, wobei die AOT in der beschleunigten Datenbank gespeichert ist, und wobei die AOT nicht in der Client-Datenbank dupliziert ist; und Verschieben der Reihe aus der AOT in ein Nur-Beschleuniger-Archiv, das in der beschleunigten Datenbank gespeichert ist und das von der AOT getrennt ist, durch das DBMS.
Computerprogrammprodukt nach Anspruch 17, wobei ein Front-End des DBMS Benutzeranforderungen, auf die Daten zuzugreifen, die in der beschleunigten Datenbank gespeichert sind, abfängt und syntaktisch analysiert und dann jede syntaktisch analysierte Anforderung an ein Beschleunigermodul des DBMS weiterleitet, welches die syntaktisch analysierte Anforderung gegen eine oder mehrere Reihen von Daten ausführt, die in der beschleunigten Datenbank gespeichert sind, und wobei das DBMS eine eingehende Anforderung empfängt, mit welcher eine Durchführung einer Datenbearbeitungsoperation an der einen oder den mehreren Reihen von Daten angefordert wird, die in der beschleunigten Datenbank gespeichert sind, wobei die Datenbearbeitungsoperation aus der Gruppe ausgewählt ist, bestehend aus: einer Einfügeoperation, mit welcher eine oder mehrere neue Reihen in eines oder beides aus der AOT und dem Nur-Beschleuniger-Archiv eingefügt werden, einer Löschoperation, mit welcher eine oder mehrere vorhandene Reihen aus einem oder beiden aus der AOT und dem Nur-Beschleuniger-Archiv gelöscht werden, und einer Aktualisierungsoperation, mit welcher Daten, die in einer oder mehreren vorhandenen Reihen von einem oder beiden aus der AOT und dem Nur-Beschleuniger-Archiv gespeichert sind, überarbeitet werden.
Computerprogrammprodukt nach Anspruch 18, wobei das Nur-Beschleuniger-Archiv in einem Nur-Lese-Format gespeichert ist und wobei: wenn die Datenbearbeitungsoperation eine Einfügeoperation ist, das Verfahren ferner umfasst: Neuschreiben der eingehenden Anforderung durch das DBMS, um Anweisungen hinzuzufügen, welche den Beschleuniger dazu führen, eine Anzahl von Reihen zu zählen, die durch die Einfügeoperation eingefügt würden und die zum Archivieren qualifiziert sind; Weiterleiten der neu geschriebenen Anforderung an das Beschleunigermodul durch das DBMS; und Zurücksenden einer Fehlermeldung durch das DBMS, wenn es eine Meldung von dem Beschleunigermodul empfängt, dass die Anzahl der Reihen größer als Null ist; wenn die Datenbearbeitungsoperation eine Löschoperation ist, das Verfahren ferner umfasst: Neuschreiben der eingehenden Anforderung durch das DBMS, um Anweisungen hinzuzufügen, welche den Beschleuniger dazu führen, eine Anzahl von Reihen zu zählen, die durch die Löschoperation gelöscht würden und die zum Archivieren qualifiziert sind; Weiterleiten der neu geschriebenen Anforderung an das Beschleunigermodul durch das DBMS; und Zurücksenden einer Fehlermeldung durch das DBMS, wenn es eine Meldung von dem Beschleunigermodul empfängt, dass die Anzahl der Reihen größer als Null ist; und wenn die Datenbearbeitungsoperation eine Aktualisierungsoperation ist, das Verfahren ferner umfasst: Neuschreiben der eingehenden Anforderung durch das DBMS, um Anweisungen hinzuzufügen, welche den Beschleuniger dazu führen, eine Anzahl von Reihen zu zählen, die durch die Aktualisierungsoperation überarbeitet würden und die zum Archivieren qualifiziert würden, nachdem sie durch die Aktualisierungsoperation überarbeitet sind; Weiterleiten der neu geschriebenen Anforderung an das Beschleunigermodul durch das DBMS; und Zurücksenden einer Fehlermeldung durch das DBMS, wenn es eine Meldung von dem Beschleunigermodul empfängt, dass die Anzahl der Reihen größer als Null ist.
Computerprogrammprodukt nach einem der Ansprüche 18 bis 19, wobei das Nur-Beschleuniger-Archiv in einem Lese/Schreib-Format gespeichert ist und wobei: wenn die Datenbearbeitungsoperation eine Einfügeoperation ist, das Verfahren ferner umfasst: Neuschreiben der eingehenden Anforderung durch das DBMS, um Anweisungen hinzuzufügen, welche den Beschleuniger zu Folgendem führen: Identifizieren, welche Reihen der Reihen, die durch die Einfügeoperation eingefügt würden, zum Archivieren qualifiziert sind, Einfügen jeder Reihe, die durch die neu geschriebene Anforderung als zum Archivieren qualifiziert identifiziert wird, in das Nur-Beschleuniger-Archiv, und Einfügen jeder Reihe, die durch die neu geschriebene Anforderung als nicht zum Archivieren qualifiziert identifiziert wird, in die AOT; und Weiterleiten der neu geschriebenen Anforderung an das Beschleunigermodul durch das DBMS; wenn die Datenbearbeitungsoperation eine Löschoperation ist, das Verfahren ferner Weiterleiten der eingehenden Anforderung an das Beschleunigermodul durch das DBMS umfasst; und wenn die Datenbearbeitungsoperation eine Aktualisierungsoperation ist, das Verfahren ferner umfasst: Neuschreiben der eingehenden Anforderung durch das DBMS, um die Datenbearbeitungsoperation durch Anweisungen zu ersetzen, welche den Beschleuniger zu Folgendem führen: Aktualisieren jeder Reihe, für die eine Aktualisierung durch die Aktualisierungsoperation angefordert ist, Verschieben jeder Reihe, die vor dem Aktualisieren nicht zum Archivieren qualifiziert ist, aber nach dem Aktualisieren zum Archivieren qualifiziert wäre, in das Nur-Beschleuniger-Archiv, und Verschieben jeder Reihe, die vor dem Aktualisieren zum Archivieren qualifiziert ist, aber nach dem Aktualisieren nicht mehr zum Archivieren qualifiziert wäre, in die AOT; und Weiterleiten der neu geschriebenen Anforderung an das Beschleunigermodul durch das DBMS.