Liebling ich habe den Export geschrumpft

Vorwort

Der wichtigste Punkt, Unregelmäßigkeiten bei Ihrem Export festzustellen ist, das Logfile und die Export Parameter zu überprüfen. Weiterhin sollten auch immer mal wieder Imports in eine Testdatenbank erfolgen.

Manch einem stellt sich jedoch auch beim Blick auf die Größe des Exportfiles die Frage, „ist mein Export fehlerhaft?“. Denn das Exportfile kann deutlich kleiner sein als die Datenbank selbst. Wie klein ist jedoch „zu klein“? Wie groß sollte mein Exportfile in ganz grober Näherung sein? Wieviel Platz muss ich im Filesystem für den Export mindestens vorhalten? Dies wird in den folgenden Kapiteln erläutert.

Da wir nur eine schnelle, überschlagsweise Prüfung benötigen, vernachlässigen wir an dieser Stelle Features wie zum Beispiel die Komprimierung, durch die die Exportgröße noch weiter reduziert werden kann.

Weiterhin werfen wir keinen Blick auf die „ESTIMATE“ Angabe, denn diese wird durch den Export selbst geschätzt und dient uns damit nicht wirklich der Kontrolle.

Des Weiteren wird auch dadurch, dass die Daten im Exportfile nicht in der Oracle Block Struktur gespeichert sind, die Größe des Exports beeinflusst. Hierbei spielen jedoch viele Faktoren eine Rolle und diese müssten zudem für jedes System einzeln bestimmt werden. Für einen groben Überschlag ist das viel zu viel Aufwand, so dass wir auch diese Abweichung an dieser Stelle vernachlässigen.

Auch wenn einige dieser Punkte auch für den klassischen Export gelten bezieht sich dieser Tipp, ausschließlich auf den Oracle Datapump Export. 

Indizes

Indizes speichern den indizierten Wert und unter anderem die Blockadresse der entsprechenden Row. Da sich nach einem Import diese Adresse ändert, macht es keinen Sinn die Daten des Index zu exportieren. Deshalb enthält der Export nur die Metadaten des Index. Daraus wird dieser beim Import neu erstellt.

Bei einer Datenbank mit vielen sehr stark indizierten Tabellen kann das eine erhebliche Einsparung an Speicherplatz für den Export bedeuten.

ORACLE_MAINTAINED Objekte

Seit der Version 12c gibt es in der View DBA_OBJECTS eine Spalte mit dem Namen ORACLE_MAINTAINED. Die entsprechende Stelle dazu aus der 12c Dokumentation lautet wie folgt:

Denotes whether the object was created, and is maintained, by Oracle-supplied scripts (such as catalog.sql or catproc.sql). An object for which this column has the value Y must not be changed in any way except by running an Oracle-supplied script.

Auch dies beeinflusst die Größe des FULL Exports. Alle Objekte die ein „Y“ bei ORACLE_MAINTAINED haben werden in einem FULL Export nicht exportiert. Dies betrifft auch unter anderem den Statspack User. Deswegen kann es sich lohnen, zu überprüfen wie das Verhältnis zwischen ORACLE_MAINTAINED und normalen Objekten in der Datenbank ist.

SELECT
    ORACLE_MAINTAINED,
    COUNT(ORACLE_MAINTAINED) AS OMC
FROM
    DBA_OBJECTS
GROUP BY
    ORACLE_MAINTAINED;

O        OMC
- ----------
Y      61741
N       1103

Gerade wenn Sie frisch von, zum Beispiel 11g auf 12c, gewechselt sind, kann sich der Export stark verkleinern.

Oracle Recycle Bin

Wenn Sie den Recycle Bin in Oracle aktiviert haben und dieser nicht geleert wird, können Sie auch hier getäuscht werden. Dann nämlich, wenn Sie zum Beispiel für einen groben Blick folgenden SELECT verwenden:

SELECT
    ROUND(SUM(BYTES)/1024/1024) AS MB
FROM
    DBA_SEGMENTS;

        MB
----------
      6386

Objekte im Recycle Bin werden nämlich nicht exportiert. Um hier zu einer realistischeren Einschätzung zu kommen, müssen Sie die Objekte, die im Recycle Bin liegen, aus der Abfrage ausschließen und es wird gleich weniger Volumen angezeigt.

SELECT
    ROUND(SUM(BYTES)/1024/1024) AS MB
FROM
    DBA_SEGMENTS
