DE112020004353T5

DE112020004353T5 - Globale tabellenverwaltungsoperationen für replizierte tabellen mit mehreren regionen

Info

Publication number: DE112020004353T5
Application number: DE112020004353.3T
Authority: DE
Inventors: Akshat Vig; Somasundaram Perianayagam; Tony Petrossian; Arijit Choudhury; James Christopher III Sorenson; Alexander Richard Keyes; Akanksha Fouzdar; Mark Roper; Oren Yossef; Joon Ahn
Original assignee: Amazon Technologies Inc
Current assignee: Amazon Technologies Inc
Priority date: 2019-09-13
Filing date: 2020-09-11
Publication date: 2022-05-25
Also published as: US20210081433A1; GB202205316D0; GB2604250A; US11030220B2; WO2021050905A1

Abstract

Systeme und Verfahren werden offenbart, um in einem Datenbanksystem globale Tabellenverwaltungsoperationen für globale Tabellen oder Objekte zu implementieren, die über mehrere Standorte repliziert werden. In Ausführungsformen wird für ein regionales Replikat einer globalen Tabelle eine angeforderte Änderung an einer Metadateneigenschaft des Replikats (z. B. ein Attributdatentyp, eine Schreibdurchsatzgrenze oder eine Time-to-live-Einstellung) an andere Replikate der globalen Tabelle an anderen Standorten weitergegeben. In Ausführungsformen kann das Datenbanksystem vor dem Ausführen der angeforderten Verwaltungsoperation zuerst verifizieren, dass die Operation an allen Standorten erfolgreich ausgeführt werden kann. In Ausführungsformen kann die Operation optimistisch ohne Verifikation ausgeführt werden und zurückgesetzt werden, wenn sie nicht überall ausgeführt werden kann. In Ausführungsformen kann das Datenbanksystem zum Serialisieren von Verwaltungsoperationen an einer globalen Tabelle nach anderen ausstehenden Verwaltungsoperationen über ein gemeinsames Steuerungsobjekt suchen und fortfahren, wenn irgendwelche ausstehenden Operationen beendet sind.

Description

HINTERGRUND
Kommerzialisierung von Computerhardware- und -softwarekomponenten hat zum Aufstieg von Dienstanbietern geführt, die Rechen- und Speicherkapazität als Dienstleistung anbieten. Hohe Durchsatz- und Verfügbarkeitsanforderungen haben dazu geführt, dass diese Dienste auf geografischer Ebene stärker verteilt sind. Unterschiedliche Ansätze zur Replikation geografisch verteilter Daten haben zu erheblichen Herausforderungen in Bezug auf Komplexität, Verfügbarkeit und Leistung geführt.
In einigen Datenbanksystemen kann ein Replikationsprozess unter Verwendung von Replikatobjekten in mehreren Regionen implementiert werden. Das Datenbanksystem kann diese Replikatobjekte verwalten, um eine einheitliche Ansicht der Daten in den Replikatobjekten über alle Regionen hinweg aufrechtzuerhalten. Wenn regionale Datenbankobjekte als Replikatobjekte in einer solchen Konfiguration verwendet werden, können Änderungen an den Metadateneigenschaften eines Replikatobjekts dazu führen, dass dieses Replikat im Laufe der Zeit von den anderen Replikaten abweicht. Techniken zur einheitlichen Verwaltung der Metadateneigenschaften dieser regionalen Replikatobjekte auf globaler Ebene sind erforderlich, um die Korrektheit des Replikationsprozesses sicherzustellen.
Figurenliste

1 ist ein Blockdiagramm, das ein beispielhaftes Datenbanksystem veranschaulicht, das globale Objektverwaltungsoperationen implementiert, um die Metadateneigenschaften von regionalen Replikatobjekten eines globalen Objekts einheitlich zu verwalten, gemäß einigen Ausführungsformen.
2 ist ein Blockdiagramm, das einen beispielhaften Datenbankdienst darstellt, der eine globale Tabelle mit regionalen Replikaten und regionalen Indexobjekten implementiert, gemäß einigen Ausführungsformen.
3 veranschaulicht beispielhafte Metadateneigenschaften eines regionalen Replikatobjekts, das über eine Datenbankobjektverwaltungsschnittstelle eines Datenbanksystems konfiguriert werden kann, gemäß einigen Ausführungsformen.
4A und 4B veranschaulichen unterschiedliche Techniken zum Weitergeben von Metadateneigenschaftsänderungen über mehrere Regionen eines globalen Objekts gemäß einigen Ausführungsformen.
5 veranschaulicht ein beispielhaftes Serialisierungsprotokoll zum Serialisieren globaler Verwaltungsoperationen an einem globalen Objekt gemäß einigen Ausführungsformen.
6 ist ein Flussdiagramm, das einen Prozess zum Durchführen von Objektverwaltungsoperationen an einem Datenbankobjekt darstellt, das ein regionales Replikat eines globalen Objekts ist, gemäß einigen Ausführungsformen.
7A und 7B sind Flussdiagramme, die zwei Prozesse zum Weitergeben von Objektverwaltungsoperationen an verschiedene Regionen eines globalen Objekts veranschaulichen, gemäß einigen Ausführungsformen.
8 ist ein Flussdiagramm, das einen Prozess zum Serialisieren globaler Verwaltungsoperationen an einem globalen Objekt veranschaulicht, gemäß einigen Ausführungsformen.
9 ist ein Blockdiagramm, das ein beispielhaftes Rechnersystem veranschaulicht, das verwendet werden kann, um einen oder mehrere Teile eines Datenbanksystems zu implementieren, das globale Objektverwaltungsoperationen implementiert, um die Metadateneigenschaften von regionalen Replikatobjekten eines globalen Objekts einheitlich zu verwalten, gemäß einigen Ausführungsformen.

Wenngleich Ausführungsformen hier beispielhaft für mehrere Ausführungsformen und veranschaulichende Zeichnungen beschrieben werden, erkennen Fachleute, dass Ausführungsformen nicht auf die beschriebenen Ausführungsformen oder Zeichnungen beschränkt sind. Es versteht sich, dass die Ausführungsformen durch die Zeichnungen und die detaillierte Beschreibung nicht auf die bestimmte offenbarte Form beschränkt werden, sondern dass im Gegenteil dadurch alle Modifikationen, Äquivalente und Alternativen abgedeckt werden, die in den Rahmen, wie er durch die beigefügten Ansprüche definiert wird, fallen. Die hier verwendeten Überschriften dienen nur organisatorischen Zwecken und sind nicht dazu gedacht, den Schutzumfang der Beschreibung oder der Ansprüche einzuschränken. In der Anmeldung wird der Ausdruck „kann“ eher in einem zulassenden Sinne (d. h. das Potenzial zu etwas habend) als im zwingenden Sinne (d. h. mit der Bedeutung darf/muss) verwendet. Desgleichen bedeuten die Wörter „beinhalten“, „beinhaltend“ und „beinhaltet“ einschließlich, jedoch ohne darauf beschränkt zu sein.
Es versteht sich auch, dass, obwohl die Begriffe erster, zweiter usw. hier verwendet werden können, um verschiedene Elemente zu beschreiben, diese Elemente nicht durch diese Begriffe beschränkt werden sollten. Diese Begriffe werden nur verwendet, um ein Element von einem anderen zu unterscheiden. Beispielsweise könnte ein erster Kontakt als zweiter Kontakt bezeichnet werden, und in ähnlicher Weise könnte ein zweiter Kontakt als erster Kontakt bezeichnet werden, ohne vom Umfang der vorliegenden Erfindung abzuweichen. Der erste Kontakt und der zweite Kontakt sind jeweils Kontakte, aber sie sind nicht der gleiche Kontakt.
DETAILLIERTE BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
Die hierin beschriebenen Systeme und Verfahren können in verschiedenen Kombinationen und in Ausführungsformen verwendet werden, um globale Objektverwaltungsoperationen in einem Datenbanksystem zu implementieren, um gemäß einigen Ausführungsformen die Metadateneigenschaften von regionalen Replikaten eines globalen Objekts einheitlich zu verwalten, das über mehrere Regionen hinweg repliziert wird.
In einigen Ausführungsformen kann ein Datenbanksystem Benutzern ermöglichen, ein globales Objekt (z. B. eine globale Tabelle) zu erstellen, das eine Gruppe von Replikatobjekten (z. B. Replikattabellen) beinhaltet, die an unterschiedlichen geografischen Standorten oder Regionen verwaltet werden. In einigen Ausführungsformen werden diese Replikatobjekte auf unterschiedlicher Hardware (z. B. Datenbankservern) und/oder Software (z. B. Datenbankinstanzen) an den verschiedenen Standorten gehostet. In einigen Ausführungsformen können die Replikatobjekte verwendet werden, um einen laufenden Replikationsprozess zu unterstützen, um Daten untereinander zu replizieren. Beispielsweise können in einigen Ausführungsformen Replikatobjekte so konfiguriert sein, dass sie Änderungen in einem Replikat an andere Replikate des globalen Objekts weiterleiten, so dass das globale Objekt eine einheitliche Ansicht der replizierten Daten in allen Regionen bereitstellen kann, möglicherweise mit einer kleinen Replikationslatenz. Auf diese Weise ermöglicht das globale Objekt Datenbankbenutzern in verschiedenen Regionen, auf einfache Weise einen Datenkörper gemeinsam zu nutzen, der von jeder Region aus lesbar und beschreibbar ist.
In einigen Ausführungsformen kann das Datenbanksystem als ein Datenbankdienst in einem cloudbasierten Dienstanbieternetzwerk implementiert werden, das Datenbankinstanzen im Namen seiner Clienten hostet, wobei „in der Cloud“-Hardware verwendet wird, die von dem Dienstanbieter betrieben wird. In einigen Ausführungsformen kann der Datenbankdienst Clienten öffentlich zugängliche Schnittstellen bereitstellen (z. B. über ein öffentliches Netzwerk wie das Internet), um den Clienten sowohl den Zugriff auf die Daten in ihren gehosteten Datenbankinstanzen als auch die Verwaltung der Metadateneigenschaften ihrer Datenbankinstanzen (z. B. die Definition von Datenbankobjekten, konfigurierte Eigenschaften und/oder Verhalten der Datenbankobjekte usw.) zu ermöglichen.
Wenn in einigen Ausführungsformen ein Datenbankobjekt als Replikatobjekt verwendet wird, das Teil eines globalen Objekts ist, können Änderungen an bestimmten Metadateneigenschaften des Replikatobjekts dazu führen, dass dieses Replikat mit der Zeit von den anderen Replikaten abweicht. In einigen Ausführungsformen kann diese Abweichung zwischen den Replikaten ein falsches Verhalten in dem globalen Objekt darstellen. In einigen Ausführungsformen müssen einige Metadateneigenschaften von Replikaten einheitlich gehalten werden (z. B. gleich gehalten werden), um die Korrektheit des globalen Objekts sicherzustellen, während andere Metadateneigenschaften über die Regionen hinweg variiert werden können, ohne falsche Ergebnisse im Replikationsprozess des globalen Objekts zu verursachen. Beispielsweise müssen in einigen Ausführungsformen Metadateneigenschaften wie die Attributtypdefinitionen regionaler Replikate (z. B. die Attribute eines materialisierten Index, der auf dem globalen Objekt definiert ist) über alle Regionen hinweg gleich gehalten werden. Wenn die regionalen Versionen der Indizes unterschiedlich definierte Attribute haben, können Änderungen am globalen Objekt verständlicherweise womöglich nicht einheitlich auf die gleiche Weise auf alle regionalen Indizes projiziert werden, was dazu führt, dass die Daten über die Regionen hinweg abweichen. Als weiteres Beispiel muss womöglich eine bereitgestellte Durchsatzgrenze (die steuert, wie viel Schreibverkehr von einem regionalen Replikat zugelassen werden kann) oder eine Time-to-live-Einstellung (TTL, Gültigkeitsdauer) (die steuert, wie lange ein Datenelement oder Datensatz in einem Replikatobjekt aufbewahrt wird) in allen Regionen einheitlich gehalten werden. Andererseits kann in einigen Ausführungsformen zugelassen werden, dass einige Metadateneigenschaften, wie z. B. einer Lesedurchsatzgrenze für das Replikatobjekt oder einem clientspezifischen Verschlüsselungsschlüssel, der für das Replikatobjekt verwendet wird, von einer Region zur anderen variieren, ohne die Korrektheit des globalen Objekts zu beeinträchtigen. In einigen Ausführungsformen müssen bestimmte Metadateneigenschaften eines Replikatobjekts in einer unveränderlichen Einstellung gehalten werden, um die Korrektheit des globalen Objekts sicherzustellen. Beispielsweise muss in einigen Ausführungsformen ein Replikatobjekt konfiguriert werden, um seinen Aktualisierungsstrom einzuschalten, der von dem Datenbanksystem verwendet werden kann, um Datenänderungen in diesem Replikat an die anderen Replikate weiterzugeben.
Um Benutzer daran zu hindern, die Metadateneigenschaften regionaler Replikatobjekte falsch zu aktualisieren, implementieren hierin offenbarte Ausführungsformen von Datenbanksystemen eine globale Objektverwaltungsschnittstelle, die verwendet werden kann, um Änderungen an den Metadateneigenschaften eines Replikatobjekts automatisch an die anderen Replikatobjekte weiterzugeben. Um die Benutzerverwechselung zu verringern, können in einigen Ausführungsformen die globalen Objektverwaltungsoperationen so implementiert werden, dass sie als Verwaltungsoperationen für regionale Objekte aufgerufen werden können (d. h. jene Objekte, die nicht Teil irgendwelcher globaler Objekte sind). In einigen Ausführungsformen kann das Datenbanksystem automatisch erkennen, dass das Ziel einer Verwaltungsoperation ein Replikatobjekt ist, und kann die Verwaltungsoperation bei einer solchen Erkennung automatisch an die anderen Regionen weitergeben.
In einigen Ausführungsformen kann die weitergegebene Verwaltungsoperation möglicherweise nicht immer erfolgreich in allen Regionen ausgeführt werden, beispielsweise aufgrund einer oder mehrerer regionsspezifischer Beschränkungen. Dementsprechend kann das Datenbanksystem in einigen Ausführungsformen verschiedene Ansätze implementieren, um sicherzustellen, dass eine Verwaltungsoperation für mehrere Regionen in einer Alles- oder-Nichts-Weise über alle Regionen hinweg ausgeführt wird. In einigen Ausführungsformen kann die Verwaltungsoperation über einen zweiphasigen Festschreibungsprozess verbreitet werden, wobei die Operation in allen Regionen nur nach einem „Vorbereitungs“-Schritt „festgeschrieben“ wird, um zu verifizieren, dass die Operation in allen Regionen erfolgreich ausgeführt werden kann. In einigen Ausführungsformen kann die Verwaltungsoperation optimistisch in allen Regionen versucht werden und in allen Regionen rückgängig gemacht werden, wenn sie in irgendeiner Region fehlschlägt.
In einigen Ausführungsformen kann das Datenbanksystem ein Serialisierungsprotokoll implementieren, um alle globalen Verwaltungsoperationen an einem globalen Objekt zu serialisieren, die aus unterschiedlichen Regionen stammen können. Es versteht sich, dass in einigen Ausführungsformen Metadateneigenschaftsänderungen an dem globalen Objekt in allen Regionen in der gleichen Reihenfolge auftreten müssen, um eine Datenabweichung zu verhindern. Dementsprechend kann in einigen Ausführungsformen eine globale Verwaltungsoperation ein gemeinsam genutztes Steuerungsobjekt für das globale Objekt prüfen (z. B. eine globale Tabelle oder eine globale Sperre), bevor mit der globalen Verwaltungsoperation fortgefahren wird. In einigen Ausführungsformen kann das gemeinsam genutzte Steuerungsobjekt verwendet werden, um die Sequenzierung von Verwaltungsoperationen an dem globalen Objekt zu erzwingen.
Vorteilhafterweise können hierin offenbarte Ausführungsformen des Datenbanksystems und der globalen Objektverwaltungsschnittstelle verwendet werden, um Metadatenkorrektheit über Replikate eines globalen Objekts hinweg umzusetzen. Darüber hinaus können einige der offenbarten globalen Objektverwaltungsoperationen als Teil regionaler Objektverwaltungsoperationen implementiert werden, um die Benutzerschnittstelle des Datenbanksystems zu vereinfachen und die Benutzerverwechselung zu verringern. Diese und andere Merkmale und Vorteile der globalen Objektverwaltungsschnittstelle sind nachstehend in Verbindung mit den Figuren ausführlicher beschrieben.
1 ist ein Blockdiagramm, das ein beispielhaftes Datenbanksystem veranschaulicht, das globale Objektverwaltungsoperationen implementiert, um die Metadateneigenschaften von regionalen Replikatobjekten eines globalen Objekts einheitlich zu verwalten, gemäß einigen Ausführungsformen.
Wie gezeigt, stellt die Figur ein Datenbanksystem dar, das an mehreren Standorten implementiert ist, einschließlich Standort A 130, Standort B 180 und Standort C 190. Es versteht sich, dass das Datenbanksystem in unterschiedlichen Ausführungsformen über eine große Anzahl unterschiedlicher Standorte hinweg implementiert werden kann. In einigen Ausführungsformen kann jeder Standort ein anderer geografischer Standort eines verteilten Systems sein. In einigen Ausführungsformen kann jeder Standort ein anderes Rechenzentrum sein, das sich in einer bestimmten geografischen Zone innerhalb eines verteilten Netzwerks von Rechenzentren befindet. In einigen Ausführungsformen kann jeder Standort ein bestimmtes Teilnetzwerk sein (z. B. ein lokales Netzwerk bzw. LAN), das mit den anderen Netzwerkstandorten verbunden ist, aber dessen Netzwerkelemente außerhalb des Netzwerks nicht allgemein zugänglich sind. In einigen Ausführungsformen kann jeder Standort A, B und C jeweils eine separate Instanz des Datenbanksystems oder -dienstes hosten. In einigen Ausführungsformen kann durch Clienten 110 an jedem der Standorte A, B oder C über ein oder mehrere Netzwerke 120 auf das Datenbanksystem zugegriffen werden.
In einigen Ausführungsformen können der / die Client(en) jede Art von Client einschließen, der konfigurierbar ist, um Dienstanforderungen an das Datenbanksystem zu übermitteln, das in einem Dienstanbieternetzwerk implementiert sein kann. In einigen Ausführungsformen kann ein Client 110 eine geeignete Version eines Webbrowsers oder ein Plug-in-Modul für einen Webbrowser oder eine andere Art von Codemodul beinhalten, das konfiguriert ist, um als eine Erweiterung einer Ausführungsumgebung oder innerhalb dieser ausgeführt zu werden, um Clients von Datenbank- oder Datenspeicherdiensten (z. B. Clientanwendungen, Benutzer und/oder Abonnenten) Zugriff auf die Dienste zu geben, die vom Anbieternetzwerk bereitgestellt werden. Alternativ kann ein Client 110 eine Anwendung umfassen, wie etwa eine Datenbankanwendung, Medienanwendung, Büroanwendung oder irgendeine andere Anwendung, die von dauerhaften Speicherressourcen Gebrauch machen kann. In einigen Ausführungsformen kann eine Anwendung eine ausreichende Protokollunterstützung (z. B. für eine geeignete Version des Hypertext Transfer Protocol (HTTP)) zum Generieren und Verarbeiten von Webdienstanforderungen beinhalten, ohne notwendigerweise eine vollständige Browserunterstützung für alle Arten von webbasierten Daten zu implementieren. Ein Client 110 kann eine Anwendung sein, die so konfiguriert ist, dass sie direkt mit den Diensten interagiert. In einigen Ausführungsformen kann ein Client 110 so konfiguriert sein, dass er Webdienstanforderungen gemäß einer Webdienstarchitektur im REST-Stil, einer dokument- oder nachrichtenbasierten Webdienstarchitektur oder einer anderen geeigneten Webdienstarchitektur generiert.
In manchen Ausführungsformen kann das Netzwerk 120 ein öffentliches Netzwerk wie etwa das Internet sein. In einigen Ausführungsformen können der eine oder die mehreren Clients 110 unterschiedliche Mengen an Rechenressourcen für einen oder mehrere Dienste leasen, die von dem Dienstanbieternetzwerk 230 bereitgestellt werden, wie z. B. einen serverlosen Ausführungsdienst 240, wie gezeigt. In einigen Ausführungsformen kann das Dienstanbieternetzwerk 230 eine große Anzahl von Datenverarbeitungsstämmen betreiben, die nach Bedarf bereitgestellt und deaktiviert werden können, um den Betrieb seiner Dienste zu unterstützen. Die Dienste können unter Verwendung eines oder mehrerer Dienstendpunkte implementiert werden, die zum Empfangen und Verarbeiten von Dienstanforderungen konfiguriert sind. Die Dienste können unter Verwendung von Hardware und/oder Software implementiert werden, um HTTP-basierte Webdienstanforderungen, die an ihre Endpunkte gerichtet sind, ordnungsgemäß zu empfangen und zu verarbeiten. In einer Ausführungsform können die Dienste als ein Serversystem implementiert werden, das konfiguriert ist, um Webdienstanforderungen von Clients zu empfangen und sie an verschiedene Komponenten weiterzuleiten, die gemeinsam ein Datenspeichersystem, ein serverloses Ausführungssystem, ein Objektspeichersystem usw. zur Verarbeitung implementieren. In anderen Ausführungsformen können die Dienste als eine Anzahl unterschiedlicher Systeme (z. B. in einer Cluster-Topologie) konfiguriert sein, die einen Lastenausgleich und andere Anforderungsverwaltungsmerkmale implementieren, die konfiguriert sind, um groß angelegte Webdienst-Anforderungsverarbeitungslasten dynamisch zu verwalten.
In einigen Ausführungsformen kann das Datenbanksystem, wie gezeigt, Datenzugriffsoperationen oder Datenobjektverwaltungsoperationen über ein Netzwerk 120 empfangen. In verschiedenen Ausführungsformen kann das Netzwerk 120 jede geeignete Kombination von Netzwerkhardware und Protokollen umfassen, die notwendig sind, um Netzwerkkommunikation zwischen Clients 110 und dem Datenbanksystem herzustellen. Beispielsweise kann das Netzwerk 120 die verschiedenen Telekommunikationsnetzwerke und Dienstanbieter umfassen, die gemeinsam das Internet implementieren. Das Netzwerk 120 kann auch private Netzwerke wie lokale Netzwerke (local area networks - LANs) oder Weitverkehrsnetzwerke (wide area networks - WANs) sowie öffentliche oder private drahtlose Netzwerke einschließen. Beispielsweise können sowohl ein bestimmter Client 110 als auch eine Datenbank jeweils innerhalb von Unternehmen bereitgestellt werden, die ihre eigenen internen Netzwerke haben. In einer solchen Ausführungsform kann das Netzwerk 120 die Hardware (z. B. Modems, Router, Switches, Load Balancer, Proxy-Server usw.) und Software (z. B. Protokollstapel, Buchhaltungssoftware, Firewall/Sicherheitssoftware usw.) beinhalten, die erforderlich sind, um eine Netzwerkverbindung zwischen dem bestimmten Client und dem Internet sowie zwischen dem Internet und dem Datenbanksystem herzustellen. In einigen Ausführungsformen können Clienten 110 mit der netzwerkbasierten Datenbank unter Verwendung eines privaten Netzwerks anstelle des öffentlichen Internets kommunizieren. Beispielsweise kann ein Client 110 innerhalb desselben Unternehmens wie die Datenbank und/oder das hierin beschriebene zugrundeliegende System bereitgestellt sein. In einigen Ausführungsformen kann ein Client 110 einen Dienst umfassen, der von demselben Dienstanbieter angeboten wird, der die Datenbank als Dienst anbietet.
Wie gezeigt, ist der Client 110 in der dargestellten Ausführungsform konfiguriert, um Verwaltungsoperationen an Datenbankobjekten in dem Datenbanksystem auszugeben, wie z. B. eine Verwaltungsoperation 122, die auf Objekt O gerichtet ist. In diesem Beispiel ist ein Datenbankobjekt O 172 ein regionales Replikatobjekt, das Teil eines globalen Objekts 170 ist. Wie gezeigt, besteht das globale Objekt 170 in diesem Beispiel aus drei regionalen Replikatobjekten 172, 182 und 192, die an den drei verschiedenen Standorten A 130, B 180 und C 190 verwaltet werden. In einigen Ausführungsformen kann das Datenbanksystem einen verwalteten Replikationsprozess unter den Replikatobjekten 172, 182 und 192 implementieren, um eine einheitliche Ansicht der Daten über die Replikatobjekte hinweg aufrechtzuerhalten. In einigen Ausführungsformen kann der Replikationsprozess an jedem Standort das Durchführen des Sendens von an diesem Standort empfangenen Datenänderungen an die anderen Standorte und das Empfangen und Anwenden von Datenänderungen von den anderen Standorten auf das lokale Replikatobjekt einschließen. In einigen Ausführungsformen kann das Senden und Empfangen von Datenänderungen unter Verwendung eines Aktualisierungsstroms durchgeführt werden, der eine Abfolge von Datenänderungen angibt, die auf ein einzelnes Replikatobjekt angewendet wurden. In einigen Ausführungsformen kann jedes der Replikatobj ekte 172, 182 und 192 beschreibbar sein, so dass das globale Objekt von jedem der drei Standorte 130, 180 und 190 aktualisiert werden kann.
In einigen Ausführungsformen kann, wie gezeigt, die Verwaltungsoperation 122 über eine Datenbankobjektverwaltungsschnittstelle 132 empfangen werden. In einigen Ausführungsformen kann die Verwaltungsschnittstelle 132 durch das Datenbanksystem bereitgestellt werden, um Clienten zu ermöglichen, eine Vielzahl von Verwaltungsoperationen zu spezifizieren, die Objektverwaltungsoperationen beinhalten können, um verschiedene Metadateneigenschaften von einzelnen Objekten in der Datenbank (z. B. Tabellen, Indizes usw.) zu modifizieren. In einigen Ausführungsformen kann die Verwaltungsschnittstelle 132 als ein Satz aufrufbarer Funktionsaufrufe implementiert sein, die beispielsweise Webdienstaufrufe sein können. In einigen Ausführungsformen kann die Verwaltungsschnittstelle 132 als eine programmatische Schnittstelle implementiert sein, zum Beispiel eine Anwendungsprogrammierschnittstelle bzw. API (Application Programming Interface). In einigen Ausführungsformen kann die Verwaltungsschnittstelle 132 als eine Benutzerschnittstelle implementiert sein, wie beispielsweise eine Befehlszeilenschnittstelle (Command Line Interface - CLI) oder eine grafische Benutzerschnittstelle (Graphical User Interface - GUI). In einigen Ausführungsformen kann die Verwaltungsschnittstelle 132 als ein Netzwerkprotokoll implementiert sein, das durch das Datenbanksystem bereitgestellt wird.
In einigen Ausführungsformen kann die Verwaltungsoperation 122 eine Vielzahl unterschiedlicher Arten von Verwaltungsoperationen beinhalten. In einigen Ausführungsformen können die Verwaltungsoperationen unterschiedlichen Arten von aufrufbaren Funktionen entsprechen, die es Benutzern des Datenbanksystems ermöglichen, Metadateninformationen über Datenbankobjekte in dem Datenbanksystem anzuzeigen und/oder zu modifizieren. Beispielsweise können Verwaltungsoperationen in einigen Ausführungsformen Operationen zum Erstellen, Modifizieren oder Löschen eines Datenbankobjekts (z. B. einer Tabelle oder eines Index für eine Tabelle), Modifizieren verschiedener Attributdatentypen eines Datenbankobjekts und Modifizieren verschiedener Metadateneigenschaften eines Datenbankobjekts (z. B. die Lese-/ Schreibdurchsatzgrenze, unterschiedliche Verschlüsselungs- oder Entschlüsselungsschlüssel, die bei dem Objekt verwendet werden, oder Time-to-live-Werte für Datenelemente im Objekt, ob ein Aktualisierungsstrom für das Objekt aktiviert werden soll usw.) beinhalten. In einigen Ausführungsformen können einige der Verwaltungsoperationen sowohl für globale Objekte als auch für regionale Objekte (z. B. diejenigen, die nicht Teil eines globalen Objekts sind) verwendet werden. Beispielsweise kann das Datenbanksystem in einigen Ausführungsformen bestimmte regionale Objektverwaltungsoperationen überlasten, um bestimmte zusätzliche oder alternative Aktionen für globale Objekte durchzuführen. In einigen Ausführungsformen können bestimmte Verwaltungsoperationen speziell für globale Objekte definiert werden. Beispielsweise können solche Operationen dem Benutzer in einigen Ausführungsformen ermöglichen, ein globales Objekt zu erstellen, die regionalen Replikate eines globalen Objekts abzutrennen, ein regionales Replikat für ein globales Objekt hinzuzufügen oder ein regionales Replikat von einem globalen Objekt zu trennen oder zu entfernen. Wie gezeigt, können all diese unterschiedlichen Arten von Verwaltungsoperationen über die Verwaltungsschnittstelle 132 an das Datenbanksystem gesendet und programmatisch durch das Datenbanksystem (z. B. eine lokale Instanz des Datenbanksystems 130, 180 oder 190) gehandhabt werden.
Wie gezeigt, kann das Datenbanksystem in einigen Ausführungsformen ein globales Objekterkennungsmodul 140 implementieren. In einigen Ausführungsformen kann, wie erörtert, eine Art von Verwaltungsoperation sowohl für ein regionales Objekt als auch für ein Replikat eines globalen Objekts aufgerufen werden. Die tatsächliche Ausführung der Operation kann jedoch unterschiedlich sein, je nachdem, ob das Zieldatenbankobjekt ein regionales Objekt oder Teil eines globalen Objekts ist. Beispielsweise kann in einigen Ausführungsformen eine Änderung einer Metadateneigenschaft eines Datenbankobjekts unterschiedlich durchgeführt werden, abhängig davon, ob das Objekt regional oder global ist. Dementsprechend kann das globale Objekterkennungsmodul 140 in einigen Ausführungsformen verwendet werden, um zu bestimmen, ob das zu modifizierende Zieldatenbankobjekt (hier Objekt O 172) Teil eines globalen Objekts ist. In einigen Ausführungsformen kann die Erkennung durchgeführt werden, indem die zugrundeliegende Metadatendefinition des Zieldatenbankobjekts untersucht wird.
Wie gezeigt, kann das Datenbanksystem in einigen Ausführungsformen, wenn bestimmt wird, dass das Zielobjekt Teil eines globalen Objekts ist, eine globale Operationsroutine oder ein globales Operationsmodul 142 aufrufen. In einigen Ausführungsformen, die in der Figur nicht gezeigt sind, kann das Datenbanksystem, wenn das Zielobjekt nicht Teil eines globalen Objekts ist, die globale Operationshandhabungsroutine umgehen und stattdessen eine regionale Operationshandhabungsroutine oder ein regionales Operationshandhabungsmodul 134 aufrufen. Auf diese Weise kann das Datenbanksystem bestimmte Verwaltungsoperationen überlasten, um sowohl an regionalen als auch an globalen Objekten zu arbeiten, um dem Benutzer eine einfachere Verwaltungsschnittstelle mit weniger Arten von Verwaltungsoperationen zu präsentieren.
Wie gezeigt, kann in einigen Ausführungsformen die globale Operationshandhabung 142 bestimmen, wie die Verwaltungsoperation 122 durchzuführen ist, basierend auf einer Art von Metadateneigenschaft, die in der Operation geändert wird. In diesem Beispiel [werden] drei verschiedene Typen von Metadateneigenschaften [und] gezeigt, Eigenschaft A 144, Eigenschaft B 146 und Eigenschaft C 148. In einigen Ausführungsformen kann die globale Operationshandhabungsroutine 142 viele oder wenige Kategorien von Metadateneigenschaften beinhalten.
In diesem Beispiel ist die Metadateneigenschaft A 144 eine Art von Metadateneigenschaft, die für Replikatobjekte in einem globalen Objekt unveränderlich zu halten ist. In einigen Ausführungsformen kann eine solche Eigenschaft das Aktivieren oder Deaktivieren eines Aktualisierungsstroms von dem Objekt beinhalten, der von dem Datenbanksystem verwendet wird, um Änderungen von einem Replikat an die anderen zu senden. Wenn ein Replikatobjekt Teil eines globalen Objekts ist, sollte sein Aktualisierungsstrom in einigen Ausführungsformen im Allgemeinen nicht abgeschaltet werden. Als weiteres Beispiel kann eine andere Art von unveränderlicher Metadateneigenschaft angeben, dass eine globale Erlaubnis für alle regionalen Replikatobjekte erteilt werden soll, um dem Datenbanksystem zu ermöglichen, eine bestimmte fortlaufende Verwaltung an den regionalen Replikaten durchzuführen. Dementsprechend wird, wie gezeigt, wenn die Verwaltungsoperation 122 versucht, diese unveränderliche Eigenschaft für globale Objekte zu ändern, die Operation 122 einfach abgelehnt, 124. In einigen Ausführungsformen kann die Ablehnung 124 über eine Antwort an die Operation 122 bereitgestellt werden und kann den Grund für die Zurückweisung angeben (z. B. dass die Operation versucht, eine unveränderliche Eigenschaft für das globale Objekt unzulässigerweise zu modifizieren).
In diesem Beispiel ist die Metadateneigenschaft B 146 eine Eigenschaftsart, die zwischen verschiedenen Replikatobjekten eines einzelnen globalen Objekts 170 variiert werden kann. In einigen Ausführungsformen kann eine solche Eigenschaft die Lesedurchsatzgrenze eines Replikatobjekts beinhalten. In einigen Ausführungsformen kann die Menge an Leseverkehr, die von einem regionalen Replikat gehandhabt werden kann, zwischen den Regionen unterschiedlich sein, da diese Eigenschaft die tatsächlichen Daten, die in den Replikatobjekten gespeichert sind, nicht beeinflusst. Als weiteres Beispiel kann ein Verschlüsselungs- oder Entschlüsselungsschlüssel, der dem regionalen Replikat zugeordnet ist, eine andere Eigenschaft sein, die sich von Region zu Region unterscheiden kann. Beispielsweise kann in einigen Ausführungsformen der Besitzer jeder Region eine regionsspezifische Verschlüsselung angeben, die auf dessen Replikat implementiert werden soll. Als weiteres Beispiel kann eine andere Art von Metadateneigenschaft, die unter Replikatobjekten variieren darf, ein Abrechnungsmodusattribut sein, das verwendet werden kann, um zu steuern, wie einem Kunden der Lese- und Schreibdurchsatz in Rechnung gestellt wird, der vom Kunden auf dem Replikatobjekt genutzt wird. In einigen Ausführungsformen kann die Abrechnungsmoduseinstellung es Kunden ermöglichen, ein gewisses Durchsatzniveau für das Objekt vorab bereitzustellen oder auf einer Pro-Anfrage-Basis abgerechnet zu werden. Dementsprechend kann, wie gezeigt, wenn die Verwaltungsoperation 122 versucht, diese Art von Metadateneigenschaft 146 zu ändern, das Datenbanksystem die Operation einfach an den regionalen Operationshandler 134 weiterleiten, der die Operation regional als eine regionale Änderung 152 ausführt.
In diesem Beispiel ist die Metadateneigenschaft C 148 eine Eigenschaftsart, die über alle regionalen Replikaten des globalen Objekts 170 hinweg einheitlich zu halten ist. In einigen Ausführungsformen kann eine solche Eigenschaft die Attributdatentypen auf dem Replikatobjekt beinhalten (z. B. die Genauigkeit eines numerischen Felds, ob das Attribut als Teil eines Primärschlüssel- oder Partitionsschlüsselsatzes oder eines Sortierschlüsselsatzes festgelegt ist usw.). In einigen Ausführungsformen kann eine solche Eigenschaft ein Attributdatentyp auf einem globalen Indexobjekt sein, das von einer globalen Tabelle abhängig ist. In einigen Ausführungsformen kann das Indexobjekt als Teil einer globalen Tabellendefinition definiert werden, so dass ein Replikat des Indexobjekts in den verschiedenen Regionen repliziert wird. In einigen Ausführungsformen kann das Indexobjekt ein materialisiertes Objekt sein, das eine Ansicht der Daten aus der Basistabelle kopiert (oder projiziert). Da das Indexobjekt in einigen Ausführungsformen auch in den mehreren Regionen repliziert werden soll, müssen womöglich auch seine Attributarten, seine Projektionslogik und andere Metadateneigenschaften über die Regionen hinweg einheitlich gehalten werden. Andernfalls können die Daten in den Indexobjekten innerhalb der Regionen voneinander abweichen. Als weiteres Beispiel ist eine andere Art von Metadateneigenschaft, die in allen Regionen gleich bleiben sollte, eine Schreibdurchsatzgrenze eines Replikatobjekts. Wenn diese Grenze von Region zu Region unterschiedlich eingestellt ist, kann in einigen Ausführungsformen ein Burst von Schreibvorgängen in einer Region erfolgreich sein, während derselbe Burst in einer anderen Region fehlschlagen kann (durch Überschreiten der Schreibdurchsatzgrenze). Um solche Situationen zu vermeiden, kann das Datenbanksystem in einigen Ausführungsformen verhindern, dass die Schreibdurchsatzgrenze über die verschiedenen Regionen hinweg variiert. Als weiteres Beispiel ist eine andere Art von Metadateneigenschaft, die in allen Regionen gleich bleiben sollte, eine Time-to-Live-(TTL-)Einstellung des Replikatobjekts. In einigen Ausführungsformen kann die TTL-Einstellung oder der TTL-Wert vorschreiben, wie lange Datenelemente in einem Datenbankobjekt aufbewahrt werden müssen, bevor sie gelöscht werden. In einigen Ausführungsformen kann das TTL-Merkmal es einem Datenbankobjekt ermöglichen, nur ein kleines Fenster neuerer Daten aufzubewahren, um so die Größe des Datenbankobjekts klein zu halten und die Abfrageleistung zu verbessern. Da unterschiedliche TTL-Werte dazu führen, dass die Replikatobjekte unterschiedliche Inhalte haben, kann das Datenbanksystem in einigen Ausführungsformen verhindern, dass die Werte über die unterschiedlichen Regionen hinweg variieren.
Wenn dementsprechend, wie gezeigt, die Verwaltungsoperation 122 versucht, diese Art von Metadateneigenschaft 148 zu ändern, kann das Datenbanksystem die Operation nicht nur an den regionalen Operationshandler 134 weiterleiten, sondern die Operation auch als globale Änderung 154 an die anderen regionalen Replikate des globalen Objekts 170 weitergeben, 156. Auf diese Weise führt das Datenbanksystem bei Bedarf automatisch Verwaltungsoperationen an allen Replikatobjekten des globalen Objekts 170 auf transparente Weise durch. In einigen Ausführungsformen kann die Weitergabe der Operation über ein globales Operationskoordinationsmodul 150 durchgeführt werden, das den tatsächlichen Weitergabeprozess implementieren kann, um sicherzustellen, dass die Weitergabe korrekt durchgeführt wird. In einigen Ausführungsformen kann die Weitergabe 156 das Übertragen der Operation 122 über ein oder mehrere zwischengeschaltete Netzwerke zu Datenbankinstanzen an den anderen Standorten (z. B. den Standorten 180 und 190) beinhalten, so dass sie an diesen entfernt gelegenen Standorten an den Replikatobjekten (z. B. den Objekten 182 und 192) durchgeführt werden können. In einigen Ausführungsformen kann der Weitergabeprozess ein Protokoll-Warten auf Bestätigungen von den entfernt gelegenen Replikatstandorten implementieren, bevor die Operation lokal am Ursprungsstandort bestätigt wird. Es sollte beachtet werden, dass in einigen Ausführungsformen die Logik und die Komponenten, die für Standort A 130 gezeigt sind, an allen Standorten des globalen Objekts 170 wiederholt werden. Somit können Verwaltungsoperationen 122 und Metadateneigenschaftsänderungsanforderungen von jeder Region des globalen Objekts 170 stammen. Durch die Verwendung des globalen Operationshandhabungsmoduls 142 und des globalen Operationskoordinierungsmoduls 150 werden jedoch bestimmte Metadateneigenschaften der Replikatobjekte (z. B. Metadateneigenschaft C 148) für alle Bereiche immer einheitlich gehalten.
2 ist ein Blockdiagramm, das einen beispielhaften Datenbankdienst darstellt, der eine globale Tabelle mit regionalen Replikaten und regionalen Indexobjekten implementiert, gemäß einigen Ausführungsformen. Wie gezeigt, stellt die Figur ein cloudbasiertes Dienstanbieternetzwerk 230 dar, das verwendet werden kann, um einem oder mehreren Regionsclients 210 und 220 Dienste bereitzustellen. Wie gezeigt, können in einigen Ausführungsformen Komponenten des Datenbanksystems, das in Verbindung mit 1 erörtert ist, als Datenbankdienst 240 im Dienstanbieternetzwerk 230 implementiert werden.
Wie gezeigt, kann das Dienstanbieternetzwerk 230 in einigen Ausführungsformen in Regionen oder Zonen unterteilt sein, wie etwa Region A 232 und Region B 234. In einigen Ausführungsformen können die Regionen unterschiedliche Teilnetzwerke innerhalb des Dienstanbieternetzwerks, unterschiedliche regionale Rechenzentren oder unterschiedliche Verfügbarkeitszonen darstellen, die unterschiedliche Gruppen von redundanten Datenverarbeitungsressourcen beinhalten, um eine hohe Dienstverfügbarkeit aufrechtzuerhalten.
Wie gezeigt, kann der Datenbankdienst 240 in einigen Ausführungsformen durch Gruppen von Datenverarbeitungsknoten implementiert werden, die Instanzen virtueller Maschinen (VM) sein können, die auf physischen Hosts gehostet werden, die von dem Dienstanbieter betrieben werden. In einigen Ausführungsformen kann sich die Bereitstellung dieser Knoten oder VM-Instanzen auf einen anderen zugrundeliegenden Dienst des Dienstanbieternetzwerks stützen, der On-Demand-Rechenknoteninstanzen bereitstellt. In einigen Ausführungsformen kann die Größe des Pools von Knoten, die dem Datenbankdienst 240 zugeordnet sind, basierend auf der Dienstnachfrage automatisch skaliert oder angepasst werden. In einigen Ausführungsformen können fehlerhafte Knoten oder Instanzen automatisch aus dem Pool entfernt und durch neue Instanzen oder Knoten ersetzt werden.
Wie gezeigt, wird in diesem Beispiel eine globale Tabelle 250 über die Regionen A 232 und B 234 implementiert. In einigen Ausführungsformen kann die globale Tabelle 250 ein Beispiel für das globale Objekt 170 von 1 sein und können die regionalen Replikate A 252 und B 254 Beispiele für das Replikatobjekt 172 von 1 sein. Wie gezeigt, können in diesem Beispiel die zwei Replikatobjekte 252 und 254 entsprechende Datenänderungen 242 und 244 von jeweiligen regionalen Clienten 210 und 220 empfangen. Diese Datenänderung kann beispielsweise über Datenzugriffsanforderungen an den Datenbankdienst 240 in den zwei Regionen empfangen werden. Die Datenzugriffsanforderungen können Anforderungen zum Einfügen, Aktualisieren oder Löschen von Datenelementen aus den Replikatobjekten 252 und 254 beinhalten.
In einigen Ausführungsformen kann der Datenbankdienst (z. B. die zwei Instanzen des Datenbankdienstes, die in den zwei Regionen 232 und 234 laufen) einen Replikationsprozess oder ein Protokoll implementieren, um die Inhalte der zwei regionalen Replikate 252 und 254 zu synchronisieren. In einigen Ausführungsformen kann das Replikationsprotokoll entsprechende Änderungsströme 260 verwenden, die von den zwei Replikatobjekten erzeugt werden. In einigen Ausführungsformen kann das Datenbanksystem ein Merkmal bereitstellen, um diesen Änderungsstrom für ein beliebiges Datenbankobjekt zu erzeugen, um alle Änderungen oder Änderungsanforderungen an das Objekt in sequentieller und/oder gestreamter Form bereitzustellen. In einigen Ausführungsformen kann das Format von Datensätzen im Änderungsstrom konfigurierbar sein, um beispielsweise den Zustand geänderter Datensätze vor der Änderung, nach der Änderung oder beides einzuschließen. In einigen Ausführungsformen können sich verschiedene Arten von interessierten Listeners registrieren, um den Änderungsstrom eines Datenbankobjekts zu empfangen und basierend auf den Inhalten des Änderungsstroms Maßnahmen ergreifen.
Wie gezeigt, können in diesem Beispiel die Replikattabellen 252 und 254 beide zu einer replizierten Tabellengruppe für die globale Tabelle 250 gehören. In einigen Ausführungsformen wird der Replikationsprozess über die Änderungsströme 260 durchgeführt. In einigen Ausführungsformen kann die empfangende Seite eines Änderungsstroms 260 die Änderungen im Änderungsstrom auf ihre lokale Replikattabelle anwenden. In einigen Ausführungsformen kann das Datenbanksystem in den zwei Regionen 232 und 234 einen stufenweisen Festschreibungsprozess implementieren, um widersprüchliche Aktualisierungen zwischen den zwei Tabellen 252 und 254 korrekt zu handhaben. Obwohl in der Figur nur zwei Standorte und zwei Tabellen gezeigt sind, können in einigen Ausführungsformen die globale Tabelle 250 und der Replikationsprozess über eine beliebige Anzahl von Regionen und Tabellen implementiert werden, wodurch eine letztendliche Einheitlichkeit über alle Replikate der globalen Tabelle 250 hinweg sichergestellt wird.
Wie gezeigt, sind in diesem Beispiel beide Tabellen 252 und 254 einem jeweiligen regionalen Indexobjekt 256 bzw. 258 zugeordnet. In einigen Ausführungsformen können diese Indexobjekte 256 und 258 als Teil der Tabelle 252 oder 254 oder als Teil des globalen Objekts 250 definiert sein. In einigen Ausführungsformen können die Indexobjekte 256 und 258 eine Kopie einiger Daten (oder transformierter Daten) aus ihren Basistabellen 252 und 254 beinhalten. In einigen Ausführungsformen können die Indexobjekte 256 und 258 wie gezeigt basierend auf den Änderungsströmen 262 und 264 gefüllt werden. Somit können alle Änderungen an der Basistabelle sofort in ihren zugehörigen Indizes widergespiegelt werden. In einigen Ausführungsformen können die Änderungsströme 262 und 264 dieselben Änderungsströme 260 sein, die verwendet werden, um die Tabellen 252 und 254 über die zwei Regionen hinweg zu replizieren. In einigen Ausführungsformen können die Indizes 256 und 258 die Daten in einem anderen Partitionierungsschema (z. B. unter Verwendung eines anderen Partitionsschlüsselattributs) oder in einer anderen Sortierreihenfolge (z. B. unter Verwendung eines anderen Sortierschlüsselattributs) speichern, um unterschiedliche Arten von Abfragen zu erleichtern. In einigen Ausführungsformen können mehrere Indexobjekte für eine einzelne Basistabelle definiert werden. In einigen Ausführungsformen können die Metadateneigenschaften der Tabelle 252 und 254 auch separat für die Indexobjekte 256 und 258 existieren, wie zum Beispiel unterschiedliche Schreibdurchsatzgrenzen, unterschiedliche TTL-Werte usw. Es versteht sich, dass, da die Inhalte dieser Indexobjekte auch Teil der globalen Tabelle 250 sind, deren Metadateneigenschaften ebenfalls vom Datenbanksystem gesteuert werden, so dass bestimmte Änderungen an deren Metadateneigenschaften entweder verboten sind oder an andere Bereiche der globalen Tabelle weitergegeben werden.
Wie gezeigt, kann der Datenbankdienst 240 in einigen Ausführungsformen im Allgemeinen Datenbankobjekte (z. B. verschiedene Tabellen oder Indizes) verwalten, die nicht Teil irgendwelcher globaler Objekte sind. In einigen Ausführungsformen kann ein bestimmter Datenspeicher oder eine gehostete Datenbankinstanz einige Objekte, die Teil eines globalen Objekts sind (z. B. in eine oder mehrere entfernt gelegene Regionen repliziert), und einige Objekte, die nur regional sind (z. B. in keine entfernt gelegenen Regionen repliziert), beinhalten. In diesem Beispiel sind die Tabellen C 270 und der Index 272 regionale Objekte in der Region A 232 und sind die Tabellen D 280 und E 282 regionale Objekte in der Region B 234. In einigen Ausführungsformen kann die Datenbankobjektverwaltungsschnittstelle 132 Verwaltungsoperationen sowohl an globalen als auch an regionalen Objekten ermöglichen. In einigen Ausführungsformen kann, wie erörtert, eine einzige Art von Verwaltungsoperation überladen werden, um sowohl auf globalen als auch auf regionalen Objekten ausgeführt zu werden.
3 veranschaulicht beispielhafte Metadateneigenschaften eines regionalen Replikatobjekts, das über eine Datenbankobjektverwaltungsschnittstelle eines Datenbanksystems konfiguriert werden kann, gemäß einigen Ausführungsformen. Wie gezeigt, stellt die Figur eine Anzahl von Anforderungen für Datenbankobjektverwaltungsoperationen dar, die über die Datenbankobjektverwaltungsschnittstelle 132 von 1 empfangen werden können. Wie gezeigt, beinhalten diese angeforderten Datenbankobjektverwaltungsoperationen alle Änderungen an einer oder mehreren Metadateneigenschaften 310 eines regionalen Replikatobjekts in Region A.
Wie gezeigt, fordert eine Modifikationsanforderung 350 eine Änderung einer unveränderlichen Eigenschaft 320 auf dem Replikatobjekt an. Wie erörtert, können in einigen Ausführungsformen bestimmte Metadateneigenschaften als für Replikate eines globalen Objekts unveränderlich festgelegt werden, wie zum Beispiel die Metadateneigenschaft A 144 von 1. Wie gezeigt, gehört in diesem Beispiel eine Aktualisierungsstromeigenschaft 322 des Replikats in diese Kategorie. In diesem Beispiel muss die Aktualisierungsstromeigenschaft des Replikatobjekts immer aktiviert sein. Dementsprechend führt die Modifikationsanforderung 350 zum Ändern dieser Eigenschaft zu einer Ablehnung 352 der Anforderung.
Wie gezeigt, fordert die Modifikationsanforderung 360 eine Änderung einer oder mehrerer Eigenschaften 330 des Replikatobjekts an. Wie erörtert, können in einigen Ausführungsformen bestimmte Metadateneigenschaften des Replikatobjekts als zu einer Kategorie 330 von Eigenschaften gehörend festgelegt werden, die über alle Replikate eines globalen Objekts hinweg einheitlich zu halten sind, wie zum Beispiel die Metadateneigenschaft C 148 von 1. Wie gezeigt, gehören in diesem Beispiel die Attributdatentypen 332 des Replikatobjekts zu dieser Kategorie. Außerdem gehören auch die Attributdatentypen 334 von Indexobjekten, die von dem Replikatobjekt abhängen, zu dieser Kategorie. Wenn es den Attributdatentypen dieser Objekte erlaubt ist, sich in den unterschiedlichen Regionen zu unterscheiden, versteht sich, dass das globale Objekt Daten nicht korrekt über die Replikatobjekte replizieren kann. Wie gezeigt, ist eine weitere Metadateneigenschaft in dieser Kategorie die Schreibdurchsatzgrenze 336 des Replikatobjekts. Es versteht sich, dass der Zustand des globalen Objekts in den verschiedenen Regionen variiert, wenn aufgrund unterschiedlicher Werte für die Grenze 336 nicht alle Schreibvorgänge in verschiedene regionale Replikate stattfinden können. In einigen Ausführungsformen können abhängig von der Fähigkeit des Datenbanksystems, sich von einer übermäßigen Schreibanforderung zu erholen, einige Datenunterschiede zwischen den Regionen dauerhaft sein (z. B. wenn übermäßige Schreibanforderungen sofort gedrosselt werden). Wie gezeigt, ist eine weitere Metadateneigenschaft, die in diese Kategorie 330 fällt, die Time-to-Live-Einstellung 338. Es versteht sich, dass die Inhalte der Replikate im Laufe der Zeit voneinander abweichen, wenn Elemente in verschiedenen Replikatobjekten eines globalen Objekts zu unterschiedlichen Zeiten auslaufen (z. B. gelöscht werden) dürfen. Dementsprechend wird die Modifikationsanforderung 360 für jede dieser Metadateneigenschaften lokal auf dem Replikat der Region A durchgeführt, aber auch an andere regionale Replikate 380 weitergegeben, 362, die Teil desselben globalen Objekts sind. In den entfernt gelegenen Regionen wird die angeforderte Operation 360 an den Metadateneigenschaften 382 dieser entfernt gelegenen Replikatobjekte durchgeführt, so dass diese Metadateneigenschaften über alle Regionen hinweg einheitlich gehalten werden.
Wie gezeigt, fordert die Modifikationsanforderung 370 eine Änderung einer oder mehrerer Eigenschaften 340 des Replikatobjekts an. Wie erörtert, können in einigen Ausführungsformen bestimmte Metadateneigenschaften des Replikatobjekts als zu einer Kategorie 340 von Eigenschaften gehörend festgelegt werden, die sich über die Replikate eines globalen Objekts hinweg unterscheiden können, wie zum Beispiel die Metadateneigenschaft B 146 von 1. Wie gezeigt, gehört in diesem Beispiel die Lesedurchsatzgrenze 342 des Replikatobjekts zu dieser Kategorie. Es versteht sich, dass die Fähigkeit der Clienten, die verschiedenen regionalen Replikate zu lesen, den Inhalt der regionalen Replikate nicht ändert. Dementsprechend wirkt sich dieser Metadatenparameter des Replikatobjekts nicht auf die Korrektheit des Replikationsprozesses aus und kann von einer Region zur anderen variieren. Wie gezeigt, sind eine weitere Metadateneigenschaft in dieser Kategorie der eine oder die mehreren Datenverschlüsselungsschlüssel 344, die verwendet werden, um Daten in dem regionalen Replikat zu verschlüsseln oder zu entschlüsseln. Es versteht sich, dass diese Eigenschaft zwar beeinflusst, wie die Daten in dem Replikat gespeichert werden, sie ändert die zugrundeliegenden Daten, die zwischen den Regionen synchronisiert werden sollen, jedoch nicht. Dementsprechend kann auch diese Metadateneigenschaft regional unterschiedlich sein. In einigen Ausführungsformen müssen jedoch möglicherweise bestimmte andere Schlüssel über die Regionen hinweg gleich gehalten werden, in denen die Schlüssel von einem gemeinsamen Schlüsselverwaltungsdienst bereitgestellt werden. In einigen Ausführungsformen kann der Datenbankdienst auf einem Regionen übergreifenden Schlüsselverwaltungsdienst basieren, um einen gemeinsamen Schlüssel bereitzustellen, der zum Verschlüsseln seiner Objekte verwendet wird. In diesem Fall müssen in einigen Ausführungsformen möglicherweise eine oder mehrere Metadateneigenschaften, die sich auf den gemeinsamen Schlüssel im Schlüsselverwaltungsdienst beziehen, über die Regionen hinweg gleich gehalten werden, so dass diese Eigenschaften zur Kategorie 330 gehören, um automatisch an die anderen Replikate des globalen Objekts weitergegeben zu werden. Wenn die zu ändernde Metadateneigenschaft in die Kategorie 340 fällt, wird die Modifikationsanforderung 360 nur lokal an dem Replikat der Region A durchgeführt und nicht an andere Replikate des globalen Objekts weitergegeben, 374, um entsprechende Metadateneigenschaften 384 dieser Replikate zu aktualisieren.
Wie gezeigt, kann die Datenbankobjektverwaltungsschnittstelle 132 auch eine Anforderung 372 zum Löschen oder Trennen eines Replikats von dem globalen Objekt bestätigen. In einigen Ausführungsformen kann diese Anforderung 372 in Kategorie 340 kategorisiert werden, so dass jegliche Metadateneigenschaften, die durch die Anforderung geändert (oder gelöscht) werden, nicht an 374 weitergegeben werden. Dies liegt daran, dass die Anforderung zum Löschen oder Lösen eines Replikats im Allgemeinen als lokale Anforderung gedacht ist und nicht im Allgemeinen dazu gedacht ist, alle Replikate in allen Regionen zu löschen oder zu trennen.
4A und 4B veranschaulichen unterschiedliche Techniken zum Weitergeben von Metadateneigenschaftsänderungen über mehrere Regionen eines globalen Objekts gemäß einigen Ausführungsformen.
4A zeigt einen zweiphasigen Festschreibungsprozess, der verwendet werden kann, um die Weitergabe von Metadateneigenschaftsänderungen von einem regionalen Replikat 410 in der Region A an andere regionale Replikate 420 desselben globalen Objekts zu implementieren. Während die Figur zu Erläuterungszwecken verschiedene funktionale Komponenten oder Operationen in den Replikaten darstellt, können diese funktionalen Komponenten oder Operationen in einigen Ausführungsformen durch die Datenbankinstanzen implementiert werden, die die Replikatobjekte verwalten.
In dem dargestellten Prozess von 4A wird eine Modifikationsanforderung 430 empfangen, um eine Eigenschaft des Replikats 410 der Region A zu modifizieren, was bewirkt, dass die Änderung an die anderen Replikate 420 weitergegeben wird. In einigen Ausführungsformen können die Datenbankinstanzen in den anderen Regionen nicht im Voraus garantieren, dass eine bestimmte Eigenschaftsänderung erfolgreich durchgeführt werden kann. Beispielsweise kann eine Eigenschaftsänderung, die in einer Region durchgeführt werden kann, in einer anderen Region aufgrund von Faktoren wie regionenspezifischen Sicherheitsregeln, aktuellen Betriebsbedingungen der Datenbankinstanz oder anderen regionenspezifischen Beschränkungen fehlschlagen. Dementsprechend wird in einigen Ausführungsformen ein zweiphasiger Festschreibungsprozess verwendet, um sicherzustellen, dass die angeforderten Verwaltungsoperationen in einer Alles-oder-Nichts-Weise über alle Regionen hinweg durchgeführt werden.
Wie gezeigt, wird ein Vorbereitungsphasenkoordinierungsmodul oder eine Vorbereitungsphasenkoordinierungsoperation 412 verwendet, um zuerst eine Anzahl von Vorbereitungsanweisungen oder -nachrichten an die anderen regionalen Replikate 420 weiterzugeben, 432. Die anderen regionalen Replikate 420 führen eine Vorbereitungsphase 422 des zweiphasigen Prozesses durch, um zu verifizieren, dass die angeforderte Verwaltungsoperation an ihren jeweiligen Standorten erfolgreich durchgeführt werden kann. Wenn die Vorbereitungsphase 422 erfolgreich ist, geben diese regionalen Replikate 420 jeweilige Bestätigungen 434 an das Koordinierungsmodul 412 zurück, das die Bestätigungen verifiziert und mit der Festschreibungsphase des Prozesses fortfährt, 436. Wichtig ist, dass, wenn eine der anderen regionalen Replikate 420 die Vorbereitungsphase 422 nicht erfolgreich abschließen kann oder keine Bestätigung 434 innerhalb eines erwarteten Zeitfensters zurückgibt, der zweiphasige Prozess als Abbruch gewertet werden kann. In einigen Ausführungsformen kann eine zusätzliche Abbruchnachricht an die anderen regionalen Replikate weitergegeben werden. Wenn auf diese Weise ein regionales Replikat eine Metadateneigenschaftsänderung nicht erfolgreich ausführen kann, wird kein Replikat des globalen Objekts die Änderung implementieren.
Wenn alle regionalen Replikate 420 den erfolgreichen Abschluss der Vorbereitungsphase 422 bestätigen, wird in einigen Ausführungsformen eine Festschreibungsphasenkoordinierungsoperation oder ein Festschreibungsphasenkoordinierungsmodul 414 durchgeführt. In einigen Ausführungsformen können während der Festschreibungsphase eine oder mehrere Anweisungen oder Nachrichten an die anderen regionalen Replikate 420 zu einer Festschreibungsphase 424 auf jedem der regionalen Replikate 420 gesendet werden. Während der Festschreibungsphase 424 kann die Modifikationsanforderung 430 tatsächlich durchgeführt werden, um auf die Replikatobjekte wirksam zu werden. Wichtig ist, dass aufgrund der während der Vorbereitungsphase 422 durchgeführten Verifizierung nur ein geringes oder kein Risiko bestehen sollte, dass die Modifikationsanforderung fehlschlägt. Sobald die Festschreibungsphase 424 bei den einzelnen regionalen Replikaten 420 abgeschlossen ist, können die regionalen Replikate eine weitere Bestätigung 438 zurück an das koordinierende Replikat 410 senden. In einigen Ausführungsformen kann der Empfang von Bestätigungen 438 von allen erwarteten entfernt gelegenen Replikatobjekten es dem koordinierenden Replikat 410 ermöglichen, eine Bestätigung 439 auf die Anforderung zurückzugeben.
4B zeigt einen optimistischen Modifikationsprozess, der ein alternativer Prozess sein kann, der in einigen Ausführungsformen verwendet wird, um die Weitergabe von Metadateneigenschaftsänderungen von einem regionalen Replikat 440 in der Region A zu anderen regionalen Replikaten 450 und 460 zu implementieren. Während die Figur zu Erläuterungszwecken verschiedene funktionale Komponenten oder Operationen in den Replikaten darstellt, können diese funktionalen Komponenten oder Operationen in einigen Ausführungsformen durch die Datenbankinstanzen implementiert werden, die die Replikatobj ekte verwalten.
In dem dargestellten Prozess von 4B wird eine Modifikationsanforderung 470 empfangen, um eine Eigenschaft des Replikats 440 der Region A zu modifizieren, was bewirkt, dass die Änderung an die anderen Replikate 450 und 460 weitergegeben wird, 472. In diesem beispielhaften Prozess wird die angeforderte Modifikation optimistisch an dem ursprünglichen regionalen Replikat 440 und jedem der anderen Replikate durchgeführt, zum Beispiel unter Verwendung eines optimistischen Ausführungsmoduls oder einer optimistischen Ausführungsoperation 442 oder anderer optimistischer Ausführungsmodule oder -operationen 452 und 462. In einigen Ausführungsformen können die optimistischen Ausführungsmodule 442, 452 und 462 bewirken, dass die angeforderte Eigenschaftsmodifikation durchgeführt und wirksam wird, ohne zu verifizieren, dass die Modifikation überall erfolgreich durchgeführt werden kann. Wenn die angeforderte Modifikation auf allen regionalen Replikaten (nicht gezeigt) erfolgreich ist, ist der Modifikationsprozess abgeschlossen und kann das Replikat 440 in der Region A kann eine Bestätigung zurückgeben.
Wenn jedoch eine der regionalen Replikate (z. B. Replikat 450 in Region B) die Eigenschaftsmodifikation nicht erfolgreich durchführen kann (z. B. aufgrund einiger regionenspezifischer Beschränkungen), wird eine Nachricht oder Antwort, die einen Fehler 474 anzeigt, an das Replikat 440 zurückgegeben, von dem die Modifikationsanforderung ausgegangen ist. In diesem Fall kann das Ursprungsreplikat 440 in einigen Ausführungsformen einen Zurücksetzungsprozess initiieren, beispielsweise unter Verwendung eines Zurücksetzungskoordinierungsmoduls oder einer Zurücksetzungskoordinierungsoperation 444. In einigen Ausführungsformen kann das Zurücksetzungskoordinierungsmodul 444 Anweisungen oder Module an alle oder einige der anderen regionalen Replikate 460 (oder 450) des globalen Objekts senden, um die anderen Replikate zu veranlassen, die von ihnen durchgeführte Eigenschaftsmodifikation zurückzusetzen, z. B. über ein Zurücksetzungsmodul oder eine Zurücksetzungsoperation 464. Wenn bei irgendeinem Replikatobjekt des globalen Objekts ein Fehler 474 der angeforderten Eigenschaftsmodifikation auftritt, kann in einigen Ausführungsformen das Ursprungsreplikat 440 eine Anforderung-fehlgeschlagen-Antwort 478 an den anfordernden Clienten zurückgeben. In einigen Ausführungsformen kann die Antwort 478 den Grund für den Fehlschlag anzeigen, einschließlich beispielsweise des regionalen Replikats 450, bei dem der Fehlschlag aufgetreten ist.
5 veranschaulicht ein beispielhaftes Serialisierungsprotokoll zum Serialisieren globaler Verwaltungsoperationen an einem globalen Objekt gemäß einigen Ausführungsformen. Während die Figur zu Erläuterungszwecken verschiedene funktionale Komponenten oder Operationen in den Replikaten darstellt, können diese funktionalen Komponenten oder Operationen in einigen Ausführungsformen durch die Datenbankinstanzen implementiert werden, die die Replikatobjekte verwalten.
Wie gezeigt, implementieren in diesem Beispiel ein Replikat 510 in Region A und ein anderes Replikat 520 in Region B ein Serialisierungsprotokoll, um eine globale Verwaltungsoperation zu serialisieren, die an einem globalen Objekt auszuführen ist. In einigen Ausführungsformen können die Replikate 510 und 520 auf ähnliche Weise wie die Replikate 252 und 254 von 2 implementiert werden, um ein globales Objekt (z. B. eine globale Tabelle 250) zu implementieren. In einigen Ausführungsformen können Verwaltungsoperationen, die Metadateneigenschaften eines globalen Objekts modifizieren, aus einer beliebigen Region stammen, in der es ein Replikatobjekt hat. In einigen Ausführungsformen können Verwaltungsoperationen aus unterschiedlichen Regionen nahezu zur gleichen Zeit stattfinden, was eine Situation schaffen könnte, in der die Verwaltungsoperationen in einer anderen Reihenfolge an die verschiedenen Replikate in der Gruppe weitergegeben werden. In einigen Ausführungsformen kann dieser Unterschied in der Reihenfolge von Verwaltungsoperationen ein Korrektheitsproblem innerhalb des globalen Objekts verursachen. Beispielsweise müssen in einem Szenario zwei widersprüchliche Verwaltungsoperationen (z. B. zum Umschalten einer Moduseinstellung an den Replikatobjekten) in derselben Reihenfolge für alle Replikatobjekte erscheinen. Dementsprechend kann das Datenbanksystem (z. B. über die Datenbankverwaltungsoperationenschnittstelle 132) in einigen Ausführungsformen eine Serialisierung aller Verwaltungsoperationen an einem globalen Objekt unter Verwendung eines Serialisierungsprotokolls 540 umsetzen.
In diesem Beispiel wird das Serialisierungsprotokoll 540 wie gezeigt durch entsprechende Operationsserialisierungsfunktionen oder -komponenten 512 und 522 an den zwei regionalen Replikaten implementiert. In einigen Ausführungsformen implementieren alle regionalen Replikate, die Metadateneigenschaftsänderungen an dem globalen Objekt ausgeben können, dasselbe Serialisierungsprotokoll 540. In diesem Beispiel beinhaltet das Serialisierungsprotokoll eine Prüfoperation (z. B. Prüfungen 542 und 546) an einem gemeinsam genutzten Steuerungsobjekt 530. In einigen Ausführungsformen gibt es immer nur eine Instanz des gemeinsam genutzten Steuerungsobjekts 530 und alle Datenbankinstanzen in den verschiedenen Regionen des globalen Objekts sind konfiguriert, um auf das Steuerungsobjekt zuzugreifen, bevor sie mit irgendeiner Verwaltungsoperation an dem globalen Objekt fortfahren.
In einigen Ausführungsformen kann das gemeinsam genutzte Steuerungsobjekt 530 einfach ein Flag sein, das gesetzt ist, um anzuzeigen, dass eine Verwaltungsoperation aktuell ausstehend oder auf dem globalen Objekt ausgeführt wird. Es versteht sich, dass eine solche Operation einige Zeit in Anspruch nehmen kann, da sie eine Koordination über mehrere Standorte hinweg erfordert. In einigen Ausführungsformen kann, solange das „wird ausgeführt“-Flag gesetzt ist, keine andere Verwaltungsoperation an dem globalen Objekt beginnen.
In einigen Ausführungsformen kann das Steuerungsobjekt eine komplexere Datenstruktur sein, wie etwa ein Semaphor, eine Sperre, eine globale Warteschlange oder dergleichen. In einigen Ausführungsformen können beispielsweise eingehende Verwaltungsoperationen in einer FIFO-Reihenfolge (First In First Out) zu einer globalen Warteschlange hinzugefügt werden, um den Verwaltungsoperationen eine Reihenfolge aufzuerlegen. In einigen Ausführungsformen kann das gemeinsam genutzte Steuerungsobjekt 530 in einer Region des globalen Objekts gespeichert werden, die auch bestimmte „Master“-Metadaten über das globale Objekt speichern kann. In einigen Ausführungsformen kann sich der Standort des Steuerungsobjekts 530 an einem beliebigen Standort des globalen Objekts befinden oder im Laufe der Zeit periodisch rotieren.
In diesem Beispiel ist das Replikatobjekt 510 das erste, das eine Verwaltungsoperation an dem globalen Objekt auslöst. Als Reaktion darauf führt die Serialisierungskomponente 512 eine Prüfung 542 am Steuerungsobjekt 530 durch und bestimmt, dass es derzeit keine ausstehenden Verwaltungsoperationen am globalen Objekt gibt. Dementsprechend aktualisiert das Serialisierungsmodul 512 das Steuerungsobjekt 530, um anzuzeigen, dass es nun eine ausstehende Verwaltungsoperation gibt. Das Serialisierungsmodul 512 lässt dann zu, dass die Verwaltungsoperation fortfährt, 544, beispielsweise durch Aufrufen des globalen Verwaltungsoperationsmoduls 514, was bewirken kann, dass die Operation an alle anderen Replikatobjekte des globalen Objekts weitergegeben wird. In einigen Ausführungsformen kann, wie gezeigt, nachdem die globale Verwaltungsoperation abgeschlossen ist (entweder erfolgreich oder nicht erfolgreich), das Operationsserialisierungsmodul 512 das gemeinsam genutzte Steuerungsobjekt 530 freigeben oder das Steuerungsobjekt 530 aktualisieren, um anzuzeigen, dass jetzt keine Verwaltungsoperationen am globalen Objekt ausstehend sind.
Wie gezeigt, wird in diesem Beispiel, wenn die erste Verwaltungsoperation ausstehend ist, eine zweite Verwaltungsoperation von dem Replikatobjekt 522 der Region B eingeleitet. Wie bei der ersten Verwaltungsoperation kann die zweite Verwaltungsoperation zuerst das Operationsserialisierungsmodul 522 von Region B aufrufen, um zu prüfen, 546, ob es irgendwelche ausstehenden Verwaltungsoperationen gibt, die durch das Steuerungsobjekt 530 angezeigt werden. In diesem Fall trifft dies zu, da die ersten Verwaltungsvorgänge, die von dem Replikat der Region A stammen, gerade ausgeführt werden. Dementsprechend wird das Modul 522 basierend auf dem Serialisierungsprotokoll 540 veranlassen, dass seine eigene Verwaltungsoperation angehalten wird, 548. In einigen Ausführungsformen kann das Serialisierungsmodul 522 die Verwaltungsoperation einfach ablehnen und eine Nachricht an den Datenbankclienten generieren, um die Verwaltungsoperation später erneut zu versuchen. Dementsprechend gibt es keine zwei Verwaltungsoperationen, die gleichzeitig durch das globale Objekt verbreitet werden. In einigen Ausführungsformen kann sich das Replikatobjekt der Region B anmelden, um auf eine Freigabe des Steuerungsobjekts zu warten, so dass es sofort mit seiner Verwaltungsoperation fortfahren kann, wenn das Steuerungsobjekt freigegeben wird. In einigen Ausführungsformen kann das Serialisierungsmodul 522 periodisch beim Steuerungsobjekt nachfragen, beispielsweise zu zufälligen Zeiten, bis es feststellt, dass keine Verwaltungsaufträge ausstehend sind. An diesem Punkt kann das Replikatobjekt der Region B mit seiner globalen Verwaltungsoperation fortfahren, die über alle Regionen des globalen Objekts hinweg weitergegeben werden kann. Es versteht sich, dass, wenn die Datenbankinstanz in allen Regionen eines globalen Objekts dieses Serialisierungsprotokoll 540 implementiert, eine eindeutige Ordnung aller Verwaltungsoperationen an dem globalen Objekt erreicht werden kann.
6 ist ein Flussdiagramm, das einen Prozess zum Durchführen von Objektverwaltungsoperationen an einem Datenbankobjekt darstellt, das ein regionales Replikat eines globalen Objekts ist, gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann der dargestellte Prozess von einer oder mehreren Komponenten des Datenbanksystems (z. B. einer Datenbankinstanz 130 an Standort A) von 1 durchgeführt werden.
Der Prozess beginnt bei Operation 610, wo eine Anforderung zur Ausführung einer Verwaltungsoperation an einem Datenbankobjekt an einem ersten Standort empfangen wird. In einigen Ausführungsformen kann die Verwaltungsoperation die Operation 122 von 1 sein, die über die Datenbankobjektverwaltungsschnittstelle 132 von 1 empfangen werden kann. In einigen Ausführungsformen kann die angeforderte Verwaltungsoperation versuchen, eine Metadateneigenschaft eines Datenbankobjekts in dem Datenbanksystem zu modifizieren oder zu ändern. Beispielsweise kann das Datenbankobjekt eine Datenbanktabelle, ein Index usw. sein. In einigen Ausführungsformen kann die Verwaltungsoperation für ein regionales Objekt (z. B. eines, das nicht Teil eines globalen Objekts ist) oder ein regionales Replikatobjekt verwendet werden, das Teil eines globalen Objekts ist.
Bei Operation 620 wird bestimmt, ob das Datenbankobjekt ein regionales Replikatobjekt eines globalen Objekts ist. Wie erörtert, können in einigen Ausführungsformen bestimmte Verwaltungsoperationen überladen werden, um sowohl an regionalen als auch an globalen Objekten zu arbeiten. In einigen Ausführungsformen kann eine Komponente oder ein Modul in der Verwaltungsoperationshandhabungsroutine (z. B. das globale Objekterkennungsmodul 140 von 1) verwendet werden, um zu bestimmen, ob das Zielobjekt der Operation ein regionales Objekt oder ein Replikat eines globalen Objekts ist. Wenn das Zielobjekt kein Replikatobjekt in einem globalen Objekt ist (z. B. nur ein regionales Objekt), fährt der Prozess mit Operation 650 fort, wobei die Operation regional gehandhabt wird. Wenn das Zielobjekt ein Replikatobjekt ist, fährt der Prozess mit Operation 630 fort.
Bei Operation 630 wird eine weitere Bestimmung durchgeführt, um die Art der Metadateneigenschaft zu ermitteln, die durch die Verwaltungsoperation modifiziert wird. Wie erörtert, können bestimmte Arten von Verwaltungsoperationen Metadateneigenschaftsobjekte von Datenbankobjekten modifizieren, die in Kategorien oder Arten gruppiert werden können, wie etwa die in 3 gezeigten Arten 320, 330 und 340. Abhängig von der ermittelten Art der Metadateneigenschaft kann der Prozess wie gezeigt mit den Operationen 640, 650 oder 660 fortfahren.
Wenn bei Operation 640 die Metadateneigenschaft, die durch die Operation geändert wird, eine Eigenschaft ist, die für Replikatobjekte unveränderlich ist (z. B. Eigenschaft der Art 320 in 3), wird die Verwaltungsoperation abgelehnt. In einigen Ausführungsformen kann eine solche Metadateneigenschaft beispielsweise eine Einstellung zum Aktivieren oder Deaktivieren eines Aktualisierungsstroms des Datenbankobjekts sein, der für ein Replikatobjekt möglicherweise immer aktiviert sein muss. In einigen Ausführungsformen kann die Ablehnung der Operation von einer Fehlermeldung an den Clienten begleitet werden, die den Grund für die Ablehnung angibt (z. B. ist die geänderte Metadateneigenschaft für ein Replikatobjekt unveränderlich).
Wenn die Metadateneigenschaft, die durch die Operation geändert wird, bei Operation 650 eine Art von Eigenschaft ist, die über regionale Replikate eines globalen Objekts variiert werden kann (z. B. Eigenschaftsart 330 von 3), wird die Verwaltungsoperation an der Datenbank an dem ersten Standort ausgeführt, ohne die Operation an andere Standorte des globalen Objekts weiterzugeben. Das heißt, die Verwaltungsoperation wird nur regional durchgeführt, wodurch die Metadateneigenschaft in den Regionen unterschiedlich sein kann. In einigen Ausführungsformen kann diese Operation durch das regionale Operationshandhabungsmodul 134 ausgeführt werden, wie es in Verbindung mit 1 erörtert wurde.
Wenn bei Operation 660 die Metadateneigenschaft, die durch die Operation geändert wird, eine Art von Eigenschaft ist, die über regionale Replikate eines globalen Objekts einheitlich gehalten werden sollte (z. B. Eigenschaftsart 340 von 3), wird die Verwaltungsoperation nicht nur an dem Datenbankobjekt am ersten Standort ausgeführt, sondern auch an andere Standorte des globalen Objekts weitergegeben, um an anderen Replikatobjekten ausgeführt zu werden. In einigen Ausführungsformen kann diese Weitergabe verwendet werden, um diese Metadateneigenschaft über alle Regionen hinweg gleich zu halten. In einigen Ausführungsformen kann diese Operation durch das globale Operationskoordinationsmodul 150 von 1 oder gemäß dem in 4A oder 4B dargestellten Prozess ausgeführt werden.
Bei Operation 670, entweder nach Operation 650 oder 660, bestätigt das Datenbanksystem, dass die angeforderte Verwaltungsoperation ausgeführt wird. Wenn die Operation in einigen Ausführungsformen an andere Regionen des globalen Objekts gesendet wurde, kann das Datenbanksystem warten, bis die Operation in allen Regionen abgeschlossen ist, bevor es die Verwaltungsoperationsanforderung bestätigt. In einigen Ausführungsformen kann die Bestätigung gemäß den Spezifikationen der Datenbankobjektverwaltungsschnittstelle 132 als Antwort auf die Anforderung bereitgestellt werden.
7A und 7B sind Flussdiagramme, die zwei Prozesse zum Weitergeben von Objektverwaltungsoperationen an verschiedene Regionen eines globalen Objekts veranschaulichen, gemäß einigen Ausführungsformen. In einigen Ausführungsformen können die abgebildeten Prozesse von verschiedenen Datenbankinstanzen eines Datenbanksystems ausgeführt werden, wie in Verbindung mit den 1, 4A und 4B erörtert.
7A zeigt einen Prozess zum Weitergeben einer globalen Verwaltungsoperation an einem globalen Objekt unter Verwendung eines zweiphasigen Festschreibungsprotokolls. Bei Operation 710 beginnt der Prozess, indem in einer Vorbereitungsphase verifiziert wird, ob eine globale Verwaltungsoperation, die an Replikate eines globalen Objekts weitergegeben werden soll, an allen Replikaten ausgeführt werden kann, aber ohne die Operation tatsächlich auszuführen. In einigen Ausführungsformen kann die Vorbereitungsphase das Senden von Anweisungen oder Nachrichten an alle Regionen des globalen Objekts beinhalten, um zu prüfen, ob die globalen Verwaltungsoperationen überall erfolgreich ausgeführt werden können. In einigen Ausführungsformen kann eine andere Datenbankinstanz in den verschiedenen Regionen die Verifizierung durch Ausführen einer Vorbereitungsphasenoperation (z. B. Operation 422 von 4A) durchführen und an eine koordinierende Region zurückmelden, ob die Vorbereitungsphase erfolgreich war.
Bei Operation 720 wird bestimmt, ob die Verwaltungsoperation bei allen Replikaten in den verschiedenen Regionen des globalen Objekts verifiziert ist (z. B. erfolgreich ausgeführt werden kann). In einigen Ausführungsformen kann die Verifizierung durch die Datenbankinstanz durchgeführt werden, die die Verwaltungsoperation ausgelöst hat, beispielsweise unter Verwendung des Vorbereitungsphasenkoordinierungsmoduls 412 von 4A. In einigen Ausführungsformen kann das Vorbereitungsphasenkoordinierungsmodul 412 die Bestimmung basierend auf Bestätigungen vornehmen, die von den Datenbankinstanzen in den anderen Regionen empfangen werden.
Wenn bei Operation 730 die globale Verwaltungsoperation für alle Replikate verifiziert ist, wird eine Festschreibungsphase durchgeführt, in der die globale Verwaltungsoperation tatsächlich an allen Replikaten des globalen Objekts ausgeführt wird. In einigen Ausführungsformen kann diese Operation das Senden einer weiteren Runde von Anweisungen oder Nachrichten von der Koordinierungsdatenbankinstanz an die anderen Datenbankinstanzen in den anderen Regionen beinhalten, wodurch die anderen Datenbankinstanzen veranlasst werden, die Verwaltungsoperation auszuführen. In einigen Ausführungsformen wird die Verwaltungsoperation auch lokal in der Ursprungsregion ausgeführt. In einigen Ausführungsformen kann diese Operation in der Ursprungsregion durch ein Festschreibungsphasenkoordinatormodul oder eine Festschreibungsphasenkoordinatoroperation 414 koordiniert werden und in den anderen Regionen durch eine Festschreibungsphasenoperation oder ein Festschreibungsphasenmodul 424 ausgeführt werden, wie in 4A gezeigt. In einigen Ausführungsformen können die Datenbankinstanzen in den anderen Regionen eine weitere Bestätigung der Festschreibungsphase bereitstellen. Wenn alle diese zweiten Bestätigungen empfangen wurden, kann die koordinierende Datenbankinstanz dem anfordernden Clienten bestätigen, dass die Verwaltungsoperation erfolgreich ausgeführt wurde.
Wenn bei Operation 740 die globale Verwaltungsoperation nicht für alle Replikate verifiziert wurde, wird die globale Verwaltungsoperation abgelehnt. Somit wird die globale Operation in keinen Regionen des globalen Objekts durchgeführt, einschließlich des Ursprungsbereichs. In einigen Ausführungsformen kann die Ablehnung eine Antwortnachricht beinhalten, die den Grund für die Ablehnung angeben kann, beispielsweise das Identifizieren einer oder mehrerer Regionen, in denen die Verwaltungsoperation während der Vorbereitungsphase nicht verifiziert oder nicht erfolgreich durchgeführt werden kann.
7B zeigt einen Prozess zum Weitergeben einer globalen Verwaltungsoperation an einem globalen Objekt unter Verwendung eines optimistischen Aktualisierungsprotokolls. Bei Operation 750 beginnt der Prozess mit der optimistischen Weitergabe einer globalen Verwaltungsoperation an verschiedene Standorte eines globalen Objekts, die an den Replikatobjekten des globalen Objekts an diesen Standorten ausgeführt werden soll. Anders als bei dem Prozess in 7A gibt es keine Verifizierung, bevor die Verwaltungsoperation an den verschiedenen Standorten versucht wurde. In einigen Ausführungsformen kann diese Operation durch das optimistische Ausführungsmodul 442 von 4B ausgeführt und weitergegeben werden und in den anderen Regionen des globalen Objekts durch die optimistischen Ausführungsmodule 452 und 462 von 4B ausgeführt werden.
Bei Operation 760 wird bestimmt, ob alle Replikatobjekte des globalen Objekts die Verwaltungsoperation erfolgreich ausgeführt haben. In einigen Ausführungsformen kann diese Bestimmung durch die Datenbankinstanz in der koordinierenden Region und basierend auf Antworten oder Bestätigungen erfolgen, die von den Datenbankinstanzen in den anderen Regionen empfangen werden. In einigen Ausführungsformen wird eine positive Bestätigung verwendet, um anzuzeigen, dass die Operation in einer anderen Region erfolgreich ist. In einigen Ausführungsformen kann eine Fehlermeldung oder fehlende Antwort innerhalb eines bestimmten Zeitfensters anzeigen, dass die Operation in einer anderen Region nicht erfolgreich war. In einigen Ausführungsformen kann die Verwaltungsoperation, sogar bevor irgendwelche Bestätigungen von den anderen Regionen empfangen werden, lokal in der Ursprungsregion ausgeführt werden, wodurch eine Metadateneigenschaftsänderung in der Ursprungsregion wirksam wird.
Bei Operation 770 wird, wenn die globale Verwaltungsoperation an allen Replikaten erfolgreich ausgeführt wurde, eine Bestätigung an den anfordernden Clienten geliefert, dass die Verwaltungsoperation erfolgreich an dem globalen Objekt ausgeführt wurde. In einigen Ausführungsformen kann diese Bestätigung asynchron mit der Anforderung für die Verwaltungsoperation durchgeführt werden. Beispielsweise kann die Anforderung für die Verwaltungsoperation sofort ohne jegliche Bestätigung zurückgegeben werden und kann die Bestätigung der Verwaltungsoperation zu einem späteren Zeitpunkt bereitgestellt werden.
Wenn die globale Verwaltungsoperation bei Operation 780 nicht bei allen Replikaten erfolgreich ausgeführt wird, wird die Verwaltungsoperation abgelehnt. Außerdem wird ein Zurücksetzungsprozess initiiert, um die Verwaltungsoperation für das globale Objekt rückgängig zu machen. In einigen Ausführungsformen kann diese Operation über die Zurücksetzungskoordinierungsoperation oder das Zurücksetzungskoordinierungsmodul 444 und die Zurücksetzungsoperation oder das Zurücksetzungsmodul 464 ausgeführt werden, wie in Verbindung mit 4B erörtert. In einigen Ausführungsformen kann der Zurücksetzungsprozess bewirken, dass die Zurücksetzungsoperation an allen Replikatobjekten des globalen Objekts ausgeführt wird, die die Verwaltungsoperation erfolgreich ausgeführt haben. In einigen Ausführungsformen kann der Client am Ende des Zurücksetzungsprozesses über die fehlgeschlagene Anforderung benachrichtigt werden. In einigen Ausführungsformen kann der Client vor dem Abschluss des Zurücksetzungsprozesses benachrichtigt werden. In einigen Ausführungsformen kann die Benachrichtigung an den Client den Grund für das Fehlschlagen der Verwaltungsoperation angeben, beispielsweise um eine Region zu identifizieren, in der die Operation nicht erfolgreich ausgeführt werden kann.
8 ist ein Flussdiagramm, das einen Prozess zum Serialisieren globaler Verwaltungsoperationen an einem globalen Objekt veranschaulicht, gemäß einigen Ausführungsformen. In einigen Ausführungsformen können die abgebildeten Prozesse von verschiedenen Datenbankinstanzen eines Datenbanksystems ausgeführt werden, wie in Verbindung mit den 1 und 5 erörtert.
Bei Operation 810 wird bestimmt, dass eine Verwaltungsoperation an einem globalen Objekt an verschiedene Standorte des globalen Objekts weiterzugeben ist, um an verschiedenen Replikatobjekten an den verschiedenen Standorten ausgeführt zu werden. In einigen Ausführungsformen kann das globale Objekt das globale Objekt 170 von 1 sein. In einigen Ausführungsformen kann die Weitergabe durch das globale Operationskoordinierungsmodul 150 von 1 und unter Verwendung eines Protokolls durchgeführt werden, wie in 4A oder 4B beschrieben.
Bei Operation 820 wird eine Prüfung an einem Steuerungsobjekt durchgeführt, das von den Replikaten gemeinsam genutzt wird, um zu bestimmen, ob es eine andere gegenwärtig ausstehende Verwaltungsoperation an dem globalen Objekt gibt. In einigen Ausführungsformen kann das Steuerungsobjekt das gemeinsam genutzte Steuerungsobjekt 530 von 5 sein. Je nach Ausführungsform kann das gemeinsam genutzte Steuerungsobjekt als Flag, Sperre, Tabelle, Warteschlange oder dergleichen implementiert werden. In einigen Ausführungsformen kann das gemeinsam genutzte Steuerungsobjekt an einem Standort des globalen Objekts verwaltet werden, aber für Datenbankinstanzen von anderen Standorten aus zugänglich sein. Es versteht sich, dass bestimmte globale Verwaltungsoperationen einige Zeit in Anspruch nehmen können, bis sie abgeschlossen sind, und das Steuerungsobjekt kann anzeigen, dass derzeit eine andere globale Verwaltungsoperation ausstehend ist. Diese Anzeige ermöglicht, dass andere globale Verwaltungsoperationen angehalten oder abgelehnt werden, um eine Überschneidung zwischen der Weitergabe von zwei Verwaltungsoperationen zu verhindern. Wenn bei Vorgang 830 eine weitere ausstehende Verwaltungsoperation bestimmt wird, fährt der Prozess mit Operation 840 fort. Wenn nicht, geht der Prozess zu Operation 850 weiter.
Bei Operation 840 wird die eingehende oder neue Verwaltungsoperation abgelehnt oder angehalten, basierend auf der Bestimmung, dass eine andere Verwaltungsoperation ausstehend ist. In einigen Ausführungsformen kann die Datenbankinstanz nach einer Pause beispielsweise unter Verwendung des Operationsserialisierungsmoduls 522 von 5 das Steuerungsobjekt (z. B. das Steuerungsobjekt 530) periodisch erneut überprüfen, 820, um zu bestimmen, ob die andere Verwaltungsoperation noch ausstehend ist. In einigen Ausführungsformen kann die Überprüfung für eine bestimmte Zeit oder eine bestimmte Anzahl von Wiederholungsversuchen fortgesetzt werden, bevor die Verwaltungsoperation abgebrochen wird. In einigen Ausführungsformen können die Wiederholungsversuche nach einer zufälligen Zeitspanne durchgeführt werden.
Wenn bei Operation 850 keine ausstehenden Verwaltungsoperationen gemäß dem Steuerungsobj ekt vorhanden sind, wird das Steuerungsobjekt aktualisiert, um anzuzeigen, dass die neue Verwaltungsoperation nun ausstehend ist. In einigen Ausführungsformen bewirkt diese Angabe, dass alle nachfolgenden Verwaltungsoperationen gemäß dem Serialisierungsprotokoll abgelehnt oder blockiert werden. In einigen Ausführungsformen kann die Aktualisierung des Steuerungsobjekts als eine einzelne atomarische Operation durchgeführt werden, so dass sie nicht gleichzeitig von zwei verschiedenen Akteuren ausgeführt werden kann. Abhängig von der Ausführungsform kann die Aktualisierungsoperation das Umschalten eines Flags, das Erlangen einer Sperre, das Schreiben eines Tabelleneintrags oder das Hinzufügen der Verwaltungsoperation zu einer Warteschlange beinhalten.
Bei Operation 860 wird die Verwaltungsoperation tatsächlich ausgeführt. Wie erörtert, kann die Ausführung der Operation in einigen Ausführungsformen das Weitergeben der Operation an mehrere entfernt gelegene Regionen beinhalten, die an Replikatobjekten in diesen Regionen durchgeführt werden soll. In einigen Ausführungsformen kann die Weitergabe auf eine Weise durchgeführt werden, wie in Verbindung mit 4A oder 4B beschrieben. In einigen Ausführungsformen wird die Ausführung der Verwaltungsoperation entweder basierend auf einem Erfolg oder Fehlschlagen der Operation an dem globalen Objekt abgeschlossen. In einigen Ausführungsformen wird es nach Abschluss der Verwaltungsoperation keine weiteren Versuche geben, die Metadateneigenschaften von Replikatobjekten des globalen Objekts zu aktualisieren.
Bei Operation 870 wird das Steuerungsobjekt erneut aktualisiert, um anzuzeigen, dass die Verwaltungsoperation nicht mehr ausstehend ist. In einigen Ausführungsformen kann diese zweite Aktualisierung gemäß dem Serialisierungsprotokoll zulassen, dass nachfolgende Verwaltungsoperationen fortgesetzt werden. In einigen Ausführungsformen kann die Aktualisierung eine Aktivierungsbenachrichtigung auslösen, die an andere wartende Datenbankinstanzen mit angehaltenen Verwaltungsoperationen gesendet wird, so dass sie sich an einem Prozess beteiligen können, um die nächste fortzusetzende Verwaltungsoperation zu bestimmen. Abhängig von der Ausführungsform kann die Aktualisierung des Steuerungsobjekts das Umschalten eines Flags, das Freigeben einer Sperre, das Löschen oder Aktualisieren eines Tabelleneintrags oder das Herausnehmen der Verwaltungsoperation aus einer Warteschlange beinhalten.
9 ist ein Blockdiagramm, das ein beispielhaftes Rechnersystem veranschaulicht, das verwendet werden kann, um einen oder mehrere Teile eines Datenbanksystems zu implementieren, das globale Objektverwaltungsoperationen implementiert, um die Metadateneigenschaften von regionalen Replikatobjekten eines globalen Objekts einheitlich zu verwalten, gemäß einigen Ausführungsformen. Das Rechnersystem 900 kann ein oder mehrere nichtflüchtige computerzugängliche Medien enthalten oder dafür konfiguriert sein, auf diese zuzugreifen. In der veranschaulichten Ausführungsform beinhaltet das Rechnersystem 900 einen oder mehrere Prozessoren 910, die über eine Eingabe/Ausgabe-Schnittstelle 930 (E/A-Schnittstelle) mit einem Systemspeicher 920 gekoppelt sind. Das Rechnersystem 900 beinhaltet ferner eine Netzwerkschnittstelle 940, die mit der I/O-Schnittstelle 930 gekoppelt ist.
In verschiedenen Ausführungsformen kann das Rechnersystem 900 ein einen Prozessor 910 beinhaltendes Einprozessorsystem oder ein mehrere (z. B. zwei, vier, acht oder eine andere geeignete Zahl) Prozessoren 910 beinhaltendes Multiprozessorsystem sein. Prozessoren 910 können beliebige geeignete Prozessoren sein, die zum Ausführen von Anweisungen befähigt sind. Beispielsweise können in verschiedenen Ausführungsformen Prozessoren 910 Allzweck- oder eingebettete Prozessoren sein, die eine aus einer Reihe von Befehlssatzarchitekturen (ISAs - instruction set architectures), wie die x86-, PowerPC-, SPARC- oder MIPS-ISAs oder jede andere geeignete ISA implementieren. In Multiprozessorsystemen kann jeder der Prozessoren 910 üblicherweise, aber nicht notwendigerweise dieselbe ISA implementieren.
Systemspeicher 920 kann dazu konfiguriert sein, Anweisungen und Daten zu speichern, auf die der / die Prozessor(en) 910 zugreifen kann / können. In verschiedenen Ausführungsformen kann der Systemspeicher 920 unter Verwendung einer beliebigen geeigneten Speichertechnologie wie eines statischen Direktzugriffsspeichers (SRAM - Static Random Access Memory), eines synchronen dynamischen RAMs (SDRAM - Synchronous Dynamic RAM), eines nichtflüchtigen Speichers/Flash-Speichers oder eines anderen Speichertyps implementiert sein. In der veranschaulichten Ausführungsform sind Programmanweisungen und Daten, die eine oder mehrere gewünschte Funktionen implementieren, wie die zuvor beschriebenen Verfahren, Techniken und Daten, im Systemspeicher 920 als Code 925 und Daten 935 gespeichert. In einigen Ausführungsformen kann der Code 925 Code oder Anweisungen beinhalten, um verschiedene Module des Datenbanksystems zu implementieren, wie z. B. das globale Verwaltungsoperationshandhabungsmodul 142 von 1. In einigen Ausführungsformen können die Daten 935 Daten beinhalten, die von dem Datenbanksystem verwaltet werden, wie etwa die Replikatobjektmetadateneigenschaften 310 von 3.
In einer Ausführungsform kann die E/A-Schnittstelle 930 dazu konfiguriert sein, den E/A-Verkehr zwischen dem Prozessor 910, dem Systemspeicher 920 und Peripherievorrichtungen in der Vorrichtung einschließlich der Netzwerkschnittstelle 940 oder anderer Peripherieschnittstellen zu koordinieren. In einigen Ausführungsformen kann die E/A-Schnittstelle 930 jegliche erforderliche Protokoll-, Zeitsteuerungs- oder andere Datentransformation durchführen, um Datensignale von einer Komponente (z. B. Systemspeicher 920) in ein Format umzuwandeln, das zur Verwendung durch eine andere Komponente (z. B. Prozessor 910) geeignet ist. In einigen Ausführungsformen kann die E/A-Schnittstelle 930 die Unterstützung von Geräten umfassen, die über verschiedene Arten von Peripheriebussen wie einer Variante des PCI-Busstandards (PCI - Peripheral Component Interconnect) oder des USB-Standards (USB - Universal Serial Bus) angeschlossen sind. In einigen Ausführungsformen kann die Funktion der E/A-Schnittstelle 930 beispielsweise auf zwei oder mehr separate Komponenten wie eine Northbridge und eine Southbridge aufgeteilt sein. In einigen Ausführungsformen kann auch ein Teil oder die gesamte Funktionalität der E/A-Schnittstelle 930 wie einer Schnittstelle zum Systemspeicher 920 direkt in den Prozessor 910 integriert sein.
Die Netzwerkschnittstelle 940 kann konfiguriert sein, um zu ermöglichen, dass Daten zwischen dem Rechnersystem 900 und anderen Vorrichtungen 960 ausgetauscht werden, die an ein Netzwerk oder Netzwerke 950 angeschlossen sind, wie etwa andere Rechnersysteme oder Vorrichtungen, wie etwa Router und andere Computergeräte, wie z. B. in 1 bis 8f veranschaulicht. In verschiedenen Ausführungsformen kann die Netzwerkschnittstelle 940 die Kommunikation über beliebige geeignete drahtgebundene oder drahtlose allgemeine Datennetzwerke, wie etwa Arten von Ethernet-Netzwerken, unterstützen. Ferner kann die Netzwerkschnittstelle 940 beispielsweise die Kommunikation über Telekommunikations-/ Telefonnetze, wie etwa analoge Sprachnetzwerke oder digitale Glasfaserkommunikationsnetze, über Speichernetzwerke wie Fibre-Channel-SAN oder über einen anderen geeigneten Netzwerk- und/oder Protokolltyp unterstützen.
In einigen Ausführungsformen kann der Systemspeicher 920 eine Ausführungsform eines computerzugänglichen Mediums sein, das so konfiguriert ist, dass es Programmanweisungen und Daten speichert, wie oben für 1 bis 8 zum Implementieren von Ausführungsformen von Verfahren und Geräten zur Verkehrsanalyse beschrieben. In anderen Ausführungsformen können jedoch Programmanweisungen und/oder Daten auf anderen Arten von computerzugänglichen Medien empfangen, gesendet oder gespeichert werden. Allgemein gesagt kann ein computerzugängliches Medium nichtflüchtige Speichermedien oder Speichermedien wie magnetische oder optische Medien beinhalten, z. B. eine Platte oder DVD/CD, die über die E/A-Schnittstelle 930 mit dem Rechnersystem 900 gekoppelt sind. Ein nichtflüchtiges computerzugängliches Speichermedium kann auch beliebige flüchtige oder nichtflüchtige Medien wie RAM (z. B. SDRAM, DDR-SDRAM, RDRAM, SRAM usw.), ROM usw. beinhalten, die in einigen Ausführungsformen des Rechnersystems 900 als Systemspeicher 920 oder eine andere Art von Speicher integriert sein können. Ferner kann ein computerzugängliches Medium Übertragungsmedien oder Signale wie etwa elektrische, elektromagnetische oder digitale Signale beinhalten, die über ein Kommunikationsmedium wie etwa ein Netzwerk und/oder eine drahtlose Verbindung übermittelt werden, wie sie etwa über die Netzwerkschnittstelle 940 implementiert werden kann.
Ausführungsformen der vorliegenden Offenbarung können hinsichtlich der folgenden Klauseln beschrieben werden:

