Histório de SQL

[Andre Renato 0]

Amigos,

 

Tenho um pequeno problema em uma instância ORACLE que administro: em momentos esporádicos o número de conexões aumenta e o banco (que é um Standard Edition) trava, chegando o Sistema Operacional bater na casa de 120 de load average.

 

Eu tenho quase certeza que tem alguma query bombástica rolando pra estar ocorrendo isso, mas... como no momento da m**** trava tudo, não consigo pegar a sessão nem o SQL que está rolando.

 

Eu sei que existe alguma view das v$s que tem o histórico de querys em um determinado momento (timestamp) mas não me lembro qual delas é.

 

Alguem aí pode me ajudar?

Valeu!

[Motta 645]

Em geral só um DBA experiente pode analisar isto , mas na dúvida consulte a tabela DICT pois ela tem o dicionário das tabelas de metadados do Oracle.

[Andre Renato 0]

Montei esse select, não sei se ele é completo mas...

 

Select g.Parsing_Schema_Name,
      g.Sql_Fulltext,
      g.Last_Active_Time,
      g.Optimizer_Mode,
      g.Optimizer_Cost
 From Gv$sqlarea g
Where g.Parsing_Schema_Name = 'USER_NAME'
  And Trunc(g.Last_Active_Time) = Trunc(Sysdate)
Order By g.Last_Active_Time Desc

[Andre Renato 0]

Bom, aconteceu de novo e o banco capotou ontem as 22h20.

O alert aparece o seguinte warning:

 

WARNING: inbound connection timed out (ORA-3136)

 

E dentro do alert tem uma referência a um Trace que começa com essas linhas:

 

*** 2009-12-07 22:21:18.912

Waited for process J000 to initialize for 60 seconds

*** 2009-12-07 22:21:22.691

Dumping diagnostic information for J000:

OS pid = 30530

loadavg : 70.73 56.27 28.74

memory info: free memory = 0.00M

swap info: free = 0.00M alloc = 0.00M total = 0.00M

skgpgpstack: read() for cmd /bin/ps -elf | /bin/egrep 'PID | 30530' | /bin/grep -v grep timed out after 60 seconds

/bin/sh: /usr/bin/gdb: Arquivo ou diretório não encontrado

*** 2009-12-07 22:22:24.630

*** 2009-12-07 22:24:08.987

Waited for process J003 to initialize for 60 seconds

*** 2009-12-07 22:24:08.987

Dumping diagnostic information for J003:

OS pid = 30989

loadavg : 111.42 77.46 41.04

memory info: free memory = 0.00M

swap info: free = 0.00M alloc = 0.00M total = 0.00M

F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD

0 S oracle 30989 1 0 78 0 - 600670 semtim 22:23 ? 00:00:00 ora_j003_jacweb

/bin/sh: /usr/bin/gdb: Arquivo ou diretório não encontrado

*** 2009-12-07 22:24:26.342

*** 2009-12-07 22:24:36.351

Waited for process J003 to initialize for 70 seconds

 

 

Eu ainda gostaria de acreditar que tem algum select moendo a maquina.

Alguem pode me dar uma luz?

[Motta 645]

tenta este

 

SELECT SQL_TEXT , CPU_TIME

FROM V$SQL B

ORDER BY CPU_TIME DESC

[alphamek 2]

Andre,

 

Seguinte cara, seus problemas não são apenas uma instrução SQL, tem mais problemas aí nesse poço.

 

1) Se quiser saber mais sobre as querys mais pesadas que executaram na sua base 10g\11g, retire os relatórios de AWR e ASH. Se fez a instalação padrão, ele faz um snapshot a cada 30 minutos.

 

Outra coisa:

 

2) Seria interessante tu postar os registros do seu alert.log, esse trace apenas informar alguns problemas, porém não todos!

 

3) Sobre o trace.

 

Bom, esse algum momento que a sua base fica travada, **PODE** ser por um JOB que está sendo executado no banco de dados no horário da tarde que está lhe matando. Segundo as informações do seu trace, os processo de background J00 (Job queue) estão apresentando erros e também deu para perceber outros erros, tais como:

 

3.1) No seu Unix\Linux não tem área de SWAP?

3.2) O seu banco de dados JACWEB, teve os parâmetros de kernel configurados de acordo com a versão e SO?

3.3) Quais os jobs que estão no banco de dados, existe algum job que tem API para o SO (DataPump, Java Proc, C Proc, ProCobol e etc)?

 

 

E sobre o erro:

 

WARNING: inbound connection timed out (ORA-3136)

 

Isso é normal do banco de dados, se estiver com o parâmetro RESOURCE_LIMIT = TRUE e existe perfil de usuário no banco de dados, com os limites de IDLE_CONNECT ou CONNECT_TIME configurados, o Oracle desce as sessões inativas. Ou se o resource_limit estiver FALSE, veja as configurações de sqlnet.ora que lá terá algumas limitações para sessões inativas.

 

Abraços,

[Andre Renato 0]

Rodrigo, na verdade essa instância tem dois problemas dinstintos que é pouca memória para a SGA (4Gb) e o outro (não menos importante) é um cara chamado APACHE.

O PHP manda para o Oracle um turbilhão de conexões tão absurdo que não há memória que aguente... esse é o problema.

 

Essa base está para ser extinta e substituída para MySql com um servidor novo.

Portanto, digamos que o problema está "resolvido".

[alphamek 2]

ok. Entendo o problema.

 

Mas se o Oracle não está conseguindo segurar as conexões, o MySQL vai suportar?

 

E existe outras manobras que pode fazer, por exemplo, preciso confirmar, mas acho que o APACHE trabalha com "Thin Client", e seu banco de dados está configurado para trabalhar com sessões dedicadas, então, para cada sessão no banco de dados, é ocupado cerca de 1.3MB. Se existe 100 sessões, 130MB. Que será ocupada da sua shared_pool.

 

O ideal para as aplicações com muitas sessões, o interessante é configurar o banco de dados para trabalhar com MTS (Multi Thread-Server), ou seja, sessões compartilhadas, desde modo, define um tamanho para alocar as sessões, que internamente será a UGA (User Global Area) que fica dentro da PGA (Program Global area), e os dispatchers irá fazer todo o trabalho, assim, consegue fornece mais sessões usando o mesmo banco e hardware.

 

Abraços,

[Andre Renato 0]

Bom Rodrigo,

 

Essa decisão veio "de cima", portanto nada pude fazer... nem da implementação desse cenário eu estou particiando.

O que sei é que o servidor também é novo com uma configuração bem melhor.

 

Tenho certeza que com o Oracle iria funcionar tão bem (e melhor) com um hardware desse.

[alphamek 2]

É muito complicado mesmo de entender. Porém, se já existe Oracle na sua empresa, as licenças já existem e poderiam reaproveitar-las.

 

Mas, perder tempo para entender os "cabeças" não é muito recomendado. Pelo menos vai aprender MySQL. he he he!

 

Abraços,