問題
VARCHARを記述するときは、単位を指定する必要があります。 VARCHAR2(200 BYTE) またはVARCHAR2(200 CHAR) 。単位を省略した場合、デフォルトはBYTEです。 （Oracleデータベースの概念の章Oracleデータ型 ）。これは細かい部分のように見えますが、マルチバイト文字セットがある場合は非常に厳しくなります。
最大11gの状況
残念ながら、VARCHAR2列の最大サイズには厳しい制限があります。これは4000バイト（！）です（OracleデータベースリファレンスのOracleデータ型 ）最大Oracle11gおよび。これは厳しい制限であり、これを回避する方法はありません。これを回避する唯一の方法はCLOB列です。
12cのソリューション
Oracle12cでは状況が異なります。そこで、パラメータMAX_STRING_SIZE = EXTENDEDを使用できます。 制限を最大32767バイトまで引き上げます（OracleDatabase言語リファレンスの章MAX_STRING_SIZE = EXTENDEDを設定します。 ドキュメントによると
テーブル定義を変更します。以前は12cではなかったインデックスは4000バイトを超えるVARCHAR2値を保持できず、まだいくつかの制限がある可能性があるため、テーブルを変更するときに一部のインデックスが失われる可能性があります。 （インデックスの問題を確認し、インデックスを再構築することで修正できるかどうかを確認する必要があります。）
解決策：データベースのエンコーディングを変更する
ネイティブデータベースのエンコーディング（データベースがCHARをBYTEにマップする方法）を変更してみることができます。このためには、通常、新しいデータベースを作成し、NLS_CHARACTERSETに適切なパラメーターを指定する必要があります。これは、データベースの動作方法における非常に大きな変更であり、いくつかの副作用が発生する可能性があります。別のエンコーディングで文字を追加しようとすると、運が悪い可能性があります（つまり、データベースに文字を保存できません）。したがって、この解決策は提案しません。
解決策：CLOBに切り替えます
通常、このような大きなテキストフィールドに任意のクエリを提供する必要はありません。大きなテキスト列で選択しているクエリを特定し、それらを OracleText に移行してみてください。 CLOB列。ただし、これは非常に大きな変更であり、既存のスキーマまたはアプリケーションでは不可能な場合があります。 「INSTEADOF」トリガーの束と、いくつかの制約チェックの欠落（新しく作成されたCLOB列を含む）が発生する可能性があります。
解決策：XMLを使用する
CLOBの代わりに、文字列をXML列として格納することを試みることができます。これらの最大サイズは4GBです。それはあなたのパフォーマンスを損なうでしょう、あなたはINSTEAD OFトリガーを提供しなければならず、そしてあなたはいくつかの制約を失うかもしれません、しかしそれはあなたのために働くかもしれません。