Il problema
Quando si descrive un VARCHAR, è necessario fornire un'unità, ad es. VARCHAR2(200 BYTE) o VARCHAR2(200 CHAR) . Se ometti l'unità, l'impostazione predefinita è BYTE (vedi Oracle Database Concepts, capitolo Tipi di dati Oracle ). Questo sembra essere un dettaglio minore, ma diventa piuttosto severo, quando hai set di caratteri multi byte.
Situazione fino a 11 g
Sfortunatamente esiste un limite rigido alla dimensione massima di una colonna VARCHAR2. Sono 4000 BYTE (!) (vedi Riferimento al database Oracle, capitolo Tipi di dati Oracle ) fino a Oracle 11g e . Questo è un limite difficile e non c'è modo di aggirarlo. L'unico modo per aggirare questo problema è una colonna CLOB.
Soluzione per 12c
La situazione è diversa su Oracle 12c. Lì puoi usare il parametro MAX_STRING_SIZE = EXTENDED per aumentare il limite fino a 32767 BYTE (consultare Oracle Database Language Reference, capitolo Tipi di dati
e Oracle Database Reference, capitolo Parametri di inizializzazione ). Quindi la soluzione ovvia è:eseguire l'aggiornamento a Oracle 12c, impostare MAX_STRING_SIZE = EXTENDED secondo la documentazione
e modificare la definizione della tabella. Potresti perdere alcuni indici quando modifichi la tua tabella, perché in precedenza a 12c non gli indici non potevano contenere valori VARCHAR2 con più di 4000 BYTE e potrebbero esserci ancora alcune limitazioni. (Devo verificare il problema con gli indici e se può essere risolto ricostruendo gli indici).
Soluzione:modifica la codifica del database
Potresti provare a cambiare la codifica del tuo database nativo (il modo in cui il tuo database mappa i CHAR in BYTE). Per questo di solito devi creare un nuovo database e fornire un parametro appropriato per NLS_CHARACTERSET. Questo è un cambiamento molto grande nel modo in cui funziona il tuo database e potrebbe avere diversi effetti collaterali. Se provi ad aggiungere caratteri con una codifica diversa, potresti essere sfortunato (cioè non puoi memorizzarli nel tuo database). Quindi non suggerirei questa soluzione.
Soluzione:passa a CLOB
Di solito non è necessario fornire query arbitrarie su campi di testo così grandi. Potresti provare a identificare le query selezionando nella colonna di testo grande e migrarle in Oracle Text su una colonna CLOB. Ma questo è un cambiamento molto grande e potrebbe non essere possibile con il tuo schema esistente o la tua applicazione. Potresti ritrovarti con una serie di trigger "INVECE DI" e con alcuni controlli dei vincoli mancanti (che coinvolgono la colonna CLOB appena creata).
Soluzione:usa XML
Invece di un CLOB potresti provare a memorizzare la tua stringa come una colonna XML. La dimensione massima per questi è 4 GB. Danneggerà le tue prestazioni, dovrai fornire INVECE DI trigger e potresti perdere alcuni vincoli, ma potrebbe funzionare per te.
