Início / dba / Perguntas / 222689
Accepted
Malvineous
Asked: 2018-11-16 19:02:54 +0800 CST

Como desabilitar a reconexão transparente do cliente Oracle OCI

  • 772

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.

oracle connectivity

2 respostas

  1. Best Answer

    Parece que o Transparent Application Failover (TAF) está habilitado para sua conexão. Se o TAF estiver ativado, o cliente Oracle o reconectará ao banco de dados ou a um banco de dados alternativo se a conexão entre o cliente e o servidor for interrompida. Você usa um cliente OCI e para isso é possível registrar uma função de retorno de chamada de failover que é chamada após a reconexão do cliente. Nesta função de retorno de chamada, você pode emitir o comando 'ALTER SESSION' necessário. Mas talvez você não queira usar o TAF.

    Portanto, primeiro o DBA deve verificar se sua sessão usa TAF. Uma consulta apropriada pode ser encontrada no Guia do Administrador do Net Services

    SELECT MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER, COUNT(*)
FROM V$SESSION
GROUP BY MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER;

    Com o seguinte exemplo de saída

    MACHINE              FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER   COUNT(*)
-------------------- ------------- ----------      ---           ----------
sales1               NONE          NONE            NO            11
sales2               SELECT        PRECONNECT      NO             1

    FAILOVER_TYPE NONE nos diz que nenhum TAF está configurado. FAILOVER_TYPE diferente de NONE nos informa que o TAF está configurado para essas sessões.

    Se a sua sessão usa o TAF, você deve descobrir onde está configurado. Pode ser configurado no lado do cliente ou no lado do servidor. Você pode verificar seu arquivo 'tnsname.ora' ou usar seu utilitário 'tnsping' para verificar a configuração do seu cliente. Se você encontrar algo semelhante a este exemplo do Guia do Administrador do Net Services

    sales.us.example.com=
 (DESCRIPTION=
  (LOAD_BALANCE=on) 
  (FAILOVER=on) 
  (ADDRESS=
       (PROTOCOL=tcp)  
       (HOST=sales1-server)  
       (PORT=1521)) 
  (ADDRESS=
       (PROTOCOL=tcp)  
       (HOST=sales2-server)  
       (PORT=1521)) 
  (CONNECT_DATA=
     (SERVICE_NAME=sales.us.example.com) 
     (FAILOVER_MODE=
       (TYPE=select) 
       (METHOD=basic))))

    então o TAF é configurado por causa do FAILOVER_MODE=(TYPE=select). Se este for o caso, você deve configurar uma string de conexão apropriada sem TAF.

    Mas mesmo que nenhum TAF esteja configurado no lado do cliente, ele pode ser configurado no lado do servidor para este serviço. Então faça a seguinte consulta

    select NETWORK_NAME, FAILOVER_METHOD, FAILOVER_TYPE
from DBA_SERVICES
where NETWORK_NAME is not null;

    A saída de exemplo a seguir mostra que o TAF será usado (SERVICE_NAME=sales.us.example.com)mesmo que não esteja configurado no cliente.

    NETWORK_NAME             FAILOVER_METHOD      FAILOVER_TYPE
------------------------ -------------------- --------------------
sales.us.example.com     BASIC                SELECT
sales3.us.example.com    NONE                 NONE

    Nesse caso, o TAF será usado (SERVICE_NAME=sales.us.example.com)mesmo que o TAF não esteja configurado no cliente. Portanto, você deve usar um serviço que não tenha o TAF configurado, no exemplo 'sales3.us.example.com' é um serviço desse tipo.

    O serviço pode ser criado com o pacote DBMS_SERVICE, mas na maioria dos casos eles são criados por algumas ferramentas adicionais como o Oracle Real Application Cluster. Pode-se exibir os serviços criados pelo RAC para um banco de dados 'salesdb' executando o seguinte comando no servidor de banco de dados

    srvctl config service -d salesdb

    A saída a seguir (que depende da versão do banco de dados) mostra que o RAC criará um serviço TAF após o início do banco de dados

    Service name: sales.us.example.com
Service is enabled
Server pool: SALESDB_sales.us.example.com
Cardinality: 2
Disconnect: false
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Failover type: SELECT
Failover method: BASIC
TAF failover retries: 5
TAF failover delay: 2
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: BASIC
Edition:
Preferred instances: sales2-server,sales2-server
Available instances:
Service is enabled on instances: SALESDB1,SALESDB2

    você pode criar um novo serviço 'sales3.us.example.com' sem TAF com o seguinte comando

    srvctl add service -d salsedb -s sales3.us.example.com
    • 1

  2. Como solução alternativa, um gatilho foi adicionado à conta do usuário para executar o ALTER SESSIONcomando em cada conexão. Isso corrigiu o problema, mas ainda não temos certeza do motivo pelo qual a sessão se reconecta de forma transparente sem nenhuma notificação ao aplicativo cliente!

    • 0

relate perguntas