Comentando sobre o que vc diz da tal rotina, eu acrescentaria :
a) vc SABE que o APPEND num INSERT só funciona SE, além da tabela-destino
estar em NOLOGGING mode (e sem índices ativos, preferencialmente) SE O INSERT
FOR DE MÚLTIPLAS LINHAS, ie :
INSERT /*+ APPEND */ intoi tabeladestino (SELECT que traz muitas linhas);
okdoc ? Usar o APPEND num comando tipo :
INSERT /*+ APPEND */ INTO tabela VALUES (valoresdesejados);
só te traz como resultado o desperdício de 13 toques no teclado, não
adianta DE NADA, não serve DE NADA, sim ??
b) como derivação de a) acima, será que vc está usando processamento
row-by-row, tipo :
for cursor in loop
...faz uns IFs e coisas do tipo...
INSERT INTO tabeladestino VALUES(valorescalculados);
end loop;
==> SE está, isso DIFICILMENTE vai ter boa performance , pois ao contrário
de um :
INSERT INTO tabela (select com as fontes de dados);
processamento via cursor NÂO pode ser otimizado pelo CBO (ele só otimiza
comandos SQLs completos), implica em MONTES de idas e vindas ao banco de dados,
é tudo de ruim.... No máximo, se não der pra fazer a carga num INSERT só (ou
num MERGE, enfim) , então PELO MENOS use BULK COLLECT e ARRAY PROCESSING... Ou
ainda, ir juntando os registros a serem inseridos numa GTT e no fim da rotina
se faz um
INSERT /* APPEND */ into tabeladestino (SELECT * FROm gtt);
c) COMMIT só no final da rotina, claro, EVITANDO os WAITs relacionados a redo
sync : provavelmente isso implica em se ter uma tablespace de UNDO gigantesca,
mas be it...
d) não entendi ainda que apito toca a tal "tabela de despesa" que é
monstruosa : ela é a tabela-destino, aonde os dados vão ser inseridos, OU ela é
a origem dos dados, aí vc tem que fazer uma consulta nela para extrair os dados
a serem inseridos em oura ??
SE a tal tabela "monstro" for a tabela a ser inserida, pode-se supor que o
que está fazendo a carga demorar seja que a cada INSERT os índices estão sendo
atualizados e as constraints checadas, implicando numa varredura da
tabela-monstro inteira : se for isso, pode-se pensar em Particionamento, em ter
constraints que só são checadas em tempo de COMMIT (ou mesmo desabilitadas e só
rehabilitadas no fim da carga), índices disabled...
SE a tal tabela "monstro" na verdade contém os dados a serem lidos,
processados e depois inseridos numa outra tabela-destino, aí o teu alvo é
DIMINUIR FORTEMENTE a qtdade de blocos que precisam ser lidos na tabela
"monstro" para se chegar aos dados : isso nos leva a pensar em Particionamento,
em um índice SELETIVO (ie, um índice de função que indexe APENAS a porção de
dados "monstruosos" que precisam ser lidos), coisas do tipo...
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Samuel Santos escreveu
>
> Estamos realizando várias cargas de dados em através de script PL/SQL. A
> quantidade de registro difere entre 5Milhões a 20Milhões de registros.
> Sendo assim temos neste exato momento uma tabela de despesa na qual é
> MOSTRUOSA, já a destrinchamos o máximo que podia, utilizamos Hints:
> Parlelismo, APPEND... mas ainda sim ja tem no mínimo 3horas dessa carga.
>
> Gostaria de uma ajuda de vcs para sugerir\dica do que podemos alterar nos
> parâmetros do SGBD, de modo que nos auxilie ainda mais nestas cargas. Estamos
> analisando query a query, através do Explain...mas ainda sim precisamos de
> mais melhorias...
>
>
>
> >________________________________
> > De: Fabricio Pedroso Jorge
> >Para: oracle_br@yahoogrupos.com.br
> >Enviadas: Terça-feira, 5 de Fevereiro de 2013 17:06
> >Assunto: Re: [oracle_br] URGENTE - SGA x PGA
> >
> >Tira um AWR em um período de carga (umas 2 horas) e de um período sem carga
> >(também de umas duas horas)
> >
> >Veja as seções dos memory advisors pra ver se há a necessidade de mudança
> >nos parâmetros de memória.
> >
> >Mas o principal é: Qual é esse problema crítico?
> >
> >Em 5 de fevereiro de 2013 17:03, Samuel Santos
> > escreveu:
> >
> >> **
> >>
> >>
> >> Pessoal, Boa Tarde!
> >>
> >> Peço-lhes uma ajuda para solucionar um problema crítico de carga de dados
> >> no servidor de um cliente, segue as características do ambiente:
> >>
> >> Modelo: DELL R710 - 2Us
> >> S/T: B3Q82R1
> >> 2 Processadores Six-Core 2,40 GHZ
> >> Memória 144G
> >> 2 HDs de 1T
> >> Servidor não possui placa HBA
> >> Sistema Operacional: Red Hat 5.8 Enterprise 64B
> >> Oracle Enterprise 11.2.0.3
> >>
> >>
> >> O que vc's sugerem para alteração\ajuste nos paramentros de SGA, PGA, etc?
> >>
> >> SQL> show parameter target
> >>
> >> NAME TYPE VALUE
> >> ------------------------------------ -----------
> >> ------------------------------
> >> archive_lag_target integer 0
> >> db_flashback_retention_target integer 1440
> >> fast_start_io_target integer 0
> >> fast_start_mttr_target integer 0
> >> memory_max_target big integer 0
> >> memory_target big integer 0
> >> parallel_servers_target integer 192
> >> pga_aggregate_target big integer 29842M
> >> sga_target big integer 89600M
> >>
> >> [As partes desta mensagem que não continham texto foram removidas]
> >>
> >>
> >>
> >
> >
> >
> >--
> >***Fabrício Pedroso Jorge.*
> >
> >Administrador de Banco de Dados
> >Oracle 11g Certified SQL Expert
> >Oracle 11g Certified Associate
> >Oracle 11g Certified Professional
> >Linux Professional Institute Certified Level I (LPIC-I)
> >certificacaodb.com.br
> >
> >*Resumo Profissional:*
> >http://br.linkedin.com/in/fabriciojorge
> >
> >*Contatos:*
> >+ 55 91 88991116 /
> >+ 55 11 82223651
> >fpjbito@...
> >
> >
> >[As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
> >------------------------------------
> >
> >--------------------------------------------------------------------------------------------------------------------------
> >>Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira
> >>responsabilidade de seus remetentes.
> >Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
> >--------------------------------------------------------------------------------------------------------------------------
> >>Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure
> >>» Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE:
> >>http://www.oraclebr.com.br/
> >------------------------------------------------------------------------------------------------------------------------
> > Links do Yahoo! Grupos
> >
> >
> >
> >
> >
>
> [As partes desta mensagem que não continham texto foram removidas]
>
