Relatorio ADDM

[Armando Veloso 0]

Pessoal, recentemente 'postei' um topico aqui sobre problema de performance em um banco 10G...Executando o relatorio ADDM, há 2 recomendacoes fortes:FINDING 1: 61% impact (484 seconds)-----------------------------------Database sessions were found waiting for Oracle Resource Manager's active session slots. RECOMMENDATION 1: DB Configuration, 61% benefit (484 seconds) ACTION: Sessions were found waiting for active session slots. Consider increasing the active session limit for these Oracle Resource Manager consumer groups. SYMPTOMS THAT LED TO THE FINDING: SYMPTOM: Wait class "Scheduler" was consuming significant database time. (61% impact [484 seconds])FINDING 2: 57% impact (451 seconds)-----------------------------------SQL statements consuming significant database time were found. RECOMMENDATION 1: SQL Tuning, 47% benefit (372 seconds) ACTION: Investigate the SQL statement with SQL_ID "8s3z8qvt3c12r" for possible performance improvements. RELEVANT OBJECT: SQL statement with SQL_ID 8s3z8qvt3c12r and PLAN_HASH 1388734953 SELECT 'A' FROM DUAL RATIONALE: SQL statement with SQL_ID "8s3z8qvt3c12r" was executed 5178 times and had an average elapsed time of 0.071 seconds. RATIONALE: Waiting for event "resmgr:become active" in wait class "Scheduler" accounted for 92% of the database time spent in processing the SQL statement with SQL_ID "8s3z8qvt3c12r".Alguma dica?

[alphamek 2]

Armando,Primeiramente, veja como está configurado o Resource Manager da base, veja se algum PLANO tem limite de utilização de CPU.Segundo, pela a escrita desse SQL com id '8s3z8qvt3c12r' e faça um plano de execução nele, para saber onde está impactando no banco de dados.Abraços,

[Armando Veloso 0]

Rodrigo,vou verificar o primeiro caso ainda (resource manager),mas quanto ao segundo, posso estar pensando besteira, mas entendi que fosse a instrucao "SELECT 'A' FROM DUAL" executada em milesimos de segundo (0.071 seconds.) só que executada seguidamente no banco (5178 vezes!), daí um grande consumo..."SELECT 'A' FROM DUALRATIONALE: SQL statement with SQL_ID "8s3z8qvt3c12r" was executed 5178times and had an average elapsed time of 0.071 seconds."

[alphamek 2]

Armando,Pode ser sim o SELECT 'A' FROM DUAL, porém, só confirma se o ID que ele está reclamando é dele mesmo, com certeza vai estar no v$librarycache ainda!!!Agora, caso seja o responsável pelo incidente, ele está reclamando novamente de alguma limitação ao PLANO que está configurado no Resource Manager, pois ele está reclamando de wait na classe "schedule", seria bom, pegar os maiores eventos de wait e latches que está tendo no banco de dados para acabar com as dúvidas.

RATIONALE: Waiting for event "resmgr:become active" in wait class "Scheduler" accounted for 92% of the database time spent in processing the SQL statement with SQL_ID "8s3z8qvt3c12r".

Só confirma se esse SQL_ID é mesmo do SELECTR 'A' FROM DUAL, pois se for, teremos que atacar por outros pontos, já que a tabela DUAL (do owner SYS) é uma tabela que fica em KEEP CACHE, automaticamente, se está tendo muito acesso, alguns latchs dentro do SGA deverá ser criada, acho que com o ADDM não poderá lhe fornecer mais detalhes, seria bom pegar as informações do AWR, pois aí analisariamos como está o SGA e PGA e pegaria os TOP10 instruções que estão afetando o banco de dados, e veriamos se esse SELECT está entre eles.Abraços,

[Armando Veloso 0]

