Freilisten versus ASSM

Freilisten versus ASSM Günter Unbescheid Database Consult GmbH Jachenau 1 Schlüsselworte Freilisten, Freiplatzverwaltung, Automatic Segment Space Management, Instance Affinity 2 Zusammenfassung Seit dem Release 1 von Oracle9i stehen zur Verwaltung des Speicherplatzes in Segmenten - alternativ zu den althergebrachten verketteten Freilisten - Bitmap-Strukturen zur Verfügung. Dieses Merkmal wird unter dem Begriff Automatic Segment Space Management, kurz ASSM, zusammengefasst. Der Beitrag zeigt die internen Speicherstrukturen ASSM auf und vergleicht sie mit den Freilisten der Oracle-Versionen 7 und 8. Ziel dieses Beitrags ist es, die Vor- und Nachteile für den praktischen Einsatz von ASSM herauszuarbeiten. 3 Einführung Die Speicherplatzverwaltung innerhalb von Index-, Cluster- und Tabellen-Segmenten wird über interne Strukturen realisiert. Diese Strukturen geben den Transaktionen Auskunft darüber, welche Blöcke des betreffenden Segmentes für Einfügeoperationen zur Verfügung stehen, mit anderen Worten, welche Blöcke neue Datensätze prinzipiell aufnehmen können. Einfügeoperationen resultieren einerseits aus INSERT-Operationen, sind aber auch dann nötig, wenn Satzmigrationen auf Grund von UPDATE-Operationen und schlecht eingestellten PCTFREE-Parametern notwendig werden. Oracle9i bietet grundsätzlich zwei unterschiedlich organisierte Strukturen zur Verwaltung von Speicherplatz in Segmenten an: Zum Einen existieren verkettete Listen, die althergebrachten Freilisten, die im Folgenden kurz als Freilisten bezeichnet werden, und zum anderen Bitmap-Blöcke, die im Folgenden unter dem Namen Automatic Segment Space Management (ASSM) beschrieben werden. Beiden Organisationsformen ist gemein, dass sie ihre Daten nicht im Kontext des Data Dictionary, sondern in einem oder mehreren Datenblöcken speichern, die dem betreffenden Segment zugerechnet werden. Aus diesem Grunde gibt des keine DD-Views, die direkte Auskünfte über den Freiplatz einer Tabelle zurückgeben würden. Alle Anfragen, die den Freiplatz eines Segmentes betreffen, konzentrieren sich vielmehr auf

die Blöcke der genannten Speicherplatzverwaltung. Die Gefahr von Zugriffskonflikten in diesem Bereich wächst demnach mit der steigenden Anzahl von INSERT- oder migrierenden UPDATE-Operationen. Besonders kritisch kann die Lage in OPS 1 - oder RAC 2 -Umgebungen werden, da die Freilistenblöcke zentrale Ressourcen darstellen, die es zu synchronisieren gilt. Vor diesem Hintergrund ist die Organisationsform der Speicherplatzverwaltung, die im Folgenden beschrieben wird, ganz entscheidend wichtig, um performante Einfügeoperationen in Datenblöcke zu ermöglichen und gleichzeitig die Speicherplatz jedes Segments optimal auszunutzen. 4 Freilisten und Freilistengruppen Freilisten werden für alle Index-, Cluster- und Tabellen-Segmente, die in den folgenden Tablespaces angelegt werden, aufgebaut: Dictionary-managed Tablespaces oder Locally-managed Tablespaces, deren Segment Space Management Attribut den Wert manual trägt. Standardmäßig wird pro Tabelle eine Freiliste erzeugt. Mit Hilfe der Storage-Klausel kann die Anzahl der Freilisten jedoch direkt beim Anlegen des Segments oder nachträglich über einen ALTER-Befehl angepasst werden. Der Maximalwert ist abhängig von der Blockgröße der betreffenden Tablespace, bei 8K-Blöcken beträgt er beispielsweise 99. Im folgenden Beispiel wird die Anzahl der Freilisten für die Tabelle kunden auf 5 gesetzt. Die Anzahl der Freilisten kann mit dem ALTER-Befehl sowohl nach oben als auch nach unten korrigiert werden. ALTER TABLE kunden STORAGE (FREELISTS 5); Listing 4.1 Anpassung der Freilisten Freilisten können darüber hinaus in Gruppen, sogenannten Freilistengruppen, organisiert werden. Freilistengruppen bieten vor allem in OPS- und RAC-Umgebungen Vorteile 3, weil sie ihre Daten in separaten Blöcken und damit synchronisationsneutral abspeichern. Im Gegensatz zu Freilisten lässt sich die Anzahl Freilistengruppen jedoch nicht nachträglich anpassen, sondern muss direkt beim Anlegen des Segmentes spezifiziert werden. Im folgenden Beispiel wird die Tabelle kunden in minimaler Syntax mit 2 Freilistengruppen und pro Gruppe drei Freilisten angelegt: CREATE TABLE KUNDEN_FL1 ( KUNDE_ID NUMBER (10,0) NOT NULL, VORNAME VARCHAR2 (50), NACHNAME VARCHAR2 (50), 1 OPS = Oracle Parallel Server 2 RAC = Real Application Cluster 3 siehe hierzu den Abschnitt 4.4

STRASSE VARCHAR2 (50), PLZ VARCHAR2 (20), ORT VARCHAR2 (50), LAND VARCHAR2 (50) ) PCTFREE 20 PCTUSED 30 STORAGE ( INITIAL 64 K NEXT 64 K PCTINCREASE 0 FREELIST GROUPS 2 FREELISTS 3 ) / Listing 4.2 Tabelle mit Freilisten 4.1 Arten von Freilisten In der Einführung wurde vereinfachend von herkömmlichen Freilisten gesprochen. Genauer betrachtet lassen sich drei unterschiedliche Arten von Freilisten unterscheiden: Für jedes Segment wird automatisch eine Master-Freiliste (MFL) angelegt. Ihre Nutzung variiert, je nachdem, ob sie die einzige Freiliste des betreffenden Segmentes ist oder noch zusätzliche Prozessfreilisten oder Gruppen existieren. Zusätzlich können für jedes Segment über die FREELISTS-Klausel mehrere Prozess- Freilisten (PFL) angelegt werden. Der Freiplatz wird dann disjunkt über diese Listen verteilt. Die Prozesse werden auf der Grundlage ihrer Prozessidentifizierungsnummer mit den ebenfalls nummerierten Freilisten nach der folgenden Formel verbunden: PFL = mod(pid, NFL) + 1 Wobei: PFL = Nummer der Freiliste; PID = Prozessidentifizierungsnummer; NFL = Anzahl der Freilisten Zusätzlich zu den Prozessfreilisten wird immer auch eine Master-Freiliste als common pool angelegt. Sie dient als allgemeiner Überlauf und übernimmt beispielsweise Blöcke anderer Freilisten, wenn die Anzahl der Listen reduziert wird. Für jedes Segment stehen darüber hinaus mindestens 16 Transaktionsfreilisten (TFL) zur Verfügung, die im Bedarfsfall jeweils einer Transaktion zugeordnet werden. Transaktionsfreilisten verwalten Blöcke, die nach dem Commit der betreffenden Transaktion ihren Weg zurück in die Freilisten finden würden; mit anderen Worten: Blöcke, deren Füllung durch das Commit unter ihre PCTUSED-Grenze sinkt. Der Transfer der Blöcke von den Transaktionsfreilisten kann mit zeitlicher Verzögerung stattfinden.