WHERE
    SEGMENT_NAME NOT LIKE 'BIN%';

        MB
----------
      4604

Leere Tabellen mit hoher High Water Mark

Gerade wenn Tabellen über ein DELETE Statement geleert werden, bleibt der Speicher noch für die Tabelle allokiert, obwohl keine Inhalte mehr enthalten sind. Dies verdeutlicht folgendes Beispiel:

SET LINESIZE 1000
COL OWNER FOR A30
COL SEGMENT_NAME FOR A30
SELECT
    OWNER,
    SEGMENT_NAME,
    SEGMENT_TYPE,
    ROUND(SUM(BYTES)/1024/1024) AS MB
FROM
    DBA_SEGMENTS
WHERE
    OWNER NOT IN ('PERFSTAT','SYS','AUDSYS','WMSYS','XDB','SYSTEM')
GROUP BY
    OWNER,
    SEGMENT_NAME,
    SEGMENT_TYPE
ORDER BY
    4;

OWNER                    SEGMENT_NAME             SEGMENT_TYPE               MB
------------------------ ------------------------ ------------------ ----------
...
USER01                   TAB04                    TABLE                      88
USER02                   TAB03                    TABLE                      88
USER02                   IDX01                    INDEX                      96
USER01                   TAB02                    TABLE                     248
USER01                   TAB01                    TABLE                     816

SELECT
    COUNT(*)
FROM
    USER01.TAB01;

  COUNT(*)
----------
         0

Im Gegensatz zur noch allokierten Segmentgröße von 816 Megabyte der Tabelle TAB01, wird diese Tabelle im Export nur minimal Platz belegen. Denn sie hat keine Inhalte mehr und somit werden auch hier nur die Metadaten exportiert werden.

Zusammenfassung

Wenn man die oben beschriebenen drei Punkte zusammennimmt, kommt man zu folgendem Vergleich:

Reine Summierung:

SELECT
    ROUND(SUM(BYTES)/1024/1024) AS MB
FROM
    DBA_SEGMENTS;

        MB
----------
      6386

Rausnehmen ORACLE_MAINTAINED, Indizies, Recycle Bin und leere Tabellen:

SELECT
    ROUND(SUM(BYTES)/1024/1024) AS MB
FROM
    DBA_SEGMENTS
WHERE
    SEGMENT_TYPE<>'INDEX' AND
    SEGMENT_NAME NOT LIKE 'BIN%' AND
    OWNER||SEGMENT_NAME||SEGMENT_TYPE IN (
        SELECT
            OWNER||OBJECT_NAME||OBJECT_TYPE
        FROM
            DBA_OBJECTS
        WHERE
            ORACLE_MAINTAINED='N'
    ) AND
    OWNER||SEGMENT_NAME IN (
        SELECT
            OWNER||TABLE_NAME
        FROM
            DBA_TABLES
        WHERE
            NUM_ROWS>0
    );

        MB
----------
       360

Dieses Beispiel verdeutlicht dass eine vermeintlich ~6GB große Datenbank auf eine Exportgröße von nur ~360MB zusammenschrumpft.

Aber auch diese Zahl ist noch nicht „die Wahrheit“. Berücksichtigt man zum Beispiel Tabellen, die nur eine einzige Zeile bzw. wenige Zeilen enthalten, aber in der Vergangenheit groß waren und mit DELETE gelöscht wurden, würde sich der geschätzte Wert für die Exportgröße noch weiter minimieren. Dies zu ermitteln ist jedoch ein zu hoher Aufwand, wenn wir nur einen Anhaltswert für die Exportgröße benötigen.
 

Fazit

Auch ein Export, der auf den ersten Blick viel zu klein wirkt, kann sich bei einem genaueren Blick als korrekt herausstellen. Wie einleitend erwähnt, ist es wichtig als erstes das Export Log und die Export Parameter zu überprüfen, denn sowohl Fehler im Export Log wie auch falsche Parameter können Folgen haben, die Sie erst sehr spät und sicher im falschen Moment bemerken. Sieht hier alles stimmig aus, können Anhaltswerte für die Exportgrößen an Hand von DBA_SEGMENTS und unter Ausschluss von Objekten, deren Daten ohnehin nicht exportiert werden, ermittelt werden.

Sollten Sie Hilfe bezüglich Oracle Export oder anderen Oracle Datenbank Themen brauchten, zögern Sie nicht und melden Sie sich bei uns.