Philipp Nebel, 05 IN. Speicherung von Datenbank-Objekten in Oracle

Transkript

1 Philipp Nebel, 05 IN Speicherung von Datenbank-Objekten in Oracle

2 1. Allgemeines Diese Ausarbeitung soll sich mit der Speicherung von Datenbankobjekten des RDBMS Oracle beschäftigen. Als Datenbankobjekte werden dabei hauptsächlich folgende bezeichnet : Tabellen (Relationale Tabellen, Objekttabellen, XML Tabellen) Views Materialized Views Indexe Cluster Package Prozeduren, Funktionen, Trigger Sequenz Objektypen usw... Datenbankinformationen liegen physisch als Folge von Bytes in den Oracle Datafiles. Logisch sind diese Informationen hierarchisch strukturiert. Die gröbste logische Unterteilung bzw. Einheit von Informationen ist der Tablespace. Oracle verwaltet sämtliche Objekte in Tablespaces. Ein Tablespace besteht aus mindestens einem Datafile, wobei ein Datafile zu genau einem Tablespace gehört. Tablespaces dienen der Trennung von Daten nach ihren semantischen Zusammenhängen und nach deren Wichtigkeit. So werden die Daten eines oder meherer Nutzer zum Beispiel von Metainformationen des DBMS getrennt. Da unterschiedliche Tablespaces auch unterschiedliche Datafiles belegen, erfolgt nicht nur eine logische sondern auch physische Trennung der Daten. An dieser Stelle sei das Problem der Fragmentierung erwähnt, welches später noch genauer betrachtet wird. Fragmentierung entsteht grundsätzlich durch nicht genutze Bytes in den Datafiles. Dies kann vorkommen, wenn bestimmte Parameter im Tablespace nicht optimal gewählt sind. Verschiedene Operationen haben ganz unterschiedliche Anforderungen an die Speicherverwaltung. So müssen zum Beispiel für Rollbackinformationen oder Zwischenspeicherungen für Sortierverfahren kurzzeitig Speicherbereiche alloziert und wieder freigegeben werden, wohin gegen das Data-Dictionary relativ gleichbleibenden Speicherbedarf hat. Um den SYSTEM Tablespace (in dem sich z.b. das Data-Dictionary befindet) vor der Fragmentierung zu schützen, die bei den dynamischen Anforderungen solcher Operationen entsteht zu schützen, gibt es für diese Operationen auch separate Tablespaces (UNDO, TEMPORARY). Weiterhin ist es sinnvoll, Rollbackinformationen auch physisch von den Nutzdaten zu trennen, am besten auf einer anderen Platte. Rollbackinformationen werden abgelegt um Transaktionen unter anderem nach einem Plattencrash rückgängig machen zu können. In diesem Fall hätte die Speicherung dieser Information auf der selben Platte nicht viel Sinn.

3 2. Strukur Die eben erwähnten Tablespaces bestehen ihrerseits aus Segmenten. Jedes Segment dient der Speicherung genau eines Datenbankobjekts. Der Speicher für ein Segment wird in Extents alloziert. Extents sind Bereiche von zusammenhängendem physikalischen Speicher, welcher nocheinmal in Blöcke (auch logical blocks, data blocks genannt) unterteilt ist. Database Tablespace Segment (Table) Extent Extent Extent Blocks Tablespace Segment (Index) Segment (Table) Abb. 1 In Abbildung 1 wird die logische Struktur bzw. Hierarchie von Oracle Datenbankobjekten dargestellt.

4 Datafile Datafile Extent Extent Extent Segment Segment Abb.2 In Abbildung 2 soll verdeutlicht werden, wie die Extents eines Segments, als die einer Tabelle oder eines Indexes liegen können. In diesem Beispiel kann man auch das Problem der Fragmentierung erkennen. Eine Scan-Operation durch das linke Segment würde den Lesekopf der Festplatte dazu zwingen, nach dem ersten gescannten Extent den Lesevorgang zu unterbrechen und durch eine mechanische Bewegung zum Start des nächsten Extents (in diesem extremen Beispiel in einem anderen Datafile) zu gelangen und dort den Lesevorgang wieder aufzunehmen. Diese Unterbrechungen kosten natürlich sehr viel Zeit und das Problem der Fragmentieren wächst mit zunehmendem Alter des Tablespaces.

