DE69818135T2

DE69818135T2 - Verfahren zum Zugriff auf Datenbankinformation

Info

Publication number: DE69818135T2
Application number: DE69818135T
Authority: DE
Inventors: Michael Oakland Ubell; Keith Portland Kelleman
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1997-04-11
Filing date: 1998-04-14
Publication date: 2004-07-22
Anticipated expiration: 2018-04-15
Also published as: US5895467A; DE69818135D1; MX9802716A; AU5943898A; JP4171537B2; CA2233537C; EP0871134B1; AU738371B2; EP0871134A3; BR9801403A; EP0871134A2; JPH10312299A; CA2233537A1

Description

Hintergrund
Diese Erfindung betrifft den Zugriff auf Informationen in einer Datenbank.
Eine Datenbank ist ein Informationsträger, der logisch aufgebaut ist, so dass seine Informationen von einer Datenbanksteuerkomponente ("database engine") – einer Gruppe von Software-Verfahren zur Manipulation von Daten in der Datenbank – zusammenhängend gespeichert, durchsucht und abgerufen werden können. Die Software-Verfahren werden typischerweise als ein Satz von aufrufbaren Routinen ausgeführt, bei denen es sich entweder um Funktionen, die einen Wert zurückgeben, oder um Prozeduren handelt, die keinen Wert zurückgeben.
Im Allgemeinen fallen Datenbanken unter eine von drei Kategorien: relationale Datenbanken, objektorientierte Datenbanken und objektrelationale Datenbanken. Eine relationale Datenbank (RDB) ist eine Sammlung von zweidimensionalen Tabellen mit festen Feldern, die in praktisch jeder von einem Datenbankentwickler gewählten Weise miteinander in Verbindung gebracht (oder "verknüpft") werden können. Der Aufbau einer relationalen Datenbank kann geändert werden, indem die Beziehungen zwischen den Tabellen nach Wahl neu festgelegt werden. Eine Datenbanksteuerkomponente kann komplexe Suchläufe in einer relationalen Datenbank schnell und problemlos durchführen, indem sie ein beliebiges von verschiedenen Datenbankabfrageprotokollen wie zum Beispiel das mittels der Structured Query Language (SQL) ausgedrückte Verfahren oder andere Mechanismen verwenden. Die Beziehungen zwischen den Tabellen machen es möglich, dass automatisch ein Querbezug zwischen Ergebnissen eines Suchlaufs und entsprechenden Informationen in anderen Tabellen in der Datenbank hergestellt werden kann.
Wie in 1 gezeigt ist, enthält eine relationale Datenbank 100 beispielsweise eine Kundentabelle 102, die über eine logische Verknüpfung 103 mit einer Auftragstabelle 104 verknüpft ist, die wiederum über eine logische Verknüpfung 105 mit einer Lagertabelle 106 verknüpft ist. Ein Benutzer kann die Datenbank 100 beispielsweise nach allen Auftragsnummern abfragen, die höher als ein Schwellenwert sind. Da die Auftragstabelle 104 mit der Kundentabelle 102 und der Lagertabelle 106 verknüpft ist, kann eine Liste mit Auftragsnummern, die als Antwort auf die Anfrage ermittelt wurden, abgerufen und zusammen mit den entsprechenden Kundennamen und Lagerartikeln, die den ermittelten Auftragsnummern entsprechen, angezeigt werden.
Eine objektorientierte Datenbank (OODB) ist eine Sammlung von "Objekten" – Softwareelementen, die sowohl Daten als auch Methoden zur Manipulation der Daten enthalten. Im Gegensatz zu einer relationalen Datenbank, die nur numerische Daten oder Daten in Form von Zeichen speichern kann, kann eine OODB praktisch jede Art von Daten (Text, dreidimensionale Grafikbilder, Videoclips usw.) speichern. Eine OODB speichert ihre einzelnen Objekte in einer Hierarchie aus Klassen mit zugehörigen Methoden, so dass die OODB einen Großteil der Logik enthält, die sie zur Durchführung nützlicher Arbeiten benötigt. Eine relationale Datenbank enthält im Gegensatz dazu nur Daten und ist auf externe Anwendungssoftware angewiesen, um nützliche Funktionen mit den Daten durchzuführen.
Eine objektrelationale Datenbank (ORDB) ist eine Mischform der beiden anderen Arten. Erweiterte Daten (z. B. eine Filmdatei) können entweder als Teil einer Zeile oder als ein großes Binärobjekt (binary large object (BLOB)) – eine undifferenzierte Datenmasse – in einer ORDB gespeichert und abgerufen werden. Eine ORDB kann auch auf Methoden (z. B. ein Dienstprogramm zum Betrachten von Filmdateien) zugreifen, um die in einem BLOB enthaltenen Daten zu manipulieren. In Abhängigkeit von der jeweiligen ORDB-Ausführung können diese Methoden getrennt von der Datenbanksteuerkomponente verwaltet oder mit ihr verknüpft werden.
In einem erweiterbaren objektrelationalen Datenbankverwaltungssystem (ORDBMS) wie zum Beispiel dem Informix Universal Server (ISU^®) werden Methoden zur Manipulation von erweiterten Daten direkt mit der Datenbanksteuerkomponente verknüpft, so dass die erweiterten Daten als ein "eigener" Datentyp, das heißt, ein Datentyp, den das ORDBMS selbst manipulieren kann, ohne auf externe Anwendungen zurückgreifen zu müssen, behandelt werden.
In 2 beispielsweise hat ein erweiterbares ORDBMS 200 die Erweiterungen X und Y, die jeweils Methoden zur Manipulation der Datenarten X und Y enthalten, welche direkt mit der Datenbanksteuerkomponente 202 verknüpft sind. Als Antwort auf eine Datenbankanfrage, die zum Beispiel auf Daten vom Typ X zeigt, ruft die Datenbanksteuerkomponente 202 automatisch die Methoden in der Erweiterung X auf, um die Daten in einer geeigneten datentypspezifischen Weise zu manipulieren.
Im Gegensatz dazu lässt ein nichterweiterbares ORDBMS eine Verknüpfung von Datenmanipulationsverfahren für beliebige Datenarten mit der Datenbanksteuerkomponente nicht zu, sondern erfordert vielmehr die Verwendung von mehreren datentypspezifischen Steuerkomponenten, die über Middleware-Ebenen miteinander verbunden werden, um mehrere Datenarten zu verwalten. Folglich weist ein nichterweiterbares ORDBMS im Allgemeinen eine geringere Leistungsfähigkeit auf und macht den Einsatz neuer Anwendungen für den Entwickler schwieriger.
Die US-Patentschrift Nr. 5 572 673 beschreibt ein Datenbankverwaltungssystem mit einem Mechanismus, der zur Bestätigung dient, dass bestimmte Arten von Objekten wie zum Beispiel gespeicherte Prozeduren, Trigger und Ansichten sicher zum Zugriff auf andere sensible Objekte in der Datenbank verwendet werden können. Die Bestätigung zeigt an, dass ein Sicherheitsbeamter (security officer) das Objekt ausgewertet und bestätigt hat und das nun bestätigte Objekte seit seiner Bestätigung keiner festgelegten sicherheitsrelevanten Änderung unterzogen wurde. "Vertrauenswürdige" ausführbare Objekte können auf Sicherheitsebenen ausgeführt werden, die über diejenigen eines Benutzers oder eines Subjekts hinausgehen. Somit kann das Subjekt mit Hilfe einer vertrauenswürdigen gespeicherten Prozedur oder eines vertrauenswürdigen gespeicherten Triggers auf bestimmte Objekte zugreifen, die höhere Sensibilitätsebenen als es selbst haben.
Die US-Patentschrift Nr. 5 590 326 beschreibt ein Verwaltungsschema für gemeinsam benutzte Daten, das die gemeinsam benutzten Daten so manipulieren kann, dass mehrere Threads auf sie zugreifen können. Unterschiedliche Bezeichner für gemeinsam benutzte Daten werden für identische gemeinsam benutzte Daten verwendet und verschiedenen Threads zugeordnet, und unterschiedliche Sperren werden für unterschiedliche Bezeichner für gemeinsam benutzte Daten gesetzt, um unter den Zugriffen, die auf die gemeinsam benutzten Daten stattfinden, einen unter Missachtung der Sperren erfolgten Zugriff für jeden Thread getrennt erkennen zu können. Die identischen gemeinsam benutzten Daten werden auf eine Vielzahl von unterschiedlichen Bereichen in einem virtuellen Speicherbereich abgebildet, der den verschiedenen Threads, die in einem Prozess gleichzeitig ausgeführt werden sollen, zugeordnet sind. Die Bezeichner für gemeinsam benutzte Daten werden mittels virtueller Adressen der verschiedenen Bereiche in dem virtuellen Speicherbereich vergeben, auf die die identischen Daten abgebildet werden.
Zusammenfassung
In einer Erscheinungsform der Erfindung wird ein von einem Datenbank-Server durchgeführtes Verfahren zur Ausführung oder Steuerung von Routinen bereitgestellt, um Daten in einer Datenbank zu manipulieren, wobei das Verfahren die folgenden Schritte umfasst: Feststellen, ob eine Datenbankmanipulationsroutine beschränkten Zugriff auf die Datenbank haben soll; selektives Ändern einer Speicherzugriffsberechtigung für die Datenbankmanipulationsroutine auf der Grundlage der Feststellung; und Ausführen der Datenbankmanipulationsroutine unter Verwendung der selektiv geänderten Speicherzugriffsberechtigung; dadurch gekennzeichnet, dass das Verfahren den weiteren Schritt des Setzens eines zu der Datenbankmanipulationsroutine gehörenden Parameters auf einen wert beinhaltet, der eine Klasse einer Vielzahl von Klassen von Prozessoren zur Ausführung der Datenbankmanipulationsroutine angibt; und der Schritt der Feststellung, ob eine Datenbankmanipulationsroutine beschränkten Zugriff auf die Datenbank haben soll, die Feststellung umfasst, ob die Datenbankmanipulationsroutine von einem angegebenen Bereich des Speichers isoliert werden soll, indem der zu der Datenbankmanipulationsroutine gehörende Parameter geprüft wird, wodurch die angegebene Prozessorklasse von dem angegebenen Speicherbereich isoliert wird.
Eine Datenbankmanipulationsroutine, die isoliert werden soll, kann mit Nur-Lese-Speicherzugriff ausgeführt werden, wodurch der angegebene Speicherbereich vor einer unsachgemäßen Änderung seines Inhalts geschützt wird.
Ob eine Datenbankmanipulationsroutine von einem angegebenen Speicherbereich (z. B. dem Kernspeicher, in dem sich Kerndatenstrukturen befinden) isoliert werden soll, kann festgestellt werden, indem ein zu der Datenbankmanipulationsroutine gehörender Parameter geprüft wird. Der Parameter kann auf einen Wert gesetzt werden, der eine Prozessorklasse (z. B. einen virtuellen Prozessor mit mehreren Threads) zur Ausführung der Datenbankmanipulationsroutine angibt. Ein bestimmter Klassenwert zeigt an, dass der entsprechende Prozessor vom Kernspeicher isoliert werden sollte, indem die Berechtigungen des Prozessors für den Kernspeicher auf "Nur Lesen" beschränkt werden. Andere Klassenwerte können anzeigen, dass der entsprechende Prozessor nicht vom Kernspeicher isoliert zu werden braucht und folglich uneingeschränkte Schreib-/Leseberechtigung für den Kernspeicher haben kann.
Eine selektive Änderung der Speicherzugriffsberechtigungen kann durch einen lokalen Prozeduraufruf vorgenommen werden, der die Speicherzugriffsberechtigung für die Datenbankmanipulationsroutine auf "Nur Lesen" für den Kernspeicher setzt, wenn die Datenbankmanipulationsroutine als "nichtvertrauenswürdig" festgestellt wird – d. h. eine Routine, die vom Kernspeicher isoliert werden muss. Alternativ dazu kann die Speicherzugriffsberechtigung für die Datenbankmanipulationsroutine auf "Schreiben/Lesen" für den Kernspeicher gesetzt werden, wenn die Routine als "vertrauenswürdig" festgestellt wird – d. h. eine Routine, die nicht vom Kernspeicher isoliert zu werden braucht.
Wenn eine nichtvertrauenswürdige Routine ausgeführt werden soll, bewirkt ein lokaler Prozeduraufruf, dass der Ausführungs-Thread für die Datenbankmanipulationsroutine von einem Prozessor, der über eine Schreib-/Leseberechtigung für den Kernspeicher verfügt, zu einem Prozessor wechselt, der Nur-Lese-Zugriff auf den Kernspeicher hat. Der Thread wechselt in einen Speicherbereich, der vom Kernspeicher logisch getrennt ist, sich aber in demselben Speicheradressraum wie der Kernspeicher befindet. Der Thread befindet sich in "einem vertrauenswürdigen Kontext", wenn er über eine Schreib-/Leseberechtigung für den Kernspeicher verfügt, und in einem "nichtvertrauenswürdigen Kontext", wenn er Nur-Lese-Zugriff auf den Kernspeicher hat.
Wenn er in einem nichtvertrauenswürdigen Kontext ausgeführt wird, muss der Thread gegebenenfalls dennoch eine Ressource im Kernspeicher nutzen, um die Datenbankmanipulationsroutine auszuführen. Nachdem dieser Umstand festgestellt wurde, wird ein Wechsel vom nichtvertrauenswürdigen Kontext in einen anderen vertrauenswürdigen Kontext vorgenommen, um dem Thread beispielsweise eine Änderung des Inhalts des Kernspeichers zu ermöglichen. Nachdem der Thread die Benutzung der Ressource im Kernspeicher abgeschlossen hat, wird ein Wechsel vom vertrauenswürdigen Kontext zurück in den nichtvertrauenswürdigen Kontext vorgenommen. Ebenso wird ein Wechsel vom nichtvertrauenswürdigen Kontext zurück in den ursprünglichen vertrauenswürdigen Kontext vorgenommen, nachdem die Ausführung der nichtvertrauenswürdigen Routine abgeschlossen ist. Eine beliebige Anzahl von Wechseln zwischen einem vertrauenswürdigen Kontext und einem nichtvertrauenswürdigen Kontext kann durchgeführt werden.
Bei der Durchführung eines Kontextwechsels von einem nichtvertrauenswürdigen Kontext in einen vertrauenswürdigen Kontext kann der Eintritt in den Kernspeicher auf einen vorher festgelegten Satz von einem oder mehr zulässigen Ausführungseintrittspunkten beschränkt werden, die zum Beispiel in einer vorher festgelegten Rückfragetabelle ausgewiesen sind. Wenn ein angegebener Eintrittspunkt in der Rückfragetabelle erscheint, ist ein Eintritt in den Kernspeicher an dieser Stelle erlaubt. Wenn ein angegebener Eintrittspunkt jedoch nicht in der Rückfragetabelle erscheint, wird der Eintritt in den Kernspeicher an dieser Stelle gesperrt.
In einer weiteren Erscheinungsform der Erfindung werden Routinen zur Manipulation von Daten in einer Datenbank von einem Datenbank-Server durchgeführt, indem ein Speicheradressraum in Speichersegmente (z. B. ein Hauptsegment und ein oder mehrere abgeschirmte Segmente (fenced segments)) aufgeteilt wird. Eine Datenbankmanipulationsroutine, zum Beispiel eine nichtvertrauenswürdige benutzerdefinierte Datenbankmanipulationsroutine, kann selektiv in einem abgeschirmten Speichersegment ausgeführt werden, während verhindert wird, dass die Routine Daten in ein anderes der Speichersegmente schreibt. Die Datenbankmanipulationsroutine, die in dem abgeschirmten Speichersegment ausgeführt wird, kann in die Lage versetzt werden, Daten aus einem anderen Speichersegment zu lesen oder in ein anderes Speichersegment zu wechseln, um eine vorher festgelegte Routine auszuführen. Andere Routinen, beispielsweise vertrauenswürdige Datenbank-Kernroutinen, können im Hauptsegment mit uneingeschränktem Schreib-/Lesezugriff auf alle Speichersegmente ausgeführt werden. Außerdem können mehrere Datenbankmanipulationsroutinen in entsprechenden der Speichersegmente ausgeführt werden, wobei jede Datenbankmanipulationsroutine Nur-Lese-Zugriff auf alle Speichersegmente außer ihrem eigenen Speichersegment hat.
Diese Erfindung kann einen oder mehrere der folgenden Vorteile aufweisen. Benutzern wird ermöglicht, ihre eigenen Routinen festzulegen, und durch die Verknüpfung dieser benutzerdefinierten Routinen mit der Datenbanksteuerkomponente kann der Datenbank-Server eine beliebige Sammlung von umfangreichen Datenarten (z. B. Bildern, Video, Ton, Landkarten, komplexe Finanzinstrumente, Daten von Zeitreihen) schnell und wirksam handhaben. Das Risiko, dass eine benutzerdefinierte Routine, die fehlerhafte Logik enthält, den Inhalt der Datenbank verfälscht, wird auf ein Mindestmaß herabgesetzt, da solche benutzerdefinierten Routinen von den Kerndatenstrukturen und -funktionen des Datenbank-Servers isoliert werden. Eine unsachgemäße Änderung des Inhalts des Kernspeichers, der vom Datenbank-Server verwendet wird, wird verhindert, indem benutzerdefinierte Routinen mit einem Prozessor (z. B. einem virtuellen Prozessor) ausgeführt werden, der über eingeschränkte Zugriffsrechte verfügt. Dem virtuellen Prozessor wird in Abhängigkeit von der jeweiligen Ausführung uneingeschränkter Schreib-/Lese-(R/W-)Zugriff entweder auf einen angegebenen Speicherbereich oder auf sein eigenes Zusatzspeichersegment bewilligt, aber auf den Kernspeicher des Datenbank-Servers hat er lediglich Nur-Lese-Zugriff. Folglich erhält der Benutzer mehr Flexibilität, während beim Datenbank-Server ein hohes Maß an Zuverlässigkeit und Leistungsfähigkeit erhalten bleibt.
Indem man einer Routine ermöglicht, eine virtuelle Prozessorklasse anzugeben, unter der die Routine ausgeführt werden soll, wird Datenbankentwicklern ein flexibler und leistungsfähiger Mechanismus an die Hand gegeben, um nichtvertrauenswürdige Routinen zu isolieren. Eine Routine kann als vertrauenswürdig oder als nichtvertrauenswürdig ausgeführt werden, indem einfach ein Parameter geändert wird, um eine virtuelle Prozessorklasse mit uneingeschränkten Schreib-/Lese-Zugriffsrechten oder einen "abgeschirmten" virtuellen Prozessor festzulegen, der über Nur-Lese-Zugriffsrechte auf einen bestimmten Speicherbereich verfügt.
In einer Konfiguration, bei der der Speicher logisch in Segmente aufgeteilt wird, belegen die Speichersegmente verschiedene Teile desselben Speicheradressraums. Folglich kann der Ausführungs-Thread für die benutzerdefinierte Routine schnell und problemlos zwischen Speichersegmenten wechseln. Außerdem gestatten vom Datenbank-Server bereitgestellte interne Routinen einem abgeschirmten virtuellen Prozessor den Zugriff auf Ressourcen, die im Kernspeichersegment vorhanden sind, während der Inhalt des Kernspeichersegments vor unsachgemäßen Änderungen geschützt wird. Dadurch wird eine Isolation von nichtvertrauenswürdigen benutzerdefinierten Routinen realisiert, während beim Datenbank-Server ein hohes Maß an Leistungsfähigkeit und Skalierbarkeit erhalten bleibt.
Ausführungsformen der vorliegenden Erfindung werden nun lediglich anhand eines Beispiels und mit Bezug auf die beigefügten Zeichnungen beschrieben, in denen:
1 ein Blockdiagramm einer relationalen Datenbank nach dem Stand der Technik ist;
2 ein Blockdiagramm eines erweiterbaren objektrelationalen Datenbankverwaltungssystems nach dem Stand der Technik ist;
die 3A und 3B Beispiele für Architekturen von Datenbank-Servern nach dem Stand der Technik sind;
4 ein Blockdiagramm einer Datenbankserver-Architektur mit mehreren Speichersegmenten ist;
5 ein Blockdiagramm der Architektur des Informix^® Universal Servers ist;
6 ein Flussdiagramm der Ausführung von Routinen bei der Architektur des Informix^® Universal Servers von 5 ist;
7 ein Datendiagramm einer Rückfragetabelle ist, die bei der Architektur des Informix^® Universal Servers von 5 verwendet werden kann.
Ausführliche Beschreibung
Der Einsatz eines erweiterbaren Datenbankverwaltungssystems (DBMS) zur Speicherung von persistenten Daten bietet mehrere Vorteile, die man bei Verwendung eines nichterweiterbaren DBMS als Datenhaltungssystem (data repository) nicht hat. Die Fähigkeit, Routinen zur Manipulation von praktisch jeder Art von Daten mit der Datenbanksteuerkomponente zu verknüpfen, gibt Entwicklern die Möglichkeit, das DBMS gezielt auf die Erfordernisse eines Unternehmens auszulegen. Darüber hinaus stellt die Möglichkeit, kundenspezifische Funktionen zusammen mit der Kernfunktionalität des DBMS als eine Lösung mit nur einer einzigen Steuerkomponente zu realisieren, eine Verbesserung der Leistungsfähigkeit des DBMS, der Korrektheit und Vollständigkeit der Transaktionen, der Skalierbarkeit und Verwaltbarkeit des DBMS sowohl bei herkömmlichen als auch komplexen Datenarten dar.
Entwicklern ein solch hohes Maß an Flexibilität und Erweiterbarkeit zu bieten, kann in Abhängigkeit von der verwendeten DBMS-Architektur möglicherweise jedoch zu Problemen führen. Bei der Architektur von 3A beispielsweise empfängt ein Datenbank-Server 300 Datenbankanfragen von den Clients I, J und K (301 bis 305) über die Kommunikationsverbindungen 307 und leitet diese Datenbankanfragen je nach Gegebenheit an die Threads Q, R oder S weiter. Jeder Client kann mit einem anderen Thread kommunizieren, wie in 3A gezeigt ist, oder ein einziger Prozess mit mehreren Threads kann Anfragen von zwei oder mehr Clients empfangen. In beiden Fällen führen die Threads wiederum Bibliothekenaufrufe durch, um vorher festgelegte Routinen aufzurufen, die die gewünschten Operationen an der Datenbank ausführen. In 3A führen alle Threads, die sich im Datenbank-Server 300 befinden, ihre jeweiligen Routinen in demselben Speicheradressraum – nämlich im gemeinsam benutzten Speicher 302 – aus, für den jeder Thread uneingeschränkte Schreib-/Lese-Zugriffsrechte besitzt.
Wenn man den Threads Q, R und S gestatten würde, Daten aus dem gemeinsam benutzten Speicher 302 ohne Einschränkung zu lesen und in ihn zu schreiben, würde dies gewöhnlich keine Probleme mit Systemoperationen verursachen, da jede der zugrunde liegenden, von den Threads aufgerufenen Routinen von demselben Software-Hersteller geschrieben und gründlich auf korrekten Betrieb und Interoperabilität mit jeder anderen an den Datenbank-Server 300 angebundenen Routine geprüft worden wäre. In manchen Fällen kann es jedoch vorkommen, dass ein verhältnismäßig unerfahrener Entwickler oder Endbenutzer eines DBMS eine fehlerhafte Datenmanipulationsroutine schreibt und diese Fehler nicht ordnungsgemäß beseitigt, d. h., die Ausführung der Routine bewirkt, dass sie den Inhalt des gemeinsam benutzten Speichers 302 des Datenbank-Servers 300 in unangebrachter Weise ändert und dabei das DBMS möglicherweise zum Absturz bringt oder den Inhalt der Datenbank verfälscht oder beides.
3B zeigt eine Lösung, um den Inhalt des gemeinsam benutzten Speichers des Datenbank-Servers vor Beschädigung durch die Ausführung einer fehlerhaften benutzerdefinierten Routine (UDR) zu schützen. Bei der Architektur von 3B werden von den Clients 301 bis 305 empfangene Datenbankmanipulationsanforderungen unterschiedlich gehandhabt, und zwar in Abhängigkeit davon, ob die zugrunde liegenden Routinen, denen sie entsprechen, als "vertrauenswürdig" (beispielsweise UDRs, die eingehend geprüft wurden, um sicherzustellen, dass sie den Inhalt des gemeinsam benutzten Speichers 302 nicht unsachgemäß ändern oder ansonsten mit anderen Routinen in Konflikt geraten) oder als "nichtvertrauenswürdig" (beispielsweise UDRs, die nicht eingehend geprüft wurden) betrachtet werden. Bei denjenigen UDRs, die als zu einer vertrauenswürdigen Klasse gehörend eingestuft werden, führt der aufrufende Thread die Routine im gemeinsam benutzten Speicher 302 mit uneingeschränkten Schreib-/Lese-Zugriffsberechtigungen in der gleichen Weise aus, wie sie vorstehend in Verbindung mit 3A beschrieben wurde.
Im Falle von nichtvertrauenswürdigen UDRs jedoch führt der aufrufende Thread (z. B. Thread S) einen Fernprozeduraufruf (RPC) – einen Programmiermechanismus, der bewirkt, dass der Thread von einem Speicheradressraum in einen anderen Speicheradressraum wechselt, während der Programmkontext beibehalten wird – an einen anderen Server 310 durch. Sobald der Thread zum Server 310 gewechselt ist, wird die nichtvertrauenswürdige UDR im Speicher 312 ausgeführt, und das Ergebnis wird zurückgegeben, indem der Thread wieder dem Datenbank-Server 300 übergegeben wird. Da der Speicher 312 im Server 310 einen Speicheradressraum darstellt, der sich vom gemeinsam benutzten Speicher 302 im Server 300 unterscheidet und von diesem getrennt ist, kann keine Routine, die auf dem Server 310 ausgeführt wird, den Inhalt des gemeinsam benutzten Speichers 302 direkt ändern. Tatsächlich isoliert der vom Thread S durchgeführte RPC den zugrunde liegenden Ausführungs-Thread vom Datenbank-Server 300 und schützt auf diese Weise den Inhalt des gemeinsam benutzten Speichers 302 vor unsachgemäßer Änderung durch die nichtvertrauenswürdige Routine.
Der Wechsel zwischen verschiedenen Speicheradressräumen ist jedoch ein verhältnismäßig zeitaufwendiger Vorgang. Jeder Fernprozeduraufruf eines anderen Speicheradressraums ist typischerweise mit einem beträchtlichen organisatorischen Zeitaufwand bei der Ordnung und Wiederherstellung von Argumenten und Ergebnissen zwischen den verschiedenen Servern verbunden. Außerdem stützt sich die RPC-basierende Architektur auf den ordnungsgemäßen Betrieb einer Kommunikationsverbindung zwischen zwei oder mehr verschiedenen Adressräumen, von denen jeder typischerweise zu einem anderen Rechnersystem gehört. Solche Übertragungen zwischen Systemen sind weitaus weniger zuverlässig als Übertragungen innerhalb eines Systems. Die RPC-basierende Isolationsarchitektur leidet folglich unter einer verhältnismäßig geringen Leistungsfähigkeit und Zuverlässigkeit.
Diese und andere Probleme, die mit der RPC-basierenden Isolationsarchitektur verbunden sind, werden mit einer Datenbankserver-Architektur angegangen, bei der bestimmte nichtvertrauenswürdige Methoden wie zum Beispiel UDRs von den Kerndatenstrukturen und vertrauenswürdigen Methoden wie zum Beispiel den Kernroutinen der Datenbanksteuerkomponente isoliert werden. Die Isolation kann durch Verwendung von sowohl dem einen als auch dem anderen von mindestens zwei verschiedenen Modellen erreicht werden: einem Mehrprozess-Modell und einem Ein-Prozess-Segmentmodell.
Bei dem Mehrprozessmodell kann die Isolation in einer Architektur, wie sie beispielsweise in 4 gezeigt ist, vorgenommen werden, indem mehrere Speichersegmente – beispielsweise ein Hauptspeichersegment 303 und ein Zusatzspeichersegment 304 – innerhalb desselben Speicheradressraums 302 gehalten werden. Das Segment 303 dient als der Speicherbereich, in dem vertrauenswürdige Kernroutinen der Datenbanksteuerkomponente und Kerndatenstrukturen ausgeführt und gespeichert werden. Das Speichersegment 304 dient als ein Zusatzspeicherbereich, der hauptsächlich zur Ausführung und Speicherung von Routinen und Daten mit Ausnahme derjenigen, die Kern-DBMS-Funktionen entsprechen, reserviert ist.
Ein Thread, der eine vertrauenswürdige Routine ausführt, bleibt im Hauptspeichersegment 303 und verfügt über uneingeschränkte Schreib-/Lese-Zugriffsrechte auf dieses Segment. Um eine nichtvertrauenswürdige Routine auszuführen, wechselt der Thread jedoch zuerst in das Zusatzspeichersegment 304, um den Thread vom Kernspeichersegment 303 zu isolieren. Ein Thread, der im Zusatzspeichersegment ausgeführt wird (z. B. Thread S'), verfügt über uneingeschränkte Schreib-/Lese-Zugriffsrechte auf das Hauptspeichersegment 304, hat aber Nur-Lese-Zugriff auf das Speichersegment 303. Durch Einschränkung der Speicherbereiche, in die der Thread S' bei der Ausführung einer nichtvertrauenswürdigen Routine schreiben kann, werden die Kern-DBMS-Datenstrukturen und -Routinen vor Überschreiben durch eine fehlerhafte UDR geschützt. Da vertrauenswürdige und nichtvertrauenswürdige Routinen in demselben Speicheradressraum (obgleich in verschiedenen Speichersegmenten) ausgeführt werden, braucht der Thread S' außerdem keinen RPC durchführen, um eine nichtvertrauenswürdige Routine auszuführen, sondern kann vielmehr einen standardmäßigen lokalen Prozeduraufruf verwenden, der im Allgemeinen zuverlässiger ist und dessen erforderlicher organisatorischer Zeitaufwand ungefähr um eine Größenordnung kleiner als der eines RPC ist. Folglich lässt sich eine Isolation von nichtvertrauenswürdigen Routinen erreichen, während ein verhältnismäßig hohes Niveau an Leistungsfähigkeit und Zuverlässigkeit erhalten bleibt.
Wenn der Datenbank-Server mit einem einzigen Prozess realisiert wird, kann man eine Isolation innerhalb eines Kernspeichersegments erreichen, indem man die Schreib-/Lese-Zugriffsrechte auf der Grundlage der Beschaffenheit der Routinen, die ausgeführt werden, ändert. Bei der Ausführung einer vertrauenswürdigen Routine verfügt der Thread in der üblichen Weise über uneingeschränkte Schreib-/Lese-Zugriffsrechte auf den Kernspeicher. Vor der Ausführung einer nichtvertrauenswürdigen Routine werden Schreib-/Lese-Zugriffsrechte auf einen Speicherbereich, der Datenbank-Kernroutinen entspricht, jedoch in ein Nur-Lese-Zugriffsrecht für den Thread geändert, der die nichtvertrauenswürdig Routine ausführt. Die Änderung von Schreib-/Lese-Zugriffsrechten für ein Speichersegment kann mittels einem von zwei Verfahren durchgeführt werden: (i) indem betriebssystemspezifische Routinen zur Änderung von Schreib-/Lese-Zugriffsrechten für einen bestimmten Speicherbereich aufgerufen werden oder (ii) indem der Prozess, in dem sich der Thread befindet, von dem Speichersegment getrennt wird und im Anschluss an die Neuzuordnung des Prozesses zu dem Speichersegment dann verschiedene Schreib-/Lese-Zugriffsberechtigungen festgelegt werden. Bei beiden Verfahren wird eine Verfälschung des Inhalts der Datenbank verhindert, indem die nichtvertrauenswürdigen Routine daran gehindert wird, den Inhalt eines bestimmten Teils des Speichers zu ändern.
Eine ausführliche Beschreibung der Art und Weise, in der die Architektur von 4 bei dem Informix^® Universal Server (IUS) genutzt werden kann, um nichtvertrauenswürdige UDRs wirkungsvoll von vertrauenswürdigen Kerndatenstrukturen und DBMS-Kernroutinen zu isolieren, folgt mit Bezug auf 5. Bei der gezeigten Mehrprozessorumgebung verwendet der IUS^® mehrere Speichersegmente – beispielsweise den Kernspeicher 402 und den abgeschirmten Speicher 412 –, die denselben Speicheradressraum belegen, aber logisch voneinander getrennt sind. Der Datenbank-Server 400 besteht aus einem oder mehreren virtuellen Prozessoren (VPs) – Software-Einheiten mit mehreren Threads, die Hardware-Prozessoren nachbilden und mehrere Client-Anfragen gleichzeitig entgegennehmen und verarbeiten können. Jeder VP ist eine Instanz einer binären ausführbaren Datei, die beispielsweise als Prozess im Betriebssystem UNIX läuft. Die binäre ausführbare Datei enthält die zur Bildung eines ORDBMS notwendigen Software-Komponenten sowie die Software-Komponenten, die die Anbindung an Erweiterungen, welche URDs zur Handhabung von beliebigen Datenarten enthalten, ermöglichen.
Es gibt viele verschiedene Klassen von VPs, wobei jede Klasse bestimmte Eigenschaften und Merkmale festlegt, die die Zugriffsrechte, über die VPs innerhalb dieser Klasse verfügen können, und die ihnen auferlegten Einschränkungen steuern. Jede Routine, die mit der Datenbanksteuerkomponente verknüpft ist, sei es eine Datenbank-Kernroutine oder eine UDR, hat einen zugehörigen Parameter, VPCLASS, der die Klasse des VP bezeichnet, mit dem die Routine ausgeführt werden soll. Im Allgemeinen wird derselben VP-Klasse eine Gruppe von funktional zusammengehörenden Routinen zugeordnet. In Abhängigkeit von der gewünschten Konfiguration des Datenbank-Servers kann der Parameter VPCLASS zum Zeitpunkt des Systemstarts geändert werden, um eine andere Klasse anzugeben.
Der Datenbank-Server kann aus mehreren unterschiedlichen VPs, entweder von derselben oder von unterschiedlichen Klassen, bestehen. Die VPs sind mit einer Bibliothek von Datenbank-Kernroutinen verbunden, die als Teil des IUS^®-Systems enthalten sind. Die VPs können auch mit einer oder mehreren UDRs verbunden werden, zum Beispiel mit UDR₁ und UDR₂, wie in 5 gezeigt ist, die kundenspezifisch ausgelegt wurden, damit sie beliebige, von einem Benutzer des IUS^®-Systems festgelegte Datenarten handhaben können. Sowohl die Datenbank-Kernroutinen als auch die UDRs werden bei der IUS^®-Architektur mit Hilfe der DataBlade^®-Technologie realisiert, die von Informix^®, Inc. entwickelt wurde. Eine ausführliche Beschreibung der DataBlade^®-Technologie und wie sie zur Erzeugung neuer UDRs eingesetzt werden kann, findet sich im DataBlade^® Developers Kit 9.01 (Informix-Bestellnr. 82181).
Bei der in 5 gezeigten Konfiguration enthält der Datenbank-Server drei verschiedene VPs 403, 405 und 409, die jeweils zu einer anderen Klasse gehören. CPU-VP 405 gehört zur VP-Klasse "cpu", der Klasse, die Routinen am wirksamsten ausführt und die Standard-VP-Klasse für die meisten der Datenbank-Kernroutinen ist. CPU-VP 405 empfängt und handhabt alle eintreffenden Datenbankanfragen oder andere Client-Anfragen in der ersten Instanz. Bei der Verarbeitung einer Client-Anfrage kann der CPU-VP andere Klassen von VPs aufrufen, um spezielle Funktionen auszuführen. Beispielswiese kann der CPU-VP 405 den Erweiterungs-VP (Extension VP) 403 (VPCLASS = "ext") aufrufen, um eine blockierende E/A-Anforderung zu bedienen und dadurch den CPU-VP freigeben, damit dieser andere Client-Anfragen bedienen kann.
Alle VP-Klassen haben statische Schreib-/Lese-Zugriffsrechte, die zum Zeitpunkt des Starts des Datenbank-Servers festgelegt werden. Sofern nicht anders angegeben, verfügen alle VP-Klassen standardmäßig über uneingeschränkte Schreib-/Lese-Zugriffsrechte auf den Kernspeicher 402. Es kann jedoch ein Erweiterungs-VP festgelegt werden, der als abgeschirmter VP läuft, indem seine VPCLASS auf "abgeschirmt" ("fenced") gesetzt wird. Andere VP-Klassen (z. B. "cpu", "aio", "tli") unterstützen gewöhnlich keine abgeschirmte Betriebsart.
In 5 verfügt der abgeschirmte VP 409 (d. h. ein Erweiterungs-VP, dessen VPCLASS auf "abgeschirmt" gesetzt wurde) folglich über uneingeschränkte Schreib-/Lese-Zugriffsrechte auf den abgeschirmten Speicher 412, hat aber lediglich Nur-Lese-Zugriff auf den Kernspeicher 402. Indem man den Parameter VPCLASS entsprechend setzt, kann die Art und Weise, in der eine Routine behandelt wird (z. B. vertrauenswürdig im Gegensatz zu nichtvertrauenswürdig), gesteuert werden. Um eine UDR als vertrauenswürdige Routine auszuführen, wird VPCLASS auf "cpu" gesetzt, was bedeutet, dass ein CPU-VP die Routine in der gleichen Weise wie die Kernroutinen der Datenbanksteuerkomponente ausführt. Um eine UDR zwar als vertrauenswürdige Routine, jedoch in einem anderen Speichersegment als dem Kernspeichersegment auszuführen, wird VPCLASS auf einen anderen VP-Klassenbezeichner als "cpu" gesetzt, zum Beispiel auf "ext.". Um als eine nichtvertrauenswürdige Routine in einem anderen Speichersegment als dem Kernspeichersegment ausgeführt zu werden, enthält VPCLASS den Bezeichner "abgeschirmt" ("fenced"), der besagt, dass die Routine von einem VP ausgeführt werden muss, der vom Kernspeichersegment "abgeschirmt" ist (d. h. nicht in dieses Segment schreiben kann).
Eine Erklärung, wie der Datenbank-Server zwischen vertrauenswürdigen und nichtvertrauenswürdigen Routinen wechselt, folgt mit Bezug auf das Flussdiagramm von 6. Ein Client greift auf den Datenbank-Server 400 zu, indem er eine Verbindung zum Server herstellt beziehungsweise sich dort anmeldet (Schritt 500) und im Laufe einer Anmeldesitzung eine oder mehrere Anfragen (z. B. SQL-Anfragen) stellt. Nachdem zuerst eine Verbindung zum Datenbank-Server 400 hergestellt wurde, wird jedem Client vom CPU-VP 405 über einen Aufruf einer Datenbank-Kernroutine, mt_alloc-stack ( ), (Schritt 502) ein Stapelspeicher zugeordnet. Der dem Client zugeordnete Stapelspeicherbereich wird von einem oder mehreren zu diesem Client gehörenden Ausführungs-Threads bei der Bedienung der Datenbankanfragen des Client, die während der Anmeldesitzung gestellt wurden, verwendet. Die Stapelspeicher-Zuordnungsroutine wird auch aufgerufen, wenn ein vorhandener Stapelspeicher zusätzlichen Speicherplatz benötigt oder um einen neuen Arbeits-Thread zur Parallelverarbeitung einer Client-Anfrage zu erzeugen.
Wenn ein Client eine Datenbankanfrage oder eine andere Anfrage an den Datenbank-Server sendet (Schritt 504), leitet der CPU-VP 405 die Verarbeitung der Anfrage ein, indem er feststellt, welche Routinen ausgeführt werden müssen, um die bestimmten Informationen abzurufen und sie im geeigneten Format zu übergeben (Schritt 506). Als Teil der Verarbeitung führt der CPU-VP 405 wahrscheinlich auch eine Anfrage-Optimierungsanalyse durch und leitet die Ausführung von Datenbankmanipulationsoperationen ein.
Schließlich erreicht der CPU-VP gewöhnlich einen Punkt, an dem eine oder mehrere Routinen ausgeführt werden müssen, um die Anfrage des Client zu bedienen. Für jede auszuführende Routine prüft der CPU-VP 405 den Parameter VPCLASS der Routine, um festzustellen, ob die Routine von einem VP, der über uneingeschränkte Schreib-/Lese-Zugriffsrechte auf den Kernspeicher 402 verfügt, oder einem abgeschirmten VP (Fenced VP) 409, der Nur-Lese-Zugriffsrechte auf den Kernspeicher 402 hat, ausgeführt werden soll (Schritt 508). Der Großteil der Routinen, die bei der Bedienung einer Client-Anfrage ausgeführt werden, sind gewöhnlich vertrauenswürdige Datenbank-Kernroutinen, die entweder vom CPU-VP 405 selbst oder von einem nichtabgeschirmten VP einer anderen Klasse als der "cpu" (z. B. Extension VP 403) im Kernspeicher 402 ausgeführt werden. Manche der Routinen, die bei der Bedienung einer Client-Anfrage ausgeführt werden müssen, können jedoch nichtvertrauenswürdige UDRs sein, die vom abgeschirmten VP 409 im abgeschirmten Speichersegment 412 ausgeführt werden, um die UDRs vom Datenbank-Kernspeicher zu isolieren.
Wenn der Parameter VPCLASS folglich nicht das Wort "abgeschirmt" ("fenced") enthält, wird die Routine als vertrauenswürdige Routine behandelt. Dazu gibt der CPU-VP 405 Parameter für die Routine in den Stapelspeicher des Client im Kernspeicher 402 ein (Schritt 510) und fügt einen Eintrag, dass ein Thread die Routine ausführen soll, in die Hauptausführungswarteschlange 404 ein (Schritt 512). Wenn die Hauptausführungswarteschlange 404 als Nächstes auf den Thread-Eintrag der Routine zeigt, wählt ein VP von der Klasse, die der Parameter VPCLASS der Routine angibt, den Thread aus und führt die angeforderte Routine im Kernspeicher 402 aus, indem er die Parameter dem Stapelspeicher des Client entnimmt und sie zur Ausführung der von der Routine angegebenen Befehle verwendet (Schritt 514). Bei der Ausführung einer vertrauenswürdigen Routine darf der VP, auf dem die Routine läuft, nach Bedarf Daten ohne Einschränkung in den Kernspeicher 402 schreiben und aus ihm lesen. Nach Beendigung schreibt die Routine alle Rückgabeparameter in den Stapelspeicher des Client und gibt die Steuerung an die entsprechende Stelle zurück (516).
Wenn der Parameter VPCLASS jedoch das Wort "abgeschirmt" enthält, wechselt der Thread, der im CPU-VP 405 ausgeführt wird, zum abgeschirmten VP 409, so dass die Routine (gewöhnlich eine UDR) im abgeschirmten Speichersegment 412 ausgeführt werden kann. Der CPU-VP 405 leitet den Thread-Wechsel ein, indem er eine Datenbank-Kernroutine, mt_priv_call( ), aufruft, die wiederum mt_alloc_stack( ) aufruft, um einen Stapelspeicher (den abgeschirmten Stapelspeicher 416) im abgeschirmten Speichersegment 412 und nicht im Kernspeichersegment 402 zuzuordnen (Schritt 518).
Nachdem der Stapelspeicher zugeordnet wurde, nimmt mt_priv_call( ) einen Kontextwechsel vor, indem sie Parameter für die UDR in den abgeschirmten Stapelspeicher 416 eingibt (Schritt 520) und einen Thread-Eintrag in eine abgeschirmte Ausführungswarteschlange 414 einfügt (Schritt 522), die getrennt verwaltet wird, um nichtvertrauenswürdige Routinen auszuführen. Der abgeschirmte VP 409 führt anschließend die nichtvertrauenswürdige UDR im abgeschirmten Speichersegment 412 aus, wenn der in die Warteschlange gestellte Thread als Nächstes ausgeführt wird (Schritt 524).
Bei der Ausführung einer UDR kann der abgeschirmte VP 409 ohne Einschränkung Daten aus dem abgeschirmten Speichersegment 412 lesen und in dieses Segment schreiben, wird aber daran gehindert, Daten in das Kernspeichersegment 402 zu schreiben. Vielmehr hat der abgeschirmte VP 409 Nur-Lese-Zugriff auf das Kernspeichersegment 402, damit er nach Bedarf Daten im Segment 402 lesen kann, um die nichtvertrauenswürdige UDR auszuführen. Der abgeschirmte VP 409 kann über interne Routinen, die von der Multithreading-(MT-)Schnittstelle, der Server-Anwendungsprogrammschnittstelle (SAPI) und dem benutzerdefinierten Routinensprachmanager (UDRLM) bereitgestellt werden, auf Ressourcen zugreifen, die sich im Kernspeicher 402 befinden. Diese internen Routinen stellen fest, ob der Thread aufgrund der Leistung einer bestimmten Routine zwischen Speichersegmenten wechseln muss. Die SAPI-Schnittstellenbibliothek legt die unterstützten Routinen fest, die von einer UDR aufgerufen werden können. Eine SAPI-Routine erkennt nach dem Eintritt, dass der aktuelle Kontext nicht vertrauenswürdig ist. Wenn eine Routine, die in einem nichtvertrauenswürdigen Kontext ausgeführt wird, den Inhalt des Kernspeichers ändern muss, wechselt sie über mt_priv_call( ) in einen vertrauenswürdigen Kontext, führt die gewünschten Operationen durch und kehrt über einen weiteren Aufruf von mt_priv_call( ) wieder in dem nichtvertrauenswürdigen Kontext zurück. Ein Wechsel zwischen vertrauenswürdigen und nichtvertrauenswürdigen Kontexten kann auf diese Weise praktisch beliebig oft vorgenommen werden. Indem die Kontexte nach Bedarf selektiv gewechselt werden, kann sich der Ausführungs-Thread zwischen Speichersegmenten und VPS in einer Weise bewegen, die für die Client-Prozesse und die UDRs transparent ist.
Wenn der abgeschirmte VP während der Ausführung einer nichtvertrauenswürdigen Routine einen Befehl ausführt, der versucht, den Inhalt des Speichers im Kernspeichersegment zu ändern, während der Thread im abgeschirmten Speichersegment ausgeführt wird, wird der abgeschirmte VP daran gehindert. Folglich wird das Kernspeichersegment vor unsachgemäßer Änderung durch eine fehlerhafte UDR geschützt. Da die verschiedenen Operationen, die an der Ausführung nichtvertrauenswürdiger UDRs beteiligt sind, alle in demselben Speicheradressraum stattfinden, sind überdies nur lokale Aufrufe notwendig, um zwischen den Speichersegmenten zu wechseln, was die Geschwindigkeit und Zuverlässigkeit erhöht, mit der die Routinen ausgeführt werden können.
Nachdem die UDR ihre Ausführung im abgeschirmten Speichersegment 412 abgeschlossen hat, erfolgt die Rückkehr aus der Routine mt_priv_call( ), so dass der Ausführungs-Thread wieder zurück zum CPU-VP 405 im Kernspeichersegment 402 wechselt (Schritt 526). Da mt_priv_call( ) lediglich ein weiterer Aufruf des Stapelspeichers des Threads ist, wird der Thread durch die Rückkehr aus dieser Routine wieder in den Kontext zurückgeführt, aus dem er kam. Folglich hebt der Thread die Zuordnung aller Ressourcen, die er in dem abgeschirmten Speichersegment erzeugt hat, auf und beginnt mit der Ausführung im CPU-VP 405.
Zwar ist der Speicher des Datenbank-Servers in 5 in zwei Segmente 402 und 404 aufgeteilt, doch könnte auch eine Architektur mit mehr Speichersegmenten realisiert werden. Der Speicher des Datenbank-Servers könnte in drei oder mehr Segmente aufgeteilt werden – zum Beispiel in ein Kernsegment und zwei oder mehr abgeschirmte Segmente. Vertrauenswürdige Routinen können im Kernsegment ausgeführt werden, und UDRs können auf der Grundlage von verschiedenen Klassen, denen die UDRs zugeordnet wurden, in verschiedenen abgeschirmten Segmenten ausgeführt werden. UDRs, die in beträchtlichem Umfang auf ordnungsgemäßen Betrieb geprüft wurden und sich als zuverlässig erwiesen, könnten beispielsweise einer ersten VP-Klasse zugeordnet werden, während UDRs, die nur in geringem Umfang oder gar nicht geprüft wurden, einer oder mehreren anderen VP-Klassen zugeordnet werden könnten. Die UDRs, die sich als zuverlässig erwiesen haben und zu der ersten VP-Klasse gehören, könnten in einem Speichersegment ausgeführt werden, während die ungeprüften UDRs, die zu den anderen Klassen gehören, in getrennten Speichersegmenten ausgeführt werden könnten, um sie von den anderen UDRs zu isolieren. Indem man ungeprüfte UDRs auf diese Weise isoliert, würde nicht nur verhindert werden, dass sie den Inhalt des Kernspeichers des Datenbank-Servers verfälschen, sondern auch andere UDRs zum Absturz bringen.
Ferner vereinfacht die Verwendung von mehreren abgeschirmten Segmenten die Erkennung von Fehlern. Wenn mehrere UDRs in einem einzigen Speichersegment ausgeführt werden, kann die Feststellung, welche UDR fehlerhaft ist, schwierig sein. Indem man UDRs auf verschiedene Speichersegmente verteilt, kann eine fehlerhafte UDR unter mehreren UDRs ermittelt werden, indem man feststellt, welches Speichersegment verfälscht wurde.
Obgleich jeder VP als ein getrennter Prozess auf einer UNIX-basierten Plattform ausgeführt wird, könnte die Gruppe aller aktiver VPs auf anderen Plattformen als ein einziger Prozess mit mehreren Threads ausgeführt werden. Die Anzahl und die Arten von VPs, die in dem Datenbank-Server vorhanden sind, hängen von den Unternehmenszielen ab und sind eine Frage der Gestaltung durch den Systemadministrator. Jede Instanz eines VP ist eine Einheit mit mehreren Threads, die mehrere Client-Anfragen gleichzeitig entgegennehmen und verarbeiten kann. Bei jeder Klasse eines VP kann mehr als eine Instanz des VP zur selben Zeit aktiv sein. Beispielsweise können mehrere Instanzen des CPU-VP zur selben Zeit aktiv sein, wobei jede eine oder mehrere Client-Anfragen gleichzeitig bedient.
Ebenso kann es mehrere Instanzen des abgeschirmten VP geben, von denen jede eine oder mehrere UDRs parallel ausführt. Alternativ dazu kann eine einzige Instanz eines abgeschirmten VP alle URDs verarbeiten, oder jeder Aufruf einer nichtvertrauenswürdigen Routine kann von einer eigens dafür vorgesehenen Instanz des abgeschirmten VP bedient werden. Obgleich die VPs bei der Architektur von 5 statische Schreib-/Lese-Zugriffsberechtigungen verwenden (d. h. entweder uneingeschränkt oder abgeschirmt), sind verschiedene Architekturen möglich, bei denen die Berechtigungen für die VPs auf der Grundlage dessen, ob ein VP eine Routine ausführt, die vom Kernspeichersegment abgeschirmt werden soll, dynamisch geändert werden. Statt alle VP-Instanzen zum Zeitpunkt des Systemstarts zu erzeugen, könnte eine Instanz eines VP überdies dynamisch nach Bedarf erzeugt werden, zum Beispiel als Antwort auf den Aufruf einer nichtvertrauenswürdigen UDR.
In einer alternativen Ausführungsform kann ein abgeschirmter VP, der eine nichtvertrauenswürdige UDR ausführt, "Rückfragen" zum Kernspeicher vornehmen, um auf darin befindliche Ressourcen zuzugreifen, während die nichtvertrauenswürdige UDR weiterhin isoliert bleibt. Das IUS-System verwaltet eine Tabelle von zulässigen Routinenaufrufen, die im Kernspeicher befindliche Ressourcen ändern. Ein abgeschirmter VP kann beliebige der Routinenaufrufe aktivieren, die in der Rückfragetabelle verzeichnet sind, indem er die entsprechende ordinale Position in der Tabelle für die gewünschte Routine angibt. wie beispielsweise in 7 gezeigt ist, würde der abgeschirmte VP die Position zwei (2) in der Rückfragetabelle 600 angeben, wenn er die Routine (y) aufrufen wollte. Wenn ein nichtabgeschirmter VP als Nächstes den Thread wählte, der zuvor auf dem abgeschirmten VP ausgeführt wurde, um die angeforderte Routine im Kernspeicher auszuführen, würde der nichtabgeschirmte VP sicherstellen, dass die Speicheradresse, auf die der Routinenaufruf zeigt, ein zulässiger und sicherer Ausführungseintrittspunkt in den Kernspeicher ist, indem er bestätigen würde, dass die angeforderte Routine in der Rückfragetabelle 600 aufgeführt ist. Wenn die angeforderte Routine nicht in der Rückfragetabelle 600 aufgeführt wäre, würde die Ausführung der angeforderten Routine gesperrt werden – d. h., der nichtabgeschirmte VP würde die angeforderte Routine nicht ausführen. Auf diese Weise schränkt der Mechanismus in Form der Rückfragetabelle die Routinenaufrufe ein, die von einem abgeschirmten VP durchgeführt werden können, und verhindert dadurch, dass er an eine möglicherweise unzulässige Stelle im Kernspeicher springt.
Die Rückfragetabelle kann auf mindestens zwei verschiedene Arten realisiert werden. Erstens könnte die Rückfragetabelle eine Liste mit Adressen von zulässigen Routinen enthalten. Eine UDR, die einen Rückfrage zum Kernspeicher vornehmen möchte, würde einen Bezeichner eines Eintrittpunkts bereitstellen, der als Index in die Rückfragetabelle zu verwenden wäre. Ein nichtabgeschirmter VP würde die Routine, auf die der jeweilige von der UDR gelieferte Eintrittspunkt-Bezeichner zeigt, ausführen. Alternativ dazu könnte die Rückfragetabelle eine Liste von zulässigen Ausführungsadressen im Kernspeicher sein. Jeder von einer UDR angegebene Eintrittspunkt würde mit den in der Rückfragetabelle aufgeführten Ausführungsadressen verglichen werden, um die Gültigkeit des Eintrittspunktes zu bestätigen.
Die hier beschriebenen Methoden und Mechanismen sind nicht auf eine bestimmte Hardware- oder Software-Konfiguration beschränkt, sondern können in jeder Rechen- oder Verarbeitungsumgebung Anwendung finden, in der Datenbankoperationen ausgeführt werden können.
Die hier beschriebenen Verfahren können in Hardware oder Software oder einer Kombination von beiden ausgeführt werden. Vorzugsweise werden die Verfahren in Rechnerprogrammen realisiert, die auf programmierbaren Rechnern ausgeführt werden, von denen jeder einen Prozessor, ein von dem Prozessor lesbares Speichermedium (einschließlich flüchtiger und nichtflüchtiger Arbeits- und/oder Hauptspeicherelemente) und geeignete Eingabe- und Ausgabeeinheiten enthält. Programmcode wird auf Daten angewandt, die mit Hilfe einer Eingabeeinheit eingegeben werden, um die beschriebenen Funktionen auszuführen und Ausgabedaten zu erzeugen. Die Ausgabedaten werden einer oder mehreren Ausgabeeinheiten zugeführt.
Jedes Programm wird vorzugsweise in einer höheren prozeduralen oder objektorientierten Programmiersprache geschrieben, um mit einem Rechnersystem zu kommunizieren. Auf Wunsch können die Programme jedoch in Assembler- oder Maschinensprache geschrieben werden. In jedem Fall kann die Sprache kompiliert oder interpretiert sein.
Jedes dieser Rechnerprogramme wird vorzugsweise auf einem Speichermedium oder einer Speichereinheit (z. B. CD-ROM, Festplatte oder Diskette) gespeichert, das/die von einem programmierbaren Universal- oder Spezialrechner gelesen werden kann, um den Rechner zu konfigurieren und zu betreiben, wenn das Speichermedium oder die Speichereinheit von dem Rechner gelesen wird, um die beschriebenen Prozeduren auszuführen. Das System kann auch als ein rechnerlesbares Speichermedium realisiert werden, das mit einem Rechnerprogramm konfiguriert wird, wobei das so konfigurierte Speichermedium bewirkt, dass ein Rechner in einer ganz speziellen und vorher festgelegten Weise arbeitet.

Claims

Von einem Datenbank-Server (300) durchgeführtes Verfahren zur Ausführung oder Steuerung von Routinen, um Daten in einer Datenbank zu manipulieren, wobei das Verfahren die folgenden Schritte umfasst: Feststellen (506), ob eine Datenbankmanipulationsroutine beschränkten Zugriff auf die Datenbank haben soll; selektives Ändern (506) einer Speicherzugriffsberechtigung für die Datenbankmanipulationsroutine auf der Grundlage der Feststellung; und Ausführen (514, 524) der Datenbankmanipulationsroutine unter Verwendung der selektiv geänderten Speicherzugriffsberechtigung; dadurch gekennzeichnet, dass das Verfahren den weiteren Schritt des Setzens eines zu der Datenbankmanipulationsroutine gehörenden Parameters auf einen Wert beinhaltet, der eine Klasse einer Vielzahl von Klassen von Prozessoren (403, 405, 409) zur Ausführung der Datenbankmanipulationsroutine angibt; und der Schritt der Feststellung, ob eine Datenbankmanipulationsroutine beschränkten Zugriff auf die Datenbank haben soll, die Feststellung umfasst, ob die Datenbankmanipulationsroutine von einem angegebenen Bereich des Speichers (404, 406, 408, 410) isoliert werden soll, indem der zu der Datenbankmanipulationsroutine gehörende Parameter geprüft wird, wodurch die angegebene Prozessorklasse von dem angegebenen Speicherbereich isoliert wird.
Verfahren nach Anspruch 1, wobei die Prozessoren virtuelle Prozessoren sind.
Verfahren nach Anspruch 1 oder 2, wobei der Schritt der selektiven Änderung einer Speicherzugriffsberechtigung die Durchführung eines lokalen Prozeduraufrufs umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Schritt der selektiven Änderung einer Speicherzugriffsberechtigung das Setzen der Speicherzugriffsberechtigung für die Datenbankroutine auf "Nur Lesen" für den angegebenen Speicherbereich umfasst, wenn die Datenbankmanipulationsroutine als eine Routine festgestellt wird, die von dem angegebenen Speicherbereich isoliert werden soll.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Schritt der selektiven Änderung einer Speicherzugriffsberechtigung das Setzen der Speicherzugriffsberechtigung für die Datenbankmanipulationsroutine auf "Schreiben/Lesen" für den angegebenen Speicherbereich umfasst, wenn die Datenbankmanipulationsroutine als eine Routine festgestellt wird, die nicht von dem angegebenen Speicherbereich isoliert werden soll.
Verfahren nach einem vorhergehenden Anspruch, wobei die selektive Änderung den Wechsel eines Ausführungs-Threads für die Datenbankmanipulationsroutine von einem Prozessor, der eine Schreib-/Leseberechtigung für den angegebenen Speicherbereich hat, zu einem Prozessor umfasst, der eine Nur-Lese-Berechtigung für den angegebenen Speicherbereich hat.
Verfahren nach Anspruch 6, wobei der Wechsel das Belassen des Ausführungs-Threads in demselben Adressraum wie demjenigen des angegebenen Speicherbereichs umfasst.
Verfahren nach einem vorhergehenden Anspruch, wobei die selektive Änderung den Wechsel von einem vertrauenswürdigen Kontext, in dem ein Ausführungs-Thread für die Datenbankmanipulationsroutine eine Schreib-/Leseberechtigung für den angegebenen Speicherbereich hat, in einen nichtvertrauenswürdigen Kontext, in dem der Ausführungs-Thread eine Nur-Lese-Berechtigung für den angegebenen Speicherbereich hat, umfasst.
Verfahren nach Anspruch 8, das des Weiteren die Feststellung umfasst, dass der Ausführungs-Thread Zugriff auf eine Ressource benötigt, die sich in dem angegebenen Speicherbereich befindet, für den der Ausführungs-Thread Nur-Lese-Zugriff hat, um die Datenbankmanipulationsroutine auszuführen.
Verfahren nach Anspruch 9, das im Anschluss an die Feststellung, dass der Ausführungs-Thread Zugriff auf eine Ressource benötigt, die sich in dem angegebenen Speicherbereich befindet, des Weiteren einen Wechsel von dem nichtvertrauenswürdigen Kontext in einen anderen vertrauenswürdigen Kontext umfasst, in dem der Ausführungs-Thread eine Schreib-/Leseberechtigung für den angegebenen Speicherbereich hat.
Verfahren nach Anspruch 10, das des Weiteren den Wechsel von dem anderen vertrauenswürdigen Kontext in den nichtvertrauenswürdigen Kontext umfasst, nachdem der Ausführungs-Thread für die Datenbankmanipulationsroutine den Zugriff auf die Ressource in dem angegebenen Speicherbereich beendet hat.
Verfahren nach einem der Ansprüche 10 oder 11, das nach der abgeschlossenen Ausführung der Datenbankmanipulationsroutine des Weiteren den Wechsel von dem nichtvertrauenswürdigen Kontext in den vertrauenswürdigen Kontext umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die selektive Änderung die Durchführung einer beliebigen Anzahl von Wechseln zwischen einem vertrauenswürdigen Kontext und einem nichtvertrauenswürdigen Kontext umfasst.
Verfahren nach einem vorhergehenden Anspruch, wobei die Durchführung das Verbleiben in demselben Adressraum wie demjenigen des angegebenen Speicherbereichs umfasst, während die Datenbankmanipulationsroutine ausgeführt wird.
Verfahren nach einem vorhergehenden Anspruch, wobei die Durchführung die Ausführung der Datenbankmanipulationsroutine mit einem Prozessor umfasst, der eine Nur-Lese-Berechtigung für den angegebenen Speicherbereich hat, wenn die Datenbankmanipulationsroutine als eine Routine festgestellt wird, die von dem angegebenen Speicherbereich isoliert werden soll.
Verfahren nach einem vorhergehenden Anspruch, wobei die Durchführung die Ausführung der Datenbankmanipulationsroutine mit einem Prozessor umfasst, der eine Schreib-Lese-Berechtigung für den angegebenen Speicherbereich hat, wenn die Datenbankmanipulationsroutine als eine Routine festgestellt wird, die nicht von dem angegebenen Speicherbereich isoliert werden soll.
Verfahren nach einem vorhergehenden Anspruch, wobei die Durchführung die Ausführung der Datenbankmanipulationsroutine in einem Speichersegment umfasst, das logisch von dem angegebenen Speicherbereich getrennt ist, wenn die Datenbankmanipulationsroutine als eine Routine festgestellt wird, die von dem angegebenen Speicherbereich isoliert werden soll.
Verfahren nach einem vorhergehenden Anspruch, wobei die Durchführung die Ausführung der Datenbankmanipulationsroutine in dem angegebenen Speicherbereich umfasst, wenn die Datenbankmanipulationsroutine als eine Routine festgestellt wird, die nicht von dem angegebenen Speicherbereich isoliert werden soll.
Verfahren nach einem vorhergehenden Anspruch, wobei die Durchführung das selektive Zulassen der Änderung von Ressourcen umfasst, die sich in dem angegebenen Speicherbereich befinden.
Verfahren nach Anspruch 19, wobei die selektive Änderung auf einen oder mehr zulässige Ausführungseintrittspunkte in dem angegebenen Speicherbereich beschränkt ist.
Verfahren nach Anspruch 20, das des Weiteren die Angabe von dem einen oder der mehreren zulässigen Ausführungseintrittspunkte in einer Rückruftabelle umfasst.
Verfahren nach einem vorhergehenden Anspruch, das des Weiteren die gleichzeitige Ausführung einer Vielzahl von Datenbankmanipulationsroutinen in jeweiligen angegebenen Bereichen des Speichers umfasst, wobei jede Datenbankmanipulationsroutine Nur-Lese-Zugriff auf alle angegebenen Speicherbereiche mit Ausnahme ihres jeweiligen angegebenen Speicherbereichs hat.
Datenbank-Server zur Ausführung oder Steuerung von Routinen, um Daten in einer Datenbank zu manipulieren, wobei der Server Mittel umfasst, die ein Verfahren nach einem vorhergehenden Anspruch durchführen.
Rechnerprogrammprodukt zur Ausführung oder Steuerung von Routinen, um Daten in einer Datenbank zu manipulieren, wobei das Produkt ein rechnerlesbares Speichermedium mit einem darauf befindlichen Rechnerprogrammcode, der ein Verfahren nach einem der Ansprüche 1 bis 22 durchführt, oder einen Datenbank-Server nach Anspruch 23 umfasst.