Então Chiappa a questão da View Materializada eu andei pensando nessa possibilidade também, outro problema que tenho é a fragmentação, pelo fato de muitos inserts e muitos deletes. No caso do insert /*+ append */ into tabeladestino (select from tabelaquecontémosdados); até acho que daria para fazer isso uma vez por dia, ao invéz de deixar as triggers que estão arrebentando com a máquina, outra coisa é que por ex hoje mesmo o Analyze ainda está rodando (09:04) da manhã e ainda matando o Load da máquina em torno de 15 até 20.
----- Original Message ----- From: jlchiappa To: oracle_br@yahoogrupos.com.br Sent: Thursday, July 03, 2008 10:32 PM Subject: [oracle_br] Re: Número Elevado de Inserts x BIG Table x Sem Particionamento 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] > __________ Informação do NOD32 IMON 3240 (20080704) __________ Esta mensagem foi verificada pelo NOD32 sistema antivírus http://www.eset.com.br [As partes desta mensagem que não continham texto foram removidas]