1. Ein System, umfassend:
- einen oder mehrere Hardwareprozessoren mit zugeordnetem Speicher, die ein Datenbanksystem implementieren, für Folgendes konfiguriert:
  - Empfangen einer Anforderung zum Ausführen einer Verwaltungsoperation an einem Datenbankobjekt an einem ersten Standort;
  - Bestimmen, dass das Datenbankobjekt ein Replikat in einer Gruppe von Replikaten ist, die als Teil eines globalen Objekts verwaltet werden, wobei sich einzelne der Replikate an unterschiedlichen Standorten befinden und Änderungen an einem Replikat des globalen Objekts an eine oder mehrere andere der verschiedenen Standorte übertragen und über alle Replikate des globalen Objekts hinweg repliziert werden;
  - Bestimmen, dass die Verwaltungsoperation eine Modifikation an einer Metadateneigenschaft des Datenbankobjekts angibt, die über alle Replikate des globalen Objekts hinweg einheitlich gehalten werden soll;
  - Senden der Verwaltungsoperation von dem ersten Standort an einen oder mehrere andere der verschiedenen Standorte, um die Verwaltungsoperation an einem oder mehreren anderen Replikaten des globalen Objekts auszuführen;
  - Ausführen der Verwaltungsoperation an dem Datenbankobjekt am ersten Standort; und
  - Bestätigen, dass die Verwaltungsoperation an dem globalen Objekt ausgeführt wurde.
