Malvineous's questions

Eu tenho um aplicativo que escrevi que usa OCI para se conectar a um banco de dados Oracle. O banco de dados foi atualizado recentemente para o Oracle 18 e, desde então, as pesquisas de banco de dados no aplicativo param de funcionar aleatoriamente.

Eu reduzi o problema a isso. Quando o aplicativo se conecta ao banco de dados, ele executa alguns ALTER SESSIONcomandos para desabilitar a distinção entre maiúsculas e minúsculas nas LIKEcondições (para que eu possa procurar "smith" e ainda encontrar "Smith"). Após algumas horas, a rede desconecta a conexão TCP. Na manhã seguinte, quando alguém tenta acessar o sistema, o cliente Oracle se reconecta e executa a consulta de forma transparente.

O problema é que essa reconexão acontece sem que meu código saiba disso, aparentemente pelo próprio cliente Oracle, e ele não executa novamente os ALTER SESSIONcomandos originais após a reconexão. Nossos DBAs me forneceram um log de auditoria que mostra a alteração do ID da sessão, uma nova LOGONtentativa e uma única ALTER SESSIONexecução para definir o fuso horário (que não vem do meu código e também apareceu na conexão original).

Isso significa que meu aplicativo emite consultas ao banco de dados normalmente, sem saber que houve alguma interrupção, mas de repente elas diferenciam maiúsculas de minúsculas e os usuários começam a reclamar que a pesquisa não está retornando nenhum resultado.

Com a versão anterior do servidor Oracle meu código receberia um erro se tivesse sido desconectado, e o código tentaria se reconectar e como parte da reconexão, ele executaria os ALTER SESSIONcomandos novamente para que não houvesse alteração no comportamento do sistema .

Não consigo encontrar nada sobre esse recurso de reconexão automática ou como ajustá-lo, então existe alguma maneira de preservar as ALTER SESSIONalterações para que sejam reaplicadas após a reconexão ou desabilitar esse comportamento e retornar um erro ao código se a conexão for perdida como costumava acontecer?

O cliente é um 11.2 mais antigo e atualizá-lo não é muito prático, mas como funcionava antes da atualização do servidor, eu achava que essa versão seria boa.

Estou procurando reparar uma tabela de dados no Oracle, de preferência via SQL sem privilégios, que teve dados UTF-8 inseridos em um banco de dados UTF-8, usando o conjunto de caracteres Latin-1 por engano.

O símbolo β GREEK SMALL LETTER BETAdeveria ter entrado no banco de dados, mas em vez disso os dois caracteres βforam... como os dois caracteres UTF-8 Î LATIN CAPITAL LETTER I WITH CIRCUMFLEXseguidos por ² SUPERSCRIPT TWO.

Este código de exemplo demonstra o problema e a correção, mas só funciona com VARCHARcolunas. Assim que a CLOBé usado, a conversão falha:

-- This must return AL32UTF8 for this example to be valid
SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER='NLS_CHARACTERSET';

CREATE TABLE EXAMPLE (T VARCHAR2(20));
INSERT INTO EXAMPLE (T) VALUES ('Example β');
SELECT T FROM EXAMPLE; -- Should return 'Example β'
SELECT CONVERT(T, 'WE8ISO8859P1') FROM EXAMPLE;
UPDATE EXAMPLE SET T=CONVERT(T, 'WE8ISO8859P1');
SELECT T FROM EXAMPLE; -- Should return 'Example β', problem fixed
DROP TABLE EXAMPLE;

No entanto, se o VARCHAR2(20)for alterado para CLOB, isso não funcionará mais. CONVERT()retorna caracteres de lixo. Eu posso usar TO_CHAR()para contornar o problema, mas eventualmente recebo um erro que CLOBtem mais de 4000 caracteres, então TO_CHAR()falha.

Existe uma maneira de fazer o exemplo acima funcionar, ao usar uma CLOBcoluna com mais de 4000 caracteres?