VARCHAR-Spalte durch CLOB ersetzen

[Jumpy]

Hallo,

ich hab in einer Tabelle eine Varchar2(4000)-Spalte die nun zu klein geworden ist und die ich daher durch eine CLOB-Spalte erstzen möchte. Gibt es da Tips zur besten vorgehensweise?
(Tabelle besteht nur aus einer ID und der Text-Spalte)

- Neue Spalte unter anderem Namen anlegen, Werte aus alter Spalte in neue übertragen, alte Spalte löschen, neue Spalte umbenennen

vs.

- Neue leere Tabelle anlegen, mit der geänderten Struktur, Werte aus alter Tabelle via Insert-Select in neue übertragen, alte Tabelle löschen/umbenennen, neue Tabelle umbenennen

vs.

- anderer Weg?

[mkinzler]

Es kommt darauf an, wie viele andere Daten sich in einem Datensatz befinden. Wenn wenig Daten Variante 2, sonst 1.

[Dejan Vu]

kennt oracle kein 'alter table foo alter TextColumn CLOB'? so würde das vermutlich mit SQL-Server funktionieren und ich dachte, 'ALTER TABLE' ist ANSI-SQL...

[mkinzler]

Die Veränderung von Datentypen der Spalten funktioniert aber nur bei (speicherungs-)kompatiblen Änderungen. Da aber Varchar-Felder im Tablespace stehen und BLOBs nur "Zeiger" sind, wird das vermutlich nicht funktionieren.

[Dejan Vu]

MS SQL-Server hat damit keine Probleme. Daher würde ich es auf einen Versuch ankommen lassen

[DeddyH]

Erster Treffer bei Google (Suchbegriff "oracle change fieldtype varchar2 to clob"): https://asktom.oracle.com/pls/asktom...86700346491686

[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:

Zitat von jobo (Beitrag 1273928)

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:

Zitat von Dejan Vu (Beitrag 1273947)

Zitat:

Zitat von jobo (Beitrag 1273928)

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";