5 2.1 Segment Jedes der Datenbankobjekte (Tabelle, Index,...) eines Tablespaces wird in genau einem Segment gespeichert. Werden zum Beispiel große Datenbanktabellen partitioniert, so erfolgt das über eine spearate Speicherung in verschiedenen Segementen. Ein Segment gehört immer genau zu einem Tablespace. Einem Tablespace sind in der Regel mehrere Segmente untergeordnet. Damit können sich mehrer Segmente in einem Datefile befinden. Der Speicher in Segmenten hat keine feste Größe. Segmente werden mit einer bestimmten Speichergröße angeleget und dann dynamisch bei Bedarf vergrößert. Diese dynamische Vergrößerung erfolgt auf Extent-Ebene und bringt das bereits genannte Problem der Fragmentierung mit sich. 2.2 Extent (Abgrenzung) Extents sind Bereiche von zusammenhängendem physischen Speicher in einem Datafile. Ein Segment besteht aus einem oder meheren Extents. Extents haben ein maximales Fassungsvermögen, welches durch den Datenbank-Administrator festgelegt werden kann. Dabei können die Extents eines Segments auch unterschiedlich groß sein. Auf dieser Ebene lassen sich einige Optimierungen vornehmen, die im Punkt 4 besprochen werden.. Wenn in einem Segment neuer Speicher alloziert werden soll, dann müssen gegebenenfalls neue Extents angelegt werden. Extents werden unabhängig von ihrem Segment nach einander im Datafile angelegt. Zum Beispiel fordert ein Segment A neuen Speicher im Datafile an, weil A zum Beispiel eine Tabelle darstellt, die neue Datensätze einfügen möchte. Daraufhin wird ein Extent alloziert. Danach fordert ein weiteres Segment B ebenfalls Speicher an. Beide Segmente liegen im selben Datafile, also wird das Extent für B hinter dem Extent für A angelegt. Falls A nun ein weiteres Extent benötigt, würde dieses hinter dem Extent für B angelegt werden. In diesem Fall ist der physische Zusammenhang des Segements A zerstört. Durch die logische Zugehörigkeit ist dies im Allgemeinen kein Problem. Allerdings wirken sich solche Verteilungen negativ auf die Performanz einiger Datenbank-Operationen aus. 2.3 Blöcke (data blocks, logical blocks) Extents werden in Blöcken alloziert. Blöcke sind die kleinste logische Einheit bei der Objektspeicherung von Oracle. Blöcke beziehen sich auf eine bestimmte Anzahl von aufeinander folgenden Bytes des physischen Datenbank-Speichers Die Größe der Blöcke kann mit dem Parameter DB_BLOCK_SIZE beeinflusst werden, mögliche Werte können 2 KB, 4 KB, 8 KB, 16 KB oder 32 KB sein. Probleme entstehen an der Stelle, wenn am Ende eines Datafiles eine Anzahl von nicht-allozierten Blöcken überig bleibt, aus der kein ganzes Extent mehr gebildet werden kann.

