8643 - shared pool no visualizador de usuários
Problema: Descrição do Problema: problemas de lock da shared pool do Banco Oracle, o que acaba travando todos os usuários do SIistema ao mesmo tempo e demais aplicações. Segundo cliente, este problema começou a ocorrer após a instalação da versão 5.7.3.22.
Inicialmente se suspeitou-se do Banco ou de lock normal da aplicação Senior, porém nunca havia ocorrido desta forma.
O que se observou é que quando o número de processos rodando supera o nosso limite de licenças, há o lock da shared pool. Pela documentação do Sapiens, o que poderia ocorrer é uma mensagem avisando que o número de licenças já foi utilizado.
Em uma noite ocorreu fato ainda mais grave. Os processos automáticos não rodaram e os coletores móveis estavam indisponíveis. Não chegavam nem a responder ao ping. Cliente reiniciou os serviços Senior, suspeitou também do firewall, do Banco, mas foi apenas derrubar o SGU -V (que estava rodando para monitorar as conexões) que tudo voltou a funcionar normalmente.
Solução: Solução: Após uma análise sobre a situação descrita no chamado, identificamos que não é o sistema que está causando esta situação, mas sim uma provável limitação do banco.
A shared pool é uma porção de memória compartilhada que contém as áreas chamadas shared SQL, estruturas de memória compartilhadas que contêm os comandos SQL que estão sendo executados pelos múltiplos usuários conectados a um banco de dados.
O que está acontecendo é que o espaço disponível para o shared pool esta sendo consumido antes que a aplicação atinja o limite de processos permitidos pela proprietária,
uma evidência encontrada é que na proprietária disponilizada para o cliente permite 211 conexões, sendo que o lock descrito na tarefa está acontecendo em torno de 188 conexões/processos, desta forma não ocorrerá a exceção lançada pelo sistema. Como houve uma alteração de versões, houve um aumento na quantidade de processos que são registrados pelo sistema, nesse caso nada mais que o normal, já que a aplicação recebe novas implementações a cada versão, assim com a execução de mais processos, mais comandos serão executados pelo banco, consumindo assim mais espaço nesta área de memória.
Referente ao SGU -v, este aplicativo não realiza nenhuma alteração na base(Insert/Delete), pois ele serve apenas como um visualizador das tabelas R911SEC/R911SRV. Esta aplicação realiza apenas SELECTs nas tabelas para listar as conexões/processos. O que acontece é que como o SGU -v realiza SELECTs na base, esses comandos ficarão armazenados na shared pool, consequentemente se o espaço disponível na shared pool estiver prestes a ser consumido, ocorrerá o lock na shared pool. Isso justifica o funcionamento do sistema com o SGU fechado, porém não indica que o problema seja ele, pois se houver um aumento nas conexões ou processos que executem comando variados o lock ocorrerá da mesma forma, caso o limite seja atingido.
Inicialmente se suspeitou-se do Banco ou de lock normal da aplicação Senior, porém nunca havia ocorrido desta forma.
O que se observou é que quando o número de processos rodando supera o nosso limite de licenças, há o lock da shared pool. Pela documentação do Sapiens, o que poderia ocorrer é uma mensagem avisando que o número de licenças já foi utilizado.
Em uma noite ocorreu fato ainda mais grave. Os processos automáticos não rodaram e os coletores móveis estavam indisponíveis. Não chegavam nem a responder ao ping. Cliente reiniciou os serviços Senior, suspeitou também do firewall, do Banco, mas foi apenas derrubar o SGU -V (que estava rodando para monitorar as conexões) que tudo voltou a funcionar normalmente.
Solução: Solução: Após uma análise sobre a situação descrita no chamado, identificamos que não é o sistema que está causando esta situação, mas sim uma provável limitação do banco.
A shared pool é uma porção de memória compartilhada que contém as áreas chamadas shared SQL, estruturas de memória compartilhadas que contêm os comandos SQL que estão sendo executados pelos múltiplos usuários conectados a um banco de dados.
O que está acontecendo é que o espaço disponível para o shared pool esta sendo consumido antes que a aplicação atinja o limite de processos permitidos pela proprietária,
uma evidência encontrada é que na proprietária disponilizada para o cliente permite 211 conexões, sendo que o lock descrito na tarefa está acontecendo em torno de 188 conexões/processos, desta forma não ocorrerá a exceção lançada pelo sistema. Como houve uma alteração de versões, houve um aumento na quantidade de processos que são registrados pelo sistema, nesse caso nada mais que o normal, já que a aplicação recebe novas implementações a cada versão, assim com a execução de mais processos, mais comandos serão executados pelo banco, consumindo assim mais espaço nesta área de memória.
Referente ao SGU -v, este aplicativo não realiza nenhuma alteração na base(Insert/Delete), pois ele serve apenas como um visualizador das tabelas R911SEC/R911SRV. Esta aplicação realiza apenas SELECTs nas tabelas para listar as conexões/processos. O que acontece é que como o SGU -v realiza SELECTs na base, esses comandos ficarão armazenados na shared pool, consequentemente se o espaço disponível na shared pool estiver prestes a ser consumido, ocorrerá o lock na shared pool. Isso justifica o funcionamento do sistema com o SGU fechado, porém não indica que o problema seja ele, pois se houver um aumento nas conexões ou processos que executem comando variados o lock ocorrerá da mesma forma, caso o limite seja atingido.