2. Das System nach Klausel 1, wobei:
- das Datenbankobjekt eine Tabelle ist, die zumindest einen Teil ihrer Daten in ein Indexobjekt projiziert, das zum Abfragen des Datenteils verwendet wird; und
- die Verwaltungsoperation einen Attributdatentyp des Indexobjekts modifiziert.
3. Das System nach einer der Klauseln 1 oder 2, wobei:
- dem Datenbankobjekt oder einem dem Datenbankobjekt zugeordneten Indexobjekt eine Schreibdurchsatzgrenze für eine Anzahl von Schreiboperationen über einen Zeitraum zugeordnet ist; und
- die Verwaltungsoperation die Schreibdurchsatzgrenze modifiziert.
4. Das System nach Klausel 3, wobei das Datenbanksystem für Folgendes konfiguriert ist:
- Verifizieren, dass die Schreibdurchsatzgrenze für alle Replikate des globalen Objekts erfolgreich modifiziert werden kann, vor dem Ausführen der Verwaltungsoperation an einer oder mehreren anderen Replikaten; und
- wobei das Verifizieren eine Vorbedingung ist, um die Verwaltungsoperation an dem einen oder den mehreren anderen Replikaten auszuführen.
5. Das System nach einer der Klauseln 1 bis 4, wobei das Datenbanksystem konfiguriert ist, um eine Serialisierung von Verwaltungsoperationen auf dem globalen Objekt umzusetzen, um:
- vor dem Ausführen der Verwaltungsoperation an dem Datenbankobjekt oder dem einen oder den mehreren anderen Replikaten:
  - Prüfen eines Steuerungsobjekts, um festzustellen, dass keine anderen Verwaltungsoperationen für das globale Objekt ausstehend sind; und
  - Aktualisieren des Steuerungsobjekts, um anzuzeigen, dass die Verwaltungsoperation ausstehend ist; und
