-
Die vorliegende Erfindung bezieht sich allgemein auf die
Verwaltung von Betriebsmitteln und Sperren in einer Umgebung mit
Mehrfachverarbeitung und im Besonderen auf die Verwaltung der
Eskalierung von Sperren und des Parallelbetriebs in einer
solchen Umgebung.
-
Es ist bekannt, daß der Sperrenverwaltungsteil eines
Betriebssystems in einer Umgebung mit Mehrfachbetrieb den
Betriebsmitteln für die Prozesse Sperren zuweist und neu zuweist. Dieser
Vorgang kann zu einem Nachlassen des
Informationsverarbeitungsdurchsatzes durch häufiges Sperren eines Betriebsmittels
führen, bei dem die Parallelbetriebsanforderung sehr hoch ist,
d.h., ein Betriebsmittel, in dem eine große Anzahl von
Prozessen parallel ablauffähig sind. Der Sperrenverwalter muß daher
tatsächlich die Konkurrenzsituation verwalten, d.h., er muß
Verarbeitungszeit für das Sperren, Entsperren und Lösen von
Warte- und Wiederaufnahmebedingungen verwenden.
-
Eine wichtige Klasse von Mehrfachverarbeitungs- und
Mehrprogrammsystemen sind die Vergleichsdatenbanksysteme. In einer
Vergleichsdatenbank wird die Existenz von Daten in einer
Tabelle oder in mehreren Tabellen wahrgenommen. Jede Tabelle
besteht aus einer bestimmten Anzahl von Spalten und einer Anzahl
ungeordneter Reihen. Jede Spalte in einer Reihe steht in einer
bestimmten Weise mit den anderen Spalten in Verbindung. Ein
Vergleichsdatenbankverwalter greift auf Daten zu, indem er
sich auf ihren Inhalt und nicht auf ihre Lage, ihre
Organisation oder ihren Speicher bezieht. Während die Reihen einer
Vergleichstabelle keine feste Reihenfolge haben, ist die
Reihenfolge der Spalten jedoch immer die Reihenfolge, in der die
Spalten innerhalb der Tabellendefinition definiert wurden.
-
Ein Verwaltungssystem für eine Vergleichsdatenbank enthält
eine Abfragesprache, wie zum Beispiel die IBM-Sprache SQL/DS,
die im "SQL/Data Systems Concepts and Facilities Manual", IBM-
Veröffentlichung GH24-5065, Copyright 1984, beschrieben wurde.
SQL (Structured Query Language = strukturierte Abfragesprache)
ist eine System-Daten-Teilsprache, die sowohl eine
Datendefinitions- als auch eine Datenmanipulationskomponente enthält.
Die Sprache hat eine deklarative Form, in der die Befehle
Objekte erzeugen, verändern, zerstören oder manipulieren, so daß
der Vergleichsdatenbankverwalter einen optimalen Befehlspfad
für die Ausführung des Befehls formulieren kann.
-
Da ein Vergleichsdatenbankverwalter in eine
Parallelverarbeitungsumgebung gesetzt wird, verwendet er zum Beispiel
Einrichtungen wie Sperrenverwalter. In diesem Zusammenhang wird der
aktuelle Stand der Technik von C.J. Date, "A Guide to DB2",
Addison-Wesley Publishing Co., Copyright 1984, Seite 191-195;
C. J. Date, "An Introduction to Data Base Systems", Addison-
Wesley Publishing Co., Copyright 1986, Seite 422-427; und
Chamberlin et al, '' History and Evaluation of System R",
Communications of the Association of Computing Machinery, Oktober
1981, Seite 632-645, dargelegt. In den genannten Schriften
wird die Eskalierung von Sperren in einem
Vergleichsdatenbanksystem sowie ein auf einer Tabelle basierender
Sperreneskalierungsmechanismus in Verbindung mit der Sprache
SQL/DS offenbart. Bei dieser Technologie wird die
Sperrengranularität in Antwort auf die Zugriffserfahrung angepaßt.
-
Allgemein entsteht bei Systemen mit Mehrfachverarbeitung und
insbesondere bei Datenbankverwaltungssystemen ein Problem
dadurch, daß alternative Protokolle für die effiziente
Verwaltung der Eskalierung eines Sperrenprotokolls für ein
Betriebsmittel von einer Sperre kleiner Granularität zu einer
Sperre großer Granularität vorhanden sind, wenn die Anzahl der
auf einem Betriebsmittel gehaltenen Sperren kleiner
Granularität eine bestimmte Grenze erreicht.
-
In der Schrift von Chamberlin wird darauf hingewiesen, daß,
wenn ein Benutzer viele kleine Sperren akkumuliert, diese
gegen eine größere sperrbare Einheit "eingetauscht" werden
können. Zum Beispiel können Sperren vieler Datensätze in einer
Tabelle gegen eine Sperre der Tabelle eingetauscht werden.
-
In "Proceedings of the IFIP working conference on modelling in
data base management systems", Freudenstadt, Januar 1976,
Seite 365-394 (Graye et al), werden verschiedene
Granularitäten von Sperren erörtert. In diesem Vortrag wird nur der Fall
berücksichtigt, bei dem eine Transaktion (d.h. eine Anwendung)
die Sperrengranularität basierend auf der von ihr
durchgeführten Funktion festlegt. Unsere Erfindung stellt eine
Systemverwaltungsmöglichkeit (d.h., ein DBMS = Data Base
Management System = Datenbankverwaltungssystem) zur Verfügung.
Nicht die Anwendung, sondern das DBMS entscheidet, wann die
Granularität erhöht werden soll. In dem Vortrag konnte ich
keinen Hinweis auf einen Fall finden, in dem die Granularität
nicht von der jeweiligen Transaktion zugemessen wurde.
-
Es ist ein Ziel dieser Erfindung, den Informationsdurchsatz in
einem System durch Unterstützung der Ausführung asynchroner
gleichlaufender Prozesse zu beschleunigen. Ein damit
zusammenhängendes Ziel ist die Erfindung eines Verfahrens zur
effizienten Verwaltung des Parallelbetriebs und der
Sperrengranularität zwischen asynchronen gleichlaufenden Prozessen
und gemeinsam nutzbaren Betriebsmitteln. Ein weiteres Ziel ist
die Erfindung eines solchen Verfahrens zur besonderen
Verwendung in einem Verwaltungssystem für eine Vergleichsdatenbank.
-
Die oben genannten Ziele wurden unerwarteterweise durch ein
Verfahren erreicht, in dem ein koordiniertes Grenzpaar
verwendet wurde. Eine erste Grenze wird auf die Anzahl der Sperren
kleiner Granularität pro Betriebsmittel plaziert. Eine zweite
Grenze wird auf die Anzahl der Sperren plaziert, die jedem
Prozeß zugeordnet werden können. Wird die erste Grenze
erreicht, eskaliert dieses Verfahren automatisch die Größe der
Sperre für ein Betriebsmittel von einer Sperre kleiner
Granularität zu einer Sperre größerer Granularität. Einem Prozeß,
der eine zusätzliche Sperre anfordert, die ihn zu der zweiten
Grenze bringen würde, wird diese Sperre nicht gewährt. Das
kann dazu führen, daß ein anfordernder Prozeß beendet wird.
Daher führt die Erfindung zu einem Ausgleich zwischen dem
Parallbetrieb und der Leistung beim Zugriff oder bei der
Bezugnahme auf ein Betriebsmittel innerhalb einer gegebenen Größe
eines virtuellen Speichers, der für das Halten der Sperren zur
Verfügung steht.
-
Es wird anerkannt, daß nach dem zitierten bisherigen Stand der
Technik kollektiv eine Eskalierung von Sperren in einem
Vergleichsdatenbanksystem offenbart wird, welches einen auf
einer Tabelle basierenden Sperreneskalierungsmechanismus
enthält. Es wird darüber hinaus anerkannt, daß die Anpassung der
Sperrengranularität entsprechend der Zugriffserfahrung als
veraltete Technologie gilt. Man ist jedoch der Ansicht, daß
der aktuelle Stand der Technik ein Verfahren weder lehrt noch
vorschlägt, bei dem eine Sperreneskalierungsgrenze durch eine
Tabellendatei und eine Seitensperrungsgrenze durch einen
Prozeß eine bessere Kontrolle bei der Verwaltung des
Parallelbetriebs und der Sperrenspeicherung ermöglicht. Das heißt, jedes
System mit Mehrfachverarbeitung, dessen Betriebsmittel und
Prozesse durch Sperren unterschiedlicher Granularität
beherrschbar sind, kann aus dem Verfahren dieser Erfindung
Nutzen ziehen.
-
Die Erfindung, welche in den beiliegenden Ansprüchen definiert
wird, wird im folgenden ausführlich unter Bezugnahme auf die
beiliegenden Zeichnungen beschrieben, in denen
-
Figur 1 einen Überblick über die Vorbereitung und Anwendung
eines Befehlsstroms in einer Vergleichsdatenbank entsprechend
dem Stand der Technik zeigt,
-
Figur 2 eine Hierarchie von Objekten in einem typischen
Vergleichsdatenbanksystem zeigt,
-
Figur 3 Seitensperren im Vergleich mit Tabellendateisperren
zeigt.
-
Ein Parallelzugriff auf Daten in einem
Vergleichsdatenbanksystem wird primär durch Sperren auf Tabellendateien und
Indizes gesteuert. Eine Sperre sollte auf jeder Tabellendatei
erforderlich sein, auf die durch die manipulativen Verben in der
Datenzugriffssprache zugegriffen wird. Bei SQL/DS gehören
hierzu die Anweisungen SELECT (Auswählen), UPDATE
(Aktualisieren), INSERT (Einfügen) oder DELETE (Löschen).
Außerdem sollte eine Sperre auf Indexseiten erforderlich sein,
wenn die Seitensperrung wirksam ist und ein Indexpfad für den
Zugriff auf die Daten ausgewählt wird, oder wenn eine
Indexschlüsselspalte in den Daten verändert wird.
-
Man sollte beachten, daß Tabellendateien einen logischen oder
physischen Speicherbereich mit einschließen, in welchem
Tabellen gespeichert sind. Jede Tabellendatei hat einen maximalen
adressierbaren Bereich und kann einen oder mehrere Datensätze,
vorzugsweise VSAM-Datensätze, enthalten. Tabellendateien
werden in Einheiten gleicher Größe, "Seiten" genannt, unterteilt.
-
Wird eine Tabellendatei gesperrt, gibt es zwei mögliche
Sperrenprotokolle, die festgelegt werden können. Es sind dies (1)
die Tabellendateisperrung, in welcher die gesamte
Tabellendatei für einen Prozess gesperrt wird, so daß auf sie durch
andere Prozesse nur zugegriffen werden kann, wenn diese
kompatible Tabellendateisperren enthalten, und (2) die
Seitensperrung, bei der nur die einzelnen Seiten, auf die zugegriffen
wird, für einen Prozess gesperrt sind und auf die übrigen
Seiten
(auf diejenigen, die nicht gesperrt sind) von anderen
Prozessen zugegriffen werden kann. Mit anderen Worten, die
Indizes verwenden dasselbe Sperrenprotokoll wie die
Tabellendatei, welche die Tabelle enthält, auf der der Index erzeugt
wird. Beim Aktualisieren erhält man folglich mit der Sperrung
der Tabellendatei einen gezielten Zugriff auf die
Tabellendatei mit all ihren Indizes durch einen Prozeß, während man mit
der Seitensperrung einen Parallelzugriff auf die Tabellendatei
und ihre Indizes durch mehrere Prozesse erhält.
-
Jedesmal, wenn eine Sperre in einer Vergleichsdatenbank
erworben, verändert oder freigegeben wird, kommt es zu einem
definitiven Leistungsverlust in bezug auf die Länge des
Ausführungspfads durch den Sperrenverwalter. Während eine
Sperre gehalten wird, wird außerdem ein vorbestimmter Bereich
des virtuellen Speichers besetzt. Während also die
Seitensperrung zu einer größeren Parallelität als die
Tabellendateisperrung führt, ist sie dennoch durch einen Faktor der Anzahl der
Seiten, auf die zugegriffen wird, wesentlich leistungs- und
speicheraufwendiger. Die Auswahl eines Sperrenprotokolls
stellt demnach einen Kompromiß in bezug auf den
Parallelbetrieb und die Leistung im Speicher dar.
-
Wenden wir uns jetzt der Figur 1 zu, in der die Sequenz der
Vorgänge dargestellt ist, in der die in einer Anwendung
eingebetteten Definitions- und Zugriffsanweisungen einer
Vergleichsdatenbank aus der Anwendungskette herausgeführt und wie
bei einer Kompilierung verarbeitet werden, um Zugriffsmodule
zu bilden. Figur 2 zeigt eine Hierarchie von Objekten, die die
Bestandteile einer Vergleichsdatenbank sind. Hierzu gehören
eine Reihe von Tabellen und zugeordnete Indizes, sowie auch
die Tabellendateien, in welchen die Tabellen und Indizes
gespeichert sind. Bei Erzeugung einer Tabellendatei wird die
Datenbank, zu der eine Tabelle gehört, und die von ihr
verwendete Speichergruppe identifiziert. Ist keine von der Anwendung
festgelegte Datenbank und Speichergruppe vorhanden, verwenden
Speicherverwalter einer Vergleichsdatenbank normalerweise eine
Standarddatenbank und Standardspeichergruppe.
-
Figur 3 zeigt eine Syntax einer Definitionsanweisung für eine
Tabellendatei. Diese enthält eine Sperrengröße, welche die
Größe (Granularität) der Sperren ist, die auf einer
Tabellendatei gehalten werden.
-
In einem typischen Vergleichsdatenbanksystem ohne
Sperreneskalierung ist LOCKSIZE (ANY) (SPERRENGRÖSSE (BELIEBIG))
normalerweise ein Befehl an den Datenbankverwalter, die
Tabellendateisperre umzuwandeln. Wenn eine Reihe von
Datenbankanweisungen wie beim Kompilieren verarbeitet wird, ein Verfahren,
das "binding" genannt wird, ist es nicht sicher, wieviele
Seitensperren erworben und gehalten werden müssen, um die
Datenbankanforderung zu verarbeiten. Wenn zuviele Seitensperren
gleichlaufend von mehreren Benutzern gehalten werden, könnte
dies dazu führen, daß die virtuelle Sperren-Speicherkapazität
überschritten wird, was zu einer katastrophenähnlichen
Situation führen würde. Um dies zu vermeiden, verwendet man eine
Sperrung der Tabellendatei, um den für das Halten der Sperren
benötigten Speicherplatz zu begrenzen. Bei der
Sperreneskalierung wird die Seitensperre als Sperrenprotokoll ausgewählt, da
bei der Ausführung gegebenenfalls eine Eskalierung zur
Tabellendateisperrung erfolgen kann.
-
Während der Ausführung eines Prozesses, der auf eine
Tabellendatei LOCKSIZE ANY zugreift, führt das
Vergleichsdatenbanksystem vorzugsweise eine Zählung der Gesamtanzahl der
Seitensperren durch, die parallel gegen die Tabellendatei gehalten
werden. Erreicht diese Zählung den Grenzwert für die
Sperreneskalierung, der zum Zeitpunkt des CREATE TABLESPACE
(TABELLENDATEI ERSTELLEN) festgelegt wurde, führt der
Datenbankverwalter dynamisch eine Eskalierung des Sperrenprotokolls
auf der Tabellendatei von Seiten- auf Tabellendateisperre aus.
Außerdem erhält er keine weiteren Seitensperren. Bereits
gehaltene Seitensperren werden freigegeben. In dieser Situation
wird die Eskalierung der Sperre nur für den Prozeß
durchgeführt, der den Grenzwert getroffen hat. Die restliche
Ausführung dieses Prozesses gegen die Tabellendatei LOCKSIZE (ANY)
wird unter der Tabellendateisperre ausgeführt. Wird die
Sperreneskalierungsgrenze nie erreicht, bleibt die Seitensperre
für die gesamte Ausführung des Prozesses für die Tabellendatei
wirksam.
-
Die nun folgenden Abschnitte beziehen sich auf
Pseudo-Code-Sequenzen, die den Kontrollfluß für die Verfahrensschritte der
Erfindung darstellen. Bei diesen Sequenzen handelt es sich um
die Auswahl der Sperrengranularität eines Betriebsmittels, die
Überwachung der Nutzung eines Betriebsmittels, die Eskalierung
des Sperrenprotokolls auf die Tabellendatei, das Verweigern
einer Sperre oberhalb der Prozeßgrenze, sowie die Erzeugung
einer Seitensperrenstatistik.
-
Der folgende Pseudo-Code zeigt, wie durch die Implementierung
des Verfahrens der Erfindung das Sperrenprotokoll für eine
Tabellendatei als eine Funktion der ausgeführten SQL-Operation
und des LOCKSIZE-Parameters, der für die Tabellendatei
festgelegt war, ausgewählt wird.
-
In dem oben beschriebenen Code wird die Variable des
Sperren_Protokolls in der Laufzeitkontrollstruktur, welche die
Verwendung der Tabellendatei durch den Prozeß darstellt,
gehalten.
-
In der Erfindung wählt die Implementierung das
Seitensperrenprotokoll (höchste Parallelitätsebene), es sei denn,
-
o der Benutzer hat ausdrücklich ein Sperrenprotokoll
für die Tabellendatei festgelegt (mit LOCKSIZE
TABLESPACE), oder
-
o Seitensperrenprotokolle wären mit der Erwartung der
Tabellendateiverwendung unverträglich, das heißt,
die ausgeführte SQL-Operation erfordert eine
Tabellendateiabtastung mit gesperrten Daten bis zur
Festschreibung, was bei Seitensperrenprotokollen
äußerst ineffizient wäre.
-
In dem folgenden Pseudo-Code werden die Variablen
Laufende_Seiten_Sperren_Zählung_für Tabellendatei und
Maximale_Seiten_Sperren_Zählung_ für Tabellendatei in der
Laufzeitkontrollstruktur gehalten, die die Verwendung einer
gegebenen Tabellendatei durch einen Prozeß darstellt. Wird zu
Beginn der Prozeßausführung die Tabellendatei dem Prozeß
zugeordnet, werden diese beiden Zähler auf Null initialisiert.
Danach wird die Laufende_Seiten_Sperren_Zählung_für
Tabellendatei aufrechterhalten, um die tatsächliche Anzahl der
Seitensperren, die zu irgendeinem Zeitpunkt gegenüber der
Tabellendatei von einem Prozeß parallel gehalten werden,
wiederzugeben.
Die Maximale_Seiten_Sperren_Zählung_für Tabellendatei
wird aufrechterhalten, um die maximale Anzahl der
Seitensperren, die durch den Prozeß während der Lebensdauer seiner
Ausführung parallel in der Tabellendatei gehalten wurden,
wiederzugeben.
-
Die Variablen Laufende_Seiten_Sperren_Zählung_für Prozeß und
Maximale_Seiten_Sperren_Zählung_für Prozeß werden in der
Kontrollstruktur gehalten, die den Prozeß während der Ausführung
darstellt. Wird der Prozeß zugeordnet, werden diese beiden
Zähler auf Null initialisiert. Danach wird die
Laufende_Seiten_Sperren_Zählung_für Prozeß aufrechterhalten, um
die Gesamtzahl der Seitensperren wiederzugeben, die parallel
in allen Tabellendateien zu irgendeinem Zeitpunkt gehalten
werden. Die Maximale_Seiten_Sperren_Zählung_für Prozeß wird
aufrechterhalten, um die maximale Anzahl der Seitensperren
wiederzugeben, die von dem Prozeß parallel während der
Lebensdauer seiner Ausführung gehalten wurden.
-
Die Variable Sperren_Eskalierungs_Grenze_für Tabellendatei
wird in der Laufzeitkontrollstruktur gehalten, die die
Verwendung einer gegebenen Tabellendatei durch einen Prozeß
darstellt. Wird zu Beginn der Prozeßausführung die Tabellendatei
dem Prozeß zugeordnet, wird dieser Variablen der Wert
zugeordnet, der durch den LOCKSIZE-Parameter auf der CREATE
TABLESPACE-Anweisung festgelegt wurde, oder der Standardwert des
IRLMLKTS-Installationsparameters, wie weiter oben erläutert.
-
Die Variable Seiten_Sperren_Grenze_für Prozeß wird in der
Kontrollstruktur gehalten, die den Prozeß während der Ausführung
darstellt.
-
Wird der Prozeß zugeordnet, erhält diese Variable den Wert,
der durch den LOCKLIMIT-Parameter auf dem Befehl BIND
festgelegt wurde, oder den Standardwert des
IRLMLKUS-Installationsparameters, wie weiter oben erläutert.
-
Der Pseudo-Code zeigt die Schritte, welche unternommen werden,
um die durch die Tabellendatei und durch den Prozeß gehaltenen
Seitensperren zu verfolgen. Dieser Code wird nach Rückkehr vom
Sperrenverwalter (IRLM) für jede Seitensperrenanforderung
ausgeführt. Wenn entweder die Eskalierungsgrenze für die
Tabellendateisperre oder die Grenze für die Prozeßseitensperre
erreicht sind, wird eine out-of-line-Verzweigung auf eine
andere Prozedur gelegt, um den entsprechenden Vorgang
auszuführen.
-
Die folgende Analyse soll zur Erläuterung der Pseudo-Code-
Schritte beitragen:
Anforderung einer Seitensperre
-
o Wird eine neue Seitensperre erworben, wird der
zugehörige Seitensperrenzähler der Tabellendatei und
der Seitensperrenzähler des Prozesses stufenweise
erhöht, um das Halten dieser Sperre wiederzugeben.
-
o Werden als Ergebnis des Erwerbens dieser Sperre
entweder neue Seitensperrenhöchstwerte für
Tabellendatei oder Seitensperre erreicht, werden die
entsprechenden Maximalzähler aktualisiert, um die
neuen Höchstwerte zu registrieren.
-
o Wenn für diese Tabellendatei eine
Sperreneskalierung zur Anwendung kommt, wird der aktualisierte
Seitensperrenzähler für die Tabellendatei im
Vergleich mit der Sperreneskalierungsgrenze für die
Tabellendatei geprüft. Entsprechen sich diese
Werte, wird eine out-of-line-Verzweigung zur
Ausführung der Sperreneskalierung auf eine separate
Prozedur gelegt. Ist die Eskalierung erfolgreich,
fährt die Programmausführung nach dieser
Code-Passage wieder mit der Ausführung des nächsten Befehls
fort.
-
o Kommt keine Sperreneskalierung zur Anwendung oder
wurde die Grenze nicht erreicht, wird der
aktualisierte Seitensperrenzähler des Prozesses mit der
Seitensperrengrenze des Prozesses verglichen.
Entsprechen sich diese Werte, wird eine out-of-line-
Verzweigung auf eine separate Prozedur gelegt, um
die Sperre als ein nicht verfügbares Betriebsmittel
zu identifizieren, wodurch dann wiederum die
Beendigung des Prozesses eingeleitet wird.
Anforderung einer Aufhebung der Seitensperre
-
o Wird die Seitensperre aufgehoben, werden der
Seitensperrenzähler der Tabellendatei und der
Seitensperrenzähler des Prozesses stufenweise reduziert,
um anzuzeigen, daß diese Sperre nicht länger
gehalten wird.
Eskalieren des Sperrenprotokolls auf die Tabellendatei
-
Der nun folgende Pseudo-Code zeigt die Schritte, die für eine
Eskalierung des Sperrenprotokolls auf die Tabellendatei
durchgeführt werden.
-
Nachdem die Sperreneskalierung stattgefunden hat, wird
die
laufende Seitensperrenzählung des Prozesses um die Zahl der
Seitensperren reduziert, welche aufgehoben wurden, wobei es
sich um die Zahl handelt, die in der laufenden
Seitensperrenzählung der Tabellendatei enthalten ist. Letztere wird dann
zurückgestellt. Wird die normale Programmausführung wieder
aufgenommen, sind in dieser Tabellendatei keine Seitensperren
mehr erforderlich, weil der gesamte Seitensperrencode vom
Sperrenprotokoll abhängt.
Ablehnung einer Sperre oberhalb der Prozeßgrenze
-
Der folgende Pseudo-Code zeigt die Schritte, welche für das
Verweigern einer Seitensperre für einen Prozeß unternommen
werden, der seine Seitensperrengrenze erreicht hat. Hierdurch
wird ein Abbruch der gerade ausgeführten SQL-Operation
verursacht, was wiederum zur Beendigung des Prozesses führt.
-
Der obenstehende Code assembliert einfach die entsprechende
Fehlerinformation, welche an den SQL-Benutzer zurückgegeben
wird, und welche die Verletzung der Grenze der
Prozeßseitensperre als den Grund für den Abbruch der Operation
kennzeichnet. Der Code tritt dann in einen gemeinsamen Abbruchpfad ein,
der von allen Abbruchfehlerbedingungen gemeinsam genutzt wird.
Erzeugung einer Seitensperrenstatistik
-
Alle Prozesse erreichen in ihrer Ausführung letztlich eine
Stufe, in der sie festgeschrieben werden und ihre
Datenbankaktualisierungen permanent und für andere Prozesse sichtbar
gemacht werden, oder auf der sie abgebrochen und ihre Datenbank-
Aktualisierungen rückgängig gemacht werden. Am Ende einer
Festschreibung oder eines Abbruchs werden alle gegen alle
Tabellendateien gehaltenen Seitensperren des Prozesses
aufgehoben. An diesem Punkt ist das Ende des Umfangs der
Seitensperrung für einen Prozeß erreicht.
-
Um die Installationsinformation zu erhalten, mit deren Hilfe
die Speicherung und der Parallbetrieb für die Sperren eines
Prozesses bei der Festschreibung oder beim Abbruch eines
Prozesses verwaltet werden können, wird bei der Implementierung
der Methode der Erfindung eine Seitensperrenstatistik erzeugt,
welche die Höchstzahl der Seitensperren angibt, welche der
Prozeß parallel in jeder Tabellendatei während der Lebensdauer
seiner Ausführung gehalten hat.
-
Diese Statistik kann mit der Sperreneskalierungsgrenze der
Tabellendatei beziehungsweise mit der Seitensperrengrenze des
Prozesses verglichen werden. Die Erzeugung der Statistik hängt
davon ab, ob der Benutzer sie über die Leistungsverfolgung
(Performance Trace facility) angefordert hat.
-
Der folgende Pseudo-Code zeigt die Schritte, die unternommen
werden, um die laufenden Seitensperrenzählungen so anzupassen,
daß sie die aufgehobenen Seitensperren wiedergeben und dann,
falls gewünscht, eine Statistik der Seitensperre erzeugen.
Dieser Code wird bei der Festschreibung oder beim Abbruch
eines Prozesses ausgeführt.
-
Die
Seitensperrenstatistik ist direkt aus den Zählungen der
maximalen Seitensperren des Prozesses und der Tabellendatei
verfügbar, die in "Überwachung der Nutzung der Betriebsmittel"
geführt wurden.
Illustrative Beispiele der Methode
Auswahl der Startwerte für die Sperrgrenzen
-
Hierbei geht man so vor, daß die Startwerte für die
Installations-Standard-Sperreneskalierungsgrenze (IRLMLKTS) und die
Installations-Standard-Prozeßseitensperrengrenze (IRLMLKUS)
ausgewählt werden und daß dann mit diesen Startgrenzwerten
gearbeitet wird, wenn die Werte, die für die
Seitensperrenstatistik benötigt werden, und durch die eine Anpassung an
optimalere Grenzen erfolgt, gesammelt werden.
-
Die bei der Verwaltung der Speicherung und des Parallbetriebs
der Sperren beteiligten Schlüsselparameter sind folgende:
-
o der zum Halten der Sperren verfügbare Umfang des
Sperrenspeichers. Dieser wird durch die
Installation als Teil der Zuordnung des virtuellen
Speichers des Gesamtsystems für verschiedene Funktionen
festgelegt. Er wird als ein Installationsparameter
gesetzt.
-
Anmerkung: Ein gewisser Teil des Sperrenspeichers
muß für Sperrenanforderungen des Systems
bereitgehalten werden, die keine Seitensperren
sind. Im Vergleich zu dem Platz, der für
Datenseitensperren benötigt wird, ist dies ein festgelegter
und relativ kleiner Umfang.
-
o Die Anzahl der gleichlaufenden Prozesse, die in
einer oder mehreren Tabellendateien Seitensperren
durchführen.
-
o Die Anzahl der Tabellendateien mit
Seitensperrenprotokollen, auf die gleichzeitig von
einem Prozeß zugegriffen werden kann.
-
Nachfolgend eine Beispielberechnung der Startwerte für
IRLMLKTS und IRLMLKUS:
-
o Man nehme an, es stehen 100 KBytes Speicher für
Sperren zur Verfügung, fünf gleichlaufende
Prozesse, die Seitensperren bewirken können, und fünf
Tabellendateien mit Seitensperrenprotokollen, auf
die von jedem Prozeß gleichzeitig zugegriffen
werden kann. Für IRLM sind etwa 200 Bytes Speicher für
das Halten jeder Sperre erforderlich.
-
Hieraus ergibt sich:
-
o Die Gesamtzahl der Sperren, die gleichzeitig
gehalten werden können, beträgt = 100 KBytes / 200 Bytes
pro Sperre = 500.
-
o IRLMLKUS Zahl der Seitensperren, die gleichzeitig
von einem Prozeß gehalten werden können
= 500 Gesamtsperren / 5 gleichlaufende Prozesse
= 100.
-
o IRLMLKTS Anzahl der Seitensperren, die gleichzeitig
in einer Tabellendatei von einem Prozeß gehalten
werden können = 100 Sperren pro Prozeß /
5 Tabellendateien pro Prozeß = 20.
-
Diese Rechnung berücksichtigt die Situation, in welcher von
jedem Prozeß genau die Sperreneskalierungsgrenze für
Seitensperren in jeder Tabellendatei akkumuliert werden
könnte, wodurch der gesamte Speicher für die Sperren
aufgebraucht würde.
Sperroperation
-
Es wird eine Sperroperation mit fünf gleichlaufenden Prozessen
zugrundegelegt, wovon jeder auf dieselben fünf Tabellendateien
zugreift, mit den oben berechneten Sperrengrenzen. Man nehme
an, die fünf Tabellendateien haben die folgenden
Sperrenprotokolle:
Tabellendatei
LOCKSIZE
BELIEBIG
SEITE
-
Nimmt man an, daß alle Prozesse mit Seitensperrenprotokollen
zu allen Tabellendateien starten, so ergibt sich daraus
folgendes:
-
o Wenn irgendein Prozeß 20 Seitensperren in der
Tabellendatei A, B oder C akkumuliert, wird das
Sperrenprotokoll dieses Prozesses zu dieser
Tabellendatei von 'Seite' auf 'Tabellendatei' eskaliert.
Wenn ein ausschließlicher Zugriff auf die
Tabellendatei benötigt wird, muß der eskalierende Prozeß
warten, bis die anderen gleichlaufenden Prozesse
mit der Tabellendatei fertig sind, d.h., ihre
Seitensperren aufgehoben sind. Nachdem die Eskalierung
der Sperre erfolgreich ausgeführt wurde, werden die
20 Seitensperren, die in der eskalierten
Tabellendatei gehalten werden, aufgehoben und von der
Zählung der Seitensperren des Besitzprozesses
abgezogen.
-
o Jeder Prozeß kann Seitensperren bis 99 in der
Tabellendatei D oder E akkumulieren. Für diese
Tabellendateien galt, daß eine hohe Parallelität
gefordert wurde.
-
o Wenn irgendein Prozeß 100 Seitensperren, zum
Beispiel 10,10,10,20,50 in A-E akkumuliert, wird er
beendet. Wenn dies passiert, ist jedoch eine
Anpassung der Sperrenparameter erforderlich, um den
Prozeß unterzubringen, da es nicht angeht, daß ein
Prozeß nicht ablaufen kann.
-
o Die höchste Anzahl von Seitensperren, die
gleichzeitig von jedem Prozeß in jeder Tabellendatei
gehalten werden, wird gesammelt und am Ende der
Prozeßausführung als Statistik ausgegeben.
Analysieren der Seitensperrenstatistik
-
Man nehme an, daß am Ende des Ablaufs der oben beschriebenen
Prozesse folgende Seitensperrenstatistik erzeugt wurde:
Maximale Anzahl der gehaltenen Seitensperren
Tabellendatei
Prozeß
Proz. Gesamt
* weist darauf hin, daß eine Sperreneskalierung stattgefunden
hat.
-
Bei der Analyse dieser Statistik sind folgende Punkte
wesentlich:
-
o Keiner der Prozesse kam der Grenze für die
Prozeßseitensperre von 100 nahe. Die Höchstzahl der
Seitensperren, die gleichzeitig für das System
insgesamt gehalten werden konnten, betrug 215 (Summe der
Prozeßmaxima) gegenüber einer Kapazität des
Sperrenspeichers von 500. Somit war der Sperrenspeicher
bei weitem nicht ausgenutzt.
-
o Bei den Prozessen zeigten sich beträchtliche
Unterschiede in bezug auf den Grad der Seitensper-
rung.
-
o Bei den Tabellendateien A und B kam es zu einer
Sperreneskalierung, die, wenn sie auftrat, zu einem
Verlust in bezug auf die Parallelität bei diesen
Tabellendateien führte.
-
o Die Verwendung der Tabellendatei C durch
irgendeinen Prozeß erreichte nicht die
Sperren-Eskalierungsgrenze.
-
Der nächste Schritt ist die Einstellung der Sperrengrenzen auf
einen optimaleren Ausgleich zwischen Sperrenspeicherung und
Parallelbetrieb. Ein optimaler Ausgleich ist erreicht, wenn:
-
o der Sperrenspeicher voll, oder wenigstens fast
voll, ausgenutzt ist, was daran erkennbar ist, daß
alle Prozesse sich ihren jeweiligen
Seitensperrengrenzen für den Prozeß nähern, jedoch kein Prozeß
aufgrund des Erreichens dieser Grenze beendet wird.
-
Die Summe der Seitensperrengrenzen gleichlaufender
Prozesse sollte in etwa der Kapazität des
Sperrenspeichers für Seitensperren entsprechen.
-
o Das Sperrenprotokoll für Tabellendateien (LOCKSIZE
PAGE oder LOCKSIZE ANY) (SPERRENGRÖSSE SEITE oder
SPERRENGRÖSSE BELIEBIG) und die Sperren-
Eskalierungsgrenzen für anwendbare Tabellendateien
geben den gewünschten Grad der Parallelität zu
bezugnehmenden Prozessen wieder, wie er durch die
Installation festgelegt wird. Das heißt,
Tabellendateien mit hoher Parallelität haben
Seitensperrenprotokolle (LOCKSIZE PAGE) oder hohe
Sperren-Eskalierungsgrenzen (LOCKSIZE ANY LIMIT high_value),
und Tabellendateien mit geringer Parallelität haben
niedrigere Sperren-Eskalierungsgrenzen, je nach
ihrem Parallelitätsgrad.
Einstellen der Sperrenparameter
-
Nachfolgend werden alternative Schritte beschrieben, die zur
Verbesserung der Ausgewogenheit im oben beschriebenen Beispiel
möglich sind:
-
o Aus dem vorhandenen Sperrenspeicher eine höhere
Parallelität gewinnen:
-
-
Da die beiden Prozesse, welche die
Sperren-Eskalierungsgrenze auf den Tabellendateien A und
B treffen, über eine zusätzliche
Seitensperrenkapazität verfügen, wäre eine
mögliche Änderung das ÄNDERN des
Sperrenprotokolls auf diesen Tabellendateien auf LOCKSIZE
PAGE, wodurch diese voll parallel werden
können.
-
- Mehr Prozesse parallel ablaufen lassen, unter
der Annahme, daß andere Systembetriebsmittel
dies zulassen.
-
Nachdem einer dieser Schritte durchgeführt wurde,
sollte das System für eine bestimmte Zeit laufen,
um neue Statistiken über die Seitensperren zu
gewinnen, anhand derer dann weitere Einstellungen
möglich sind. Bei diesem Beispiel kann es sein, daß
immer noch zuviel Sperrenkapazität vorhanden ist,
was dann wiederum zu der folgenden Maßnahme führen
würde.
-
o "Zurückgeben" des ungenutzten Sperrenspeichers und
Ausgleichen der Parallelität im übrigen Speicher:
-
- Basierend auf den Prozessen, wie sie jetzt
ablaufen, werden nicht mehr als 215
Seitensperren gleichzeitig gehalten, was sich auf 43K-
Sperrenspeicher umwandeln läßt (gegenüber den
ursprünglich zugewiesenen 100K). Unter
Berücksichtigung eines gewissen Freiraums
könnten 50K zur Verwendung für andere Zwecke an
das System "zurückgegeben" werden. Der
Sperrenspeicher kann in der vorliegenden Methode
über den IRLMMCSA-Installationsparameter
verändert werden.
-
- Basierend auf der verbleibenden Kapazität des
Sperrenspeichers (50K), sollte die
Standardgrenze für die Prozeßseitensperre auf 50 und
die Standardgrenze für die Eskalierung der
Sperre auf 10 reduziert werden (im
vorliegenden Verfahren über die Installationsparameter
IRLMLKUS und IRLMLKTS).
-
- Durch Setzen individueller Grenzen für jeden
Prozeß kann im Vergleich mit den
Standardwerten eine ausgewogenere Einstellung verwendet
werden, die den Parallelitätsanforderungen
jedes Prozesses gerecht wird. Die Einschränkung
hierbei ist, daß die Summe der Prozeßgrenzen
die Kapazität des Sperrenspeichers nicht
überschreiten soll. Demnach wäre ein Satz von
Prozeß-Seitensperrengrenzen, der zu dem oben
genannten Beispiel passen würde, zum Beispiel
70,50,30,40,60 für die Prozesse 1-5, d.h. 70 +
50 + 30 + 40 + 60 = 250 maximale
Seitensperrenkapazität. Diese Grenzen können durch
Neubindung des Anwendungsplans für jeden Prozeß
und Festlegung der LOCKLIMIT-Parameter gesetzt
werden. Durch Setzen individueller Grenzwerte
für die Prozeßseitensperre kann jedem Prozeß
annähernd die Parallelität gegeben werden, die
er braucht, jedoch nicht mehr, als er braucht.
-
Die Auswahl dieser Grenzen muß sich jedoch auf
eine tatsächliche Betriebserfahrung gründen,
damit festgestellt werden kann, wie die
Sperrenstruktur für jeden Prozeß aussieht.
-
- Die Sperren-Eskalierungsgrenzen der
Tabellendateien A und B könnten auch
individuell zugeschnitten werden, um am besten zu den
Prozessen zu passen, von denen sie am
häufigsten parallel verwendet werden. Zum Beispiel
könnte die Tabellendatei C eine niedrigere
Eskalierungsgrenze, etwa 15, haben, zugunsten
von A und B, die höhere Eskalierungsgrenzen,
etwa 25, haben. Auch diese Auswahl sollte sich
auf tatsächliche weitere Betriebserfahrungen
gründen.