11g Release 2: Deferred Segment Creation und Zero Size Unusable Index
von Ulrike Schwinn, ORACLE Deutschland GmbH

Ressourcen effizient einsetzen durch optimale Ausnutzung des Speicherplatzes und Optimierung von Ausführungsplänen ist ein wichtiges Thema in 11g Release 2. Keine unnötigen Informationen sollen den Platz in der Datenbank verschwenden. Falls beispielsweise grosse Installationen viele Tabellen benötigen, die niemals befüllt werden, wäre es sinnvoll, keinen Speicherplatz zu allokieren. Ein anderes Thema ist die Verwendung und Speicherung von UNUSABLE Indizes. Auch sie verwenden in jedem Fall Platz, was bei grossen nicht mehr genutzten Indexpartitionen eine unnötige Speicherplatzverschwendung bedeutet. Dabei kann es zusätzlich zu nicht optimalen Ausführungsplänen kommen.

In 11g Release 2 ändert sich dieses Verhalten und folgende neue Features addressieren diese Anliegen:

  • Speicherplatz bei Bedarf - auch bekannt unter deferred segment creation
  • Segmentlose UNUSABLE Indizes - auch bekannt unter zero size unusable index
Was bedeutet dies nun für den Umstieg auf 11g Release 2?

Die Bezeichnung der beiden Features gibt schon einen Einblick in die Funktionalität. Speicherplatz bei Bedarf bedeutet für die Datenbank, dass erst nach dem ersten Einfügen von Daten automatisch die entsprechenden Segmente angelegt und Speicherplatz allokiert wird. Auch die Nutzung des Speicherplatzes für UNUSABLE Indizes oder Indexpartitionen hat sich geändert: Der gesamte Speicherplatz wird wieder freigegeben, wenn diese Objekte auf den Status UNUSABLE gesetzt werden. Indexpartitionen von älteren Daten, die nur selten im Zugriff sind, können nun gezielt auf UNUSABLE gesetzt werden und verbrauchen damit keinen Speicherplatz mehr. In diesem Zusammenhang ist auch der Zugriff auf Index-Partitionen optimiert worden. In den folgenden Abschnitten werden die beiden Features genau untersucht.

Deferred Segment Creation
Speicherplatz bei Bedarf ist ein einfach zu verwendendes Feature und ist automatisch eingeschaltet. Es bedeutet, dass neuangelegte Tabellen, zugehörige Index- und LOB-Segmente beim Anlegen mit CREATE TABLE keinen Speicherplatz verwenden. Erst nach dem Einfügen der ersten Zeile, wird das initiale Extent angelegt. Das folgende Beispiel zeigt eine einfache Verwendung.
CREATE TABLE no_seg (t number CONSTRAINT p_no_seg PRIMARY KEY, t1 date);
Table created. 

SELECT bytes FROM dba_segments  WHERE segment_name LIKE '%NO_SEG%';
no rows selected 

INSERT INTO no_seg VALUES (1,sysdate); 
1 row created. 

SELECT segment_name, bytes FROM dba_segments 
WHERE segment_name LIKE '%NO_SEG%'; 
SEGMENT_NAME BYTES 
------------ ----- 
NO_SEG	     65536 
P_NO_SEG     65536 
Beeinflussen lässt sich dieses Feature durch einen neuen Initialisierungsparameter, der auf System- oder auf Session-Ebene eingeschaltet werden kann. Folgendes Beispiel zeigt die Verwendung des Parameters und das Überlagern der Funktionalität mit der neuen CREATE TABLE-Syntax.
ALTER SESSION SET deferred_segment_creation=false;

CREATE TABLE no_seg (t number CONSTRAINT p_no_seg PRIMARY KEY, t1 date) 
SEGMENT CREATION DEFERRED;
Table created. 

SELECT bytes FROM dba_segments WHERE segment_name LIKE '%NO_SEG%';
no rows selected 
Allerdings gibt es im aktuellen Release einige Einschränkungen, über die man sich klar sein sollte. So können beispielsweise nur nichtpartitionierte Heap-organisierte Tabellen von diesem Feature profitieren. Mehr Informationen dazu finden sich im Handbuch Oracle Database SQL Language Reference 11g Release 2 (11.2) . Ausserdem gibt es im aktuellen Release (noch) keine Möglichkeit nachträglich durch ein TRUNCATE- oder ein ALTER TABLE- Kommando diese Technik der Speichernutzung bzw. -freigabe zu verwenden. Nur bei der Verwendung von UNUSABLE Indizes ist diesbezüglich eine Änderung eingetreten, wie im folgenden Abschnitt illustriert wird.

Zero Size UNUSABLE Index
Auch die Nutzung des Speicherplatzes für UNUSABLE Indizes oder Indexpartitionen hat sich geändert: Der gesamte Speicherplatz wird wieder freigegeben, wenn diese Objekte auf den Status UNUSABLE gesetzt werden. Indexpartitionen von älteren Daten, die nur selten im Zugriff sind, können nun auch gezielt auf UNUSABLE gesetzt werden und verbrauchen damit keinen Speicherplatz mehr. Als Beispiel nehmen wir eine LIST partitionerte Tabelle SALES_P mit zwei lokal partitionierten Indizes. Folgender Abschnitt zeigt das Setup.
desc sales_p
Name                           Null     Typ            
------------------------------ -------- ------------- 
PROD_ID                        NOT NULL NUMBER                                              
CUST_ID                        NOT NULL NUMBER                                                                        
TIME_ID                        NOT NULL NUMBER      
CHANNEL_ID                     NOT NULL NUMBER
PROMO_ID                       NOT NULL NUMBER        
QUANTITY_SOLD                  NOT NULL NUMBER(10,2)                 
AMOUNT_SOLD                    NOT NULL NUMBER(10,2)  