- im Anschluss an das Ausführen der Verwaltungsoperation an dem Datenbankobjekt und dem einen oder den mehreren anderen Replikaten:
  - Aktualisieren des Steuerungsobjekts, um anzuzeigen, dass die Verwaltungsoperation nicht mehr ausstehend ist.
6. Ein Verfahren, umfassend:
- Durchführen durch einen oder mehrere Hardwareprozessoren mit zugehörigem Speicher unter Implementierung eines Datenbanksystems:
  - Empfangen einer Anforderung zum Ausführen einer Verwaltungsoperation an einem Datenbankobjekt an einem ersten Standort;
  - Bestimmen, dass das Datenbankobjekt ein Replikat in einer Gruppe von Replikaten ist, die als Teil eines globalen Objekts verwaltet werden, wobei sich einzelne der Replikate an unterschiedlichen Standorten befinden;
  - Bestimmen, dass die Verwaltungsoperation eine Modifikation an einer Metadateneigenschaft des Datenbankobjekts angibt, die über alle Replikate des globalen Objekts hinweg einheitlich gehalten werden soll;
  - Senden der Verwaltungsoperation von dem ersten Standort an einen oder mehrere andere der verschiedenen Standorte, um die Verwaltungsoperation an einem oder mehreren anderen Replikaten des globalen Objekts auszuführen;
  - Ausführen der Verwaltungsoperation an dem Datenbankobjekt am ersten Standort; und
  - Bestätigen, dass die Verwaltungsoperation an dem globalen Objekt ausgeführt wurde.
