Menu de navegação

[Glaucia BressanParticipant]

Olá,
Eu atualizei um banco de dados de 10g XE para 18c XE para um teste de migração.
A importação de dados (expdp no 10 e impdp no 18) e o acesso ao banco de dados funcionaram.
Porém, notei que algumas sessões que rodavam muito rápido lá no 10g, começaram a ficar travadas no 18c.
Na tabela v$session dessa sessão, a coluna EVENT estava “PGA memory operation”, a coluna SQL_ID e PREV_SQL_ID não se alteravam, dando a entender que a sessão está travada porque as operações dela não mudam. A coluna STATUS fica em “ACTIVE”, coluna BLOCKING_SESSION é nula.
A quantidade de memória utilizada na PGA nem chegou perto do limite setado nos parâmetros.

Eu não estou familiarizada com este evento, alguém poderia me ajudar a entender o que está acontecendo ou como arrumar isso, pra fazer a sessão destravar?

Obrigado

[José Laurindo ChiappaModerator]

Tudo jóinha ? Espero que sim… Então, primeiro para vc ficar conhecendo esse evento, é a nota metalink/my oracle support “12c: ‘acknowledge over PGA limit’ Wait Event” (Doc ID 2138882.1) que eu recomendo – ela explica que esse é um novo evento exposto no 12c em diante, atendendo ao novo parâmetro de inicialização PGA_AGGREGATE_LIMIT, E a funcionalidade que esse evento registra é que quando uma sessão quer mais PGA do que recebeu E o consumo geral de PGA tá perto do limite indicado, a sessão que solicitou mais memória PGA VAI ser ‘congelada’ um pouco, ela vai ser FORÇADA a esperar um pouco antes de receber a memória que solicitou, na esperança que OUTRAS sessões liberem alguma memória enquanto isso ….
Essa mesma nota recomenda que, se REALMENTE isso é um overhead Significativo no seu ambiente, vc DESLIGUE o novo comportamente com :

ALTER SYSTEM SET PGA_AGGREGATE_LIMIT=0 SID=’*’ SCOPE=BOTH;

Com isso o comportamento volta a ficar como era no 12cR1 e versões anteriores (incluindo a sua antiga versão 10g)… Além disso, a nota também sugere vc Aumentar PGA_AGGREGATE_TARGET mas como vc tá usando XE (a versão gratuita mas restrita E capada), onde o máximo de RAM no total (aí sendo SGA + PGA, o que seria a soma de SGA_MAX_SIZE + PGA_TARGET_SIZE, se vc adotar o desligamento do PGA_AGGREGATE_LIMIT) que o RDBMS pode usar é 2 GB, isso teria que ser Testado e mensurado Cuidadosamente no seu database para nunca Ultrapassar o limite…..
E é CLARO, vale muito a pena vc MONITORAR como está crescendo ou descendo o consumo de PGA, o que se faz consultando constantemente V$PGASTAT e/ou (se vc quiser uma visão mais detalhada, por processo) a V$PROCESS – se vc ver a PGA em uso só crescer e crescer e nunca descer vc PODE ter algum bug na sua aplicação….
Um exemplo :

SYSTEM@xepdb1::CONTAINER=XEPDB1> select * from v$pgastat;

NAME VALUE UNIT CON_ID

---

aggregate PGA target parameter 0 bytes 0
aggregate PGA auto target 0 bytes 0
global memory bound 104857600 bytes 0
total PGA inuse 3601408 bytes 0
total PGA allocated 5443584 bytes 0
maximum PGA allocated 44404736 bytes 0
total freeable PGA memory 917504 bytes 0
MGA allocated (under PGA) 0 bytes 0
maximum MGA allocated 0 bytes 0
process count 1 0
max processes count 9 0
PGA memory freed back to OS 1048576 bytes 0
total PGA used for auto workareas 0 bytes 0
maximum PGA used for auto workareas 3282944 bytes 0
total PGA used for manual workareas 0 bytes 0
maximum PGA used for manual workareas 0 bytes 0
over allocation count 0 0
bytes processed 43397120 bytes 0
extra bytes read/written 0 bytes 0
cache hit percentage 100 percent 0
recompute count (total) 79 0

21 linhas selecionadas.

==> Agora numa Outra sessão vou criar um grande array em memória (variáveis locais PL/SQL é UMA das coisas que consomem PGA) :

SYSTEM@xepdb1::CONTAINER=XEPDB1> ed
Gravou file afiedt.buf

1 declare
2 type w_type is table of varchar2( 1000 );
3 w_list w_type := w_type();
4 begin
5 for i in 1..10000 loop
6 w_list.extend;
7 w_list(i) := rpad(‘x’, 1000 );
8 end loop;
9* end;
SYSTEM@xepdb1::CONTAINER=XEPDB1> /

