Esta é a segunda parte do tema que trata sobre Kill de Sessões Siebel. A introdução sobre o assunto pode ser lida aqui. O terceiro e último artigo sobre o tema será referenciado assim que for publicado.
Alinhando algumas expectativas
Conforme esse artigo foi sendo rascunhado, o texto foi ficando cada vez mais extenso porque existe muito assunto correlato.
Foi necessário um saneamento (sim, este artigo está saneado!), com uma abordagem mais centrada no tema. Por isso, tópicos que merecem um atenção exclusiva foram removidos desse texto.
Se você busca as causas das sessões ofensoras, aqui você encontrará um bom mapa.
Relembrando o motivo que faz o Kill de Sessões Siebel no Database merecer uma trilogia de artigos
Em suma, os motores de alta disponibilidade interpretam um kill de sessões como uma interrupção abrupta da conexão. Em decorrência disso, lançam novamente a mesma instrução para o banco de dados reiniciando a sessão ofensora e o problema inicial.
Identificando uma sessão ofensora
Em operações maduras, onde há um ou mais de um SADMIN responsáveis pelo ambiente Siebel, certamente há processos que rotineiramente identificam sessões ofensoras.
Automatizar os processos de identificação, log e kill de sessões ofensoras é algo que quase todas as operações têm necessidade e deveriam fazer.
Nesse artigo, vamos passar informações gerais que, se bem aproveitadas, podem servir como base para que os SADMINs automatizem esses processos conforme as particularidades da operação onde estão inseridos.
ATENÇÃO: O kill de sessões ofensoras é um último recurso. Portanto, é importante seguir algumas boas práticas para evitar que sessões se tornem ofensoras. Ao longo desse artigo, daremos algumas dicas de boas práticas para tal.
Detectando o problema do início
Em operações ainda pouco maduras do ponto de vista da gestão automatizada de problemas no ambiente, as sessões ofensoras geralmente são percebidas na “ponta”. Isso quer dizer que são notadas quando causam impactos sensíveis de alguma forma a alguma área da operação.
No artigo anterior sobre o tema “Kill de Sessões Siebel”, mencionamos alguns desses pontos de impacto sensíveis às sessões ofensoras. Relembrando, falamos superficialmente sobre:
- 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.
Só para deixar claro, os exemplos a anteriores não contemplam todos os cenários possíveis onde o problema pode ser observado. É meio óbvio, mas é sempre bom alinhar expectativas 😉 .
Continua após a publicidade
Quando um componente Siebel é impactado por alguma sessão ofensora ao banco de dados, o SADMIN é sempre o segundo a saber. O primeiro, por óbvio, é o usuário do produto ou da operação impactada.
Dentre as causas mais comuns de sessões ofensoras, destacamos:
- Queries em BCs com Search Specification sobre colunas não indexada ou com índices ruins;
- Queries feitas pelo usuário em colunas não indexadas;
- Queries em campos multivalorados;
- Queries montadas via script usando variáveis como binds e que, por N motivos, as variáveis são passadas nulas ou vazias;
- Export de registros em list applets sem filtros eficientes;
- Queries (até as rápidas) em execução repetidas vezes dentro de loops imensos;
Pesquisando sessões ofensoras diretamente no banco de dados (Oracle)
Para executar a seguinte consulta, você precisa do seguinte grant (além da boa e velha SSE_ROLE):
GRANT SELECT_CATALOG_ROLE TO seu_usuário;
Consulta para recuperar sessões em execução:
Claro que nem todas as sessões que retornarem na consulta acima são necessariamente sessões problemáticas. Veja que temos uma coluna “TEMPO DE EXECUÇÃO” que nos dá um norte a seguir.
Ainda assim, nem todas as sessões em execução há muito tempo são elegíveis a um kill e, da mesma forma, nem toda sessão em execução a pouquíssimo deixa de ser ofensora.
Podem existir sessões relacionadas a extratores de dados, processos batch mais demorados, leituras gigantescas, backup de dados, etc. que ficam em execução por horas, mas não são passíveis de kill. Já foram otimizados ao máximo, mas ainda assim demoram. Faz parte do negócio.
Também é comum ter uma mesma sessão (mesmo SID/serial#/inst_id) sempre em execução a pouquíssimos segundos. Isso é um indício de uma consulta dentro de um loop. Pode ser um comportamento normal, dependendo do processo que o originou, ou pode ser classificado como erro. Cada caso é um caso.
Uma outra informação importantíssima é dada pelas colunas ses.username, ses.machine, ses .program e ses.process. Em conjunto elas informam o usuário siebel, o servidor de aplicação, o tipo de componente (multithread, batch, etc.) e, o mais importante, o número do processo e thread que está originando a sessão ofensora. Trocando em miúdos, é o mapa para achar o processo siebel (servidor > componente > tarefa > usuário) problemático.
O “list task” da console do Server Manager e suas variantes nunca foi tão útil quanto agora ;).
As colunas ses.client_identifier, ses.action e ses.module só vão te ajudar em algo se o workload tagging estiver habilitado (à partir do Siebel 8.1.1.9).
Veja que o malandrão que escreveu esse artigo já deixou no esquema o comando para dar o kill na sessão se for necessário.
Locks (Oracle)
Os locks também são ofensores e do pior tipo que existe , pois criam um efeito cascata gigantesco se o bloco lockado for de um objeto extremamente utilizado.
Apesar deles retornarem no SELECT do tópico anterior , algumas informações mais específicas para esse tipo de ofensor são mais características.
Não vou aprofundar o assunto, pois é muito pano pra manga, mas é importante destacar que geralmente locks ocorrem por causa de:
- Workflows com EAI Transaction que apresentam erros e não têm fluxo de exceção;
- Erros de configuração de normas de Workflow;
- Algum bonitão fazendo update direto na base de dados e esquecendo commitar (um dia, quem sabe, faremos alguns artigos só pra falar de blindagem de banco de dados Siebel );
Além disso, basta matar a sessão causadora do lock para que todas as demais sessões impactadas pelo lock sejam liberadas na sequência.
Aqui uma consulta que pode ajudar a mapear sessões ofensoras e impactadas por locks (créditos ao meu amigo Taian Nunes).
Não colocamos o comando para dar o kill na consulta, mas se você entendeu bem o tópico anterior, fica fácil adaptar. Tenha cuidado para não confundir as colunas que identificam a sessão ofensora – Hold – da sessão impactada – Wait).
AWR (Oracle)
O AWR do banco de dados Oracle também é uma fonte valiosa para buscar sessões ofensoras, principalmente quando queremos buscar dados históricos (recentes) e não temos nenhum outro tipo de monitoria personalizada no ambiente.
No mesmo passo que o AWR dispõe de informações mais detalhadas, também exige um maior nível de conhecimento para conectar os comandos ofensores com os processos Siebel que os causaram.
Em linhas gerais, o AWR serve mais ao esforço de correção de problemas no nível do banco de dados do que no mapeamento de ofensores na camada de aplicação. Ainda assim, vamos tentar destacar alguns pontos importantes desse relatório quando o contexto são as sessões Siebel.
Só para facilitar a contextualização, abaixo temos exemplo de AWR:
Sobre o que consideramos importante destacar sobre os AWR sob a ótica que rege esse artigo, segue:
- Atenção ao “Inst Num”, “Begin Snap” e “End Snap”.
- Se as sessões ofensoras não executaram na instancia em questão (se RAC) ou nesse intervalo específico, a chance de serem identificáveis no relatório são remotas.
- O “SQL ordered by Elapsed Time”, como o nome informa, exibe os sql ordenados pelo tempo de execução.
- Nem todos os SQLs aqui necessariamente foram disparados pelo Siebel.
- Como dito anteriormente, tempo de execução é apenas um indício (forte, é verdade) de sessão ofensora.
- Aqui, mesmo as consultas com tempo de execução baixo, olhando de forma isolada, serão destacadas como ofensoras quando são muito executadas ( Elapsed Time (s) / Executions /Elapsed Time per Exec (s))
- O “Module” dá uma boa pista da origem da consulta
- O SQL id é sempre único por comando SQL
- Mesmo em outra instancia de banco de dados (um data guard ou um banco do ambiente de testes, por exemplo) um mesmo sqlid representa a mesma consulta sql (desde que os bancos de dados estejam na mesma versão)
- Sob a ótica exclusivamente do banco de dados, ofensores podem estar relacionados a tempo de execução ou:
- CPU Time
- User I/O Wait Time
- Gets
- Reads
- Physical Reads
- Executions
- Parse Calls
- Sharable Memory
- Version Count
Logs do Siebel
Os logs do que o Siebel pode gerar são outra forma de encontrar sessões ofensoras.
Para ter a visibilidade das informações que utilizaremos como exemplo, será necessário a configuração do seguinte nível de log:
ObjMgrSqlLog = 4
Esse set pode ser feito via console do Server Manager através do seguinte comando:
change evtloglvl ObjMgrSqlLog=4 for comp ALIAS_COMPONENT server SIEBEL_SERVER
Abaixo um exemplo de como os comandos aparecem no log das tarefas instanciadas para o componente com nível de log configurado:
Com o evento de log ObjMgrSqlLog = 5 (DEBUG) combinado com o evento ObjMgrSqlCursorLog = 5 temos algumas informações adicionais que podem ajuda a identificar o ponto onde o comando é disparado:
Destacamos alguns aspectos dos trechos de log acima para utilizar as informações da melhor forma possível. Vejamos:
- Binds são binds. Se você não sabe o que são binds, volte um casa.
- A última tabela de uma consulta Siebel geralmente é a tabela base do BC.
- Atenção para o geralmente. Existem exceções em BCs que utilizam classes especiais, queries decorrentes de campos multivalorados, etc.
- O SQL tagging, em versões superiores a 8.1.1.1, fornecem algumas informações interessantes no log que são passadas na Bind variable 1. Mais detalhes aqui.
- O tempo de execução é passado em segundos
- “0.061 seconds” é o equivalente a 1 segundo / 1000 * 61, ou seja, 61 milissegundos. Se fossem 1.233 seconds, seria 1 segundo mais 233 milissegundos.
- O “SQL Statement Prepare Time” representa o tempo necessário para o banco de dados preparar a consulta para execução.
- O tempo de preparação envolve, entre outras ações da engenharia do banco de dados, o esforço para encontrar o o melhor plano de execução para a consulta.
- Problemas com o tempo de preparação em banco de dados Oracle geralmente estão associadas a complexidade da consulta associada com algum parâmetro do banco de dados que aumenta o esforço para encontrar o melhor plano de execução
- O “SQL Statement Execute Time” representa o tempo que a consulta efetivamente ficou em execução.
- A maior parte das sessões ofensoras gastam tempo no tempo de execução.
- O “SQL Statement Initial Fetch Time” representa o tempo até preparar primeiro fetch de dados.
- Fetch é, de certo modo, a transferência do dado do banco de dados para o cliente do banco de dados (Servidor Siebel, nesse caso)
- Problemas relacionados com fetch geralmente estão associados a latência de rede, perda de pacotes, regras de firewall, etc.
- O “ObjMgrSqlCursorLog Fetch” (transferência do banco de dados para o servidor de aplicação) representa no log o fetch de cada linha.
Atenção: Muitas vezes o tempo de fetch parece estar comprometido nos logs do Siebel quando na verdade é o log do siebel que está comprometendo o tempo de fetch. Em servidores siebel com alto consumo de CPU ou atividades extremas de IO, a escrita em arquivo de log para cada fetch de linha retornada do banco de dados pode criar um gargalo do lado do client (servidor siebel). Portanto, seja cuidadoso na sua análise para não confundir as bolas.
Fechando o segundo artigo
Enquanto o primeiro artigo dessa série focou no contexto do que vem a ser uma sessão ofensora e na dificuldade de matar esse tipo de sessão no banco de dados, esse artigo focou nas formas de identifica essas sessões, seja através do banco de dados ou através de logs do siebel.
No próximo artigo dessa trilogia, veremos como desativar a reconexão da engine do Siebel em alguns componentes para, de fato, conseguirmos matar uma sessão ofensora no banco de dados.
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.
Do you need help with Assessment and Troubleshootings in your Oracle Siebel CRM environment or in the Database? Contact us.
By Neilson Faria
Siebel Architect & Troubleshooter