7. Das Verfahren nach Klausel 6, wobei:
- das Datenbankobjekt eine Tabelle ist, die zumindest einen Teil ihrer Daten in ein Indexobjekt projiziert, das zum Abfragen des Datenteils verwendet wird; und
- die Verwaltungsoperation einen Attributdatentyp des Indexobjekts modifiziert.
8. Das Verfahren nach einer der Klauseln 6 oder 7, wobei:
- dem Datenbankobjekt oder einem dem Datenbankobjekt zugeordneten Indexobjekt eine Schreibdurchsatzgrenze für eine Anzahl von Schreiboperationen über einen Zeitraum zugeordnet ist; und
- die Verwaltungsoperation die Schreibdurchsatzgrenze modifiziert.
9. Das Verfahren nach einer der Klauseln 6 bis 8, wobei:
- dem Datenbankobjekt eine Time-to-live-Eigenschaft zugeordnet ist, die angibt, wie lange Datenelemente im Datenbankobjekt aufbewahrt werden sollen, bevor sie gelöscht werden; und
- die Verwaltungsoperation die Time-to-live-Eigenschaft modifiziert.
10. Das Verfahren nach einer der Klauseln 6 bis 9, das ferner unter Durchführung durch das Datenbanksystem umfasst:
- Empfangen einer weiteren Anforderung zum Ausführen einer weiteren Verwaltungsoperation an dem Datenbankobjekt;
- Bestimmen, dass die andere Verwaltungsoperation keine Modifikation an einer Metadateneigenschaft des Datenbankobjekts angibt, die über alle Replikate des globalen Objekts hinweg einheitlich gehalten werden soll;
- Ausführen der anderen Verwaltungsoperation an dem Datenbankobjekt; und Bestätigen, dass die andere Verwaltungsoperation an dem globalen Objekt ausgeführt wurde, ohne die andere Verwaltungsoperation an einen oder mehrere andere der verschiedenen Standorte zu senden.
11. Das Verfahren nach Klausel 10, wobei die andere Verwaltungsoperation eines oder mehrere beinhaltet aus:
- einer Modifikation einer Lesedurchsatzgrenze für eine Menge von Leseoperationen, die über einen Zeitraum an das Datenbankobjekt gerichtet sind;
- einer Modifikation eines Clienten verwalteten Verschlüsselungsschlüssels, der verwendet wird, um Daten in dem Datenobjekt zu verschlüsseln;
- einer Trennung des Datenbankobjekts von dem globalen Objekt; und einer Löschung des Datenbankobjekts, aber nicht der einen oder mehreren anderen Replikate des globalen Objekts.
12. Das Verfahren nach einer der Klauseln 6 bis 9, weiterhin umfassend Durchführung durch das Datenbanksystem:
- Empfangen einer weiteren Anforderung zum Ausführen einer weiteren Verwaltungsoperation an dem Datenbankobjekt, wobei die andere Anforderung angibt, einen Aktualisierungsstrom zu stoppen, der von dem Datenbankobjekt erzeugt wird, und der Aktualisierungsstrom verwendet wird, um Änderungen am Datenbankobjekt an die eine oder mehreren anderen Replikate des globalen Objekts zu übertragen; und
- Ablehnen der anderen Verwaltungsoperation und Bereitstellen einer Nachricht, die anzeigt, dass der Aktualisierungsstrom für das globale Objekt nicht gestoppt werden kann.
13. Das Verfahren nach einer der Klauseln 6 bis 12, weiterhin umfassend Durchführung durch das Datenbanksystem:
- Verifizieren in einer Vorbereitungsphase und vor dem Ausführen der Verwaltungsoperation an einem oder mehreren anderen Replikaten, dass die Metadateneigenschaft für alle Replikate des globalen Objekts erfolgreich modifiziert werden kann; und
- wobei das Verifizieren eine Vorbedingung ist, um die Verwaltungsoperation an dem einen oder den mehreren anderen Replikaten auszuführen.
14. Das Verfahren nach einer der Klauseln 6 bis 13, weiterhin umfassend Durchführung durch das Datenbanksystem:
- Empfangen einer Nachricht, dass die Verwaltungsoperation an mindestens einem Replikat des globalen Objekts nicht erfolgreich ausgeführt wurde; und
- als Reaktion auf die Nachricht Initiieren einer Zurücksetzungsoperation, um die Verwaltungsoperation an dem globalen Objekt rückgängig zu machen.
15. Das Verfahren nach einer der Klauseln 6 bis 14, weiterhin umfassend Durchführung durch das Datenbanksystem:
- vor dem Ausführen der Verwaltungsoperation an dem Datenbankobjekt oder dem einen oder den mehreren anderen Replikaten:
  - Prüfen eines Steuerungsobjekts, um zu bestimmen, dass keine anderen ausstehenden Verwaltungsoperationen für das globale Objekt vorhanden sind, wobei das Erkennen von ausstehenden Verwaltungsoperationen an dem globalen Objekt bewirkt, dass die Verwaltungsoperationen abgelehnt oder angehalten werden; und
  - Aktualisieren des Steuerungsobjekts, um anzuzeigen, dass die Verwaltungsoperation ausstehend ist; und
