Moçada. Alguma nova sugestão?
>________________________________ > De: Samuel Santos <samuel.gsan...@yahoo.com.br> >Para: "oracle_br@yahoogrupos.com.br" <oracle_br@yahoogrupos.com.br> >Enviadas: Segunda-feira, 25 de Fevereiro de 2013 12:55 >Assunto: Re: [oracle_br] Re: Carga ETL > > >Prezados > > >Os dados são extraídos de uma base de dados, e estes são montados\tratados >através de um SELECT no qual irá carregar a base STAGE. Logo após os STAGE >estive carregado ai entra o ODI carregando a base OLAP. > > >1 - Necessito diariamente ter todos (tenho tabelas com mais 138 Milhões de >registro) os dados do STAGE atualizados, para que posteriormente o ODI comece >a tratar\carregar as tabelas FATOS e DIMENSÕES - numa segunda fase. > > > >Segue exemplo de parte do SELECT que utilizo: > > >insert /*+ APPEND PARALLEL(DEGREE 12 INSTANCES DEFAULT) */ into TESTE >SELECT > ROWNUM AS ID_PESSOA_AQUISICAO, > qry.SEQ_MUNICIPIO, > qry.SEQ_ORGAO, > qry.SEQ_REMESSA, > qry.SEQ_PESSOA, > qry.COD_PROCESSO_AQUISICAO, > qry.DSC_TIPO_COMISSAO_LICITACAO, > qry.NUM_DECRETO_PORTARIA, > qry.NUM_ATO_NOMEACAO, > qry.SEQ_TEMPO_ATO_NOMEACAO, > qry.DSC_CARGO, > qry.DSC_NATUREZA_CARGO > >>________________________________ >> De: J. Laurindo Chiappa <jlchia...@yahoo.com.br> >>Para: oracle_br@yahoogrupos.com.br >>Enviadas: Segunda-feira, 25 de Fevereiro de 2013 12:23 >>Assunto: [oracle_br] Re: Carga ETL >> >> >> >>Explica um pouco melhor : esse SELECT que vai recuperar os dados busca os >>dados em outras instâncias via dblink, é isso ? OU os dados já estarão >>carregados (via algum processo anterior, provavelmente) em tabelas STAGE/de >>trabalho nesse mesmo database ?? Essas 'n tabelas', são tabelas DESTINO, a >>serem carregadas, OU são as tabelas de origem dos dados ?? De quantas >>tabelas-destino a serem carregadas estamos falando ? Se existem tabelas-stage >>e/ou tabelas remotas a buscar os dados, mais ou menos quantas ? É possível um >>único SELECT buscar todos os dados, ou não, não hpa nenhum tipo de >>relacionamento entre as tabelas-destino e as origem ?? >>DEPENDENDO do que vc disser a gente pode fazer recomendações, mas algumas >>best practices se impõem : >> >>a) uma solução de ETL fora do database, não escrita por vc mesmo (como >>datastage, warehouse builder, etc, etc, etc) te dá a vantagem de ser mais >>rápida para implementar, se houver expertise nela (já que vc escreve menos), >>E via de regra a customização é feita sem programação, numa GUIzinha da tool, >> MAS nem sempre ela te dá a máxima performance (já que nem Todas conseguem >>usar todos os recursos do RDBMS Oracle), além de terem um CUSTO >>não-desprezível, seja em licenciamento seja em valor homem-hora para instalar >>e configurar >> >>b) SE os dados-stage vêm de outras fontes e num formato de arquivo-texto, é >>via de regra INDEFENSÁVEL a opção de se criar tabelas-stage e carregar os >>dados pra lá via sql*loader ou quetais : no século XXI, o ideal é acessar os >>arquivos-texto como se fossem tabelas Oracle via EXTERNAL TABLES >> >>c) SEJA QUAL FOR a solução de ETL adotada (externa ou Customizada/escrita por >>vc mesmo), ela ** TEM ** que onde recomendado/possível/viável usar os >>recursos do RDBMS Oracle, como insert em direct-mode, constraints em >>novalidate, Paralelismo (de SQL e/ou DIY, via múltiplas sessões simultãneas), >>MERGE, Particionamento (ie, swap de tabelas em partições, carga referenciando >>a partição, etc, etc), e outras >> >>d) se vc optar por solução desenvolvida aí E for feita dentro do banco (em >>PL/SQL provavelmente), as principais Recomendações são vc : >> >>- EVITAR CURSORES A (quase) QUALQUER CUSTO, pois isso implica em context >>switch, não-otimização de trechos SQL separados, etc : o negócio é mesmo >>INSERT INTO tabelasdestino (SELECT em questão), SEM loops e cursores >> >>- programar a carga para uma janela com menos utilização >> >>- evitar SQL dinâmico : SQL dinâmico NECESSARIAMENTE IMPLICA em hard parse, >>mais gasto de CPU... E já que vc vai ter POUCO código para cada tabela a >>carregar, não vejo como impossível vc simplesmente escrever na sua procedure >>PL/SQL de carga os INSERTs.. INTO necessários. >>O que vc PODE fazer é pedir para o próprio RDBMS te "escrever" o código, tipo >>: >> >>no sqlplus, vc pede um SPOOL rotina.sql >>configura o sqlplus para não trazer infos extras/cabeçalho >>SELECT 'INSERT INTO ' || table_name || ' SELECT * FROM tabela' FROM >>DBA_TABLES WHERE owner='nomedodono' and TABLE_NAME in (lista das tabelas); >>spool off >> >>Depois carregaa isso num editor de texto, mete CREATE PROCEDURE e faz as >>pequenas edições necessárias, e é isso ... >> >>[]s >> >>Chiappa >> >>--- Em oracle_br@yahoogrupos.com.br, Samuel Santos escreveu >>> >>> PessoALL >>> >>> Tenho o seguinte cenário de ETL para que seja realizado diariamente (este >>> será realizado após as 20hrs). >>> Este procedimento trata-se de carga de dados insert into (através de um >>> SELECT) que deverá ser realizado em n's tabelas. >>> >>> O que vocês sugerem a realizar? >>> >>> Virew Materializada (ser puder enviar exemplos de criação, agendamentos, >>> incremento ou não), enfim qual a melhor forma? >>> Procedure? >>> >>> >>> Desde já agradeço o apoio de todos. >>> >>> [As partes desta mensagem que não continham texto foram removidas] >>> >> >> >> >> >> > > [As partes desta mensagem que não continham texto foram removidas]