6 3. Allozierung von Extents. Die Allozierung von Extents kann auf verschiedenen Wegen gesteuert werden 3.1 auf Tablespace-Ebene Bei Erstellung des Tablespaces kann der Administrator festlegen, nach welcher Methode Oracle die Extents in diesem Tablespace generell allozieren soll. Dazu stellt Oracle die beiden Methoden UNIFROM und AUTOALLOCATE bereit. AUTOALLOCATE : Dies bedeutet, dass Oracle die Extents automatisch alloziert, also auch deren Größen selbstständig festlegt. Dabei wählt Oracle allerdings keine feste Größe für die Extents, sondern vergrößert die Extents mit fortlaufender Zeit. Das geschiet um stark wachsende Objekte nicht durch ständig notwendige Allozierungen zu fragmentieren. Eher soll so vorgegangen werden, dass je öfter ein Objekt neuen Speicher anfordern muss, desto mehr erhält es, damit zukünftige Speicheranforderungen bereits erfüllt /reduziert werden können. UNIFORM : Der Administrator kann bei der Erstellung des Tablespaces festgelegen, welche feste Größe die Extents dieses Tablespaces haben sollen. Legt der Administrator nur fest, dass die Extents uniform sein sollen, so werden alle Extents per Default mit 1 MB alloziert. Auch hier kann die Allozierung mit Fortschreiten der Zeit mehr Speicher anfordern. Der Administrator kann so Einstellungen vornehmen, die bei einer erwarteten Wachstumsrate der Objekte günstig sind. Vorraussetzung ist natürlich, dass eine Aussage über das Wachstum der Objekte in der Datenbank getroffen werden kann. Der zu verwendende Parameter nennt sich PCTINCREASE, was für Percentage Increase steht. Der Wert dieses Parameter gibt die Prozentzahl an, um die jedes Extents im Vergleich zum Vorgänger größer ist. Weiterhin kann nicht nur die initale Größe und das Wachstum angegeben werden, sondern auch die Größe des zweiten Extents mittels dem Parameter NEXT. Die Wachstumsrate bezieht sich dann auf diesen Wert Wenn also das erste Extent eine Größe von 100 M, NEXT 100 KB beträgt und ein PCTINCREASE von 50 angegeben wurde, dann werden sich die (theoretischen) Größen der Extents folgendermaßen entwickeln : 1. Extent : 1 MB 2. Extent : 100 KB 3. Extent : 150 KB 4. Extent : 225 KB 5. Extent : 337,5 KB Im praktischen Sinne muss natürlich hier gesagt werden dass Oracle ein Extent in Blöcken alloziert und seine Größe damit ein ganzzahliges vielfaches der Blockgröße annimmt.

7 Beispielanwendung CREATE TABLESPACE test_tablespace DATAFILE '/emc/oradata/test_tablespace1.dbf' SIZE 50M EXTENT MANAGEMENT LOCAL AUTOALLOCATE; CREATE TABLESPACE test_tablespace DATAFILE '/emc/oradata/test_tablespace1.dbf' SIZE 50M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 512K; 3.2 auf Objekt-Ebene Die Storage-Klausel kann auch nach CREATE bzw. ALTER Klauseln von Tabellen, Clustern, Indexen usw. aufgerufen werden. Hier überschreiben die Einstellungen für das jeweilige Objekt die Einstellungen des Tablespaces Das Extentgrößen auf Objekt-Ebene beeinflusst werden können sei hier nur am Rande bemerkt. In der Regel wird man auf solche Maßnahmen verzichten, es sei denn ein bestehender und in Verwendung befindlicher Datenbestand benötigt eine solche Änderungen, ohne neu erstellt werden zu können (Software-Update oder ähnliches) Beispielanwendung CREATE TABLE test Beispieltabelle 'Test' ( a number (8), s varchar2 (1000) ) TABLESPACE USERS STORAGE ( initial 1M next 100K minextents 1 maxextents 100 pctincrease 50 ); Test wird im Tablespace Users angelegt Das erste Extent hat die Größe 1 MB Das nächste Extent hat die Größe 100 KB Jedes weitere Extent ist 50 % größer als sein Vörgänger