- im Anschluss an das Ausführen der Verwaltungsoperation an dem Datenbankobjekt und dem einen oder den mehreren anderen Replikaten:
  - Aktualisieren des Steuerungsobjekts, um anzuzeigen, dass die Verwaltungsoperation nicht mehr ausstehend ist.
16. Das Verfahren nach einer der Klauseln 6 bis 15, wobei die Verwaltungsoperation eine überladene Operation ist, die an die anderen Standorte weitergegeben wird, wenn sie an ein Replikat eines globalen Objekts gerichtet ist, aber nicht an die anderen Standorte weitergegeben wird, wenn sie an ein regionales Objekt gerichtet ist, das nicht Teil eines globalen Objekts ist.
17. Ein oder mehrere nichtflüchtige computerzugängliche Speichermedien, die Programmanweisungen speichern, die bei Ausführung auf einem oder mehreren Prozessoren eines Datenbanksystems oder über diese das Datenbanksystem veranlassen zum:
- Empfangen einer Anforderung zum Ausführen einer Verwaltungsoperation an einem Datenbankobjekt an einem ersten Standort;
- Bestimmen, dass das Datenbankobjekt ein Replikat in einer Gruppe von Replikaten ist, die als Teil eines globalen Objekts verwaltet werden, wobei sich einzelne der Replikate an unterschiedlichen Standorten befinden;
- Bestimmen, dass die Verwaltungsoperation eine Modifikation an einer Metadateneigenschaft des Datenbankobjekts angibt, die über alle Replikate des globalen Objekts hinweg einheitlich gehalten werden soll;
- Senden der Verwaltungsoperation von dem ersten Standort an einen oder mehrere andere der verschiedenen Standorte, um die Verwaltungsoperation an einem oder mehreren anderen Replikaten des globalen Objekts auszuführen;
- Ausführen der Verwaltungsoperation an dem Datenbankobjekt am ersten Standort; und
- Bestätigen, dass die Verwaltungsoperation an dem globalen Objekt ausgeführt wurde.
18. Ein oder mehrere nichtflüchtige computerzugängliche Speichermedien nach Klausel 17, wobei:
- dem Datenbankobjekt oder einem dem Datenbankobjekt zugeordneten Indexobjekt eine Schreibdurchsatzgrenze für eine Anzahl von Schreiboperationen über einen Zeitraum zugeordnet ist; und
- um zu bestimmen, dass die Verwaltungsoperation eine Modifikation an einer Metadateneigenschaft des Datenbankobjekts angibt, die über alle Replikate des globalen Objekts hinweg einheitlich gehalten werden soll, die Programmanweisungen, wenn sie auf dem einen oder den mehreren Prozessoren oder über diese ausgeführt werden, das Datenbanksystem veranlassen, zu bestimmen, dass die Verwaltungsoperation eine Modifikation der Schreibdurchsatzgrenze angibt.
19. Das eine oder die mehreren nichtflüchtige(n) computerzugängliche(n) Speichermedium / Speichermedien nach einer der Klauseln 17 oder 18, wobei die Programmanweisungen, wenn sie auf dem einen oder den mehreren Prozessoren oder über diese ausgeführt werden, das Datenbanksystem veranlassen zum:
- Bestimmen, dass die Verwaltungsoperation an mindestens einem Replikat des globalen Objekts nicht erfolgreich ausgeführt wurde; und
- als Reaktion auf die Bestimmung, dass die Verwaltungsoperation nicht erfolgreich ausgeführt wurde, Initiieren einer Zurücksetzungsoperation, um die Verwaltungsoperation an dem globalen Objekt rückgängig zu machen.
20. Das eine oder die mehreren nichtflüchtige(n) computerzugängliche(n) Speichermdium / Speichermedien nach einer der Klauseln 17 bis 19, wobei:
- dem Datenbankobjekt eine Time-to-live-Eigenschaft zugeordnet ist, die angibt, wie lange Datenelemente im Datenbankobjekt aufbewahrt werden sollen, bevor sie gelöscht werden; und
- um zu bestimmen, dass die Verwaltungsoperation eine Modifikation an einer Metadateneigenschaft des Datenbankobjekts angibt, die über alle Replikate des globalen Objekts hinweg einheitlich gehalten werden soll, die Programmanweisungen, wenn sie auf dem einen oder den mehreren Prozessoren oder über diese ausgeführt werden, das Datenbanksystem veranlassen, zu bestimmen, dass die Verwaltungsoperation eine Modifikation der Time-to-live-Eigenschaft angibt.

