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 [oracle_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 [oracle_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 ativasb) V$SESSION_WAIT W, V$SESSION S, V$PROCESS P,
V$SQLTEXT SQL
c) oratopd) 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?
#yiv3288987806 -- #yiv3288987806ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3288987806
#yiv3288987806ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3288987806
#yiv3288987806ygrp-mkp #yiv3288987806hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv3288987806 #yiv3288987806ygrp-mkp #yiv3288987806ads
{margin-bottom:10px;}#yiv3288987806 #yiv3288987806ygrp-mkp .yiv3288987806ad
{padding:0 0;}#yiv3288987806 #yiv3288987806ygrp-mkp .yiv3288987806ad p
{margin:0;}#yiv3288987806 #yiv3288987806ygrp-mkp .yiv3288987806ad a
{color:#0000ff;text-decoration:none;}#yiv3288987806 #yiv3288987806ygrp-sponsor
#yiv3288987806ygrp-lc {font-family:Arial;}#yiv3288987806
#yiv3288987806ygrp-sponsor #yiv3288987806ygrp-lc #yiv3288987806hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3288987806
#yiv3288987806ygrp-sponsor #yiv3288987806ygrp-lc .yiv3288987806ad
{margin-bottom:10px;padding:0 0;}#yiv3288987806 #yiv3288987806actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3288987806
#yiv3288987806activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3288987806
#yiv3288987806activity span {font-weight:700;}#yiv3288987806
#yiv3288987806activity span:first-child
{text-transform:uppercase;}#yiv3288987806 #yiv3288987806activity span a
{color:#5085b6;text-decoration:none;}#yiv3288987806 #yiv3288987806activity span
span {color:#ff7900;}#yiv3288987806 #yiv3288987806activity span
.yiv3288987806underline {text-decoration:underline;}#yiv3288987806
.yiv3288987806attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv3288987806 .yiv3288987806attach div a
{text-decoration:none;}#yiv3288987806 .yiv3288987806attach img
{border:none;padding-right:5px;}#yiv3288987806 .yiv3288987806attach label
{display:block;margin-bottom:5px;}#yiv3288987806 .yiv3288987806attach label a
{text-decoration:none;}#yiv3288987806 blockquote {margin:0 0 0
4px;}#yiv3288987806 .yiv3288987806bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv3288987806
.yiv3288987806bold a {text-decoration:none;}#yiv3288987806 dd.yiv3288987806last
p a {font-family:Verdana;font-weight:700;}#yiv3288987806 dd.yiv3288987806last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3288987806
dd.yiv3288987806last p span.yiv3288987806yshortcuts
{margin-right:0;}#yiv3288987806 div.yiv3288987806attach-table div div a
{text-decoration:none;}#yiv3288987806 div.yiv3288987806attach-table
{width:400px;}#yiv3288987806 div.yiv3288987806file-title a, #yiv3288987806
div.yiv3288987806file-title a:active, #yiv3288987806
div.yiv3288987806file-title a:hover, #yiv3288987806 div.yiv3288987806file-title
a:visited {text-decoration:none;}#yiv3288987806 div.yiv3288987806photo-title a,
#yiv3288987806 div.yiv3288987806photo-title a:active, #yiv3288987806
div.yiv3288987806photo-title a:hover, #yiv3288987806
div.yiv3288987806photo-title a:visited {text-decoration:none;}#yiv3288987806
div#yiv3288987806ygrp-mlmsg #yiv3288987806ygrp-msg p a
span.yiv3288987806yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv3288987806
.yiv3288987806green {color:#628c2a;}#yiv3288987806 .yiv3288987806MsoNormal
{margin:0 0 0 0;}#yiv3288987806 o {font-size:0;}#yiv3288987806
#yiv3288987806photos div {float:left;width:72px;}#yiv3288987806
#yiv3288987806photos div div {border:1px solid
#666666;min-height:62px;overflow:hidden;width:62px;}#yiv3288987806
#yiv3288987806photos div label
{color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv3288987806
#yiv3288987806reco-category {font-size:77%;}#yiv3288987806
#yiv3288987806reco-desc {font-size:77%;}#yiv3288987806 .yiv3288987806replbq
{margin:4px;}#yiv3288987806 #yiv3288987806ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv3288987806 #yiv3288987806ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv3288987806
#yiv3288987806ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv3288987806
#yiv3288987806ygrp-mlmsg select, #yiv3288987806 input, #yiv3288987806 textarea
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv3288987806
#yiv3288987806ygrp-mlmsg pre, #yiv3288987806 code {font:115%
monospace;}#yiv3288987806 #yiv3288987806ygrp-mlmsg *
{line-height:1.22em;}#yiv3288987806 #yiv3288987806ygrp-mlmsg #yiv3288987806logo
{padding-bottom:10px;}#yiv3288987806 #yiv3288987806ygrp-msg p a
{font-family:Verdana;}#yiv3288987806 #yiv3288987806ygrp-msg
p#yiv3288987806attach-count span {color:#1E66AE;font-weight:700;}#yiv3288987806
#yiv3288987806ygrp-reco #yiv3288987806reco-head
{color:#ff7900;font-weight:700;}#yiv3288987806 #yiv3288987806ygrp-reco
{margin-bottom:20px;padding:0px;}#yiv3288987806 #yiv3288987806ygrp-sponsor
#yiv3288987806ov li a {font-size:130%;text-decoration:none;}#yiv3288987806
#yiv3288987806ygrp-sponsor #yiv3288987806ov li
{font-size:77%;list-style-type:square;padding:6px 0;}#yiv3288987806
#yiv3288987806ygrp-sponsor #yiv3288987806ov ul {margin:0;padding:0 0 0
8px;}#yiv3288987806 #yiv3288987806ygrp-text
{font-family:Georgia;}#yiv3288987806 #yiv3288987806ygrp-text p {margin:0 0 1em
0;}#yiv3288987806 #yiv3288987806ygrp-text tt {font-size:120%;}#yiv3288987806
#yiv3288987806ygrp-vital ul li:last-child {border-right:none
!important;}#yiv3288987806
