O problema
Ao descrever um VARCHAR, você deve fornecer uma unidade, por exemplo.
VARCHAR2(200 BYTE) ou VARCHAR2(200 CHAR) . Se você omitir a unidade, o padrão é BYTE (consulte Conceitos de banco de dados Oracle, capítulo Tipos de dados Oracle ). Isso parece ser um detalhe menor, mas se torna bastante grave, quando você tem conjuntos de caracteres de vários bytes. Situação até 11g
Infelizmente, há um limite rígido no tamanho máximo de uma coluna VARCHAR2. São 4.000 BYTEs (!) (consulte Referência do banco de dados Oracle, capítulo Tipos de dados do Oracle ) até Oracle 11g e . Este é um limite rígido e não há maneira de contornar isso. A única maneira de contornar isso é uma coluna CLOB.
Solução para 12c
A situação é diferente no Oracle 12c. Lá você pode usar o parâmetro
MAX_STRING_SIZE = EXTENDED para aumentar o limite para 32.767 BYTEs (consulte Referência de linguagem de banco de dados Oracle, capítulo Tipos de dados
e Oracle Database Reference, capítulo Parâmetros de inicialização ). Portanto, a solução óbvia é:Atualize para o Oracle 12c, defina MAX_STRING_SIZE = EXTENDED de acordo com a documentação
e altere sua definição de tabela. Você pode perder alguns índices ao alterar sua tabela, porque anteriormente a 12c não índices não podiam conter valores VARCHAR2 com mais de 4000 BYTEs e ainda pode haver alguma limitação. (Tenho que verificar o problema com os índices e se pode ser corrigido reconstruindo os índices). Solução:altere a codificação do banco de dados
Você pode tentar alterar a codificação do banco de dados nativo (a maneira como seu banco de dados mapeia CHARs para BYTEs). Para isso você normalmente tem que criar um novo banco de dados e fornecer um parâmetro apropriado para NLS_CHARACTERSET. Esta é uma mudança muito grande na forma como seu banco de dados opera e pode ter vários efeitos colaterais. Se você tentar adicionar caracteres em uma codificação diferente, poderá estar sem sorte (ou seja, não poderá armazená-los em seu banco de dados). Então eu não sugeriria essa solução.
Solução:mude para CLOB
Normalmente, não é necessário fornecer consultas arbitrárias em campos de texto tão grandes. Você pode tentar identificar as consultas selecionadas na coluna de texto grande e migrá-las para Oracle Text em uma coluna CLOB. Mas esta é uma mudança muito grande e pode não ser possível com seu esquema existente ou seu aplicativo. Você pode acabar com um monte de gatilhos "INSTEAD OF" e com algumas verificações de restrição ausentes (envolvendo a coluna CLOB recém-criada).
Solução:use XML
Em vez de um CLOB, você pode tentar armazenar sua string como uma coluna XML. O tamanho máximo para estes é de 4 GB. Isso prejudicará seu desempenho, você terá que fornecer gatilhos INSTEAD OF e poderá perder algumas restrições, mas pode funcionar para você.
