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]