Obwohl vorstehend spezifische Ausführungsformen beschrieben wurden, sollen diese Ausführungsformen den Umfang der vorliegenden Offenbarung nicht einschränken, selbst wenn nur eine einzige Ausführungsform in Bezug auf ein bestimmtes Merkmal beschrieben wird. Beispiele für Merkmale, die in der Offenbarung bereitgestellt werden, sollen veranschaulichend und nicht einschränkend sein, sofern nicht anders angegeben. Der Umfang der vorliegenden Offenbarung beinhaltet jedes Merkmal oder jede Kombination von Merkmalen, die hierin offenbart sind (entweder explizit oder implizit), oder jede Verallgemeinerung davon, unabhängig davon, ob sie einige oder alle der hierin angesprochenen Probleme mindert oder nicht. Dementsprechend können während der Weiterverfolgung dieser Anmeldung (oder einer Anmeldung, die deren Priorität beansprucht) neue Ansprüche auf eine solche Kombination von Merkmalen formuliert werden. Unter Bezugnahme auf die beigefügten Ansprüche können insbesondere Merkmale von abhängigen Ansprüchen mit denen der unabhängigen Ansprüche kombiniert werden, und Merkmale von jeweiligen unabhängigen Ansprüchen können auf jede geeignete Weise und nicht nur in den in den beigefügten Ansprüchen aufgezählten spezifischen Kombinationen kombiniert werden.
Die hierin beschriebenen Verfahren können in verschiedenen Ausführungsformen in Software, Hardware oder einer Kombination davon implementiert werden. Außerdem kann die Reihenfolge der Blöcke der Verfahren geändert werden und verschiedene Elemente können hinzugefügt, neu geordnet, kombiniert, weggelassen, modifiziert usw. werden. Verschiedene Modifikationen und Änderungen können vorgenommen werden, wie für den Fachmann angesichts dieser Offenbarung offensichtlich. Die hierin beschriebenen verschiedenen Ausführungsformen sollen veranschaulichend und nicht einschränkend sein. Viele Variationen, Modifikationen, Ergänzungen und Verbesserungen sind möglich. Dementsprechend können mehrere Instanzen für hier als eine einzelne Instanz beschriebene Komponenten bereitgestellt werden. Grenzen zwischen verschiedenen Komponenten, Operationen und Datenspeichern sind willkürlich, und bestimmte Operationen sind im Zusammenhang mit spezifischen veranschaulichenden Konfigurationen veranschaulicht. Andere Funktionszuordnungen sind vorgesehen und können in den Umfang der folgenden Ansprüche fallen. Schließlich können Strukturen und Funktionalitäten, die in den beispielhaften Konfigurationen als diskrete Komponenten präsentiert werden, als eine kombinierte Struktur oder Komponente implementiert werden. Diese und andere Variationen, Modifikationen, Ergänzungen und Verbesserungen können in den Umfang der Ausführungsformen fallen, wie sie in den folgenden Ansprüchen definiert sind.

Claims

Ein System, umfassend: einen oder mehrere Hardwareprozessoren mit zugeordnetem Speicher, die ein Datenbanksystem implementieren, konfiguriert für: Empfangen einer Anforderung zum Ausführen einer Verwaltungsoperation an einem Datenbankobjekt an einem ersten Standort; Bestimmen, dass das Datenbankobjekt ein Replikat in einer Gruppe von Replikaten ist, die als Teil eines globalen Objekts verwaltet werden, wobei sich einzelne der Replikate an unterschiedlichen Standorten befinden und Änderungen an einem Replikat des globalen Objekts an eine oder mehrere andere der verschiedenen Standorte übertragen und über alle Replikate des globalen Objekts hinweg repliziert werden; Bestimmen, dass die Verwaltungsoperation eine Modifikation an einer Metadateneigenschaft des Datenbankobjekts angibt, die über alle Replikate des globalen Objekts hinweg einheitlich gehalten werden soll; Senden der Verwaltungsoperation von dem ersten Standort an einen oder mehrere andere der verschiedenen Standorte, um die Verwaltungsoperation an einem oder mehreren anderen Replikaten des globalen Objekts auszuführen; Ausführen der Verwaltungsoperation an dem Datenbankobjekt am ersten Standort; und Bestätigen, dass die Verwaltungsoperation an dem globalen Objekt ausgeführt wurde.
Das System nach Anspruch 1, wobei: das Datenbankobjekt eine Tabelle ist, die zumindest einen Teil ihrer Daten in ein Indexobjekt projiziert, das zum Abfragen des Datenteils verwendet wird; und die Verwaltungsoperation einen Attributdatentyp des Indexobjekts modifiziert.
Das System nach Anspruch 1, wobei: dem Datenbankobjekt oder einem dem Datenbankobjekt zugeordneten Indexobjekt eine Schreibdurchsatzgrenze für eine Anzahl von Schreiboperationen über einen Zeitraum zugeordnet ist; und die Verwaltungsoperation die Schreibdurchsatzgrenze modifiziert.
Das System nach Anspruch 3, wobei das Datenbanksystem konfiguriert ist zum: Verifizieren, dass die Schreibdurchsatzgrenze für alle Replikate des globalen Objekts erfolgreich modifiziert werden kann, vor dem Ausführen der Verwaltungsoperation an einer oder mehreren anderen Replikaten; und wobei das Verifizieren eine Vorbedingung ist, um die Verwaltungsoperation an dem einen oder den mehreren anderen Replikaten auszuführen.
Das System nach Anspruch 1, wobei das Datenbanksystem konfiguriert ist, um eine Serialisierung von Verwaltungsoperationen auf dem globalen Objekt umzusetzen, zum: vor dem Ausführen der Verwaltungsoperation an dem Datenbankobjekt oder dem einen oder den mehreren anderen Replikaten: Prüfen eines Steuerungsobjekts, um festzustellen, dass keine anderen Verwaltungsoperationen für das globale Objekt ausstehend sind; und Aktualisieren des Steuerungsobjekts, um anzuzeigen, dass die Verwaltungsoperation ausstehend ist; und im Anschluss an das Ausführen der Verwaltungsoperation an dem Datenbankobjekt und dem einen oder den mehreren anderen Replikaten: Aktualisieren des Steuerungsobjekts, um anzuzeigen, dass die Verwaltungsoperation nicht mehr ausstehend ist.
Das Verfahren, umfassend: Durchführen durch einen oder mehrere Hardwareprozessoren mit zugehörigem Speicher unter Implementierung eines Datenbanksystems: Empfangen einer Anforderung zum Ausführen einer Verwaltungsoperation an einem Datenbankobjekt an einem ersten Standort; Bestimmen, dass das Datenbankobjekt ein Replikat in einer Gruppe von Replikaten ist, die als Teil eines globalen Objekts verwaltet werden, wobei sich einzelne der Replikate an unterschiedlichen Standorten befinden; Bestimmen, dass die Verwaltungsoperation eine Modifikation an einer Metadateneigenschaft des Datenbankobjekts angibt, die über alle Replikate des globalen Objekts hinweg einheitlich gehalten werden soll; Senden der Verwaltungsoperation von dem ersten Standort an einen oder mehrere andere der verschiedenen Standorte, um die Verwaltungsoperation an einem oder mehreren anderen Replikaten des globalen Objekts auszuführen; Ausführen der Verwaltungsoperation an dem Datenbankobjekt am ersten Standort; und Bestätigen, dass die Verwaltungsoperation an dem globalen Objekt ausgeführt wurde.
Das Verfahren nach Anspruch 6, wobei: das Datenbankobjekt eine Tabelle ist, die zumindest einen Teil ihrer Daten in ein Indexobjekt projiziert, das zum Abfragen des Datenteils verwendet wird; und die Verwaltungsoperation einen Attributdatentyp des Indexobjekts modifiziert.
Das Verfahren nach Anspruch 6, wobei: dem Datenbankobjekt oder einem dem Datenbankobjekt zugeordneten Indexobjekt eine Schreibdurchsatzgrenze für eine Anzahl von Schreiboperationen über einen Zeitraum zugeordnet ist; und die Verwaltungsoperation die Schreibdurchsatzgrenze modifiziert.
Das Verfahren nach Anspruch 6, weiterhin unter Durchführung durch das Datenbanksystem umfassend: Empfangen einer weiteren Anforderung zum Ausführen einer weiteren Verwaltungsoperation an dem Datenbankobjekt; Bestimmen, dass die andere Verwaltungsoperation keine Modifikation an einer Metadateneigenschaft des Datenbankobjekts angibt, die über alle Replikate des globalen Objekts hinweg einheitlich gehalten werden soll; Ausführen der anderen Verwaltungsoperation an dem Datenbankobjekt; und Bestätigen, dass die andere Verwaltungsoperation an dem globalen Objekt ausgeführt wurde, ohne die andere Verwaltungsoperation an einen oder mehrere andere der verschiedenen Standorte zu senden.
Das Verfahren nach Anspruch 9, wobei die andere Verwaltungsoperation eines oder mehreres beinhaltet aus: einer Modifikation einer Lesedurchsatzgrenze für eine Menge von Leseoperationen, die über einen Zeitraum an das Datenbankobjekt gerichtet sind; einer Modifikation eines Clienten verwalteten Verschlüsselungsschlüssels, der verwendet wird, um Daten in dem Datenobjekt zu verschlüsseln; einer Trennung des Datenbankobjekts von dem globalen Objekt; und einer Löschung des Datenbankobjekts, aber nicht der einen oder mehreren anderen Replikate des globalen Objekts.
Das Verfahren nach Anspruch 6, weiterhin unter Durchführung durch das Datenbanksystem umfassend: Empfangen einer weiteren Anforderung zum Ausführen einer weiteren Verwaltungsoperation an dem Datenbankobjekt, wobei die andere Anforderung angibt, einen Aktualisierungsstrom zu stoppen, der von dem Datenbankobjekt erzeugt wird, und der Aktualisierungsstrom verwendet wird, um Änderungen am Datenbankobjekt an die eine oder mehreren anderen Replikate des globalen Objekts zu übertragen; und Ablehnen der anderen Verwaltungsoperation und Bereitstellen einer Nachricht, die anzeigt, dass der Aktualisierungsstrom für das globale Objekt nicht gestoppt werden kann.
Das Verfahren nach Anspruch 6, weiterhin unter Durchführung durch das Datenbanksystem umfassend: Verifizieren in einer Vorbereitungsphase und vor dem Ausführen der Verwaltungsoperation an einem oder mehreren anderen Replikaten, dass die Metadateneigenschaft für alle Replikate des globalen Objekts erfolgreich modifiziert werden kann; und wobei das Verifizieren eine Vorbedingung ist, um die Verwaltungsoperation an dem einen oder den mehreren anderen Replikaten auszuführen.
Das Verfahren nach Anspruch 6, weiterhin unter Durchführung durch das Datenbanksystem umfassend: Empfangen einer Nachricht, dass die Verwaltungsoperation an mindestens einem Replikat des globalen Objekts nicht erfolgreich ausgeführt wurde; und als Reaktion auf die Nachricht Initiieren einer Zurücksetzungsoperation, um die Verwaltungsoperation an dem globalen Objekt rückgängig zu machen.
Das Verfahren nach Anspruch 6, weiterhin unter Durchführung durch das Datenbanksystem umfassend: vor dem Ausführen der Verwaltungsoperation an dem Datenbankobjekt oder dem einen oder den mehreren anderen Replikaten: Prüfen eines Steuerungsobjekts, um zu bestimmen, dass keine anderen ausstehenden Verwaltungsoperationen für das globale Objekt vorhanden sind, wobei das Erkennen von ausstehenden Verwaltungsoperationen an dem globalen Objekt bewirkt, dass die Verwaltungsoperationen abgelehnt oder angehalten werden; und Aktualisieren des Steuerungsobjekts, um anzuzeigen, dass die Verwaltungsoperation ausstehend ist; und im Anschluss an das Ausführen der Verwaltungsoperation an dem Datenbankobjekt und dem einen oder den mehreren anderen Replikaten: Aktualisieren des Steuerungsobjekts, um anzuzeigen, dass die Verwaltungsoperation nicht mehr ausstehend ist.
Das Verfahren nach Anspruch 6, wobei die Verwaltungsoperation eine überladene Operation ist, die an die anderen Standorte weitergegeben wird, wenn sie an ein Replikat eines globalen Objekts gerichtet ist, aber nicht an die anderen Standorte weitergegeben wird, wenn sie an ein regionales Objekt gerichtet ist, das nicht Teil eines globalen Objekts ist.