Operacao debug. O Gargalo deve estar no servidor de aplicação que vem antes do oracle....
Vou sugerir, tentar rodar essas mesmas queries no servidor de aplicação (se isso for possivel ), se lá tiver um sqlplus. Ta muito evidente.. Você roda a mesma query na mão, a partir do seu desktop ou em outra maquina e resultado é instantâneo. A partir do servidor, alguma coisa trava e o resultado nao é instantaneo. Ora pois, se estão todos no mesmo ambiente, mesma rede, etc etc... Talvez essa ainda seja a hipotese que ninguém testou por ai? ou ja fizeram ? Depois que tudo foi desligado e religado, nao deve ter subido alguma coisa corretamente.. de repente um novo reset (no servidor de aplicação) vai resolver a parada. []s angelo 2016-09-14 11:24 GMT-03:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] <oracle_br@yahoogrupos.com.br>: > > > A aplicação é feita em Delphi e também muita coisa escrita em PL/SQL > > ***** Inclusive essa consulta está escrita dentro de uma trigger.***** > > - O problema é só com um determinado usuário da aplicação mesmo? > > R: Não, o problema é com qualquer usuário que tenta executar essa mesma > tarefa. > > - A lentidão da aplicação com esse usuário é geral ou apenas em > determinados processos ou consultas? > > R: A lentidão é geral em todo processo que ele realiza, consultando sempre > a v$session_wait entre outras V$ vi que a maior parte do tempo (80%) a > sessão fica ativa com a consulta que foi passada. > > - Ele já tentou executar de outra máquina? > > R: Já tentamos fazer isso, de qualquer máquina o tempo de término é o > mesmo. > > - Se outro usuário executar a mesma consulta (com exatamente os mesmos > parâmetros), qual é o tempo? > > R: Se eu executar essa consulta por fora com os mesmo parâmetros a > consulta me retorna em milissegundos. > > > > Obs: Rodrigo, irei estudar a respeito desses parametros para ajustar e > respondo aqui se houve alguma melhora significativa, também entrei em > contato com o usuário e com os desenvolvedores, e tudo indica que essa > TRIGGER não é de fundamental importancia para o sistema que o usuario está > utilizando (nem para outros), porém iremos estudar se é viável desabilitar > a trigger e verificar a melhora do processo. > > > > Em Quarta-feira, 14 de Setembro de 2016 10:48, "Andre Santos > andre.psantos...@gmail.com [oracle_br]" <oracle_br@yahoogrupos.com.br> > escreveu: > > > > Rafael > > Problema misterioso, heim! > Depois do desligamento imprevisto, acho que subiu algo desconfigurado... > O que me chamou a atenção: > > Event waited on Times Max. Wait Total > Waited > ---------------------------------------- Waited ---------- > ------------ > SQL*Net message *from* client 3566 19.03 > 65.30 > > O evento que mais demora é esperando as mensagens a partir "do cliente" > (no caso, seria o servidor de aplicação). > > Sem contar que tanto o SELECT quanto o INSERT (que parece ser simples) > gastaram praticamente o mesmo tempo de Execute (elapsed = 41.6...). > Pode ser coincidência, mas talvez seja o "padrão" de algum gargalo que > está ocorrendo na aplicação. > E o Fetch mesmo parece que não está demorado. > > A arquitetura da aplicação é de 3 camadas (com um servidor de aplicação > entre o client e o SGBD)? > Para continuar investigando: > - O problema é só com um determinado usuário da aplicação mesmo? > - A lentidão da aplicação com esse usuário é geral ou apenas em > determinados processos ou consultas? > - Ele já tentou executar de outra máquina? > - Se outro usuário executar a mesma consulta (com exatamente os mesmos > parâmetros), qual é o tempo? > > [ ]'s > > André > > > Em 13 de setembro de 2016 20:18, Rodrigo Mufalani rodr...@mufalani.com.br > [oracle_br] <oracle_br@yahoogrupos.com.br> escreveu: > > > Boa noite, > > O teu problema não está em disco (db file sequential read). > > > Event waited on Times Max. Wait Total Waited > ------------------------------ ---------- Waited ---------- ------------ > db file sequential read 1 0.00 0.00 > latch: row cache objects 4 0.00 0.00 > SQL*Net message to client 3566 0.00 0.02 > log file sync 41 0.00 0.08 > SQL*Net message from client 3566 19.03 65.30 > latch: shared pool 1 0.00 0.00 > direct path read 23 0.02 0.05 > direct path write 6 0.00 0.00 > SQL*Net more data from client 3 0.00 0.00 > SQL*Net more data to client 2 0.00 0.00 > > > Olhe para as colunas Times Waited que tem maiores valores. Se for uma apps > java aumente o fetchsize, (procure por setFetchSize(100)), ou mais, o > padrão são 10 linhas, também incremente o SDU size e TDU size no tnsnames e > listener.ora > > > Atenciosamente, > > <http://www.mufalani.com.br/> Rodrigo Mufalani - Diretor Técnico | > rodr...@mufalani.com.br< mailto:rodr...@mufalani.com.br > | +55 21 988 > 994 817 > Mufalani - +55 21 3193 0326 | Rua Alm Grenfall, 405, Bl 3, Sl 310, Centro > Empresarial > Washington Luiz, Duque de Caxias, RJ | CEP 25085-009 | www.mufalani.com.br > <mailto:rod r...@mufalani.com.br <rodr...@mufalani.com.br>> > <http://www.mufalani.com.br/>[ cid:image001.png@01D20DFB. > F9D31B80]<http://www.mufalani. > com.br/ <http://www.mufalani.com.br/>>[cid:image002.png@ > 01D20DFB.F9D31B80] > > > De: <oracle_br@yahoogrupos.com.br> em nome de "Rafael Mendonca > raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> > Responder para: "oracle_br@yahoogrupos.com.br" < > oracle_br@yahoogrupos.com.br> > Data: terça-feira, 13 de setembro de 2016 18:46 > Para: "oracle_br@yahoogrupos.com.br" <oracle_br@yahoogrupos.com.br> > Assunto: Re: [oracle_br] Lentidão ?? > > > Angelo/Andre > > Ele acessa o sistema que conecta no servidor de aplicação e > consequentemente no banco de dados, eu não tenho mais informações a > respeito disso, pois o responsável pela aplicação já foi embora. O usuário > está local. > > > Em relação ao trace, segue algumas informações relevantes: > > > > > SQL ID: 8mvsyr5t2sndh Plan Hash: 2923565733 > > SELECT MIN(EMD.DTHRMOV) > FROM > LOCALFISICO LF, MOVIMENTOFISICO MF, EXPMOVDISTRIBUICAO EMD WHERE MF.CODDOC > = > :B1 AND MF.DTHRMOV = (SELECT MAX(DTHRMOV) FROM MOVIMENTOFISICO WHERE > CODDOC > = :B1 AND DTHRMOV < :B2 ) AND MF.CODLOCAL = LF.CODLOCAL AND EMD.CODDOC= > MF.CODDOC AND EMD.DTHRMOV=MF.DTHRMOV > > > call count cpu elapsed disk query current rows > ------- ------ -------- ---------- ---------- ---------- ---------- > ---------- > Parse 0 0.00 0.00 0 0 0 0 > Execute 1 19.96 41.60 0 7963807 0 0 > Fetch 1 0.00 0.00 0 7 0 1 > ------- ------ -------- ---------- ---------- ---------- ---------- > ---------- > total 2 19.96 41.60 0 7963814 0 1 > > Misses in library cache during parse: 0 > Optimizer mode: ALL_ROWS > Parsing user id: 1253 (recursive depth: 2) > > > > SQL ID: 3kkvtpq5bfaq8 Plan Hash: 0 > > INSERT INTO MOVREMINT (CODDOC, DTHRMOV, CODFASE, CODCOMPL1, CODCOMPL2, > CODLOCALRESP,INDPROCCLASSE2) > VALUES > (:B7 , :B6 , :B5 , :B4 , :B3 , :B2 , :B1 ) > > > call count cpu elapsed disk query current rows > ------- ------ -------- ---------- ---------- ---------- ---------- > ---------- > Parse 3 0.00 0.00 0 0 0 0 > Execute 4 19.97 41.62 0 7963822 101 4 > Fetch 0 0.00 0.00 0 0 0 0 > ------- ------ -------- ---------- ---------- ---------- ---------- > ---------- > total 7 19.97 41.62 0 7963822 101 4 > > Misses in library cache during parse: 1 > Misses in library cache during execute: 1 > Optimizer mode: ALL_ROWS > Parsing user id: 1253 (recursive depth: 1) > > > OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS > > call count cpu elapsed disk query current rows > ------- ------ -------- ---------- ---------- ---------- ---------- > ---------- > Parse 2121 0.17 0.47 0 1 0 0 > Execute 2122 1.23 3.49 0 800 547 1394 > Fetch 2079 2.15 6.38 1 4472 0 18720 > ------- ------ -------- ---------- ---------- ---------- ---------- > ---------- > total 6322 3.55 10.35 1 5273 547 20114 > > Misses in library cache during parse: 123 > Misses in library cache during execute: 83 > > Elapsed times include waiting on following events: > Event waited on Times Max. Wait Total Waited > ------------------------------ ---------- Waited ---------- ------------ > db file sequential read 1 0.00 0.00 > latch: row cache objects 4 0.00 0.00 > SQL*Net message to client 3566 0.00 0.02 > log file sync 41 0.00 0.08 > SQL*Net message from client 3566 19.03 65.30 > latch: shared pool 1 0.00 0.00 > direct path read 23 0.02 0.05 > direct path write 6 0.00 0.00 > SQL*Net more data from client 3 0.00 0.00 > SQL*Net more data to client 2 0.00 0.00 > > > > OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS > > call count cpu elapsed disk query current rows > ------- ------ -------- ---------- ---------- ---------- ---------- > ---------- > Parse 2286 0.16 0.47 1 6 34 0 > Execute 42179 43.19 92.84 88 15931421 5832 456 > Fetch 52438 1.18 3.68 214 152556 6 49992 > ------- ------ -------- ---------- ---------- ---------- ---------- > ---------- > total 96903 44.54 97.00 303 16083983 5872 50448 > > Misses in library cache during parse: 275 > Misses in library cache during execute: 248 > > Elapsed times include waiting on following events: > Event waited on Times Max. Wait Total Waited > ------------------------------ ---------- Waited ---------- ------------ > db file sequential read 280 0.03 0.91 > latch: row cache objects 8 0.00 0.00 > latch: shared pool 4 0.00 0.00 > direct path read 18 0.01 0.08 > direct path write 18 0.00 0.02 > > 1410 user SQL statements in session. > 253 internal SQL statements in session. > 1663 SQL statements in session. > > > > Em Terça-feira, 13 de Setembro de 2016 17:06, "Andre Santos > andre.psantos...@gmail.com [oracle_br]" <oracle_br@yahoogrupos.com.br> > escreveu: > > > Rafael > > No trace 10046, está incluindo informação de "waits" (level 8 ou maior)? > Aparece em que está gastando tempo, para totalizar esses 40~45 segundos? > > [ ] > > André > > > Em 13 de setembro de 2016 15:42, angelo angelolis...@gmail.com<mailto: > angelolis...@gmail.com> [oracle_br] <oracle_br@yahoogrupos.com.br< > mailto:oracle_br@yahoogrupos. > com.br <oracle_br@yahoogrupos.com.br>>> escreveu: > > Rafael, > > E a aplicação do usuário ? Como a aplicação alcança o banco de dados ? > Seria a partir da maquina dele x banco ou algum servidor de aplicacao ou > webservice no meio do caminho ? > > Esse usuario, está local, esta remoto... ? > > > > > > 2016-09-13 15:32 GMT-03:00 Rafael Mendonca raffaell.t...@yahoo.com< > mailto:raffaell.t...@yahoo.com > [oracle_br] <oracle_br@yahoogrupos.com.br< > mailto:oracle_br@yahoogrupos. com.br <oracle_br@yahoogrupos.com.br>>> : > > => Oracle EE 11.2.0.4.16 AIX 6.1 64 bits ASM single instance. > Options -> tuning pack, diagnostic pack > > > Senhores, boa tarde. > > Um usuário em especial está reclamando de problema de lentidão na tarefa > que ele está executando. A tarefa era executada em 15 segundos no pior dos > casos (até o dia 09/09/2016) e agora a mesma tarefa está levando 40 a 45 > segundos. Nesse intervalo de tempo nada foi modificado, nem aplicação, nem > database, o que houve foi uma queda de energia no final de semana > desligando todos os servidores (Pessoal do storage e AIX já verificou se > existiu algum problema após o desligamento e nada foi encontrado). > > Verificação: > > Verificando CPU, Memória, I/O Swap do servidor está tudo normal, o RDBMS > está respondendo rápido, não estamos com problema de desempenho, é uma > reclamação única de um determinado usuário. > > a) Verifiquei sessões ativas > b) V$SESSION_WAIT W, V$SESSION S, V$PROCESS P, V$SQLTEXT SQL > c) oratop > d) trace 10046 > > O que consegui encontrar é que existe uma consulta que é onde o usuário > passa a maior parte do tempo com a sua sessão ATIVA. Uma consulta simples, > segue abaixo: > > > SELECT MIN(EMD.DTHRMOV) > FROM YYYY LF, > XXX MF, > TTTT EMD > WHERE MF.CODDOC = :B1 > AND MF.DTHRMOV = (SELECT MAX(DTHRMOV) > FROM XXX > WHERE CODDOC = :B1 > AND DTHRMOV < :B2 > ) > AND MF.CODLOCAL = LF.CODLOCAL > AND EMD.CODDOC=MF.CODDOC > AND EMD.DTHRMOV=MF.DTHRMOV > > > Plan hash value: 2923565733 > ------------------------------ ----------------- > Id | Operation NAME ROWS Cost Stale > ------------------------------ ---------------------- > | 0 | SELECT STATEMENT 1 2 > | 1 | SORT AGGREGATE 1 2 > | 2 | NESTED LOOPS 1 2 > | 3 | NESTED LOOPS 1 2 NO > | 4 | TABLE ACCESS BY INDEX ROWID XXX 1 2 > | 5 | INDEX RANGE SCAN XXX 1 2 NO > | 6 | SORT AGGREGATE 1 2 NO > | 7 | TABLE ACCESS BY INDEX ROWID XXX 1 2 NO > | 8 | INDEX RANGE SCAN XXX 1 2 NO > | 9 | INDEX RANGE SCAN XXX 1 2 NO > | 10 | TABLE ACCESS BY INDEX ROWID XXX 1 2 NO > ------------------------------ ---------------------- > > Acontece que quando eu executo essa consulta no sqlplus ou em outro > front-end a consulta é executada em menos de um segundo, extremamente > rápida. > > obs: Na wait_event quando a consulta é executada é mostrado o > db_file_sequencial read, só adiantando que o cache_size é mais que > suficiente. > > > Alguém poderia ajudar a resolver essa bronca? > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > >
