Nesse artigo vamos discutir alguns aspectos e configurações à cerca do Siebel Database Connection Pooling com ou sem persistência para alta disponibilidade.
Sobre conexões de banco de dados não “pooled”
Num Application Object Manager com configuração default, o número de conexões com o banco de dados corresponderá ao número de sessões/tarefas do Siebel Application Object Manager, ou seja, as conexões do banco de dados não são compartilhadas.
Nesses caso, nenhuma configuração especial do é necessária para usar conexões de banco de dados dessa forma.
Quando nenhum pooling é configurado, as conexões com o banco de dados são fechadas quando a sessão do usuário é finalizada e uma nova conexão é aberta quando necessário.
Sobre conexões de banco de dados em pool
Opcionalmente, você pode configurar seus componentes do Siebel Application Object Manager para suportar a persistência de conexões de banco de dados, compartilhamento (multiplexação) dessas conexões ou ambos
As conexões persistentes são agrupadas, mas não necessariamente compartilhadas. O uso de conexões persistentes pode melhorar o desempenho, evitando o custo de criação de conexões com o banco de dados.
Já as conexões compartilhadas suportam várias sessões do usuário ao mesmo tempo, por meio da multiplexação (compartilhamento) de operações do banco de dados para várias instruções SQL sobre a mesma conexão com o banco de dados. Todas as conexões compartilhadas também são conexões persistentes.
Continua após publicidade.
Quando considerar o uso do pool de conexões de banco de dados
Considere a possibilidade de implementar o pool de conexões com o banco de dados se, e somente se , um ou mais dos seguintes itens forem verdadeiros para sua implantação:
O RDBMS não pode suportar o número de conexões de usuários dedicadas que você precisaria se estivesse usando conexões de banco de dados não reunidas. O agrupamento de conexões de banco de dados padrão para uso compartilhado pode reduzir o número de conexões necessárias.
Os recursos de memória são escassos no computador do Siebel Server no qual o Siebel Application Object Manager está sendo executado. O agrupamento de conexões de banco de dados padrão para uso compartilhado pode reduzir os requisitos de memória do Siebel Application Object Manager por usuário simultâneo.
Sua implantação usa autenticação externa, como LDAP e a criação de novas conexões é lenta no servidor de banco de dados. O agrupamento de conexões com o banco de dados pode acelerar o login ou outras operações, fornecendo um agrupamento persistente, independentemente de as conexões também serem ou não compartilhadas.
Você usa um componente do Servidor Siebel que requer logins freqüentes para processamento de propósito especial. O agrupamento de conexões de banco de dados para fornecer pooling de conexões persistentes (não compartilhamento) pode fornecer um benefício significativo para esses componentes.
Para o Siebel Configurator, se você estiver usando o componente Siebel Product Configuration Object Manager (alias eProdCfgObjMgr_jpn em um código de idioma japonês), é altamente recomendável configurar o conjunto de conexões persistentes.
Para alguns outros componentes, como o EAI Object Manager (quando executado no modo sem sessão), também pode ser útil configurar o pool de conexões persistentes.
O Workflow Process Manager (WfProcMgr) ou os componentes que compartilham essa engine não precisam e não devem ser considerados para customização do pooling de conexões, pois suas engines vanilla já possuem esse mecanismo incorporado e funcional.
Siebel Database Connection Pooling + Persistência
Os parâmetros de para o Siebel Database Connection Pooling possuem uma relação direta com o ratio de tasks por OM e, portanto, com os parâmetros MaxTask e MaxMTServers.
Considerando que a configuração default do Siebel prevê uma relação de 1 x 1 em relação à sessões/tasks e conexões no banco de dados, a recomendação geral é nunca ser ousado demais ao alterar esse ratio.
Comece devagar
Um ratio de 2 X 1 (duas conexões no banco de dados por sessão/task) seria configurado da seguinte forma para um componente com MaxTask=100 e MaxMTServer=5:
- MaxSharedDbConns =50
- MinSharedDbConns = 50
A configuração acima instrui o Siebel Component a abrir e persisitir 50 conexões no DB e compartilhar essas conexões com até 100 sessões/tasks.
Essa configuração habilita persistência de conexão e poolling.
Podem haver situações que você não possa ou não deva habilitar o pooling (componentes que, por desenho da ambiente em questão ficam muito tempo processando queries pesadas, geralmente criam gargalos de processamento quando o pooling está habilitado), mas seja interessante habilitar a persistência de conexões. Veremos como fazer à seguir.
Persistência sem Siebel Database Connection Pooling
Nos casos onde você deseje que as conexões no DB persistam mas não seja compartilhadas entre as sessões (sem pooling), o seguinte exemplo de configuração pode ser utilizado:
MaxTask=100
MaxMTServer=5
MaxSharedDbConns =99
MinSharedDbConns = 99
Com praticamente 1 conexão por tarefa (100/99) não há de fato o pooling contudo 99 DB connections são abertas e persistem para serem utilizadas pelas 100 sessões/task do component.
Você pode se perguntar: “Por que não setar o Min e o MaxSharedDbConns =100?”. A resposta é simples: Igualando o valor de MaxTasks com o valor do MaxSharedDbConns a engine do Siebel conclui que deve utilizar um ratio de 1×1 e desabilita tanto o pooling quanto a persistência de conexões no database.
Utilizar MaxSharedDbConns igual ao MinSharedDbConns ou não?
Nos exemplos dados até aqui, nós sempre igualamos o MaxSharedDbConns com o MinSharedDbConns. Na prática, isso significa que quando os OMs são lançados no SO, todas as conexões de banco necessárias para as tarefas que podem ser instanciadas já são abertas.
Isso pode se refletir numa atividade mais intensa no banco de dados ao subir os serviços do Siebel, mas, em compensação, elimina o overhead decorrente da abertura de sessões sob demanda ao longo da operação.
Se os recursos do Banco de Dados são mais escassos ou se sua operação tem demanda e uso bem deslabanceado (semanas há 1000 usuários e semanas há 100 usuários trabalhando, por exemplo) pode ser interessante um MinSharedDbConns mais baixo.
E o MinTrxDbConns?
O MinTrxDbConns é outro parâmetro mais restrito que controla a quantidade de conexões especializadas que um OM pode utilizar em pooling.
Conexões especializadas nada mais são que conexões adicionais que uma mesma tarefa pode abrir com o Database de forma explícita.
Como vocês bem sabem, o Siebel trabalha os DMLs em blocos nas suas transações normais. Contudo, existem situações funcionais onde uma determinada operação precisa ser “commitada” no database independente do resultado de processamento do bloco de operações restantes. Geralmente esses cases são atendidos pelo Business Services de EAI Transaction Service (BeginTransaction, EndTransaction, etc.).
Voltando ao MinTrxDbConns…
O default desse parâmetro é -1, ou seja, não há pooling para conexões especializadas e, sempre que um BeginTransaction for invocado, uma nova conexão será aberta no banco de dados por aquele OM “pai” daquela tarefa em execução.
Para qualquer valor maior ou igual a 1, o OM cria um pool para as conexões especializadas que fica permanentemente aberta.
Aqui, o único alerta é que esse pool é por OM. Se o componente, tem um Min/MaxMtServer igual a 20 e a configuração para o MinTrxDbConns = 10, estamos falando de 200 conexões adicionais no banco de dados permanentemente abertas e exclusivas para transações especializadas. Pode ser um exagero e um consumo de recursos desnecessários, certo?
Bem, cada caso é um caso.
Do you need a Siebel architect to assess whether DB connection pooling could reduce resources in your environment? Contact us.