ORACLE9i : table-Compression

Computer: Software & Programmierung Datenbanken allgemein
#1

Hallo:

ich bin gerade dabei, die compress-option bei tables auszuprobieren, die in ORACLE-9i eingeführt wurde.

Ein „create table xyz compress as select * from zzz“ und
„insert /* append */ into xyz as select * from zzz“ funktioniert auch soweit gut. Materialized Views liessen sich auch gut komprimieren.

Nun soll ich aber ein Export eines Schemas (aus einer anderen DB)importieren, und die Daten sollen in komprimierte Form geladen werden.

Bei diesem Thema fällt mir eigentlich nur ein, das Schema „normal“ zu importieren und die Tabellen anschliessend über „alter table move“ in einen anderen Tablespace zu verschieben, der mit COMPRESS angelegt wurde.

Gibt es eine Möglichkeit, die Daten COMPRESSed über IMPORT zu laden?

Beim SQL-Loader gibt es den direct-path, um die Daten komprimiert zu laden, beim Import kenne ich nichts.

viele Grüße
Regine

#2

Hallo,

wenn die Tabelle bereits existiert sollte das doch kein Problem sein, oder? (Option Erstellungsfehler ignorieren vorausgesetzt)

Gruß

Peter

#3

Hallo Peter:

Das war mein erster Gedanke, ein IMPORT ohne Daten, um die Struktur zu erstellen, die Tables in den Modus COMPRESS setzen und dann die Daten importieren.
Aber ist ein Import ein „Bulk Load“, dass die Daten auch in komprimierter Form in die compressed table geladen werden oder liegen sie danach unkomprimiert in der Tabelle?
Oder gibt die Option direct=y beim Export mir die Möglichkeit, dass beim Import die Daten komprimiert geladen werden können?

Ich muss leider bis morgen warten, um es auszuprobieren da ich durch die Neuinstallierung meines Rechners z.Z. keine Oracle-DB drauf habe

Gruss
Regine

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#4

Hallo Regine,

wenn ich recht erinnere wandelt die DB das einfach in ein Insert um. Damit ist es egal, welche Struktur die Tabelle hat.

Gruß

Peter

#5

Hallo Peter:

ich habe den Export/Import heute mal ausprobiert.

Ich exportierte die Tabelle TESTTAB mit der Option direct=y.
(1048576 rows)

Danach lud ich sie „normal“ in das Schema BIGUSR
und mit rows=n (nur die Struktur) in das Schema TESTUSER.

TESTUSER.TESTTAB änderte ich in modo compress mit

SQL\> ALTER TABLE testuser.testtab COMPRESS;

Als nächstes importierte ich in das Schema TESTUSER die Daten
(mit ignore=y)

=> Ergebnis: beide Tabellen haben diesselbe Größe, d.h. die Daten wurden in die Tabelle
(mit der Option compress) in unkomprimierter Form geladen (wie normale Inserts)

#######################################################################

SQL\> select owner, bytes,tablespace\_name from dba\_segments where
owner='BIGUSR' and segment\_name='TESTTAB';

OWNER BYTES TABLESPACE\_NAME
------------------------------ ---------- -----------------------------
BIGUSR 14680064 USERS





SQL\> select owner, bytes,tablespace\_name from dba\_segments where
owner='TESTUSER' and segment\_name='TESTTAB';

OWNER BYTES TABLESPACE\_NAME
------------------------------ ---------- ------------------------------
TESTUSER 14680064 USERS

#######################################################################

Nun verlagerte ich die Tabelle (mit der option compress) in einen anderen Tablespace

SQL\> alter table testuser.testtab move tablespace smallsizets;

=> Ergebnis: die Daten wurden komprimiert

SQL\> select owner, bytes,tablespace\_name from dba\_segments where
owner='TESTUSER' and segment\_name='TESTTAB';

OWNER BYTES TABLESPACE\_NAME
------------------------------ ---------- -----------------------------
TESTUSER 12582912 SMALLSIZETS

#######################################################################

Die Option direct=y ist zwar ein „direct-path Export“, hat aber keinen Einfluss auf ein Import in eine Tabelle mit der Option COMPRESS.
Ich hatte davon auch nichts in der Doku gelesen, war mir aber gestern garnicht mehr so sicher, ob die Daten vielleicht doch komprimiert geladen werden.

Ich glaube an einem Import mit einem späteren „move tablespace“ werde ich wohl nicht herumkommen.

Vielen Dank für Deine Hilfe.

viele Grüße
Regine

#6

Re^5: Segmentgrössen: Reingefallen… :wink:
Hallo Regine!

Erstmal: Vertraue dem Data Dictionary: Um herauszufinden, ob eine Tabelle komprimiert ist, würde ich persönlich die DBA_TABLES, für einen Index die DBA_INDEXES befragen, das erspart mir die Tests, die du gemacht hast (die brauche ich nur, um herauszufinden, wie gut die Komprimierung tatsächlich komprimiert).

SQL> select owner, bytes,tablespace_name from dba_segments
where
owner=‚BIGUSR‘ and segment_name=‚TESTTAB‘;

Zweitens: Du stellst falsche Vermutungen über die Bedeutung der Spalte ‚Bytes‘ an. Tasächlich ist das nur die Summe der Grösse aller allozierten Extents für das betreffende Segment. Zur Kontrolle kannst du ja mal die Daten mit „DELETE TESTUSER.TESTTAB“ machen und dir dann den gleichen Select noch einmal ansehen: Die Größe sollte sich nicht geändert haben. Nur bei einem TRUNCATE schmeisst er leere Extents (im Allgemeinen, kommt noch auf die Storage-Parameter der Tabelle an) weg, sodass auch deine Spalte „Bytes“ wieder kleiner wird.
Um die tatsächlich verwendeten Blocks zu sehen musst du das Package DBMS_SPACE verwenden.

Nun verlagerte ich die Tabelle (mit der option compress) in
einen anderen Tablespace
SQL> alter table testuser.testtab move tablespace
smallsizets;

…der vermutlich andere default Storage-Parameter hat und mit diesen die Tabelle anlegt (nachdem du dem ALTER TABLE ja nichts mitgibst, was ihn zu irgendetwas anderem veranlasst hätte).

=> Ergebnis: die Daten wurden komprimiert

Nein, die bleiben komprimiert, allerdings in einem (?) kleineren Extent, daher liefert auch „Bytes“ weniger…

Die Option direct=y ist zwar ein „direct-path Export“, hat
aber keinen Einfluss auf ein Import in eine Tabelle mit der
Option COMPRESS.

Der direct-path Export hat überhaupt keinen Einfluss auf den Import, es geht da nur um die Art und Weise, wie die Daten aus den Tabellen in das Export-File kommen; abgesehen von irgendwelchen Fehlern (z.B. LOB-Export unter 8.1.5) und evtl. der Sortierung der exportierten Datensätze sieht das resultierende File aber völlig identisch aus.

Ich hatte davon auch nichts in der Doku gelesen, war mir aber
gestern garnicht mehr so sicher, ob die Daten vielleicht doch
komprimiert geladen werden.

Probier’s einmal hier: http://download-west.oracle.com/docs/cd/B10501_01/se… (gratis OTN-Mitgliedschaft nötig)

Ich glaube an einem Import mit einem späteren „move
tablespace“ werde ich wohl nicht herumkommen.

Doch, einfach nur Export und Import reicht…

Gruß
Martin