DRCP e seus processos

[Emerich 0]

Boa tarde amigos!

 

Estou com uns problemas na combinação Oracle+DRCP+PHP. Apliquei as diretivas indicadas pela Oracle como conexão persistente e connection class mas nos horários de pico ele estoura as conexões limites do pool.

 

O DBA aqui da empresa mata os processos ora_l que estão rodando há muito tempo pois ele acha que estão presos até porque uma consulta durar mais que 10 segundos é muito tempo, certo?! Imagina uma de 30, 50 minutos. Mas fica uma pulguinha atráz da minha orelha dizendo que é pra ser assim mesmo, já que a ideia de se ter um pool é compartilhar as conexões existentes, certo? Portanto o processo ficaria mais tempo na máquina.

 

Busquei na internet e não achei nada sobre a lifetime de uma conexão pooled, se quando uma conexão é reutilizada o processo é finalizado e reiniciado ou simplesmente continua rodando.

 

Agradeceria a ajuda dos colegas! Obrigado!

[Motta 645]

https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:5671284058977

 

 

https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:22140261281764

 

 

 

 

Depende do que os processos estão fazendo, de como foi montada a arquitetura, numa pesquisa rápida achei dois links doAskTom, mas acho que precisa detalhar melhor o problema.

[Emerich 0]

Opa! Vlw o retorno!

 

Vamos lá! Quando me refiro a processo, digo os que aparecem no comando top do servidor. O oracle gera processos com nomes iniciados com 'ora_l', vamos usar como exemplo um processo chamado ora_l013.

 

Quando executo select * from gv$process where program like '%(L0%)' ORDER BY program, inst_id; aparecem todos os processos a serem gerados. Atualmente gera de L000 até L009. Diminuimos de 40 para 10 o máximo de conexões para averiguar a vida de um processo.

 

Quando executo select * from gv$session where program like '%(L0%)' ORDER BY program, inst_id; fica oscilando a quantidade de registros. O que me intriga nessa query é que o status está sempre INACTIVE, mas não to focando muito nisso ainda. E muitas vezes o processo no continua no 'top' e não aparece nessa query.

 

Um cliente solicita conexão no pool, o processo ora_l013 é iniciado. O retorno da SQL é enviado para o apache/php e o usuário recebe o retorno, mas o processo ora_l013 continua aparecendo no comando 'top' e fica lá até alguém matá-lo. Fica por 20, 30 minutos. Ontem alteramos umas configurações no pool e diminuimos a lifetime das conexões para ver se isso muda, mas a minha dúvida persiste. O processo ora_l013 continua aberto, contando tempo mesmo não sendo utilizado a conexão ou a conexão está ficando presa mesmo?

 

O DBA aqui da empresa diz que esses processos estão ficando travados e com isso gera fila no banco e assim derruba os sistemas, mas algo me diz que esses processos devem ficar rodando mesmo e então devemos rever as configurações do pool.

[Motta 645]

mas algo me diz que esses processos devem ficar rodando mesmo e então devemos rever as configurações do pool.

 

 

Concordo, é a ideia do pool de conexões, não ficar criando conexões a todo momento eles estão lá esperando as requisições.

[Emerich 0]

Opa! Fico feliz em não ser o único com essa teoria!

 

Você pode me indicar algum local onde eu possa buscar uma documentação que comprove essa teoria? procurei nas documentações do oracle, mas elas não falam do lifetime do processo no 'top'. Falam do lifetime da conexão, da sessão menos do processo gerado no SO.

[Motta 645]

Os links do AskTom não ajudaram ?

[Emerich 0]

não especificaram sobre o processo no SO... vou dar uma relida ali. Eu não conhecia esse site, ele é específico pra oracle?

 

nem tinha reparado na URL que é do oracle mesmo.. vou dar uma fuçada ali! Vlw cara!

 

 

Bom dia amigos!

 

Venho aqui dar um retorno sobre este tópico. Fizemos vários testes aqui na empresa e foi constatado que os processos no SO ficam abertos mesmo por vários minutos pois ele é reutilizado.

 

Para monitorar o seu pool DRCP você deve utilizar as views dele. [g]v$session e [g]v$process não dão informações importantes sobre a utilização do pool. Estamos usando aqui:

 

- GV$CPOOL_STATS: mostra a utilização das conexões disponíveis (num_busy_servers) e a consistência do pool onde num_requests deve ser o mais próximo possível de num_hits. Essa view que está nos ajudando a tomar nossas ações para evitar o travamento do banco.

- GV$CPOOL_CONN_INFO: mostra detalhes de cada conexão

- DBA_CPOOL_INFO: essa mostra apenas o modo que o pool está configurado.

 

Aqui temos 2 servidores ligados em RAC. Se você tirar o 'G' da frente da view (usar V$CPOOL_STATS por exemplo) vai mostrar informações da máquina em que você está conectado. Com o 'G' você recebe mais um campo chamado 'INST_ID' e mostra todos os nós do RAC, facilitando o gerenciamento do seu pool.

 

Agradeço a atenção do forum. Podem fechar o tópico!

 

Obrigado!

 

 

Ops.. esqueci de uma que me ajudou no início: GV$CPOOL_CC_STATS

 

As conexões num pool são compartilhadas apenas entre requisições onde o usuário e o conection class são iguais. Essa view mostra a utilização do pool por cada conection class que ele mostra em CCLASS_NAME composto por USUARIO.CONNECTION_CLASS.

 

No PHP eu defini o conection class usando a diretiva oci8.connection_class no php.ini. Pode ser atribuída via ini_set se vc tiver permissão.

 

Então, se você tiver muitas linhas nessa view e os cclass_name for composto por USUARIO.[OCI|JDBC...][hash enorme] você não está fazendo bom uso do seu pool já que nenhuma conexão está sendo reutilizada. Aí na view GV$CPOOL_STATS o campo num_requests sobe, o num_hits pode até estar e continuar zerado e sobe muito o num_misses e quando a casa tá caindo o num_waits.

 

Espero que isso ajude alguns que se encontram perdidos, assim como eu estava no começo dessa batalha!