Het probleem
Bij het beschrijven van een VARCHAR moet u een eenheid leveren, b.v. VARCHAR2(200 BYTE) of VARCHAR2(200 CHAR) . Als u de eenheid weglaat, is de standaard BYTE (zie Oracle Database Concepts, hoofdstuk Oracle-gegevenstypes ). Dit lijkt een klein detail, maar wordt behoorlijk ernstig als je tekensets van meerdere bytes hebt.
Situatie tot 11g
Helaas is er een harde limiet voor de maximale grootte van een VARCHAR2-kolom. Het is 4000 BYTE's (!) (zie Oracle Database Reference, hoofdstuk Oracle-gegevenstypen ) tot Oracle 11g en . Dit is een harde limiet en er is geen manier om dit te omzeilen. De enige manier om dit te omzeilen is een CLOB-kolom.
Oplossing voor 12c
De situatie is anders op Oracle 12c. Daar kunt u de parameter MAX_STRING_SIZE = EXTENDED . gebruiken om de limiet op te heffen tot 32767 BYTE's (zie Oracle Database Language Reference, hoofdstuk Gegevenstypen
en Oracle Database Reference, hoofdstuk Initialisatieparameters ). De voor de hand liggende oplossing is dus:upgrade naar Oracle 12c, stel MAX_STRING_SIZE = EXTENDED in volgens de documentatie
en verander uw tabeldefinitie. U kunt enkele indexen verliezen bij het wijzigen van uw tabel, omdat voorheen tot 12c niet-indexen geen VARCHAR2-waarden met meer dan 4000 BYTE's konden bevatten en er mogelijk nog steeds een beperking is. (Ik moet het probleem met de indexen controleren en of het kan worden opgelost door de indexen opnieuw op te bouwen).
Oplossing:databasecodering wijzigen
U kunt proberen uw eigen databasecodering te wijzigen (de manier waarop uw database CHAR's toewijst aan BYTE's). Hiervoor moet u meestal een nieuwe database maken en een geschikte parameter opgeven voor NLS_CHARACTERSET. Dit is een zeer grote verandering in de manier waarop uw database werkt en kan verschillende bijwerkingen hebben. Als u ooit tekens in een andere codering probeert toe te voegen, heeft u misschien pech (u kunt ze niet in uw database opslaan). Dus ik zou deze oplossing niet aanraden.
Oplossing:overschakelen naar CLOB
Meestal is het niet nodig om willekeurige zoekopdrachten te geven op zulke grote tekstvelden. U kunt proberen de query's te identificeren die in de grote tekstkolom zijn geselecteerd en ze te migreren naar Oracle Text op een CLOB-kolom. Maar dit is een zeer grote verandering en is misschien niet mogelijk met uw bestaande schema of uw toepassing. Je zou kunnen eindigen met een aantal "INSTEAD OF"-triggers en met enkele ontbrekende beperkingscontroles (waaronder de nieuw gemaakte CLOB-kolom).
Oplossing:XML gebruiken
In plaats van een CLOB zou je kunnen proberen om je string op te slaan als een XML-kolom. De maximale grootte hiervoor is 4 GB. Het zal je prestaties schaden, je zult IN PLAATS VAN triggers moeten geven en je zou wat beperkingen kunnen verliezen, maar het zou voor jou kunnen werken.