4.2 Architektur von Freilisten Freilisten einer Gruppe werden stets innerhalb eines Oracle-Blockes angelegt. Hat das Segment nur eine Freilistengruppe, ist diese Bestandteil des Header-Blockes des betreffenden Segments. Die Strukturen von Freilisten lassen sich am Besten durch Blockdumps ermitteln. Im Dump 4.1 wird der Header-Block der Tabelle kunden_fl1 gezeigt. Die Dump-Datei wurde mit Hilfe des folgenden ALTER SYSTEM-Befehls erzeugt: ALTER SYSTEM DUMP DATAFILE <rel_file_no> BLOCK <block_no>; Listing 4.3 Dump erzeugen Die Tabelle kunden_fl1 wurde standardmäßig mit einer Freiliste innerhalb einer Gruppe angelegt. Start dump data blocks tsn: 9 file#: 9 minblk 9 maxblk 9 buffer tsn: 9 rdba: 0x02400009 (9/9) scn: 0x0000.0002cd3e seq: 0x01 flg: 0x04 tail: 0xcd3e1001 frmt: 0x02 chkval: 0x28b2 type: 0x10=DATA SEGMENT HEADER UNLIMITED Extent Control Header --------- Extent Header:: spare1: 0 spare2: 0 #extents: 2 #blocks: 15 last map 0x00000000 #maps: 0 offset: 4128 Highwater:: 0x0240001e ext#: 1 blk#: 5 ext size: 8 #blocks in seg. Hdr s freelists: 2 #blocks below: 12 mapblk 0x00000000 offset: 1 Unlocked Map Header:: next 0x00000000 #extents: 2 obj#: 28289 flag: 0x40000000 Extent Map --------- 0x0240000a length: 7 0x02400019 length: 8 nfl = 1, nfb = 1 typ = 1 nxf = 0 ccnt = 7 SEG LST:: flg: USED lhd: 0x0240001c ltl: 0x0240001d Dump 4.1 Segment Header-Block. Besprochene Passagen sind fett gekenzeichnet Die Abbildung zeigt den Block 9 der Datei mit der relativen Dateinummer 9. In hexadezimaler Notation ergibt sich daraus die relative Datenblockadresse (rdba) 0x02400009 in einer Länge von 4 Bytes, wobei die ersten 10 Bits für die Dateinummer und die restlichen 22 Bits für die Blocknummer reserviert sind. Der Typ 0x10 weist den Block als einen Header-Block aus, dessen Anzahl von Extents nicht begrenzt ist. Das Segment besteht derzeit aus 2 Extents, die beide im Rahmen des Header-Blockes verwaltet werden 4 und eine Größe von jeweils 8 Oracle-Blöcken haben der Header-Block des Segments im ersten Extent wird nicht mitgezählt. Damit hat das Segment 15 datenfähige Blöcke. Die auf und jenseits der Hochwassermarke (HWM) des Segments (highwater) liegenden Blöcke enthalten noch keine Datensätze, aus diesem Grunde werden sie auch nicht in den Freilis- 4 Hier ist die Extent-Verwaltung aus Sicht des Segments gemeint, die der Tablespace findet selbstverständlich im Data Dictionary oder den Bitmaps der Datei-Header statt.

ten erfasst. Die Blöcke diesseits der HWM dagegen sind entweder vollständig oder teilweise befüllt oder durch Löschen aller Datensätze ggf. auch leer. Auf jeden Fall muss jede full table scan-operation alle Blöcke des Segments, ob befüllt oder nicht, bis zur HWM lesen. Die HWM dieses Beispiels liegt bei 0x0240001e, das ist Block 30 in der Datei mit Nummer 9. Da das zweite Extent bei Block 25 (0x19) beginnt, liegt die HWM somit im fünften Block des zweiten Extents (ext#: 1 blk#: 5). Die Anzahl der Freilisten wird mit 1 angegeben (nfl = 1). Gleichermaßen ist die Anzahl der Blöcke, die Freilisteninformationen enthalten, ebenfalls 1 (nfb = 1). Die Freiliste ist damit wie bereits erwähnt in den Header-Block integriert. Der Status USED zeigt an, dass die Liste freie Blöcke enthält, d.h. Blöcke, deren Befüllung entweder die durch PCTFREE vorgegebene Grenze noch nicht erreicht hat oder aber unterhalb von PCTUSED liegt. Der erste freie Block liegt bei 0x0240001c, der letzte bei 0x0240001d; somit sind 2 Blöcke auf der Freiliste. Die Freilisten referenzieren wie jede verkettete Liste stets den Anfang und das Ende der Freibereiche; die Blöcke sind darüber hinaus untereinander durch Pointer verbunden, wie der folgende Blockdump zeigt: Start dump data blocks tsn: 9 file#: 9 minblk 28 maxblk 28 buffer tsn: 9 rdba: 0x0240001c (9/28) scn: 0x0000.0002ddfc seq: 0x01 flg: 0x06 tail: 0xddfc0601 frmt: 0x02 chkval: 0xbc1f type: 0x06=trans data Block header dump: 0x0240001c Object id on Block? Y seg/obj: 0x6e81 csc: 0x00.2d957 itc: 2 flg: O typ: 1 DATA fsl: 0 fnx: 0x240001d ver: 0x01... Dump 4.2 Headerbereich eines Datenblocks Die Kennzeichnung flg = O zeigt die Verfügbarkeit des Blockes an. Gleichzeitig wird auf den nächsten freien Block verwiesen fnx: 0x0240001d der in unserem Beispiel gleichzeitig die Freiliste beschliesst. An diesem Beispiel lässt sich leicht erkennen, dass die Freilisten keinerlei Informationen über den Freiplatz der betreffenden Blöcke enthalten. Angaben hierzu finden sich erst in den Headern der betreffenden Datenblöcke und sind den Transaktionen aus diesem Grunde erst dann zugänglich, wenn sie den Block eingelesen und den Header ausgewertet haben, wie das folgende Beispiel zeigt. Es ist leicht vorstellbar, dass durch ungünstige PCTUSED und PCTFREE-Werte der Platz zum Einfügen neuer Datensätze nicht ausreicht. In diesem Fall kann der Block vom System aus der Freiliste entfernt werden (UNLINK-Operation). Start dump data blocks tsn: 9 file#: 9 minblk 28 maxblk 28 buffer tsn: 9 rdba: 0x0240001c (9/28)... ntab=1 nrow=169 frre=-1 fsbo=0x164 fseo=0x8aa avsp=0x723 tosp=0xb19 Dump 4.3 Datenblock mit Freiplatzinformationen

Der verfügbare Platz (avsp) wird in diesem Dump ebenso ausgewiesen wie der gesamte Platz, der nach dem Abschluss aller offenen Transaktionen zur Verfügung stehen würde (tosp). Das Segment des folgenden Beispiels wurde mit drei Freilisten (nfl = 3) und einer Freilistengruppe angelegt. Alle Listen liegen aus diesem Grund in dem Header-Block des Segments (nfb = 1). Trotzdem werden im unteren Bereich des Dumps vier Listen (SEG LST) ausgewiesen: den drei Prozessfreilisten hat sich die obligatorische Master-Freiliste hinzugesellt. Von den angegebenen Listen wird derzeit nur eine genutzt, da das Segment diesseits der Hochwassermarke nur einen freien Block aufweist. Ein weiterer Block liegt in einer Transaktionsfreiliste (XCT LST), die der Transaktion mit der Kennung 0x000a.02c.00000105 zugeordnet wurde. Nach dem Commit der Transaktion und dem Cleanout des Blockes würde damit ein weiterer Block zur Verfügung stehen, so dass sich die Gesamtzahl von 2 Blöcken auf den Freilisten ergibt. Start dump data blocks tsn: 9 file#: 9 minblk 49 maxblk 49 buffer tsn: 9 rdba: 0x02400031 (9/49) scn: 0x0000.0003e738 seq: 0x01 flg: 0x00 tail: 0xe7381001 frmt: 0x02 chkval: 0x0000 type: 0x10=DATA SEGMENT HEADER UNLIMITED Extent Control Header --------- Extent Header:: spare1: 0 spare2: 0 #extents: 1 #blocks: 7 last map 0x00000000 #maps: 0 offset: 4128 Highwater:: 0x02400037 ext#: 0 blk#: 5 ext size: 7 #blocks in seg. hdr's freelists: 2 #blocks below: 5... nfl = 3, nfb = 1 typ = 1 nxf = 1 ccnt = 0 SEG LST:: flg: UNUSED lhd: 0x00000000 ltl: 0x00000000 SEG LST:: flg: UNUSED lhd: 0x00000000 ltl: 0x00000000 SEG LST:: flg: UNUSED lhd: 0x00000000 ltl: 0x00000000 SEG LST:: flg: USED lhd: 0x02400036 ltl: 0x02400036 XCT LST:: flg: USED lhd: 0x02400032 ltl: 0x02400032 xid: 0x000a.02c.00000105... End dump data blocks tsn: 9 file#: 9 minblk 49 maxblk 49 Dump 4.4 Header-Block eines Segments mit 3 Freilisten und einer Freilistengruppe (gekürzt) 4.3 Architektur von Freilistengruppen Die Erhöhung der Anzahl Freilisten führt wie dargestellt zu einer besseren Verteilung der Prozesse auf die Block-Pointer, aber nicht zu einer Verteilung des betreffenden IO- Verhaltens, da alle Listen im Header-Block des betreffenden Segments gehalten werden. Um hier Abhilfe zu schaffen, müssen mehrere Freilistengruppen angelegt werden, die jede für sich wiederum aus mehreren Freilisten bestehen können. Jede Gruppe wird in diesem Fall in einem eigenen Freilistenblock gespeichert, wodurch automatisch eine entsprechende Verteilung der Zugriffe erreicht wird. Die Blöcke für die Freilistengruppen werden unmittelbar hinter dem Header-Block des Segments aufgebaut; dies ist ein Grund dafür, dass die Anzahl der Freilistengruppen im Gegensatz zu der Anzahl der Freilisten nicht nachträglich durch ALTER-Befehle geändert werden kann. Die Tabelle des folgenden Beispiels wurde mit zwei Freilistengruppen und jeweils drei Freilisten angelegt:

Start dump data blocks tsn: 9 file#: 9 minblk 33 maxblk 33 buffer tsn: 9 rdba: 0x02400021 (9/33) scn: 0x0000.0002df25 seq: 0x01 flg: 0x00 tail: 0xdf251101 frmt: 0x02 chkval: 0x0000 type: 0x11=DATA SEGMENT HEADER WITH FREE LIST BLKS UN- LIMITED Extent Control Header --------- Extent Header:: spare1: 0 spare2: 0 #extents: 1 #blocks: 5 last map 0x00000000 #maps: 0 offset: 4128 Highwater:: 0x02400029 ext#: 0 blk#: 5 ext size: 5 #blocks in seg. hdr's freelists: 0 #blocks below: 5 mapblk 0x00000000 offset: 0 Unlocked Map Header:: next 0x00000000 #extents: 1 obj#: 28293 flag: 0x40000000 Extent Map --------- 0x02400024 length: 5 nfl = 3, nfb = 3 typ = 1 nxf = 0 ccnt = 0 SEG LST:: flg: UNUSED lhd: 0x00000000 ltl: 0x00000000 End dump data blocks tsn: 9 file#: 9 minblk 33 maxblk 33 Dump 4.5 Header-Block eines Segments mit FRELISTS = 3 und FREELIST GROUPS = 2 Der Dump zeigt trotzdem die Verteilung der Freilisten über drei Blöcke (nfb = 3) und auf drei Listen (nfl = 3): Der Segment-Header enthält den sogenannten common pool mit einer obligatorischen Master-Freiliste, die nicht in der nfl-zählung wohl aber unter nfb auftaucht und in unserem Beispiel noch nicht gefüllt ist. Die beiden Folgeblöcke speichern die beiden explizit angeforderten Freilistengruppen. Der Dump unseres Beispiels zeigt noch eine weitere Transaktionsfreiliste Start dump data blocks tsn: 9 file#: 9 minblk 34 maxblk 34 buffer tsn: 9 rdba: 0x02400022 (9/34) scn: 0x0000.0002df5c seq: 0x01 flg: 0x00 tail: 0xdf5c1601 frmt: 0x02 chkval: 0x0000 type: 0x16=DATA SEGMENT FREE LIST BLOCK WITH FREE BLOCK COUNT blocks in free list = 2 ccnt = 0 SEG LST:: flg: UNUSED lhd: 0x00000000 ltl: 0x00000000 SEG LST:: flg: UNUSED lhd: 0x00000000 ltl: 0x00000000 SEG LST:: flg: UNUSED lhd: 0x00000000 ltl: 0x00000000 SEG LST:: flg: USED lhd: 0x02400028 ltl: 0x02400028 XCT LST:: flg: USED lhd: 0x02400024 ltl: 0x02400024 xid: 0x0003.012.000000d4 Dump 4.6 Freilistenblock mit drei Prozess- und einer Transaktionsfreiliste 4.4 Zuordnung von Blöcken und Instanzen Bei der praktischen Nutzung von Freilistengruppen ist es vor allem wichtig zu verstehen, nach welchem Muster Datenblöcke auf die Freilistengruppen verteilt werden und wie im Umfeld von OPS und RAC die einzelnen Instanzen diese Gruppen nutzen. Die Zuordnung von Instanzen zu Freilistengruppen geschieht ähnlich wie bei der Verteilung von Prozessen auf Freilisten über ein Divisionsrestverfahren: FLG = mod(inst 1, NFLG) + 1

Hierbei bedeutet: FLG (Freilistengruppe), INST (Nummer der Instanz), NFLG (Anzahl der Freilistengruppen. Der Algorithmus führt dazu, das jede Instanz ihre eigene Freilistengruppe erhalten kann, wenn die Anzahl der Freilistengruppen identisch mit der Anzahl Instanzen ist. Umgekehrt teilen sich mehrere Instanzen ein Gruppe, wenn mehr Instanzen als Gruppen existieren. Für die Verteilung der Datenblöcke auf die Freilistengruppen und über diese auf spezifische Instanzen ist es notwendig, Extents explizit für jedes Segment anzulegen. Im folgenden Beispiel wird für die Tabelle kunden explizit ein Extent der Größe 50 Mbyte in der Datei u- sers_fl.dbf angelegt. Die Blöcke dieses Extents werden der entsprechenden Freilistengruppe hier die Gruppe 1 5 zugeschlagen. ALTER TABLE kunden ALLOCATE EXTENT (DATAFILE 'D:\ORACLE\ORA_9IR2\ORA_9IR2\USERS_FL.DBF' SIZE 50M INSTANCE 2) Listing 4.4 Explizites Anlegen von Extents Damit die entsprechende Instanz die neuen Blöcke tatsächlich für INSERT-Operationen nutzt und nicht auf ein beliebiges anderes Extent ausweicht, werden durch den ALTER TABLE-Befehl die Blöcke den Freilisten der vorgegebenen Freilistengruppe sofort zugerechnet und dort möglichst gleichmäßig auf die Freilisten verteilt. Dies wiederum ist nur dadurch möglich, dass die Hochwassermarke des betreffenden Segments nach oben angepasst wird! Dieses Verfahren weicht erheblich vom Standard ab, bei dem die Hochwassermarke erst dann verschoben wird, wenn die Freiliste keine Block-Kandidaten enthält. Das Verschieben der Marke führt darüber hinaus zu aufwendigeren und damit langsameren full table scan- Operationen. Extents, die nicht explizit, sondern implizit angelegt werden, werden dem Common Pool zugerechnet, der im Prinzip allen Instanzen offen steht. Blöcke, die durch DELETE-Operationen unter die PCTUSED-Grenze sinken und damit wieder zu INSERT-Kandidaten werden, werden der Freilistengruppe der Instanz des verursachenden Prozesses zugeschlagen. Auf diese Weise können Blöcke zwischen den Instanzen einer Datenbank migrieren. Jede Session wird zunächst der Instanz zugeteilt, über die sie mit der Datenbank verbunden ist. Jede Session kann jedoch auch die ihr zugeordnete Instanznummer explizit ändern, um damit den zur Verfügung stehenden Freiplatz in den Extents anderer Instanzen nutzen zu können. Die Änderung der Instanz der Session wird über den folgenden Befehl erreicht und ist nicht mit einem neuen CONNECT an das System verbunden: ALTER SESSION SET INSTANCE = 2 Listing 4.5 Setzen der Instanznummer 5 Freilistengruppen beginnen mit der Identifikationsnummer 0.

4.5 Suchalgorithmen Die konkrete Suche eines freien Blockes wird nach dem folgenden Schema in der dargestellten Reihenfolge abgewickelt. Es versteht sich, das die Suche im dem Moment beendet ist, wenn ein geeigneter Block gefunden wurde: 1. Suche in der TFL der eigenen Transaktion 2. Suche in der PFL, die dem eigenen Prozess in der betreffenden Freilistengruppe zugeordnet ist. 3. Suche in der MFL der eigenen Freilistengruppe und ggf. Transfer von bis zu fünf Blöcken in die eigene PFL. 4. Suche in den TFLs anderer Transaktionen, die bereits mit COMMIT beendet wurden, und ggf. Transfer der Blöcke über die MFL in die betreffende PFL. 5. Suche in der MFL des common pool im Header des Segments und ggf. Transfer der Blöcke. 6. Verschiebung der Hochwassermarke in Schritten von fünf Blöcken oder bis zum Ende des Extents. 7. Falls die Verschiebung nicht möglich ist, implizites Anlegen eines neuen Extents. 4.6 Charakteristische Merkmale von Freilisten Die vorangehenden Abschnitte haben Folgendes verdeutlicht: Die Prozesse müssen die offerierten Blöcke in der Reihenfolge der Verkettung abarbeiten, und nicht in Einklang mit ihren konkreten Speicheranforderungen. Zur Vermeidung von Zugriffskonflikten und IO-Engpässen müssen zusätzliche Freilisten und Freilistengruppen explizit angelegt werden. Die Kopplung von Prozessen und Freilisten ist starr. Jeder Prozess sucht nur in seiner PFL oder der MFL und nicht in den PFLs anderer Prozesse. Dadurch wird vorhandener Speicherplatz schlecht genutzt. Die Kopplung von Instanzen und Freilistengruppen ist ebenfalls starr. Die Suchalgorithmen berücksichtigen zwar bei Bedarf den Common Pool des Segments, niemals jedoch die Freilistengruppen anderer Instanzen! Wenn die einzelnen Extents nicht gut an den Platzbedarf der betreffenden Instanzen angepasst sind, kommt es zu unnötigen Speicherverbrauch durch das implizite Anlegen zusätzlicher Extents. Freilistengruppen, die Instanzen zugeteilt werden, führen zu zusätzlichem Verbrauch von Ressourcen beim vollständigen Lesen der betreffenden Tabellenobjekte. 4.7 Views und Prozeduren Neben den oben benutzten Blockdumps stehen einige Views und Prozeduren zur Verfügung, die zumindest einen Teil der dargestellten Informationen ausgeben können:

Views: DBA_SEGMENTS, DBA_EXTENTS Pakete: DBMS_SPACE, DBMS_SPACE_ADMIN 5 Automatic Segment Space Management Die automatische Verwaltung des Speicherplatzes in Segmenten (ASSM) steht in allen locally-managed Tablespaces zur Verfügung, die darüber hinaus die Klausel SEGMENT SPACE MANAGEMENT = AUTO gesetzt haben. Da ASSM im Kontext der Tablespace festgelegt wird, übernehmen alle in der betreffenden Tablespace gespeicherten Objekte diese Einstellung. Außerhalb dermaßen konfigurierter Tablespaces, d.h. in dictionary-managed oder locally-managed Tablespaces die ASSM auf MANUAL gesetzt haben, wird die Freiplatzverwaltung über die im Abschnitt 4 beschriebenen Freilisten und Freilistengruppen abgewickelt. Bei allen ASSM-Segmenten sind die Storage-Parameter PCTUSED, FREELISTS und FREE- LIST GROUPS außer Kraft gesetzt. Die Wiederverwendung der Blöcke und die Verteilung der Prozesse und Instanzen wird vielmehr implizit und automatisch geregelt, wie die folgenden Abschnitte darstellen. 5.1 Die Architektur von ASSM 5.1.1 Überblick ASSM verwaltet den Freiplatz innerhalb eines Segmentes über verschiedene Bitmap-Blöcke. Die Bitmap-Blöcke sind vergleichbar den Baumstrukturen von Indizes hierarchisch geordnet. Ausgehend von dem Header-Block eines Segmentes wird auf einen oder mehrere Level 2-Blöcke (L2) verwiesen, die wiederum auf Level 1-Blöcke (L1) zeigen. In den L1- Blöcken schließlich liegen die Bitmaps, die den Füllgrad der ihnen zugeordneten Datenblöcke mit Hilfe unterschiedlicher Bitmuster beschreiben. Je nach Anzahl der zu referenzierenden Datenblöcke kann die Baumstruktur um eine weitere Schicht Level 3 ergänzt werden, die wiederum über den Header-Block des Segments angesteuert werden kann und ihrerseits auf L2-Blöcke verweist. Darüber hinaus richtet sich die Anzahl der Datenblöcke, die über jeden L1-Block referenziert werden, nach der Gesamtgröße des Segmentes. Die Zahlen bewegen sich zwischen 16 und 1024 Blöcken. Diese Architektur zeigt bereits nach dieser groben Beschreibung die folgenden Vorteile: Der Füllgrad der Blöcke kann direkt aus der Bitmap abgeleitet werden. Die Füllgrade der Datenblöcke werden automatisch über mehrere Freilisten verteilt. Die differenzierte Referenzierung der Datenblöcke sorgt dafür, dass auch bei extrem kleinen oder großen Segmenten die Anzahl der L1-Blöcke eine ausreichende Verteilung der Zugriffe bei der Such nach Freiplatz garantiert.

Segment Header Level 2 Level 1 Level 1 Level 1 Bereiche von Datenblöcken Abbildung 5.1 ASSM Blockhierarchien Im Gegensatz zu Freilisten-Segmenten liegt bei ASSM-Objekten der Header-Block des Segmentes nicht am Anfang des ersten Extents. Vielmehr Beginnt das erste Extent mit L1- und L2-Blöcken, dann erst folgt der Header-Block und nach ihm schließlich die Datenblöcke. Werden zusätzliche Extents durch INSERT-Operationen angelegt und benötigen die in ihnen enthaltenen Datenblöcke zusätzliche Bitmap-Blöcke, werden diese am Anfang von nachfolgenden Extents aufgebaut. Tabelle KUNDEN 4 Extents mit jeweils 8 Blöcken Datenblöcke Segment-Header 1 L2/L1 Bitmap-Block B9 B10 B11 B12 B13 B14 B15 B16 E1 Datei 9 1 2 B25 B26 B27 B28 B29 B30 B31 B31 E2 Datei 9 B41 B42 B43 B44 B45 B46 B47 B48 E3 Datei 9 1 B49 B50 B51 B52 B53 B54 B55 B56 E4 Datei 9 Dezimale Angaben Abbildung 5.2 Blocktypen in ASSM-Segmenten

Die Abbildung 5.2 zeigt die Verteilung von Blocktypen am Beispiel der Tabelle kunden. Der Segment-Header ist dort der dritte Block des ersten Extents; ihm geht der einzige L2- Block voraus, der wiederum zwei L1-Blöcke am Anfang des ersten und dritten Extents referenziert. Wegen der geringen Größe der Tabelle existieren keine L3-Blöcke. 5.1.2 Header-Block Der folgende Dump zeigt Ausschnitte aus dem Header-Block des erwähnten Segmentes, der vom Typ 0x23 (pagetable) ist. Die verfügbaren Blöcke in den Freilisten werden pauschal mit 0 angegeben, weil die freien Blöcke hier über Bitmaps und nicht über Freilisten verwaltet werden. Im unteren Teil des Blockes findet sich der Verweis auf die L2-Blöcke; in der Mitte Verweise auf das Ende der L1-Kette sowie auf L2-Blöcke, die noch Platz zum Einfügen bieten. Auxillary Map schließlich ordnet die Extents den L1-Blöcken zu, die sie verwalten und gibt darüber hinaus der ersten Datenblock jedes Extents an. Der erste Datenblock muss nicht unbedingt der erste Block des Extents sein, da am Anfang des Extents noch Bitmap- Blöcke liegen können. Start dump data blocks tsn: 7 file#: 7 minblk 11 maxblk 11 buffer tsn: 7 rdba: 0x01c0000b (7/11) scn: 0x0000.0002d623 seq: 0x03 flg: 0x04 tail: 0xd6232303 frmt: 0x02 chkval: 0x5438 type: 0x23=PAGETABLE SEGMENT HEADER Extent Control Header --------- Extent Header:: spare1: 0 spare2: 0 #extents: 4 #blocks: 32 last map 0x00000000 #maps: 0 offset: 2716 Highwater:: 0x01c00039 ext#: 3 blk#: 8 ext size: 8 #blocks in seg. hdr's freelists: 0 #blocks below: 28... Level 1 BMB for High HWM block: 0x01c00029 Level 1 BMB for Low HWM block: 0x01c00029 Segment Type: 1 nl2: 1 blksz: 8192 fbsz: 0 L2 Array start offset: 0x00001434 First Level 3 BMB: 0x00000000 L2 Hint for inserts: 0x01c0000a Last Level 1 BMB: 0x01c00029 Last Level II BMB: 0x01c0000a Last Level III BMB: 0x00000000 Map Header:: next 0x00000000 #extents: 4 obj#: 28287 flag: 0x20000000... Auxillary Map Extent 0 : L1 dba: 0x01c00009 Data dba: 0x01c0000c Extent 1 : L1 dba: 0x01c00009 Data dba: 0x01c00019 Extent 2 : L1 dba: 0x01c00029 Data dba: 0x01c0002a Extent 3 : L1 dba: 0x01c00029 Data dba: 0x01c00031 Second Level Bitmap block DBAs DBA 1: 0x01c0000a End dump data blocks tsn: 7 file#: 7 minblk 11 maxblk 11 Listing 5.1 Header-block eines ASSM-Segmentes

5.1.3 L2-Blöcke Über den Header-Block führt der Weg in diesem Beispiel auf den einzigen L2-Block, der im folgenden Dump abgebildet ist. Die parent dba (pdba) weist von dort aus wieder zurück auf den Header-Block. Der Block enthält darüber hinaus Angaben zu der Anzahl der vom ihm verwalteten L1-Blöcke (number) und der Anzahl der L1-Blöcke, über die noch Freiplatz zur Verfügung steht. Schließlich werden die Block-Adressen der abhängigen L1-Blöcke zusammen mit der ihnen zugeordneten Instanz (Inst) und dem minimalen Füllungsgrad aufgelistet. Start dump data blocks tsn: 7 file#: 7 minblk 10 maxblk 10 buffer tsn: 7 rdba: 0x01c0000a (7/10) scn: 0x0000.0002e096 seq: 0x03 flg: 0x04 tail: 0xe0962103 frmt: 0x02 chkval: 0x2702 type: 0x21=SECOND LEVEL BITMAP BLOCK Dump of Second Level Bitmap Block number: 2 nfree: 2 ffree: 0 pdba: 0x01c0000b opcode:0 xid: L1 Ranges : 0x01c00009 Free: 5 Inst: 1 0x01c00029 Free: 5 Inst: 1 End dump data blocks tsn: 7 file#: 7 minblk 10 maxblk 10 Dump 5.1 L2-Block 5.1.4 L1-Blöcke L1-Blöcke verwalten die ihnen zugeordneten Datenblöcke über DBA-Bereiche (DBA Ranges). Jeder DBA-Bereich verweist auf ein Extent und in ihm auf einen Bereich fortlaufend adressierter Datenblöcke. Die Anzahl der Datenblöcke, die in einem DBA-Bereich enthalten sind, hängt von der Größe des Extents und der Anzahl DBA-Bereiche pro L1-Block ab. Die Anzahl der DBA-Bereiche pro L1-Blockes dagegen ergibt sich aus der Größe des betreffenden Segmentes, wie die nachfolgende Tabelle 5.1 im Detail zeigt. Die Größe des im nachfolgenden Dump referenzierten Segmentes beträgt 256 Kbyte. Die Daten befinden sich in 32 Blöcken und sind über 4 Extents mit jeweils 8 Blöcken der Größe 8 Kbyte verteilt. Folglich sind pro L1-Block 16 Datenblöcke zu referenzieren, dies ergibt zwei L1-Blöcke für das Segment. Da jeder DBA-Bereich sich nur auf ein Extent beziehen darf, werden pro L1-Block zwei DBA-Bereiche (nranges) mit jeweils 8 Blöcken benötigt (length). Start dump data blocks tsn: 7 file#: 7 minblk 41 maxblk 41 buffer tsn: 7 rdba: 0x01c00029 (7/41) scn: 0x0000.0002d627 seq: 0x03 flg: 0x04 tail: 0xd6272003 frmt: 0x02 chkval: 0x63ef type: 0x20=FIRST LEVEL BITMAP BLOCK Dump of First Level Bitmap Block -------------------------------- nbits : 4 nranges: 2 parent dba: 0x01c0000a poffset: 1 unformatted: 0 total: 16 first useful block: 1 owning instance : 1 instance ownership changed at 09/30/2002 16:51:10 Last successful Search 09/30/2002 16:51:10 Freeness Status: nf1 0 nf2 0 nf3 0 nf4 3 Extent Map Block Offset: 4294967295 First free datablock : 10 Bitmap block lock opcode 0

Locker xid: : 0x0000.000.00000000 Highwater:: 0x01c00039 ext#: 3 blk#: 8 ext size: 8 #blocks in seg. hdr's freelists: 0 #blocks below: 28 mapblk 0x00000000 offset: 3 HWM Flag: HWM Set DBA Ranges : 0x01c00029 Length: 8 Offset: 0 0x01c00031 Length: 8 Offset: 8 0:Metadata 1:FULL 2:FULL 3:FULL 4:FULL 5:FULL 6:FULL 7:FULL 8:FULL 9:FULL 10:75-100% free 11:75-100% free 12:FULL 13:75-100% free 14:FULL 15:FULL End dump data blocks tsn: 7 file#: 7 minblk 41 maxblk 41 Dump 5.2 L1-Block Segment-Grösse S <= 1 Mbyte Referenzierte Datenblöcke pro L1-Block 16 Datenblöcke 1Mbyte <= S <=32 Mbyte 64 Datenblöcke 32 Mbyte <= S <= 1 Gbyte 256 Datenblöcke 1 Gbyte <= S 1024 Datenblöcke Tabelle 5.1 Abhängigkeiten von L1-Blöcken und Segmentgrössen Im Mittelteil des Blocks werden zusammenfassende Informationen über die Anzahl der Blöcke in den unterschiedlichen Füllgraden (freeness status) und Hinweise auf den ersten freien Datenblock gegeben. Zur Beschreibung der Füllgrade wird jeder Datenblock in vier Sektionen eingeteilt, jede Sektion steht für einen Prozentsatz freien Platzes: Sektion % Freiplatz f1 zwischen 0% und 25% f2 zwischen 26% und 50% f3 zwischen 51% und 75% f4 zwischen 76% und 100% Tabelle 5.2 Freiplatz Stati von Datenblöcken Am Ende des Blockes werden schließlich die Stati der Datenblöcke im Einzelnen beschrieben. Hierfür stehen insgesamt vier Bits zur Verfügung, die folgende Bedeutung tragen: Bit 1: 1 = Block ist voll; 0 = Freiplatz wird durch Folgebits angezeigt

Bits 2-3 6 : 00 = mehr als 75%, 01 = mehr als 50%, 10 = mehr als 25%, 11 = weniger als 25% Bit 4: 1 = Block ist formatiert; 0 = nicht formatiert Nach wie vor wird jeder Datenblock als voll markiert, wenn er die vorgegebene PCTFREE- Grenze überschreitet. Da bei ASSM-Segmenten der Parameter PCTUSED fehlt, muss es alternative Regeln dafür geben, wann ein Block wieder befüllbar wird. PCTUSED wird bei ASSM durch die Sektionsgrenze ersetzt, d.h. sobald die Füllung eines vollen Blocks die nächste, untere Sektionsgrenze erreicht, steht dieser wieder für Einfügeoperationen zur Verfügung. 5.2 Suchalgorithmen Jede Transaktion, die in einem ASSM Platz für INSERT- oder UPDATE-Operationen benötigt durchläuft den folgenden Suchalgorithmus:: 1. Liegt ein geeigneter Datenblock im Buffer-Cache wird er geprüft und ggf. benutzt. Ansonsten: 2. Über den Hinweis L2 hint des Header-Blockes wird ein L2-Block ausgewählt und in diesem die Stati der enthaltenen L1-Blöcke geprüft. Eine Hash-Funktion auf Basis der Instanz- und Prozessnummern sorgt für die Verteilung der Suchläufe innerhalb des L2-Blockes. Die Suche wird in einem benachbarten L2-Block fortgesetzt, falls keine geeigneten L1-Blöcke verfügbar sind. Ansonsten werden bis zu 10 Blockadressen von L1-Blöcken gemerkt, die genügend Platz für die konkrete Einfügeoperation vorweisen und der betreffenden Instanz zugeordnet sind. 3. Der Startpunkt der Suche innerhalb der gemerkten L1-Blöcke wird ebenfalls über eine Hash-Funktion, in diesem Fall nur auf der Basis der Prozessnummer, ermittelt. Die Blockadressen der L1-Blöcke sind in 16er Reihen formatiert ; die Suche geht nach Ermittlung des Startpunktes Spaltenweise vor, so dass jeder 16te Block geprüft wird. Möglicherweise werden bei dieser Suche unformatierte Blöcke gefunden, die vor Benutzung natürlich formatiert werden müssen. Dieser Suchpfad garantiert eine gut verteilte Nutzung der über den L1-Block angebotenen Datenblöcke. 4. Werden keine geeigneten Datenblöcke über die L1-Blöcke der eigenen Instanz gefunden, können die anderer Instanzen übernommen werden. Auf diese Weise entstehen selbstkonfigurierende Freilistengruppen. 5. Ist die Übernahme geeigneter Datenblöcke aus anderen Instanzen nicht möglich, muss das Extent erweitert werden. 5.3 Anlegen von Extents in ASSM-Segmenten Extents in ASSM-Segmenten können sowohl implizit, d.h. angestoßen durch eine Einfügeoperation, oder explizit durch den ALTER TABLE-Befehl ausgelöst werden. In beiden Fällen wird das Extent an das Ende des betreffenden Segments gehängt. Betroffene Bitmap-Blöcke 6 Bei Indexblöcken wird nur ein Bit für die Zustandsbeschreibung benötigt, da sie nur befüllt werden, wenn sie vollständig leer sind.

werden angepasst oder neue angelegt für den Fall, das die bestehenden die Metadaten des neuen Extents nicht mehr fassen können. Sodann wird nur der erste Bereich an Datenblöcken in der Regel 16 an der Zahl formatiert und die entsprechenden Bitmaps werden angepasst. Werden Extents explizit unter Angabe der Instanznummer 7 angelegt, wird trotzdem nur eine weiche Verbindung zwischen der angegebenen Instanz und einem Teil der das neue Extent repräsentierenden L1-Blöcke hergestellt. Auf diese Weise steht der dynamischen Nutzung des neuen Extents durch anderen Instanzen nichts im Wege. 5.4 Hochwassermarken Die Abschnitte 5.2 und 5.3 haben gezeigt, dass die Datenblöcke der Extents nur schrittweise formatiert werden und die Suche nach Freiplatz über Hash-Algorithmen gestreut wird. Dieses Verhalten führt zwangsläufig dazu, dass es Bereiche gibt, in denen formatierte und unformatierte Datenblöcke koexistieren. Um diese Bereiche zu markieren, wurden in ASSM- Segmenten zwei unterschiedliche Hochwassermarken eingeführt: eine untere (low hwm) und eine obere Hochwassermarke (high hwm). Weitere Details zeigt die folgende Abbildung: Low HWM High HWM header formatiert gemischt unformatiert Full table scan Abbildung 5.3 Hochwassermarken in ASSM-Segmenten 5.5 Charakteristische Merkmale von ASSM-Segmenten Die in den vorangehenden Abschnitten beschriebenen Merkmale von ASSM-Segmenten und die sich aus diesen Merkmalen ergebenden Vorteile bei der Implementierung sollen im Folgenden noch einmal kurz zusammengefasst werden Die Bitmap-Blöcke beschreiben im Gegensatz zu herkömmlichen Freilisten sämtliche Blöcke eines Segmentes im Hinblick auf ihren Füllstand. Dadurch sind effektivere Suchalgorithmen möglich. Unnötiges Formatieren und das Anpassen der Hochwassermarke beim expliziten Anlegen von Extents entfällt. 7 Siehe hierzu Listing 4.4

Durch die Füllung der Bitmap-Blöcke in Abhängigkeit von Segmentgrößen entstehen automatisch unterschiedliche Blockgruppen, die eine Verteilung von Suchzugriffen garantieren. Die dynamische Bindung zwischen Bitmap-Blöcken und Instanzen nutzt den Speicherplatz von Segmenten besser aus und vereinfacht die Administration. Zu Recht werden aus diesen Gründen ASSM-Segmente für die Optimierung der Blockverwaltung empfohlen. Kontaktadresse Dr. Günter Unbescheid Database Consult GmbH D-83676 Jachenau Fon: 0172 8530790 Fax: 08043 1011 Mail: g.unbescheid@database-consult.de