Rodrigo,duas coisas:1) Ainda não estive na empresa hoje pra verificar o Resource Manager. Talvez hoje ainda de pra eu ver isso, mas se você puder me ajudar me dando uma dica de como verificar esses planos eu te agradeco, POIS estou achando muito estranho pq vejo com o "top"/"sar"/"iostat" que a CPU fica com alto percentual de IDLE e mesmo assim tem gargalo com CPU !!!Ontem usei o STATSPACK por umas 6 horas durante expediente e abaixo segue o "Top 5 Timed Events" :Top 5 Timed Events Avg %Total~~~~~~~~~~~~~~~~~~ wait CallEvent Waits Time (s) (ms) Time----------------------------------------- ------------ ----------- ------ ------CPU time 706 72.7SQL*Net more data to client 1,619,624 148 0 15.3db file scattered read 30,141 50 2 5.2db file sequential read 16,003 40 3 4.1os thread startup 577 13 22 1.3 -------------------------------------------------------------Host CPU (CPUs: 8)~~~~~~~~ Load Average Begin End User System Idle WIO WCPU ------- ------- ------- ------- ------- ------- -------- 0.13 0.07 1.28 0.23 98.50OBS: me ajude aqui a interpretar, na linha "CPU Time" ta com a coluna "Waits" em branco (diferente de "0"?)! Em contrapartida ta com 706 (Times) e 72% (Total call time)2) Nesse mesmo relatorio do STATSPACK, a instrucao "SELECT 'A' FROM DUAL" aparece 2 vezes nas SQL (pela qtde de execucoes e de parses), veja:-> SQL ordered by ExecutionsEla é a 3ª SQL que foi mais executada: CPU per Elap per Old Executions Rows Processed Rows per Exec Exec (s) Exec (s) Hash Value------------ --------------- ---------------- ----------- ---------- ---------- 21,055 21,055 1.0 0.00 0.00 734857649SELECT 'A' FROM DUAL-> SQL ordered by Parse CallsEla é a 1ª que mais gerou parse: % Total Old Parse Calls Executions Parses Hash Value------------ ------------ -------- ---------- 21,055 21,055 5.46 734857649SELECT 'A' FROM DUALUfa!Não sei bem o desempenho de usar o Oracle numa maquina com dois processadores Quad-core, mas em comparacao com uma maquina com um Pentium 4, o oracle na maq. quad-core demora mais a resposta, tendo sido gerado o mesmo plano de execucao nas duas maquinas! Acesso a disco não é, pois nao vejo waits significativos para isso. A SGA no quad-core utilizo o dobro! E ainda perde...

[alphamek 2]

Armando,

 

Vamos dar uma analisada geral sobre o problema:

 

Caso o servidor seja novo (Quad-core), veja na instância o valor do parâmetro CPU_COUNT, esse será o valor que a instância Oracle está enxergando para os processadores.

 

Caso seja Linux ou Unix, abaixe todos os patchs de correções do SO, pq eu também ano passado tive problemas de performace com máquinas DELL, Linux RedHat AS4, Oracle 10GR2 e tinha sérios problemas de performance, analise banco de dados e nada, e quando fui ver, existia patchs de correções para o gerenciamento de memória, principalmente quando seu banco de dados trabalha com SGA acima de 2GB, o tal de Hugepages para VLM.

 

Agora, vamos analisar alguns pontos do seu Statspack, primeiramente os eventos:

 

CPU time

SQL*Net more data to client

db file scattered read

db file sequential read

os thread startup

 

Não dê muita importancia para o primeiro evento, CPU Time, pois o banco está abusando a utilização do CPU, (o top/sar/vmstat) pode apontar uma certa porcentagem alta de %idle Time, porém é a nível de SO e não banco de dados.

 

O valor de CPU Time está alto, pois está sendo bem utilizado, principalmente nas leituras de índices da sua base de dados, porque podemos verificar que temos 2 eventos seguidos para ele, que são:

 

db file scattered read

db file sequential read

 

Você pode estar tendo disputa por "Hot Blocks" quando executa processos diferentes que utilizam as mesmas tabelas e consequentemente os índices.

 

Depois temos um eventos de OS thread e SQL*NET, para OS thread, novamente digo que seu SO está desatualizado ou mal configurado, eu "ACHO" que o SO não está conseguindo enxergar os 4 núcleos do processador e fora isso, que a configuração para trabalhar com alto valor de SGA ( <2GB) também não está configurado.

 

O SQL*NET é evento que interfere na rede, ou seja, os problemas vindos dele podem ser vários, como:

 

- Mal configuração da placa de rede (Half-duplex, duplex e etc)

- Broadcast na sua rede.

- Galrgalos nos switchs.