Procedimento PL/SQL concluído com sucesso.

SYSTEM@xepdb1::CONTAINER=XEPDB1>

=> Veja como ficou o consumo global de PGA :

NAME VALUE UNIT CON_ID

---

aggregate PGA target parameter 0 bytes 0
aggregate PGA auto target 0 bytes 0
global memory bound 104857600 bytes 0
total PGA inuse 6133760 bytes 0
total PGA allocated 9248768 bytes 0
maximum PGA allocated 44404736 bytes 0
total freeable PGA memory 2097152 bytes 0
MGA allocated (under PGA) 0 bytes 0
maximum MGA allocated 0 bytes 0
process count 2 0
max processes count 9 0
PGA memory freed back to OS 12255232 bytes 0
total PGA used for auto workareas 0 bytes 0
maximum PGA used for auto workareas 3282944 bytes 0
total PGA used for manual workareas 0 bytes 0
maximum PGA used for manual workareas 0 bytes 0
over allocation count 0 0
bytes processed 43397120 bytes 0
extra bytes read/written 0 bytes 0
cache hit percentage 100 percent 0
recompute count (total) 428 0

21 linhas selecionadas.

==> Ou seja, de 3601408 bytes (cerca de 3,5 MB) passou para 6133760 bytes, quase o dobro… Agora vou desconectar da sessão que consumiu a PGA :

SYSTEM@xepdb1::CONTAINER=XEPDB1> exit
Desconectado de Oracle Database 18c Express Edition Release 18.0.0.0.0 – Production
Version 18.4.0.0.0

SID:XE::C:\Users\User 2am>

==> Olha como ficou o consumo global :

SYSTEM@xepdb1::CONTAINER=XEPDB1> select * from v$pgastat;

NAME VALUE UNIT CON_ID

---

aggregate PGA target parameter 0 bytes 0
aggregate PGA auto target 0 bytes 0
global memory bound 104857600 bytes 0
total PGA inuse 3576832 bytes 0
total PGA allocated 5443584 bytes 0
maximum PGA allocated 44404736 bytes 0
total freeable PGA memory 1048576 bytes 0
MGA allocated (under PGA) 0 bytes 0
maximum MGA allocated 0 bytes 0
process count 1 0
max processes count 9 0
PGA memory freed back to OS 13172736 bytes 0
total PGA used for auto workareas 0 bytes 0
maximum PGA used for auto workareas 3282944 bytes 0
total PGA used for manual workareas 0 bytes 0
maximum PGA used for manual workareas 0 bytes 0
over allocation count 0 0
bytes processed 43397120 bytes 0
extra bytes read/written 0 bytes 0
cache hit percentage 100 percent 0
recompute count (total) 538 0

21 linhas selecionadas.

SYSTEM@xepdb1::CONTAINER=XEPDB1>

=> caiu para 3576832, até um pouco menos do que estava antes – ISSO é o normal, SE não houver bug na app cfrme as sessões requisitam E liberam memória o total em uso cresce e desce, E se ele ficar sempre distante dos limites, vc Não deveria ficar esperando pelo evento indicado….

E claro : se minimamente possível eu RECOMENDO que vc : faça uma consulta no momento do consumo de PGA, deslige a aplicação / desconecte as sessões todas E consulte de novo, depois suba a aplicação sem nenhum usuário conectar e consulte de novo, aí peça para um e depois outro usuário ir conectando e desconectando, vai consultando cfrme as coisas acontececem e veja o que acontece aí…

[]s

Chiappa

[Glaucia BressanParticipant]

José, muito obrigado pelas explicações, me ajudou a entender um pouco mais. Vou fazer alguns comentários sobre o que você falou, para detalhar mais:

“quando uma sessão quer mais PGA do que recebeu E o consumo geral de PGA tá perto do limite indicado, a sessão que solicitou mais memória PGA VAI ser ‘congelada’ um pouco, ela vai ser FORÇADA a esperar um pouco antes de receber a memória que solicitou, na esperança que OUTRAS sessões liberem alguma memória”

“MONITORAR como está crescendo ou descendo o consumo de PGA, o que se faz consultando constantemente V$PGASTAT”

– No teste realizado, apenas tinha essa única sessão ativa, não coloquei mais nenhuma tarefa no banco em paralelo, justamente para testar unicamente apenas aquela tarefa, ou seja, nem existem outras sessões para liberar mais memória pra ela. E eu cheguei a monitorar a quantidade de memória utilizada na PGA e ela nem chegou perto do limite setado nos parâmetros, que no caso é 512MB pra PGA (porque deixei 1536MB pra SGA). A versão que estou testando é XE, pois preciso apenas realizar testes de comportamento do sistema nessa versão nova 18c.

