Bem, antes de comentar as opções, REALMENTE não há como não dizer que
esse é um caso CLÁSSICO aonde o Particionamento iria propiciar
performance TOP (evtando tanto o delete dos dados velhos quanto até,
talvez, o insert, fazendo exchange dos novos dados), facilidade
administrativa ALTÍSSIMA (vc não ia ter que programar NADA, custo e
risco zero), de repente não sei se isso, comparado com o RISCO, com a
DIFICULDADE de manutenção, e com o custo de homens-hora que vc vai ter
desenvolvendo uma solução não justificaria, ou quase, o valor do
Enterprise Edition.... Isso sem contar que também pra replicação e
captura e dados o Enterprise tem *** várias *** opções prontinhas e
nativas, portanto normalmente com performance e segurança MUITO muito
maiores do que qquer coisa que nós , sapos de fora do kernel do banco,
possamos ter, iiso TEM que ser considerado também na equaão do custo X
benefício...
Bom, Realmente tendo que assumir o risco e os custos a desembolsar
mantendo o Standard, eu diria o seguinte :
1. a maneira PRINCIPAL, quase que diria a única, de ter INSERTs em
top-performance é vc fazer INSERTs com um ÙNICO SQL (esqueça cursores
PL/SQL, esqueça LOOPs e processamento linha-a-linha), ** E ** juntar
os dados a inserir num único select, a rotina TEM QUE SER :
insert /*+ append */ into tabeladestino (select from
tabelaquecontémosdados);
e se pudessem ser inserido os 3 milhões que vc fala de uma vez
EXCELENTE, sopa no mel.... Se não der, pois os dados chegam aos
poucos, junte uma porão de registros e mais tarde faça o insert /*+
append */ .... No banco 10g (e 9i, inclusive ), esse "lugar" pode ser
até um arquivo-texto que seria lido via external table. Opcionalmente,
se permitido, poderia se usar Paralelismo.
2. há exigências e recomendações para 1), tais como tabelas em modo
nologging, índices desabilitados durante a carga,triggers
DESABILITADAS também, e outras mais, SE isso inviabilizar no seu caso
a opção 1) aí a próxima melhor opção seria continuar ajuntando os
dados a inserir e quando juntou uma boa porção ter um cursor fazendo
leitura em bulk e inserindo em array com forall.
==> O que NÃO funciona eficientemente, e não tem muito como
otimizar, é a PIOR das piores, que deve ser evitada sempre que
possível, é vc fazer um INSERT com uma linha de cada vez, repetidas e
inúmeras vezes pra no final ter os tais 3 milhões, isso não tem mágico
que faça ficar nem perto de comparável às outras opções...
3. o delete : se a query que localiza os regs velhos a deletar já está
o máximo possível otimizada, sozinha ela roda muito bem, provavelmente
fazendo um index scan num índice que só contenha a data de controle,
mas ainda assim o tempo do delete não está atendendo,provavelmente o
que deve estar "pegando" é o undo gerado e/ou a manutenção dos
índices, ambos são INESCAPÁVEIS quando há um delete, não existe
NOLOGGING para deletes, aí uma opção poderia ser vc adotar o delete
lógico, ie : vc tem uma FLAG indicando que o registro não pode ser
usado, os SQLs programas TODOS foram alterados para respeitar isso, e
a rotina de remoção ao invés de delete físico faz só o update dessa
flag (em bulk, paralelo, etc) - DEPOIS, fora do horário de pico,
talvez num fim-de-semana ou feriado, aí sim vc se livra desses
registros flagados, se compensar em termos de processamento/esforço vc
simplesmente manda um INSERT /*+ APEND */ INTO novatabela (select from
tabela where NOT registros estão flagados, e depois dropa a tabela
atual e renomeia novatabela para tabelaatual, tipo assim- se não
puder, ou no compensar, aí sim vc deleta esses caras fisicamente mesmo
na tua janela de manutenção...
4) trigger de replicação : vc não diz, mas será que o tal banco aonde
deve ser replicadaos os dados é Oracle ? SE for, vc deveria pesquisar
outras opções, como basic replication (single-master), Streams, Views
Materializadas, se me lembro bem em algumas versões de banco Standard
algumas dessas opções já são permitidas....Já se não for banco Oracle,
PESQUISE a possibilidade de "inverter" a mão de direção, ie, ao invés
do banco Oacle manfar pro banco estrangeiro os dados, o banco Oracle
disparar um job lá no banco estrangeiro que de lá busca as infos no
Oracle, OU ainda vc ter no Oracle uma tabela ou view materializada
aonde ficam as alteraões e o banco estrangeiro tem um job que a cada x
minutos consulta essa tab de alterações...
O problema de trigger é que ele necessariamente, para poder capturar
os dados, tem que ser um trigger de row level, aí TOCA a disparar
trigger para cada linha de cada DML, urgh... SE não tiver outro jeito,
as outras opções REALMENTE tão fora por qquer motivo, ao menos sugiro
que vc tenha uma tabela temporária de trabalho, aonde a trigger insira
cada registro que sofreu dml e deve ser enviado pro banco-remoto,
depois da transação o Oracle manda esses dados em bulk ou o banco
estrangeiro vem buscar.
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, "Willian Frasson" <[EMAIL PROTECTED]>
escreveu
>
> Boa tarde pessoal como estão?
> Gostaria de saber se algum de vocês tem um ambiente por ex onde
temos uma tabela de 200 milhões de registros, com um volume diário de
3 milhões de INSERTS, onde os dados mais antigos devem ser apagados, e
lembrando que esta tabela também tem uma trigger de replicação para
outra tabela com 70 milhões de registros, vamos raciocionar qual seria
a melhor forma para que o banco trabalhe com um Load baixo, sendo que
a tabela só recebe Inserts e poucos selects.
> Versão: Oracle 10.2.0.3 Standart (portanto sem particionamento).
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
