Problemet
Når du beskriver en VARCHAR, bør du levere en enhed, f.eks. VARCHAR2(200 BYTE) eller VARCHAR2(200 CHAR) . Hvis du udelader enheden, er standarden BYTE (se Oracle Database Concepts, kapitel Oracle-datatyper a> ). Dette ser ud til at være en mindre detalje, men bliver ret alvorligt, når du har flere byte tegnsæt.
Situation op til 11g
Desværre er der en hård grænse for den maksimale størrelse af en VARCHAR2 kolonne. Det er 4000 BYTEs (!) (se Oracle Database Reference, kapitel Oracle-datatyper ) op til Oracle 11g og . Dette er en hård grænse, og der er ingen vej udenom dette. Den eneste måde at undgå dette på er en CLOB-søjle.
Løsning til 12c
Situationen er anderledes på Oracle 12c. Der kan du bruge parameteren MAX_STRING_SIZE = EXTENDED at hæve grænsen op til 32767 BYTEs (se Oracle Database Language Reference, kapitel Datatyper
og Oracle Database Reference, kapitel Initialiseringsparametre ). Så den åbenlyse løsning er:Opgrader til Oracle 12c, sæt MAX_STRING_SIZE = EXTENDED ifølge dokumentationen
og ændre din tabeldefinition. Du kan miste nogle indekser, når du ændrer din tabel, fordi tidligere til 12c ikke-indekser ikke kunne indeholde VARCHAR2-værdier med mere end 4000 BYTEs, og der kan stadig være en vis begrænsning. (Jeg er nødt til at tjekke problemet med indekserne, og om det kan løses ved at genopbygge indekserne).
Løsning:Skift databasekodning
Du kan prøve at ændre din oprindelige databasekodning (den måde, din database kortlægger CHARs til BYTEs). Til dette skal du normalt oprette en ny database og angive en passende parameter for NLS_CHARACTERSET. Dette er en meget stor ændring i, hvordan din database fungerer og kan have flere bivirkninger. Hvis du nogensinde prøver at tilføje tegn i en anden kodning, kan du være uheldig (dvs. du kan ikke gemme dem i din database). Så jeg vil ikke foreslå denne løsning.
Løsning:Skift til CLOB
Normalt er det ikke nødvendigt at stille vilkårlige forespørgsler på så store tekstfelter. Du kan prøve at identificere de forespørgsler, du vælger i den store tekstkolonne og migrere dem til Oracle Text på en CLOB kolonne. Men dette er en meget stor ændring og er muligvis ikke mulig med dit eksisterende skema eller din applikation. Du kan ende med en masse "I STEDET FOR"-udløsere og med nogle manglende begrænsningstjek (involverer den nyoprettede CLOB-kolonne).
Løsning:Brug XML
I stedet for en CLOB kan du prøve at gemme din streng som en XML-kolonne. Maksimal størrelse for disse er 4 GB. Det vil skade din præstation, du bliver nødt til at give I STEDET FOR triggere, og du kan miste nogle begrænsninger, men det kan fungere for dig.