“…Essa mesma nota recomenda que, se REALMENTE isso é um overhead Significativo no seu ambiente, vc DESLIGUE o novo comportamente com :

ALTER SYSTEM SET PGA_AGGREGATE_LIMIT=0 SID=’*’ SCOPE=BOTH;

Com isso o comportamento volta a ficar como era no 12cR1 e versões anteriores (incluindo a sua antiga versão 10g)… Além disso, a nota também sugere vc Aumentar PGA_AGGREGATE_TARGET…”

– Eu acabei alterando o parâmetro como orientado (estava setado com 2GB), reiniciei a instância e o evento ainda ocorreu. PGA_AGGREGATE_TARGET estava com 512MB porque deixei 1536MB pra SGA. E na versão 10g XE ela tinha muito menos memória disponível em PGA e SGA e a sessão não ficava aguardando como fica aqui no 18c XE de ficar horas ativas e não executar.

[José Laurindo ChiappaModerator]

Seguinte : é ABSOLUTAMENTE COMUM que novas versões do RDBMS consumam mais memória, já que trazem novos recursos E novas funcionalidades, que não vem de graça, todas CAUSAM consumo extra… No seu caso, já que simplesmente desabilitar o limite hard de PGA não resolveu, eu sugiro que vc faça seus testes numa versão ATUAL e COMPLETA do RDBMS Oracle : o Oracle XE/Express Edition é, como eu disse, uma versão MUITO capada, limitada e restrita…. Já que (imagino!!) teu sistema quando entrar em produção NÃO VAI USAR Express Edition, recomendo vc baixar e instalar uma versão full em http://technet.oracle.com – para TESTES, com dados FICTÍCIOS (do tamanho que seja mas NÃO SENDO dados Reais, válidos, de Produção), vc pode usar os softwares Oracle que vc baixa nesse site Gratuitamente….

Abraços,

Chiappa

[José Laurindo ChiappaModerator]

E um detalhe também : aposto e ganho que se a sua Aplicação antigamente rodava em pré-históricos databases 10g, com CERTEZA ela usava software client Oracle antigo, drivers JDBC/ODBC/OLEDB antigos, gerenciador de pool de conexão de versão antiga…. De modo geral, SE vc vai subir a versão do RDBMS é MUITO RECOMENDADO que vc suba também a versão dos drivers, client Oracle, middleware, etc – isso ajuda MUITO em issues de compatibilidade, E também se for o caso te habilita a obter Suporte Técnico da Oracle……

Abraços,

Chiappa

[Glaucia BressanParticipant]

Obrigado novamente pelas explicações José. Eu estou ciente que a versão XE é limitadíssima e o que estou testando são tarefas que atualmente também rodam em um oracle 10g XE, por isso deduzi que testes nos oracle 18c XE não fariam o consumo mudar assim tão drasticamente, sabia que poderiam ter impactos, mas não da maneira que encontrei. Sobre utilização de drivers antigos, gerenciador de conexões, etc. também estou ciente sobre a incompatibilidade, justamente por isso planejava testes no oracle 18c XE para checar e ajustar esses itens.
Vou planejar testes no site que você sugeriu já que o 18c XE não me ajudou ;/

[José Laurindo ChiappaModerator]

Isso aí… Na verdade, é muito muito provável que só a atualização dos drivers, conectores, client Oracle e framework em geral da Aplicação já resolva ou ajude em muito, MAS meu conselho, já que não dá pra determinar se vc está esbarrando nalguma limitação ou bug do XE, é aproveitar a oportunidade e Realmente já deixar tudo atual, baixando e instalando uma versão full e atual do RDBMS Oracle e depois  instalar e testar teu aplicativo nela com todo o middleware atualizado….

Abraços,

José Laurindo Chiappa

[José Laurindo ChiappaModerator]

E só uma Observação : claro, não uso XE (seja o 18c seja qquer versão mais antiga dele) em ambientes profissionais nunca, nem para Prod nem para Homologação, MAS a esmagadora maioria dos meus Testes (tanto aqui no Fórum quanto no meu trabalho quando estou desenvolvendo uma Prova de Conceito simples de um conceito qquer, ou para debugar algum problema que um colega me traz, enfim) eu faço no XE 18c, então acho POUCO provável que seja um problema no XE per se, já que nunca vi um caso tipo onde uma simples conexão de uma só sessão criada numa tool Oracle (como sql*plus) já consuma PGA enormemente – repito, pra mim isso é algo advindo do middleware, externo ao banco….Mas já que vai atualizar, atualiza tudo e nem esquenta em debugar isso, ok ??

Abraços,

Chiappa

[Author]

Posts