Oracle - Partionierung von Tabellen

[Heffernan2007]

Hallo,

nicht ganz das richtige Forum, aber bis jetzt wurde mir hier immer geholfen

Ich habe eine relativ große DB zu verwalten und einige Tabellen verfügen über ein dutzend Indices. Bei über einer Million Einträgen dauert Insert und Delete Operationen erschreckend langsam, da jeder Index beim Einfügen aktualisiert werden muss.

Macht hier eine Tabellenpartionierung Sinn? Eine andere Möglichkeit wäre es neue Eintragungen in einer zweiten Tabelle zu sammeln und einmal am Tag in die große Tabelle zu schreiben, wobei dort vorher alle Indices entfernt werden. Oder ist es ausreichend einfach vor dem Einfügen vieler Datensätze den Index der Tabelle zu löschen und anschließend wieder zu erstellen? Werden dabei parallel ablaufende Select's nicht unerträglich langsam?

Ich hoffe jemand kann mir dabei helfen

 

[Lim_Dul]

Kannst du die Daten nicht in einer Transaktion einfügen?
Eventuell wird der Index dann nur 1x aktualisiert.

 

[Heffernan2007]

Wie lang darf ein übergebener SQL Befehl sein? Dann könnte man zumindest mehrere bei einer Transaktion einfügen. Das Problem verschiebt sich dadurch aber doch nur.

Hat jemand Erfahrungen mit Partitionen gemacht?

Vielen Dank!

 

[Gast]

Ich würde in einem solchen Falle BulkCollect benutzen

 

[abollm]

Was genau meinst oder genauer gesagt was willst du mit der Partionierung von Tabellen erreichen?

Wenn es allein um die Index-Problematik im Zusammenhang mit einem INSERT, UPDATE oder DELETE von sehr vielen Einträgen (z.B. mehrere zig Millionen) geht, kannst du das mit Oracle auch folgendermaßen lösen:

Angenommen, du musst in einer deiner Tabellen (z.B. MY_TABLE) eine Spalte col1 aktualisieren, dann kannst du das folgende Standardverfahren anwenden:

CREATE TABLE NEW_TABLE as SELECT <hier dein UPDATE-Statement> from MY_TABLE;

index NEW_TABLE
grant ... on NEW_TABLE
add constraints on NEW_TABLE
etc on NEW_TABLE

drop table MY_TABLE
rename NEW_TABLE to MY_TABLE;

Das kann man laut Oracle mit einer so genannten parallel query zusammen mit "nologging" auf die meisten DB-Aktionen anwenden, in einem Bruchteil der Zeit zum "üblichen" UPDATE.

Hth