- Este tópico contém 3 respostas, 2 vozes e foi atualizado pela última vez 16 anos, 7 meses atrás por
David Siqueira.
-
AutorPosts
-
4 de agosto de 2009 às 4:13 pm #88520
ramasine
ParticipanteCaros,
Oracle 9.2.0.8
Tenho uma procedure em execução rodando desde ontem em uma sessão do sqlplus. Ela traz dados referentes ao ano de 2007 de um outro banco de dados, através de dblink, e insere em uma determinada tabela,
Tenho como monitorar se realmente ainda está inserindo os dados??
O display do select count na tebela destino já é o mesmo há pelo menos 2 horas, não há locks no banco…
O numero de linhas a inserir é de aproximadamente 1.478.700 e até agora fez 45.252..
Estes são os eventos do banco, não vi nada que chamasse muita a atenção:
12:44:28 sql’@’bposing > @event
INST_ID EVENT TOTAL
———- —————————————————————- ———-
1 SQL*Net message from client 265
1 rdbms ipc message 16
1 pipe get 1
1 pmon timer 1
1 virtual circuit status 1
1 SQL*Net message to client 1
1 wakeup time manager 1
1 smon timer 1As informações da sessão:
12:43:36 sql’@’bposing > @sid
Enter value for sid1: 221SSE SQL_ADDRESS LAST_CALL_ET SECONDS_IN_WAIT OSUSER USERNAME STATUS MACHINE HORA
———— —————- ———— ————— ———- —————– ——– ————————- —————–
‘221,11650’ 07000001B369DBA8 63197 0 iramas MZD ACTIVE INGAWDSIUSBD75 03/08/09 19:10:19Fui ao banco de dados em que a procedure se liga através do dblink e tb não há locks e nem eventos de wait, que possam justificar uma “possível” lentidão no processo!
A Procedure:
DECLARE
v_par_num VARCHAR2 (13);
v_are_iti NUMBER (9, 2);
v_are_rn NUMBER (9, 2);
v_are_rn_iti NUMBER (9, 2);
v_conta NUMBER;
o_err NUMBER;
o_men VARCHAR2 (400);
v_fim EXCEPTION;CURSOR c_ped
IS
SELECT pro_num_ord, ter_ninga
FROM pun_ped_uni_08
WHERE aju_codigo = ‘PUN’
AND cam_ano_ini_cam = ‘2009’
AND NVL (pun_ics, ‘N’) = ‘S’;v_ped c_ped%ROWTYPE;
CURSOR c_par (p_pro NUMBER)
IS
SELECT upr_num_par, NVL (upr_baldio, ‘N’) baldio
FROM pun_uni_pro_08
WHERE pro_num_ord = p_pro
AND cam_ano_ini_cam = ‘2009’
AND aju_codigo = ‘PUN’;v_par c_par%ROWTYPE;
CURSOR c_exi (p_par VARCHAR2)
IS
SELECT ‘X’
FROM sup_par_rn_07
WHERE cam_ano_ini_cam = ‘2009’ AND pao_num_par = p_par;v_exi c_exi%ROWTYPE;
BEGIN
o_err := 0;
o_men := ‘Acabou Bem’;
v_conta := 0;OPEN c_ped;
FETCH c_ped
INTO v_ped;WHILE c_ped%FOUND
LOOP
v_conta := v_conta + 1;OPEN c_par (v_ped.pro_num_ord);
FETCH c_par
INTO v_par;WHILE c_par%FOUND
LOOP
IF v_par.upr_num_par IS NOT NULL
THEN
OPEN c_exi (v_par.upr_num_par);FETCH c_exi
INTO v_exi;IF c_exi%NOTFOUND
THEN
v_are_iti := 0;
v_are_rn := 0;
v_are_rn_iti := 0;IF SUBSTR (v_par.upr_num_par, 11, 3) = ‘999’
OR v_par.baldio = ‘B’
THEN
con_adm.bal_rn_iti_09 (v_par.upr_num_par,
v_are_iti,
v_are_rn,
v_are_rn_iti,
o_err,
o_men
);IF o_err <> 0
THEN
RAISE v_fim;
END IF;
ELSE
con_adm.par_rn_iti_09 (v_par.upr_num_par,
v_are_iti,
v_are_rn,
v_are_rn_iti,
o_err,
o_men
);IF o_err <> 0
THEN
RAISE v_fim;
END IF;
END IF;INSERT INTO sup_par_rn_07
(cam_ano_ini_cam, pao_num_par, prn_are_rn,
prn_are_rn_iti, prn_are_iti
)
VALUES (‘2009’, v_par.upr_num_par, v_are_rn,
v_are_rn_iti, v_are_rn
);
END IF;CLOSE c_exi;
END IF;FETCH c_par
INTO v_par;
END LOOP;CLOSE c_par;
IF v_conta = 2000
THEN
DBMS_OUTPUT.put_line (‘cONTAGEM ‘ || v_conta);
COMMIT;
v_conta := 0;
END IF;FETCH c_ped
INTO v_ped;
END LOOP;CLOSE c_ped;
DBMS_OUTPUT.put_line (‘acabou’);
EXCEPTION
WHEN v_fim
THEN
DBMS_OUTPUT.put_line (‘Erro: ‘ || o_err || ‘ ‘ || o_men);
DBMS_OUTPUT.put_line ( v_conta
|| ‘ processo: ‘
|| v_ped.pro_num_ord
|| ‘ parcela ‘
|| v_par.upr_num_par
);
WHEN OTHERS
THEN
o_err := SQLCODE;
o_men := SQLERRM;
DBMS_OUTPUT.put_line (‘Erro: ‘ || o_err || ‘ ‘ || o_men);
DBMS_OUTPUT.put_line ( v_conta
|| ‘ processo: ‘
|| v_ped.pro_num_ord
|| ‘ parcela ‘
|| v_par.upr_num_par
);
END;Abraços!!
Marcelo
4 de agosto de 2009 às 4:31 pm #88521David Siqueira
ParticipanteMarcelo como vai?
Dúvidas?
– Ambas as Bases são 9.2.0.8?
– Há gargalos de rede na sua camada network?
– A tabela de Oriegem dos dados, possui indices que satisfaçam a condição do seu processo?
– A tabela Origem é particionada?
– Há Commit points no seu processo?Abraço!
4 de agosto de 2009 às 5:42 pm #88522ramasine
ParticipanteDavid,
Não, uma é 9.2.0.8 (origem) e a outra é 10.1.0.5!
Quanto a gargalos de rede, provavelmente, tenho maneiras de checar isso?
A tabela de origem não é particionada e aparentemente tem os índices necessários!Como essa procedure foi o pessoal de DEV que mandou executar, vou questionar a eles sobre os commit points..
De qq forma estou gerando um trace dos dois lados para ver se há mais algum problema…
Abs
Marcelo
4 de agosto de 2009 às 6:04 pm #88523David Siqueira
ParticipanteBoa Marcelão.
Com os Traces poderemos ver os pontos e as querys que mais estão impactando, possa ser que no final das contar uma reescrita de alguns passos do processo como um todo já recolvam em muito o problema.
Quanto ao gargalo, você pode identificar via PING e verificar se ha perdas de pacotes, pode verificar também via TNSPING esses vão registrar tempos altos caso estejam ocorrendo perdas de pacotes, pode também utilizar os logs de listener e de SQLNET que podem mostrar problemas de conectividade em determinados horários, e ha também a ajuda do seu ADM de redes para checkar junto ao S.O e aos gerenciadores de cada um deles se há problemas com a interface de redes.
Abração!!!
-
AutorPosts
- Você deve fazer login para responder a este tópico.