Global temporary table

[Martin R.]

Hallo,

beim Erstellen von GLOBAL TEMPORARY TABLE werden die Daten bei Anwendung eines Scripts zu früh verworfen.

Verwendet habe ich die ON COMMIT DELETE ROWS Option.
Sollten die Daten dort nicht erst nach einem Commit gelöscht werden?

Bei ON COMMIT PRESERVE ROWS kann iich keine Indexes erstellen.

Würdet Ihr mir zur Option nologging für Erstellung der Tabellen und Indexes raten? Da weiss ich wenigstens was ich mach

Ernsthaft, welche Option ist für meine Zwecke geeignet.
Das Sript dient zur Bearbeitung falsch gescannter Daten.
Es werden ca. 10 Mio Daten mehrfach gegen einige Tausend Stammdaten geprüft.

Einige vernünftige Performance waere also schon wünschenswert.
Und von Dauer ist nur die upgedatete Ursprungstabelle.

Ich entschuldige mich jetzt schon mal, dass ich heute nicht mehr antworten kann, da gleich mein Zug Richtung Heimat fährt.
Viele Dank schon mal

Viele Grüße und einen schönen Abend

Martin

[dimitri]

Bei ON COMMIT PRESERVE ROWS kann iich keine Indexes erstellen.

Wie kommst denn da drauf?

create global temporary table t1 (col1 varchar2(10), col2 varchar2(10)) on commit preserve rows;

create index t1_ix1 on t1(col1);

create unique index t1_ix2 on t1(col2);

Geht tadellos.

Würdet Ihr mir zur Option nologging für Erstellung der Tabellen und Indexes raten? Da weiss ich wenigstens was ich mach

Die Änderungen an einer GTT werden sowieso nicht in den REDOS mitgelogt und bei einem INDEX kannst es nicht verhindern. Daher ist nologging hier nicht sinnvoll und würde zu einem ORA-14451 führen.
Du kannst einen INSERT /*+APPEND*/ zum befüllen verwenden, dann werden für die Tabellenänderungen keine UNDO Informationen weggeschrieben.

Dim

[Martin R.]

Hallo Dim,
vielen Dank für Deine Hilfe.
Die Indexes hatte ich anders als Du im Datenscript erstellt bzw nicht erstellt.
Oracle sagte, dass er die Indexes nicht erstellen kann.
Mache es nun so, wie Du es vorgeschlagen hast.
Das nologgin hätte ich anstelle der GGL genutzt.
Mit Hints kenne ich mich leider nicht wirklich aus.

Zu quasi diesem Thema hätte ich noch eine Frage.
[highlight=sql]update a
set a.ID =
(select b.bnr
from b
where a.ID = b.snr
--and a.nr = b.a_nr7
)
where a.ID in (
select c.snr
from c
where a.ID <> c.bnr[/highlight]

Ich verwende o.a. Sript für ein update einer Tabelle (a) mit ca 11.000.000 Datensätzen.
Die Tabellen b und c sind die selbe in einem Sript.
Beim erten Lauf ändert es ca 500.000 Daten b=c hat ca. 10.000 Datensätze.
Beim zweiten hat b=c ca. 250 Datensätze.

Ist es sinnvoll für a die Indexes ausser Betrieb zu schalten, da relativ viele Daten geändert werden.
Oder sollte ich doch den Index nutzen, da ich den Index auch in der where Bedingung nutzen kann.

Auch hierfür vielen Dank Gruß

Martin

[Martin R.]

Du kannst einen INSERT /*+APPEND*/ zum befüllen verwenden, dann werden für die Tabellenänderungen keine UNDO Informationen weggeschrieben.

Dim

Habe mir gerdade mal etwas Literatur zu Deinem Hint-Tipp gelesen.

Sinn würde dieser aber in Verbindung mit GGL nicht machen, oder?

[dimitri]

Ist es sinnvoll für a die Indexes ausser Betrieb zu schalten, da relativ viele Daten geändert werden.
Oder sollte ich doch den Index nutzen, da ich den Index auch in der where Bedingung nutzen kann.

Würde ich nicht machen, denn das Verhältnis von zu Ändernden Sätzen : Gesamt vorhandenen Datensätzen ist so gering, dass Oracle wohl keinen Full Tablescan durchführen würde um die 500 Tsd Sätze zu finden. Ein Index dürfte hier wohl definitiv Vorteile bringen. Davon abgesehen musst Du den Index anschließend auch wieder aufbauen, was natürlich auch Zeit benötigt.
Letzten Endes kann das natürlich nur ein Test klären, aber ich würde den Index stehen lassen.

Habe mir gerdade mal etwas Literatur zu Deinem Hint-Tipp gelesen.

Sinn würde dieser aber in Verbindung mit GGL nicht machen, oder?

Nein nicht ganz. Bei einer GTT wird kein REDO bezüglich der Änderungen in der Tabelle selbst gemacht, es wird aber UNDO geschrieben damit Du nach einem INSERT oder Update auch wieder ein ROLLBACK ausführen kannst. UNDO ist aber immer auch durch REDO geschützt.
Ein INSERT /*+APPEND*/ wiederum schreibt ausserhalb der Tabelle in einen für die Tabelle nicht sichtbaren Bereich. Im Falle eines ROLLBACKs bleibt dieser Bereich einfach unsichtbar - er enthält einfach Datenmüll der von anderen überschrieben werden kann, daher braucht man auch (fast) kein UNDO. Da der beschriebene Bereich erst nach dem COMMIT der Tabelle zugeordnet wird, ergibt ein INSERT /*+APPEND*/ nur Sinn mit der Option ON COMMIT PRESERVE ROWS.

Hast Du Indices auf der Tabelle, so werden diese Indices im TEMP-TS aufgebaut und anschließend mit den vorhandenen Indices zusammengemischt. Hier erzeugst Du auf jeden Fall UNDO und daraus resultierend wieder REDO - unabhängig ob es sich um eine GTT oder eine echte Tabelle handelt.

Dim

[Martin R.]

Hallo Dim,

vielen Dank für Deine umfassende Erklärung zum Post.
Deine Ausführungen haben mir sehr geholfen.

Nochmals vielen Dank

Gruß

Martin