Cara valeu mesmo, essas informações poderão me ajudar a descobrir qual query
esta fazendo essa cagada.
________________________________
De: José Laurindo <jlchia...@yahoo.com.br>
Para: oracle_br@yahoogrupos.com.br
Enviadas: Terça-feira, 23 de Fevereiro de 2010 22:30:59
Assunto: [oracle_br] Re: Como descobrir a query que trava o banco ?
Raul, isso funcionaria ** SE ** realmente fosse um lock, mas esse sintoma de
CPU constantemente batendo 100% ** não ** é típico de locks, uma sessão lockada
fica em WAITING, gastando muito pouco de CPU... Aleksandro,pelo jeito o que
deve estar acontecendo é algum SQL tão ruim, tão malfeito, que tenta movimentar
uma porrada de blocos Oracle duma vez, e (claro) cada I/O lógico implica em
gasto de CPU pra controlar cache, em rede pra enviar os n blocos lidos pro
cliente... Eu diria o seguinte :
a) o truque básico nessa situação pra vc poder consultar o banco é vc já deixar
aberta uma conexão como sysdba no banco (via sqlplus de preferência) ANTES do
problema, já que vc não consegue abrir uma na hora que o problema ocorre
b) se for conexão dedicada (um elemento crítico que não é citado) , logicamente
é criado uma task no SO pra cada conexão, necessariamente aquela que estiver
consumindo muita CPU ** vai ** aparecer nas tools de SO para monitorar consumo
de CPU, como top, glance, vmstat, etc : UMA VEZ que vc identificou que é a PID
número x no SO que está consumindo muita CPU, procure esse pid do SO na coluna
SPID da v$process
c) dentro do banco, pra vc tentar acompanhar o problema na hora que ele ocorre,
vc tem também N views que podem ter dar informação sobre sessões/SQLs
consumindo muitos recursos , uma pode ser a V$SQL : no banco 10gr2 e acima,
cfrme os SQLs longos vão progredindo Automaticamente o banco vai atualizando as
colunas de consumo de recursos, como FETCHES, EXECUTIONS, PARSE_CALLS,
DISK_READS, DIRECT_WRITES, BUFFER_GETS, CPU_TIME : assim, se vc fazer algumas
consultas sucessivas com um pequeno intervalo necessariamente vc vai ver que os
SQLs ruins vão consumir mais recursos... Identificado o SQL, pra vc relacionar
o SQL com uma sessão vc pode consultar a coluna SQL_ID e/ou as colunas de
identificação (como PROGRAM_ID, MODULE, etc) na V$SQL e na V$SESSION. Outra
nesse sentido é a V$SQLSTATS, ela é um subset (menor e mais rápido) da V$SQL
d) se vc não conseguir fazer online, enquanto o problema ocorre, para tentar
identificar o SQL ruim depois que ele executou, muitas vezes um SQL permanece
algum tempo na V$SQL após a execução, veja lá se pelas stats de consumo vc
localiza o(s) SQL(s) ruins, e vc pode também tentar as views de histórico, como
a DBA_HIST_ACTIVE_ SESS_HISTORY, DBA_HIST_SQLSTAT e relacionadas.
e) via de regra o bd 10g (e superiores) está configurado pra tirar 'snapshots'
- ie, 'fotos', 'cópias' das views internas - , pode ser que vc ache lá info
também : há relatórios prontos que consultam essas infos, veja na documentação
por ASH e por AWR.
[]s
Chiappa
--- Em oracle...@yahoogrup os.com.br, "Raul Francisco Costa F. de Andrade, DBA"
<raulf...@.. .> escreveu
>
> Para o Oracle a partir do 10g eu uso:
>
> SELECT /*+ rule */ l.inst_id,s. event, l.SID, s.serial# serial, p.spid,
> s.username,
> s.status, s.osuser, s.machine, s.program,
> to_char(s.logon_ time,'dd/ mm/yyyy hh24:mm:ss') LOGON_TIME, l.ctime
> LOCK_TIME
> FROM gv$lock l, gv$session s, gv$process p
> WHERE s.inst_id = l.inst_id
> and s.inst_id = p.inst_id
> AND s.SID = l.SID
> and s.PADDR = p.addr
> AND (l.id1, l.id2, l.TYPE) IN (SELECT id1, id2, TYPE
> FROM gv$lock
> WHERE request > 0)
> ORDER BY ctime DESC;
>
> Depois pelo ID eu acho o SQL com esta:
>
> select sql_text
> from GV$sqltext_with_ newlines where inst_id = &INSTANCE_NUMBER AND
> address = (select DECODE(RAWTOHEX( sql_address) , '00', prev_sql_addr,
> sql_address)
> from GV$session
> where username = '&USERNAME'
> and inst_id = &INSTANCE_NUMBER
> and sid = &SID)
> ORDER BY piece
>
> Att.
>
> Raul
>
> Em 23 de fevereiro de 2010 17:31, aleksandrosouza <
> aleksandrosouza@ ...> escreveu:
>
> >
> >
> > Boa tarde,
> >
> > Utilizo o oracle 11.1.0.6.0 windows e estou tentando descobrir qual
> > processo o usuário esta rodando que deixa o banco travado.
> > O Processador fica em 100% e quando isso acontece, não consigo nem conectar
> > com o banco.
> > Após uns 5 minutos ele libera. Isso acontece umas 4 vezes ao dia.
> > Alguem tem alguma idéia de pegar o histórico das querys que deixam o banco
> > lento ou que dão lock ?
> >
> >
> >
>
>
>
> --
> ------------ --------- --------- --------- --------- --------- -
> Raul Francisco da Costa Ferreira de Andrade
> DBA - OCA - Oracle Certified Associate
> Fone: (41)8855-8874 Brt
> email: raulf...@...
> "Deus não dá prova superior às forças daquele que a pede;
> só permite as que podem ser cumpridas.
> Se tal não sucede, não é que falte possibilidade, falta vontade."
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
[As partes desta mensagem que não continham texto foram removidas]