SELECT index_name, locality, partitioning_type FROM user_part_indexes 
WHERE table_name='SALES_P';

INDEX_NAME                     LOCALITY PARTITIONING_TYPE 
------------------------------ -------- ----------------- 
SALES_P_I                      LOCAL    LIST              
SALES_CUST_I                   LOCAL    LIST              
Auch die Enterprise Manager Console bietet einen guten Überblick über das Setup. Folgender Ausschnitt zeigt einen Ausschnitt der Seite "View Tables".


Für eine größere Ansicht auf das Bild klicken.

Der Status UNUSABLE der Index-Partition wird entweder manuell mit ALTER INDEX MODIFY PARTITION eingestellt oder erfolgt automatisch nach bestimmten Operationen. Folgende Liste zeigt einige Beispiele:
  • Partition Import oder conventional Path SQL*Loader
  • Partition Maintenance Operationen wie ALTER TABLE MOVE PARTITION
  • Partition Maintenance Operationen wie ALTER TABLE TRUNCATE PARTITION
  • Partition Maintenance Operationen wie ALTER TABLE SPLIT PARTITION
  • Index Maintenance Operationen wie ALTER INDEX SPLIT PARTITION
Was bedeutet nun der Status UNUSABLE? Ein UNUSABLE Index (kurz UI) verbraucht bis einschliesslich 11g Release 1 Speicherplatz und wird nicht mehr durch DML-Operationen gepflegt. Dies kann bei Massenladevorgängen natürlich von Vorteil sein kann. USABLE wird der Index oder die Indexpartition erst wieder nach einer expliziten REBUILD-Operation. Für Abfragen, die USABLE und UNUSABLE Index-Partitionen einschliessen, bedeutet dies im Normalfall auch, dass keine Index-Partitionsegmente für die Ausführung verwendet werden können. Dieses Verhalten hat sich in Release 2 geändert. Zur Überprüfung wird die Partition SALES_2 des Index SALES_P_I manuell auf UNUSABLE gesetzt. Im folgenden Listing wird die Segmentgröße überprüft.
ALTER INDEX sales_p_i MODIFY PARTITION sales_2 UNUSABLE;
alter index sales_cust_i successful.

SELECT segment_name, partition_name, bytes FROM user_segments 
WHERE partition_name = 'SALES_2' AND segment_type='INDEX PARTITION';

SEGMENT_NAME          PARTITION_NAME                 BYTES                  
--------------------- ------------------------------ --------- 
SALES_CUST_I          SALES_2                        65536                 
Nur noch die Partition SALES_2 des Index SALES_CUST_I ist in der Liste der Segmente zu finden.

Was bedeutet dies nun für den Ausführungsplan? Um einen Vergleich ziehen können, wird eine gemischte Abfrage in einer 10g und einer 11g Release 2 Umgebung ausgeführt. Dies kann ohne zusätzliche Installation über den Initialisierungsparameter OPTIMIZER_FEATURES_ENABLE realisiert werden. Im ersten Fall wird die Abfrage einfach mit dem Wert 10.2.0.4 ausgeführt. Der Parameter SKIP_UNUSABLE_INDEXES hat dabei den Standardwert TRUE.


Für eine größere Ansicht auf das Bild klicken.

Offensichtlich kann keine Indexpartition bei der Ausführung verwendet werden. Es erfolgt ein TABLE ACCESS über SALES_P.

Das gleiche Szenario wird nun in 11g Release 2 ausgeführt. Dazu wird der Parameter OPTIMIZER_FEATURES_ENABLE entsprechend verändert. Folgende Abbildung im SQL*Developer zeigt den neuen Ausführungsplan.


Für eine größere Ansicht auf das Bild klicken.

Bei gemischten Abfragen in 11g Release 2 können offensichtlich die verwendbaren (USABLE) Index-Partitionen zum Einsatz kommen. Dieses Verhalten kann allerdings nur eintreten, wenn die Indexpartition(en) zur Parsezeit bestimmt werden können. Ansonsten könnte beispielsweise der Einsatz von INDEX-Hints weiterhelfen.

Speicherplatzsparen vor 11g Release 2
Nicht vergessen sollte man die Methoden und die Techniken, die auch schon vor 11g Release 2 zur Speicherplatzeinsparung zur Verfügung stehen. Mit 11g beispielsweise gibt es viele Neuerungen im Bereich Komprimierung von Tabellen, LOBs und Backupdaten. Online Table Shrink- Operationen stehen schon in 10g zur Verfügung und geben die Möglichkeit online den Tabellenspeicher sogar unterhalb der Highwatermark zu reduzieren. External Tables sind seit Oracle 9i das geeignete Mittel, Datenmengen, die in Flat Files ausserhalb der Datenbank gespeichert sind, im READ-ONLY Zugriff zu haben. So können grosse Datenmengen aus Flat Dateien über External Tables einfach selektiert, über einen Join ausgewertet oder sortiert werden wie mit normalen Tabellen. Auch das Kommando ALTER TABLE ADD COLUMN mit Default Werten ist in 11g optimiert worden. Der Default Wert wird jetzt im Dictionary gespeichert statt Speicher- und Performance-intensive Updates auf die Spalten durchzuführen. Temporäre Tablespaces müssen nicht mehr gelöscht und neuerzeugt werden um den Tablespacespeicher zu verkleinern. In 11g übernimmt diese Aufgabe ein ALTER TABLESPACE SHRINK SPACE- oder SHRINK TEMPFILE- Kommando.
Mehr Informationen zu diesen Themen finden Sie beispielsweise in den folgenden Tipps.
Mehr zu diesem Thema bzw. zu weiteren Themen rund um die Datenbank lesen Sie in den nächsten Ausgaben ...



Zurück zur Community-Seite