sua conveniência a repito ao final desta, ignore se vc já a recebeu.
Vou fazer alguns comentários adicionais, vamos ver se te são úteis :
a) vc não explica direito, mas pelo tom geral duduzo que o tal soft
hoje busca a informação numa fonte de dados que não é um arquivo-
texto, faz uma série de cálculos, inclusive rejeitando alguns
registros, altera algumas colunas do registro lido e no final grava
os regs aprovados, certo ? Em sendo isso, o uso do loader fica
invalidado por não ser arquivo-texto.
b) como eu disse, tabela em NOLOGGING só adianta de alguma coisa **
SE ** for usado direct-mode, e direct-mode IMPLICA que as condições
que citei se cumprem, entre elas o insert não ser linha-a-linha
c) antes de abandonar a opção de um único comando SQL, cheque as
extensões mais recentes no dialeto SQL da Oracle, como CASE, cláusula
WITH, funções analíticas, sub-query factoring, coisas que vc não
conseguia fazer só em SQL ás vezes com os novos recursos dá
d) se c) realmente não for possível de modo algum, vc vai partir
pruma solução programada, o ponto ** PRINCIPAL ** aqui é que ler e
gravar linha a linha é ** INAPELAVELMENTE ** lento, com a mais
absoluta certeza eu diria que nesse caso nem parallel query nem
storage nem coisa alguma (afora uma RE-ESCRITA do processo de modo a
não fazer row by row) vai adiantar grande coisa.
Essa re-escrita usaria algo MISTO, ie : procedural lendo a fonte de
dados (** obviamente ** nunca lendo row by row, mas sim VÁRIOS
registros por vez, armazenados num array), e OU é esse array que é
gravado na tabela desejada (em BULK), OU cfrme o caso preenche-se uma
tabela Global temporary table que depois é inserida em APPEND-MODE na
tabela definitiva. Essa re-escrita até pode ser feita no próprio
prog Java que vc tem hoje se for conexão jdbc com driver Oracle (que
afaik aceita array processing e bulk collect), ** MAS **
recomendaria se pesar cuidadosamente a chance de se fazer em PL/SQL
essa re-escrita, pois aí não só vc obtém array processing e bulk de
modo transparente (ie, independente de driver), como também stored
pl/sql tem as grandes vantagens que citei na minha msg.
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, "Rafael Mueller" <[EMAIL PROTECTED]>
escreveu
>
> Agradeço pelas respostas,
>
> vamos lá, o uso do sql*loader ou insert into tabela (select
dados...) não é
> possível, o insert precisa ser realizado 1 por 1, pois a inserção é
> resultado de um software que realiza calculos em cima de um modelo,
e então
> envia os resultados para o banco.
>
> A migração desse software para dentro do banco, é complicada pois é
um
> software bastante complexo e que usa muita memória (algo em torno
de 200 mb
> de memoria ram quando esta realizando os cálculos).
>
> Então as soluções que restaram é:
> - Desabilitar os índices e depois recontruí-los. (talvez com
NOVALIDATE)
> - Colocar a tabela em NOLOGGING
> - Parallel Query
> - Modificações de storage.
>
> Algo mais pode ser modificado para melhorar a performance durante a
> inserção?
>
> Seria possível fazer alguma procedure para auxiliar nessa inserção?
>
> Grato
>
>
--------------------------------------------
--- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]>
escreveu
>
> Rafael, em primeiro lugar vc teria que ter feito o TUNNING do
processo
> que obtém os dados a inserir, se for um SELECT que ele esteja o mais
> otimizado possível.
> depois, no caso de append-mode, temos que notar que o hint de
APPEND
> só produz benefícios (gerando menos redo log) se :
>
> a) a tabela sendo inserida está em modo nologging
> b) o banco NÃO está com o parâmetro de force logging ativado
> c) o insert está sendo feito em "bulk", ie, MUITAS linhas de uma vez
> INSERT /*+ APPEND */ INTO tabela (SELECTqueretornaummontãodelinhas);
>
> SE as condições acima não estão válidas, o APPEND que vc colocou não
> serve de RIGOROSAMENTE nada na prática... E há ainda a questão de
> manutenção de índices, NECESSARIAMENTE índices ativos durante uma
> operação direct-mode serão SIM logados, se é uma operação
de "carga",
> considere a possibilidade de desabilitar os índices enquanto ela
> ocorre , e depois os re-buildar em parallel nologging, se possível.
Em
> alguns casos, utilizar constraints deferred , ou mesmo , se vc tem
> absoluta certeza que os dados já estão ok, um DISABLE e um ENABLE
> NOVALIDATE nelas.
> Afora isso, algumas recomendações adicionais :
>
> 1. se for uma carga extensa, e se houver a chance de se ter os
dados
> em arquivo-texto, o sql*loader ou external tables em nolog,
parallel,
> direct, etc, normalmente ** HUMILHAM ** outras soluções caseiras,
com
> loader nesses mesmos 11 minutos eu faço carga é de dezena de milhão
de
> linhas
>
> 2. se for exigida por qquer motivo solução programada, a PRIMEIRA
> opção é SQL fazendo um único INSERT, construtos tipo :
>
> INSERT into tabela (SELECTquemetrazoquequero)
>
> é MUITO mais performático do que código tipo slow-by-slow :
>
> loop
> obtém um registro;
> faço algum tratamento;
> insert no banco desse registro;
> saio se não há mais regs na fonte de dados;
> end loop;
>
> 3. se num único SQL não é possível por qquer motivo, considere
> FORTEMENTE a chance de usar PL/SQL armazenado no banco, pois nesse
> caso além de vc obter facilmente BULK COLLECT e ARRAY PROCESSING,
vc
> ainda tem a GRANDE vantagem de que Pl/SQL reside no banco, os dados
a
> consultar também, o tráfego de rede normalmente é MUITO minimizado
com
> ele.
>
> ==> Estes pontos entendidos, avaliados e empregados, aí sim vc
> pensaria nosa itens mais avançados, como : eventuais modificações de
> storage para favorecer o INSERT (como FREELISTS/FREELIST GROUPS/PCT
> FREE/PCT USED), eventual uso de GTTs para se armazenar registros
> temporários, etc.
>
> []s
>
> Chiappa
> --- Em oracle_br@yahoogrupos.com.br, "Rafael Mueller" <[EMAIL PROTECTED]>
> escreveu
> >
> > Ola lista,
> >
> > tenho um software java que insere 800.000 linha em uma tabela,
esse
> processo
> > demora 11 minutos.
> >
> > Gostaria de algumas dicas de como melhorar essa performance, já
estou
> > utilizando o hint /*+ APPEND */
> >
> > Grato,
> >
> > -- Rafael
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
--------------------------------------------------------------------------------------------------------------------------
Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
--------------------------------------------------------------------------------------------------------------------------__________________________________________________________________
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine
__________________________________________________________________
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário.
| Yahoo! Grupos, um serviço oferecido por: | |
|
Links do Yahoo! Grupos
- Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/
- Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]
- O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço do Yahoo!.