8 4. Optimierung Wie können diese Informationen gewinnbringend genutzt werden? Dem Datenbankadministrator sind mit den oben aufgeführten Werkzeugen zur Steuerung der Extent-Allozierung von Oracle einige Möglichkeiten zur Optimierung gegeben. 4.1 Art der Allozierung Grundlage für die Optimierung des Allozierens ist die Oracle-Option "UNIFORM" als Gegensatz zu "AUTO ALLOCATE", welche als Allozierungsmethode beim Erstellen des jeweiligen Tablespaces angegeben wird. Bei AUTO ALLOCATE hat der Administrator keinen Einfluss auf die Art und Weise der Allozierung. Diese Option ist sinnvoll, wenn keine Aussage über das Wachstumsverhalten der Datenbankobjekte im Tablespace getroffen werden kann. Auch entsehen hierbei keine ungenutzten Speicherbereiche, da Oracle überstehende Blöcke am Ende eines Datafiles automatisch mit dem letzten Extents mitalloziert. Bei AUTOALLOCATE wird möglicherweise zunächst zu wenig Speicher alloziert, später wird zuviel Speicher alloziert. Höchstwahrscheinlich werden die Speicherbereiche auch nicht aufeinander folgen (da öfter alloziert werden musste). Mit uniformen Extents kann man für die jeweilige Anforderung die optimale Größe festlegen, so dass für ein Segment relativ wenige Extents alloziert werden müssen, und auf der anderen Seite keine zu großen Extents alloziert werden, die nur Speicherplatz verschwenden. Grundsätzlich kann die Optimierungsarbeit an der Extent-Größe als Kompromiss zwischen diesen beiden Faktoren betrachtet werden. Fragmentierung verschlechtert die Performance und kann durch große Extents (zusammenhängender Speicher) vermieden bzw. reduziert werden, was natürlich Speicherplatz kostet. Oft wird Speicherverlust in Kauf in genommen, um die gewünschte Performance zu gewährleisten und zu halten. Dazu ist zu bemerken, dass vorallem Scan-Operationen also Operationen, die von Natur aus eine relativ lange Laufzeit benötigen von großen Extents profitieren, da der Lesekopf der Platte kaum mechanisch bewegt werden muss um die großen Mengen an Information zu lesen. Der Administrator hat die Möglichkeit, eine Wachstumsrate für die Extents festzulegen, so dass er bestimmen kann, wie groß, dass erste Extent, das zweite und so weiter werden wird. In der Regel wird dazu geraten, Extents wirklich uniform, also auch ohne Wachstum zu allozieren.

9 4.1 Größe von Datafiles bei uniformen Extents Ein weiteres Problem neben der Fragmentierung von Segmenten ist die Speicherverschwendung durch nicht genutzte Blöcke am Ende von Datafiles. Da der Speicherplatz in Datafiles in Form von Extents hintereinander alloziert wird, können unter Umständen einige Datenblöcke am des Datafiles übrig bleiben, die allerdings nicht ausreichen um ein vollwertiges Extent zu bilden. Dieses Problem tritt nur auf, wenn der Datenbank-Administrator für den Tablespace eine uniforme Extentgröße festlegt, da Oracle bei automatischer Allozierung immer überprüft, wieviele Datenblöcke im Datefile übrig sind und ob diese ausreichen für das nächste Extent. Sind zu wenig Datenblöcke für das nächste Extent vorhanden, so werden die restlichen Blöcke dem gerade allozierten Extent mit angegliedert, da es keinen Sinn macht, diese Blöcke ungenutzt zu lassen. Da der Administrator in der Lage ist, die nicht nur die Größe der Extents sondern auch die der Datafiles festzulegen, sollte er sich bewusst sein, dass er an dieser Stelle mit einer durchdachten Größenvergabe das Problem der übrigbleibenden Datenblöcke völlig beseitigen kann. Dabei ist scheint es logisch, die Größe eines Datafiles so zu wählen, dass es ein Vielfaches der Blöcke belegt, wie ein Extent mit unformer Größe. So würde eine bestimmte Anzahl von Extents das Datafile komplett ausnutzen. Oracle verwendet allerdings in der Regel den ersten Block jedes Datafiles für interne Steuerinformationen. Achtung : Wenn Raw Devices zum Einsatz kommen, dann verwendet Oracle 2 Blocks. Daher sollten Datafiles grundsätzlich folgende Größe haben : Ein ganzzahliges Vielfaches der im Tablespace festgelegten Größe + 1 Blockgröße Beispiel : Ein Tablespace mit einer Blockgröße von 4 KB, uniforme Extents mit einer Größe von 5120 KB Größe des Datafiles (für x = 50) : x 5120 KB 4 KB=

10 Quellen : physikalische_strukturen.pdf