VARCHAR-Spalte durch CLOB ersetzen

[DeddyH]

Erster Treffer bei Google (Suchbegriff "oracle change fieldtype varchar2 to clob"): https://asktom.oracle.com/pls/asktom/f?p=100:11:0:::11_QUESTION_ID:177008670034649168 6

[Jumpy]

Von so einer Seite hatte ich auch meine 2 Vorschläge her, wobei mir die Version aus einem der Kommentare in deinem Link auch sehr zusagt:

Code:

alter table t add y_copy varchar2(4000);
update t set y_copy = y;
update t set y = null;
commit;
alter table t modify y long;
alter table t modify y clob;
update t set y = y_copy;
alter table t drop column y_copy;

Mir ging es jetzt weniger darum wie es geht, als darum, ob irgendwas zu beachten ist oder was vllt. effektiver oder sicherer ist.

Datensätze ~500Tsd.

[jobo]

Die Links die hier gezeigt wurden sind schon relativ alt.
Mit 11g gibt es vielleicht andere Möglichkeiten.
Über Typ "long" zu gehen, halte ich für etwas fragwürdig.
Ein Thema bei dem ganzen Kram ist bspw. Zeichencodierung. Long ist eigentlich "abgekündigt" oder so. Kann sein, dass es mit ein Byte Codierung geht. Würde ich auf jeden Fall testen.
Dann hat man den physikalischen Teil, also wo landet die Blobspalte, in der Tabelle, extra Tablespace, .. das kann man aber auch unabhängig von der Konvertierung später noch verschieben/ändern.
Dann wäre noch die Frage, auf welchen Systemen das durchgeführt werden muss. Auf ganz vielen Kundensystem im Rahmen eines Upgrades? Oder nur einmalig in der "Hausdatenbank"? Kann das System dafür abgeklemmt werden oder soll es online bleiben? Für online Umstrukturierung gibt es extra Paketfunktionen.

[Dejan Vu]

SSMS verwendet lustigerweise den 'alter table' Befehl selbst nicht, wenn man im Designer einen Feldtyp ändert, sondern geht den Weg über eine temporäre Tabelle, pseudocode:
To change column X to datatype Y in Table T:

1. create table T_tmp with column 'X' as 'Y'
2. copy all fields from T to T_tmp
3. drop table T
4. rename T_tmp to T
5. rebuild all indexes, constraints and stuff on T

Das scheint schneller zu gehen, als ein das alter table. Bei bestimmten Aktionen stimmt das auch.
Ich denke, wenn Du das in eine Transaktion packst, kannst Du einfach den ALTER-Befehl nehmen.

Code:

begin transaction
alter table bar alter column foo CLOB
select * from bar
rollback transaction

wenn Du mit dem Resultat zufrieden bist, machst Du aus dem rollback ein commit und führst das Skript nochmal aus. So mach ich das immer. Der Vorteil ist ja, das man -wenn das Teil abschmiert- das Rollback auch per Hand ausführen kann.

[jobo]

DDL Statements (wie alter table ) sind in oracle immer automatisch mit einem impliziten commit(!) verbunden.
Also Vorsicht bitte an der Stelle.

[Jumpy]

Ist nur eine einmalige Sache in einer Hausdatenbank, an der ich das Samstag morgen durchziehen kann.
Ich werde mal berichten wie es war.

[Dejan Vu]

Zitat von jobo:

DDL Statements (wie alter table ) sind in oracle immer automatisch mit einem impliziten commit(!) verbunden.
Also Vorsicht bitte an der Stelle.

Und nested transactions ziehen hier nicht? Aua.

[Elvis]

Zitat von Dejan Vu:

Zitat von jobo:

DDL Statements (wie alter table ) sind in oracle immer automatisch mit einem impliziten commit(!) verbunden.
Also Vorsicht bitte an der Stelle.

Und nested transactions ziehen hier nicht? Aua.

Doch, teilweise.
Lassen sich aber bei Locks außerhalb der autonomen Transkation selten für etwas sinnvolles nutzen.

Zum Thema: du kannst dir ein Update sparen.
Du kannst in einem Schritt die temp. Spalte besetzen und dein Feld auf null setzen. Bei 500k sollte es aber egal sein. Das sollte nicht lange dauern.

Code:

alter table t add "temp column" clob;
update t set "temp column" = y, y = null;
alter table t modify y long;
alter table t modify y clob;
update t set y = "temp column";
alter table t drop column "temp column";