Kill de Sessões Siebel – Parte I

Esta é a primeira abordagem do tema Kill de Sessões Siebel com a introdução e dicas preliminares sobre o assunto. O próximo artigo será referenciado aqui assim que for publicado.

Por que o Kill de Sessões Siebel no Database merece um artigo (ou uma trilogia de artigos)?

Todo DBA ou SADMIN que suporta alguma instância Oracle (ou SQL Server, IBM DB2, Sybase/SQL Anywhere) de um Siebel Enterprise está careca de saber a resposta para esta pergunta.

Para quem ainda não sabe, um “alter system kill session” em sessões Siebel ofensoras no banco de dados, por padrão, não adianta nada e as vezes até piora a situação que se queria remediar.

Nem mesmo um “kill -9” direto no processo (PID) no SO do banco de dados é suficiente para se livrar de uma vez por todas de um ofensor com origem no Siebel.

Assim que uma sessão Siebel no banco de dados é “morta”, o que acontece, por padrão, é re-logon numa nova sessão devido algum mecanismos para Alta Disponibilidade.

Ok, mas o que é uma sessão ofensora?

Uma sessão ofensora é uma instrução DML ou DQL na imensa maioria das vezes.

As vezes pode até ser um DDL ou DTL e, bem raramente, um DCL – quando um abençoado dá um grant num objeto high usage que exige atualização de dicionário de dados, p. ex..

Essas sessões são ofensoras porque consomem recursos por mais tempo que o normal ou  consumem mais recursos que o normal.

• Pode ser um select fazendo full scan ou usando um índice pouco seletivo
• As vezes é um grupo de queries rápidas que ficam executando em loop
• Um update impactado por um lock
• Um commit travado
• Um gargalo de CPU devido a configuração do Resource Manager do banco de dados.
• Pode ocorrer em decorrência de algum processos custoso em execução durante o horário de pico da aplicação (RMAN, datapump, delta sync do Data Guard, algum extrator mau construído, etc.)
• Enfim, pode ter inúmeras causas. 

Camarada, uma sessão ofensora pode ser o pior pesadelo da sua empresa. 

Continua após a publicidade

Sua operação inteira pode ficar indisponível em casos extremos e o trabalho de investigação pode exigir o envolvimento de vários profissionais até se descobrir e resolver a causa raiz do problema.

No contexto do dia-a-dia do Siebel, as causas mais comuns de sessões ofensoras são queries ruins, códigos em loop ad infinitum e locks.

E os impactos causados pelas sessões ofensoras?

Bem, impactos podem ser muitos dependendo do processo específico que originou a sessão ofensora. Aqui eu vou exemplificar os primeiros que me vêm a mente separando por módulo:

• Application Object Manager (eEnergy, eSales, eCommunications, etc.): Lentidão em certos fluxos, telas ou processos dentro da operação (call-center, equipe de vendas, etc.);
• Workflow
  • Online: Filas de processamento cada vez maiores devido a lentidão de processamento (lembrando que o processamento de grupos de workflows é serializado;
  • Batch: Processos que rodam de madrugada invadindo o horário comercial;
• EAI: Timeout em integrações web. Se o serviço executa algum comando que causa uma sessão ofensora, não vai responder no dentro do timeout e vai provocar um erro no sistema cliente;
• Assignment Manager: Activities, SRs, Quotes, Contracts, Accounts, Opportunities, etc. demoram muito para serem atribuídas aos times ou perfis responsáveis;
• Product Configurator: Lentidão ao configurar um produto;
• Lentidão generalizada.

A Alta Disponibilidade (HA) é a nossa inimiga!

Não, a alta disponibilidade não é nossa inimiga ou, em dois casos bem específicos, até podem ser. Explico:

Alta Disponibilidade – Siebel

A partir da versão Siebel 7.8.2.x, se não me falha a memória, foi introduzido nas bibliotecas de gestão de recursos no banco de dados do Siebel o recurso de reconexão quando há a perda de conexão abrupta.

É fácil para nós, meros mortais, interpretar a perda de conexão abrupta como quedas de instâncias do Oracle RAC, perdas de conectividade com a rede ou falhas de roteamento de rede, por exemplo, certo?

Contudo, o grande xis da questão é que o kill de sessões no banco de dados também é considerado uma perda de conexão abrupta e, por isso, há a reconexão partindo do Siebel Object Manager para continuar a processamento exatamente do ponto onde ele foi interrompido. 

Meu amigo, esse é um tremendo recurso que merece vir habilitado por padrão. 

Imagine a quantidade de reclamações dos usuários se, por exemplo, intermitências de rede causassem a queda irremediável da conexão com um posterior logoff do usuário e a necessidade de reinício da atividade que gerou o problema inicial? Seria o caos!

Alta Disponibilidade – Oracle TAF

O Oracle  TAF (Transparent Application Failover) interpreta o kill de sessões da mesma forma que faz com qualquer outra conexão de rede perdida e simplesmente reconecta e reinicia a consulta. 

Já sabe do que estamos falando?

Agora que você já sabe o que é uma sessão ofensora e porque matá-la não adianta nada com o ambiente padrão, seguimos adiante sobre esse tema tão recorrente para o SADMIN e o DBA, mas não hoje.

No próximo artigo dessa trilogia, vou mostrar como identificar sessões ofensoras no database, seja através dos logs do Siebel ou do próprio banco de dados, e no último artigo sobre esse tema, veremos como desativar a reconexão da engine do Siebel para alguns componentes.

Se sua operação Siebel está com problemas de lentidão, travamentos inexplicáveis ou crashs e erros incorrigíveis, fale com a gente. 

Abraço.