14 Synchronisation in Shared-Disk-DBS
Ein offenkundiges Problem bei einem zentralen Sperrverfahren ist, daß ein einziger GLM-Rechner leicht zum Engpaß wird und somit Durchsatz und Erweiterbarkeit des Systems beeinträchtigt. Dieser Nachteil kann jedoch relativ leicht behoben werden, indem die globale Sperrverantwortung auf mehrere dedizierte Rechner verteilt wird. Ein einfacher Ansatz dazu, der u.a. im Shared-Disk-System von Oracle (Parallel Server) verfolgt wird, ist die feste Aufteilung der GLA über eine Hash-Funktion, welche zu jedem Objektbezeichner den zuständigen GLM-Rechner bestimmt. Neben der Engpassgefahr wird damit auch die Verfügbarkeit verbessert, da ein GLM-Ausfall nur noch einen Teil der Datenbank betrifft (s. Übungsaufgaben).
Die Verwendung mehrerer dedizierter Rechner löst natürlich nicht das Problem der hohen Bearbeitungskosten von Sperranforderungen, wenn diese stets vom zuständigen GLM-Rechner zu bearbeiten sind. Im Falle von Spezialprozessoren (lock engines) zur GLM-Realisierung (Kap. 13.4.2), welche auch ein dediziertes Sperrprotokoll unterstützen, wird der hohe Kommunikationsaufwand durch spezielle Maschinenbefehle umgangen. Bei loser Kopplung kann der Kommunikations-Overhead durch Einsatz einer Nachrichtenbündelung reduziert werden. Dabei werden mehrere Sperranforderungen verschiedener Transaktionen eines Verarbeitungsrechners zusammen übertragen. Dies ermöglicht Einsparungen vor allem bei einem zentralen Sperrverfahren, wo sämtliche Anforderungen an einen GLM zu richten sind. Allerdings ergibt sich damit für die Antwortzeiten eine zusätzliche Verschlechterung, da eine Sperranforderung erst übertragen wird, wenn mehrere Anforderungen zusammen gekommen sind (bzw. ein Timeout abgelaufen ist).
Eine wirkungsvollere Optimierung ist, die Anzahl globaler Sperranforderungen zu zu senken, da dies sowohl die Antwortzeiten als auch den Kommunikations-Overhead verbessert. Dazu stellen wir im nächsten Kapitel (Kap. 15) zwei Ansätze vor.