- No momento do processo ou durante o dia que foi retirado o statspack, estava tendo um alto consumo de rede ou trafegando grandes arquivos.

- Firewall também é um cara que pode segurar o consumo.

 

Um modo que existe que "tentar" amenizar esses problemas, é primeiramente, verificar o estado geral da rede como citado acima (pois não será necessário mexer no banco de dados), caso contrário, somente mexendo os valores de SDU e MDU no tnsnames e alterando o valor de transferência para conseguir DIMINUIR o valor de wait para SQL*NET.

 

Outro ponto, como a instrução SELECT 'A' FROM DUAL está sendo umas das instruções que mais está matando o seu banco de dados, no início do report do STATSPACK, deve ter uma porcentagem de Soft e Hard parse no banco de dados, e o HARD PARSE deve estar bem alto. Para resolver isso com utilizando BIND VARIABLES, porém, nesse caso será mais complicado.

 

Mas vai uma sugestão: PEGUE OS PROCESSOS que estão utilizando esse SELECT e veja qual é o motivo dele executar tantas vezes somente para colocar o valor A, com certeza ele deve estar dentro de um LOOP ou sua procedure é chamada muitas vezes ao dia!!!

 

Bom, isso são apenas sugestões e um ponto de vista minha... e acho que pode lhe ajudar.

 

Abraços, http://forum.imasters.com.br/public/style_emoticons/default/thumbsup.gif

[Armando Veloso 0]

Rodrigo,essa observacao do CPU_COUNT eu ja havia verificado antes, e ta o valor 8, correto portanto.Nao uso nenhuma tabela com "alter table NOME_TABELA degrre 8", é bom usar? Para usar isso, é bom tambem usar o parametro "parallel_automatic_tuning" como TRUE?Interessante essa sua observacao do problema q você teve com uma maquina DELL e o Linux RedHat AS4, é o mesmo ambiente meu!!!Estou cadastrado no RH Network e o linux tem um software de update que ja verifica automaticamente os updates de packages disponiveis no site, e assim todas as packages estao em dia! Estaria questoes de PATCH fora dessa verificacao automatica? você pode me ajudar nessa questao, me dizendo como posso verificar esses patchs?Essa maquina DELL ta me dando trabalho demais, com 1 mes de uso ja foi trocada a placa-mae dela pois estava acontecendo desconexoes dos usuarios ao BD ao longo do expediente...Quanto aos "db file scattered read" (full table scan) e "db file sequential read" (index scan) acho que estao ate com "waits" baixos, visto que, respectivamente, estao com 30mil e 16 mil, enquanto que o evento "SQL*Net more data to client" esta com 1milhao e 600 mil !!!Essa proporcao é a que eu entendi.... nao sei se é valido comparar assim... e tb o evento "CPU TIME" ta com a quantidade de waits em brano, e nao "0" !Quanto ao evento "SQL*NET" esta altissimo... e vou verificar questoes de rede o mais rapido possivel...Quanto a SQL "SELECT 'A' FROM DUAL" e respondendo a sua pergunta, no inicio do relatorio do STATSPACK, no item "Instance Efficiency Percentages" , dentre outros valores de parse, ha esses dois itens relevantes:Soft Parse %: 97.91Execute to Parse %: 62.82 Sao esses que você queria saber?Quanto as BIND VARIABLES o sistema usado na empresa é uma solucao comprada,portanto, de codigo fechado, mas tenho visto que sao utilizadas...A questao da inumeras execucoes do "select 'A' from dual" esta muito esquisito e dificil de encontrar a solucao... Durante expediente, medi pela v$sql e vi que esse select em media esta sendo executado 2 vezes por segundo!!!! Mas nao consigo encontrar o processo do SO que executa tal select! (vou verificar mais, mas acho q é execucao dentro do proprio banco, tipo um job)MAS...verificando na DBA_JOBS só há um job la, que é do SYSMAN, muito esquisito, mas ta com intervalo "sysdate + 1 / (24 * 60)" e executando o seguinte:"EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS();"O MAIS ESQUISITO é que estou acessando a empresa agora a noite de casa e estou verificando que NAO ESTA SENDO EXECUTADO O "SELECT 'A' FROM DUAL" !!!Ta dificil...Obrigado pela atencao!!!