Este é o terceiro e último artigo que trata do tema “Kill de Sessões Siebel”. A introdução sobre o assunto pode ser lida na primeira parte e o mapa para identificar sessões ofensoras pode ser consultado aqui.
Alguns alertas importantes
Os procedimentos descritos aqui envolvem configurações sensíveis que, quando mal parametrizadas, podem causar a indisponibilidade do seu ambiente Siebel.
Faça sempre os backups das suas configurações conforme as sugestões aqui descritas. Se qualquer coisa der errado, faça o rollback das configurações ao estado que estavam antes da configuração e descubra onde está o erro antes de tentar novamente.
Esse guia não é um passo-a-passo e tão pouco recomendado de ser implantado de forma indiscriminada.
Cada ambiente é um ambiente e muito provavelmente a configuração do seu ambiente seja ou esteja diferente da configuração base o que é utilizada como exemplo aqui.
Do mais. sobre desabilitar o recurso de alta disponibilidade para conexões no banco de dados, conforme falamos logo no primeiro artigo dessa série de artigos:
“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!”
Portanto, apenas desative esse recurso se, e somente se, você estiver seguro que há mais ganhos que perdas do ponto de vista de operações.
Esteja seguro dos riscos envolvidos e só siga adiante se seu SADMIN e seu DBA estiverem de acordo.
Nós recomendamos nunca desativar esse recurso em ambientes com altas taxas de perdas de conexão decorrente de problemas de rede como latência, perda de pacotes ou quedas constantes de instâncias do Oracle RAC.
O caminho das pedras
O caminho a seguir para conseguir matar sessões ofensoras do Siebel é a própria Oracle quem aponta no documento Doc ID 753941.1.
Se você não têm acesso ao My Oracle Support, deixo aqui o documento PDF com data de 19/09/2020 (os documentos da Oracle no MOS podem sofrer alterações ao longo do tempo).
Mastigando o Doc ID 753941.1
O documento aponta o parâmetro DSDisableExecuteRetry (padrão é False) como o flag capaz de indicar para o Object Manager se deve deixar de persistir as sessões que foram interrompidas de forma abrupta no banco de dados ou não.
O problema é que esse parâmetro está embutido no Named Subsystem ServerDataSrc que é atribuído a todos os Objects Managers do Siebel Enterprise num ambiente “vanilla” e raramente isso é alterado, mesmo nos ambientes mais customizados.
Trocando em miúdos, se você “ativar a desativação” integralmente, você desativa o recurso para todo seu Siebel Enterprise. A seguir o procedimento:
- Fazer cópia de segurança do siebns.dat
- Baixar o serviço dos servidores Siebel, sem baixar o Siebel Gateway
- Logar na console do Server Manager no nível do Siebel enterprise com o comando
- srvrmgr /g GATEWAY /e ENTERPRISE /u USER /P PASSWORD
- Alterar o parâmetro DSDisableExecuteRetry para True com o comando
- change parameter DSDisableExecuteRetry=True for named subsystem ServerDataSrc
É isso que você quer? Tem certeza? Faça backup do seu siebns.dat e vá em frente. Agora pense bem: Faz sentido fazer isso?
Um AOM tipo o eSales, eEnergy ou eCommunications podem gerar muitas sessões ofensoras em decorrência das queries que os próprios usuários acabam fazendo na aplicação.
Nesses casos, até faz sentido desativar ao recurso, pois blindar o usuários de usar a aplicação como ele bem entende é quase impossível.
Agora, faz sentido “ativar a desativação” para componente co perfil de utilização semelhante ao EAI, Workflows Process Manager, Workmons (batches e on-line), eMail Inbound Processor, ou outros cujas as consultas são majoritariamente decorrentes de customizações do produto?
Talvez em casos específicos, mas apenas para um ou outro componente. Dificilmente para todos.
Ativar o DSDisableExecuteRetry de forma mais restrita
A alternativa a desativar a reconexão para todo Siebel Enterprise consiste em:
- Fazer cópia de segurança do siebns.dat
- Duplicar o Named Subsystem ServerDataSrc
- Ativar o DSDisableExecuteRetry alterando o valor para TRUE no novo Named Subsystem
- Atribuir o novo Named Subsystem ao componente que se pretende alterar, removendo o alias do antigo Named Subsystem e substituindo pelo novo alias nos seguintes parâmetros do componente:
- NamedDataSource
- DataSource
- CFGDatasource
O caminho mais simples é fazer essa configuração através da interface de usuário do seu ambiente, na administração de perfis, para a cópia do Named Subsystem, e depois na definição de componentes, para alterar o Named Subsystem associado ao mesmo.
Caso queira fazer via console de administração (srvrmgr), apesar de perfeitamente possível, o processo é mais complexo e têm muito mais chances de dar errado.
- Fazer cópia de segurança do siebns.dat
- Baixar o serviço dos servidores Siebel, sem baixar o Siebel Gateway
- Logar na console do Server Manager no nível do Siebel enterprise com o comando, listar os parâmetros e os parâmetros avançados do ServerDataSrc com o spool ligado
- srvrmgr /g GATEWAY /e ENTERPRISE /u USER /P PASSWORD
- spool PATH
- list param for named subsystem ServerDataSrc show PA_ALIAS, PA_VALUE
- list advanced param for named subsystem ServerDataSrc show PA_ALIAS, PA_VALUE
- Editar o arquivo de spool gerado copiando todos os parâmetros e parâmetros avançados e reservando
Criar um novo Named Subsystem com os mesmo parâmetros reservados acima, com exceção do
create named subsystem NOME_NAMED_SUBSYSTEM for subsystem ALIAS_NAMED_SUBSYSTEM with DSDisableExecuteRetry=TRUE,parameter_alias_name1=value1, parameter_alias_name2=value2…
- Reconfigurar o componente que você deseja atribuir o nome Named Subsystem
reconfig compdef ALIAS_COMPONENTE
- Modificar os parâmetros do componente
change parameter NamedDataSource=”ALIAS_NAMED_SUBSYSTEM,GatewayDataSrc,DataMart,ServerDataSrc2″ , CFGDatasource=”ALIAS_NAMED_SUBSYSTEM”, DataSource=”ALIAS_NAMED_SUBSYSTEM” for compdef ALIAS_COMPONENTE
Comitar a reconfiguração das definições do componente ” UCM Object Manager (PTB)”
commit reconfig compdef ALIAS_COMPONENTE
- Iniciar os serviços dos Siebel Servers
Processo de Rollback
Deu errado? Pare todo o ambiente Siebel, incluíndo o Siebel Gateway, e volte o backup do siebns.dat.
Continua após a publicidade.
E agora?
Agora que o DSDisableExecuteRetry foi ativado, quando uma sessão ofensora sofrer um kill, o componente não irá forçar uma reconexão e resubmissão do mesmo comando para o banco de dados.
Um erro irá subir para o componente e possivelmente irá causar um fechamento da tarefa que originou o comando.
E assim termina nossa trilogia
Enquanto no primeiro artigo passamos o contexto geral do que vem a ser um sessão ofensora e no segundo as formas de identificar essas sessões, nesse derradeiro artigo oferecemos o workaround para desativar o recurso de Alta Disponibilidade para sessões no banco de dados.
Não deixem de comentar os artigos.
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
