Menu de navegação

[luizhumbParticipante]

O Oracle é 10G executei o SELECT SID, EVENT, SECONDS_IN_WAIT FROM V$SESSION_WAIT W ORDER BY SECONDS_IN_WAIT; em um momento que estava com lentidão é possível identificar alguma anomalia?

SQL> @c:1.sql

SID EVENT
———- —————————————————————-
SECONDS_IN_WAIT
—————
169 rdbms ipc message
0

167 rdbms ipc message
0

166 rdbms ipc message
0

SID EVENT
———- —————————————————————-
SECONDS_IN_WAIT
—————
158 SQL*Net message to client
0

159 jobq slave wait
0

162 rdbms ipc message
1

SID EVENT
———- —————————————————————-
SECONDS_IN_WAIT
—————
165 rdbms ipc message
4

151 Streams AQ: waiting for time management or cleanup tasks
72

147 SQL*Net message to client
73

SID EVENT
———- —————————————————————-
SECONDS_IN_WAIT
—————
146 SQL*Net message from client
85

161 rdbms ipc message
107

160 rdbms ipc message
307

SID EVENT
———- —————————————————————-
SECONDS_IN_WAIT
—————
164 smon timer
309

168 rdbms ipc message
610

163 rdbms ipc message
613

SID EVENT
———- —————————————————————-
SECONDS_IN_WAIT
—————
154 Streams AQ: qmn coordinator idle wait
641

149 Streams AQ: qmn slave idle wait
641

170 pmon timer
686

18 rows selected.

[José Laurindo ChiappaModerador]

Blz ? Sorry pelo atraso mas só agora é que pude responder…
Seguinte : após uma limpada & formatação (que teriam sido *** MUITO MAIS FACILITADAS *** se vc tivesse usado SET LINESIZE, SET PAGESIZE e os comandos COLUMN apropriados no seu script, Considere a possibilidade da outra vez!!), cheguei no seguinte :

SID EVENT SECONDS_IN_WAIT
— ————————————- —————
164 smon timer 309
168 rdbms ipc message 610
163 rdbms ipc message 613
154 Streams AQ: qmn coordinator idle wait 641
149 Streams AQ: qmn slave idle wait 641
170 pmon timer 686

18 rows selected.

Primeiro eu tenho que perguntar : certeza Absoluta que esse script foi rodado quando as coisas que vc quer mensurar performance tavam executando , E no banco correto ?? Pois apenas 18 sessões conectadas no total é *** minúsculo *** prum banco PROD : como o próprio banco Oracle cria coisa de quase uma dúzia isso implicaria que vc tem umas seis sessões só de usuário conectadas ? É pouco demais….
E isso é IMPORTANTE porque a V$SESSION_WAIT Só Registra os waits ATUAIS, das sessões conectadas NESTE MOMENTO e NESTA INSTÂNCIA : se os picaretas que estavam causando lentidão já desconectaram quando vc rodou este script, vc NÃO VERÁ COISA NENHUMA com ele…

Aí vem a sua resposta então : dando de barato que o banco era o banco correto, na instância correta E QUE não havia sessões problemáticas que já tinham se desconectado quando vc rodou o script sim, não vejo NADA de errado nesse database, até porque TODOS os eventos indicados são IDLE EVENTS, ie, eventos internos do database, que via de regra registram as situações em que o banco ficou esperando ser acionado….

Pode valer a pena vc fazer uns testes adicionais para comprovar que o database tá respondendo bem e rápido – por exemplo, abrir uma sessão nele e nessa sessão fazer umas dezenas de acessos via index value E uns full table-scans em várias tabelas médias bastante usadas no sistema – se a resposta foi de sub-segundo para os acessos via chave de índice E foi coisa de menos de dez segundos para cada mil linhas lidas em FTS, tá comprovado que esse banco em si tá saudável, tá respondendo bem…. Nesse caso toca a procurar por ineficiências na Aplicação e na Rede, pois o banco em si em princípio tá bem se esses testes forem OK e além disso os WAITs cfrme acima são idle…

[]s

Chiappa

[Autor]

Posts