Res: [oracle_br] Performance em Insert into Select
Boa tarde!!! Vou dar alguns palpites: A ação de excluir os indices antes do insert é valida, mas acho que o seu problema esta no plano de execucao que deve ter sido alterado ou nas coletas de estatisticas. - Mensagem original De: Zumba [EMAIL PROTECTED] Para: oracle_br@yahoogrupos.com.br Enviadas: Quarta-feira, 16 de Janeiro de 2008 15:17:37 Assunto: Re: [oracle_br] Performance em Insert into Select Enterprise 9i/suse linux --- Danilo de Novais Silveira [EMAIL PROTECTED] com escreveu: Cara, qual versão do Oracle? 10g, 9i? É Standard ou Enterprise? Em 16/01/08, Zumba zumba_oracle@ yahoo.com. br escreveu: Eu pensei nisso, mas este processo já estava rodando e agora perdeu performance. Mas também não sei dizer o que aconteceu (dba atual não sabe/nao tem controle), que mudanças tiveram pra tal comportamento. Parametros de banco não foi mexido. Também não há concorrencia pois somente este processo interage na tabela. Qquer sugestão é bem vinda. Muito obrigado. --- Danilo de Novais Silveira [EMAIL PROTECTED] com coragi%40gmail. com escreveu: Já tentou dropar os índices, inserir os dados e recriar os índices novamente? Em 16/01/08, Zumba zumba_oracle@ yahoo.com. brzumba_oracle% 40yahoo.com. br escreveu: Olá pessoal, estou com uma situação um pouco estranha. Um select um pouco grande, mas está bem indexando e retornando rápido. O resultado do select é inserido numa tabela na forma de INSERT INTO TB_XX SELECT. Este processamento está em package e ao executar este trecho, a performance degrada demais levando 2min p/ cada registro. Mais estranho é se pegar o mesmo trecho e executar manualmente no sqlplus, roda sem problemas. A tabela a ser inserida não dispara trigger, mas tem 4 indices sendo que 3 deles tem 4 colunas cada. Existe alguma forma de implementar ou configurar p/ resolver este problema. Já utilizamos FORALL e nada. Bom, se tiverem alguma sugestão e puderem contribuir, agradeço muito. Abraço Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail. yahoo.com/ [As partes desta mensagem que não continham texto foram removidas] Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail. yahoo.com/ [As partes desta mensagem que não continham texto foram removidas] Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail. yahoo.com/ Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas]
Re: RES: [oracle_br] Performance em Insert
Obrigado pelas respostas pessoal.
É o seguinte, realmente eu entendo que, com o indice, o oracle gera
redo, etc, etc, essa foi a explicação que eu tinha em mente. Mas é
que não pareceu ser problema da inserção de dados em si, porque como
eu disse, foram inseridos poucas linhas, umas 67, e os updates pelo
trace enviado pelo cliente foram bem rápidos. Para exemplificar, eu
fiz um teste no XE, se alguem quiser pode testar também.
Primeiro criei uma tabele com uma pk:
create table teste(id number, valor number)
alter table teste add constraint pk_teste primary key (id)
Depois criei um script para inserir dados nessa tabela:
---
declare
i integer;
PROCEDURE grava(p_id in number, p_valor in number) is
BEGIN
INSERT INTO teste( id, valor) VALUES ( 1, p_valor);
EXCEPTION WHEN DUP_VAL_ON_INDEX THEN
UPDATE teste
SET valor = valor + p_valor
WHERE id = p_id;
END;
begin
dbms_output.put_line('INICIO: ' || TO_CHAR(SYSDATE, 'DD/MM/
HH24:MI:SS'));
for i in 1 .. 2000 loop
grava(1, 1);
end loop;
dbms_output.put_line('FIM: ' || TO_CHAR(SYSDATE, 'DD/MM/
HH24:MI:SS'));
end;
Executando esse script, demorou uns 40 segundos aqui na minha
máquina. Ai fiz o seguinte teste:
alter table teste disable constraint pk_teste
CREATE INDEX idx_teste ON teste ( id )
E mudei o script para o seguinte:
-
declare
i integer;
PROCEDURE grava(p_id in number, p_valor in number) is
v_achou varchar2(10);
BEGIN
BEGIN
SELECT 'TRUE' INTO v_achou FROM teste WHERE id = p_id;
EXCEPTION WHEN NO_DATA_FOUND THEN
v_achou := 'FALSE';
END;
if v_achou = 'FALSE' then
INSERT INTO teste( id, valor) VALUES ( 1, p_valor);
else
UPDATE teste
SET valor = valor + p_valor
WHERE id = p_id;
end if;
END;
begin
dbms_output.put_line('INICIO: ' || TO_CHAR(SYSDATE, 'DD/MM/
HH24:MI:SS'));
for i in 1 .. 2000 loop
grava(1, 1);
end loop;
dbms_output.put_line('FIM: ' || TO_CHAR(SYSDATE, 'DD/MM/
HH24:MI:SS'));
end;
Esse segundo script demorou 1 segundo. Como podem ver, a única
mudança foi tirar a pk e colocar somente o indice no lugar, e fazer
a verificação manualmente antes de inserir os dados. Nos 2
scripts, foram feitos 1 insert e 1999 updates, portanto, acho que
deveria gerar os mesmos números de redos, etc. Inclusive, no segundo
script tem indice pra atualizar também. O problema parece estar na
pk, não sei se para o oracle validar um insert ele executa algumas
tarefas a mais, sei lá, foi por isso que enviei a mensagem, pra ver
se vocês poderiam explicar o porque disso.
Quanto as dicas que deram, acho que não é problema de rebuild do
indice, pois no exemplo que fiz, numa base totalmente limpa, a
difereça de performance é brutal. Quanto as dicas do Chiappa,
infelizmente não da pra fazer somente num select, tem que ser
procedure mesmo porque existem muitas consistencias antes da
gravação, e tem que ser gravado mesmo numa tabela, pois ela vai ser
lido por um outro sistema e eles exigiram que fosse dessa maneira.
Bem, o problema na verdade está resolvido, eu mandei a mensagem
mesmo pra tentar entender porque da pk ser mais lento. Talvez eu
esteja fazendo besteira nesses testes que fiz também, se tiver podem
falar, hehe.
Abraços
RES: [oracle_br] Performance em Insert
Será que um REBUILD no índice da PK não teria resolvido? Milton Bastos Henriquis Junior Oracle Database Administrator Equipe de Tecnologia [EMAIL PROTECTED] Smartn ® IT Solutions Rua Candido de Abreu, 651 - 16º andar Centro Cívico - Curitiba CEP 80.530-907. Tel: ++ 55 41 3313-8613 Fax: ++ 55 41 3313-8620 www.smartn.com.br De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de rbr72 Enviada em: sexta-feira, 1 de dezembro de 2006 08:40 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Performance em Insert Pessoal, tava analisando um problema num cliente, e percebi que o processo mais demorado era um insert executado várias vezes numa tabela. A lógica era mais ou menos essa abaixo, se já existia um dado na tabela, era feito um update de valores. insert into tabela values ... exception when dup_val_on_index update tabela set ... No trace gerado pelo cliente, ele tentou executar 56000 inserts, foram gravados somente 56 linhas, o resto foi tudo pro update. O problema que pra executar os 56000 inserts demorou 300 segundos, os updates foram bem rápidos. Fazendo os testes, o problema era a primary key, eu desabilitei ela, criei um indice normal, e fiz a verificacao se o registro existe, faco update, senão, insert. Desse modo ficou bem rápido também. O que eu gostaria de saber é a explicação pra isso, sei que, com a primary key, é necessário atualizar o arquivo de indice a cada insert. Mas no cliente só gravou 56 inserts, então conclui que o problema em alguma verificação que a primary key força o oracle a fazer. Alguém sabe o que o Oracle realiza nos inserts, e o porque da demora? Outra coisa, tem como fazer o insert ficar mais rápido ou uma solução melhor do que desabilitiar a pk? Se alguém tiver idéia melhor ajuda, porque vou ter que alterar um monte de procedures. :-) Obrigado ADVERTENCIA: Esta mensagem (incluindo quaisquer anexos) e confidencial e de uso restrito. Se voce recebeu esta mensagem por engano, por favor notifique ao emitente por meio do retorno do e-mail e delete (remova) esta mensagem de seu sistema. Qualquer uso nao autorizado ou distribuicao desta mensagem em sua totalidade ou em parte e estritamente proibido. Por favor, lembre-se de que e-mails sao susceptiveis a alteracoes. Smartn (incluindo outras empresas participantes direta ou indiretamente) nao devem ser responsabilizados pelo uso improprio ou pela transmissao incompleta da informacao contida neste comunicado, nem por nenhum atraso em seu recebimento ou dano ao seu sistema. Smartn (incluindo outras empresas participantes direta ou indiretamente) nao garante que a integridade deste comunicado foi mantida nem que este comunicado esta livre de virus, interceptacao ou interferencia. DISCLAIMER: This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. Smartn (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. Smartn (or its group companies)does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interception or interference. NEGACIÓN: Este mensaje (incluyendo cualquieres accesorios) es confidencial y puede ser privilegiado. Si usted lo ha recibido por error por favor notifique el remitente por el E-mail de vuelta y suprima este mensaje de su sistema. Cualquier uso o difusión desautorizado de este mensaje en entero o en parte se prohíbe terminantemente. Observe por favor que los E-mails son susceptibles al cambio. Smartn (incluyendo sus compañías del grupo) no será obligado para la transmisión incorrecta o incompleta de la información contenida en esta comunicación ni para cualquier no retrasa en su recibo o daño a su sistema. Smartn (o sus compañías del grupo) no garantiza que la integridad de esta comunicación se ha mantenido ni que esta comunicación está libre de virus, de la interceptación o de interferencia. [As partes desta mensagem que não continham texto foram removidas]
