É o melhor, eu acho também. Agora, como eu disse, NÃO deixe de usar sempre que possível o APPEND-mode, de ter lá no bd origem o multiblock_read no talo do máximo do teu hardware (já que é FTS que vc fará lá), o teu dba pode te ajudar nas configs necessárias pra isso...
[]s Chiappa --- Em oracle_br@yahoogrupos.com.br, José Resende Neto <[EMAIL PROTECTED]> escreveu > > Valeu, Chiappa. > Vou fazer mesmo com INSERT INTO.... SELECT * FROM... como vc sugeriu. > Já falei com o meu DBA e ele disse que a área de rollback "aguenta". > Essa programação toda já me desanimou só de planejar... > > Abraço. > Neto. > > > ----- Original Message ----- > From: "jlchiappa" <[EMAIL PROTECTED]> > To: <oracle_br@yahoogrupos.com.br> > Sent: Tuesday, April 04, 2006 9:55 AM > Subject: [oracle_br] Re: HELP!!! Migração de dados - SQL Dinamico. > > > Verdade, um INSERT é atômico, é uma coisa só que será feita duma vez > só, mas pra solucionar erros de rollback, comitar várias vezes NÃO É, > e NUNCA FOI, a solução 100% correta e funcional, é tranquilo vc > montar um caso onde mesmo comitando a cada X registros vc cai nesse > erro, SE a tablespace de undo não for de tamanho adequando E os > segmentos não estiverem em quantidade/tamanhos/storage adequado à > transação que vc vai fazer. Além disso, NO SEU CASO, já que vc está > populando o bd destino, claro que ele está "inativo", ninguém o está > usando, então NADA impede de vc ajustar a área de rollback > corretamente, confere ??? > E ** mais ainda **, já que vc está inserindo dados só agora, E os > dados estão ok no bd origem, vc VAI desabilitar as constraints, > desativar índices e fazer INSERT em APPEND, a qtdade de undo/rollback > gerada assim vai ser MINÚSCULA, cfrme : > > [EMAIL PROTECTED]:SQL>select count(*) from fco.TMP_CRIT_RELATS; > > COUNT(*) > ------------------ > 2517056 > > ==> ok, 2 milhões e pouquinho, já dá pra brincar. Vamos a criar > primeiro no bd destino (onde já há dblink pro bd origem) : > > [EMAIL PROTECTED]:SQL>create table TAB_TESTE tablespace USERS as (select * > from [EMAIL PROTECTED] where 1=2); > > Tabela criada. > > ==> vamos botar uns índices & constraints, que mais tarde vou > desabilitar, só pra mostrar que SE desabilitados o APPEND-mode > funciona : > > [EMAIL PROTECTED]:SQL>create index IDX_TEST on TAB_TESTE(tmp_id) tablespace > users; > > Índice criado. > > [EMAIL PROTECTED]:SQL>create index IDX_TEST2 on TAB_TESTE > (MUNICIPIO_ORIGEN_ID,MUNICIPIO_DESTINO_ID,MOTIVO_EVENTO) tablespace > users; > > Índice criado. > > [EMAIL PROTECTED]:SQL>alter table TAB_TESTE add constraint TAB_TESTE_PK > primary key (tmp_id); > > Tabela alterada. > > [EMAIL PROTECTED]:SQL>alter table TAB_TESTE add constraint TAB_TESTE_UK > unique (MUNICIPIO_ORIGEN_ID,MUNICIPIO_DESTINO_ID,MOTIVO_EVENTO); > > Tabela alterada. > > ==> vamos botar tabela em nolog & desligar índices e constraints : > > [EMAIL PROTECTED]:SQL>alter table TAB_TESTE nologging; > > Tabela alterada. > > [EMAIL PROTECTED]:SQL>alter table TAB_TESTE disable constraint TAB_TESTE_UK ; > > Tabela alterada. > > [EMAIL PROTECTED]:SQL>alter table TAB_TESTE disable constraint TAB_TESTE_PK; > > Tabela alterada. > > [EMAIL PROTECTED]:SQL>alter index IDX_TEST unusable; > > Índice alterado. > > [EMAIL PROTECTED]:SQL>alter index IDX_TEST2 unusable; > > Índice alterado. > > [EMAIL PROTECTED]:SQL>select distinct status from user_constraints where > table_name='TAB_TESTE'; > > STATUS > -------- > DISABLED > > [EMAIL PROTECTED]:SQL>select distinct status from user_indexes where > table_name='TAB_TESTE'; > > STATUS > -------- > UNUSABLE > > ==>> Já que há índices unusable, vou pedir pro bd os ignorar : > > [EMAIL PROTECTED]:SQL>alter session set skip_unusable_indexes=TRUE; > > Sessão alterada. > > [EMAIL PROTECTED]:SQL>insert /*+ APPEND */ into TAB_TESTE (select * from > [EMAIL PROTECTED]); > > 2517056 linhas criadas. > > [EMAIL PROTECTED]:SQL> > > ==>> legal, quanto de rollback eu usei ?? > > > [EMAIL PROTECTED]:SQL>@used_rollback_blocks > > SEGMENT_NAME USERNAME SID SERIAL# > USED_UBLK USED_UREC START_UBAFIL > START_UBABLK START_UBAREC STATUS > TABLESPACE_NAME SEGMENT_ID > FILE_ID BLOCK_ID > --------------- ---------------- ---- ------- ------------------ --- -- > ------------- ------------------ ------------------ ---------------- -- > ---------------- ------------------------------ ------------------ -- > ---------------- ------------------ > _SYSSMU8$ SCOTT 49 647 > 1 1 4 > 1232 3 ONLINE > UNDO_TABLESPACE 8 > 2 121 > > [EMAIL PROTECTED]:SQL>get used_rollback_blocks > 1 # > 2 column sid format 999 > 3 column segment_name format a15 > 4 select b.segment_name, a.username, a.sid, a.serial#, > c.used_ublk, c.used_urec,c.START_UBAFIL, c.START_UBABLK, > c.START_UBAREC , b.status, > 5 b.TABLESPACE_NAME, b.SEGMENT_ID, b.FILE_ID, b.BLOCK_ID > 6 from v$session a, dba_rollback_segs b, v$transaction c > 7 where b.segment_id = c.xidusn > 8 and a.taddr = c.addr > 9 / > > [EMAIL PROTECTED]:SQL> > > ==> cara, usei UM BLOCO de rollback, ie, 8 Kb no meu banco !!! > Lógico, o seu banco é seu, vc fará como quiser,mas ter o trabalhão > (que NÃO é brinquedo, longe de ser simples!!) de fazer programado em > vista da evidência acima IMHO simplesmente NÂO se justifica.... > > []s > > Chiappa > --- Em oracle_br@yahoogrupos.com.br, José Resende Neto > <[EMAIL PROTECTED]> escreveu > > > > Chiappa, > > > > eu pensei em fazer por código para não correr o risco de estourar a > área de > > rollback, uma vez que algumas tabelas têm uma quantidade bastante > grande de > > registros. Assim eu poderia dividir os registros por blocos e > commitar a > > cada 10000 registros, por exemplo. > > > > Agora se eu fizer como vc disse usando "select 'INSERT INTO ' || > TABLE_NAME > > ||'@nomedodblink (select * from ' > > || TABLE_NAME || ');'", como eu faria para commitar a cada X > registros e não > > estourar a área de rollback? > > > > Abraço. > > Neto. > > > > > > > > ----- Original Message ----- > > From: "jlchiappa" <[EMAIL PROTECTED]> > > To: <oracle_br@yahoogrupos.com.br> > > Sent: Monday, April 03, 2006 4:08 PM > > Subject: [oracle_br] Re: HELP!!! Migração de dados - SQL Dinamico. > > > > > > Friend, vamos por partes aí : primeiro de tudo, já que vc > > diz "migração de dados de tabelas idênticas", eu entendo que os > nomes > > das tabelas E os nomes das colunas são os mesmos tanto no bd origem > > quanto no destino, confere ??? Sendo assim, por mais divertido que > > seja vc brincar com código, administrativamente a maneira rápida de > > se fazer esta tarefa é montar e rodar um script tipo : > > > > set term off feedback off verify off pages 0 lines 500 trimspool on > > head off > > spool tabs_a_inserir.sql > > select 'INSERT INTO ' || TABLE_NAME ||'@nomedodblink (select * > from ' > > || TABLE_NAME || ');' > > from dba_tables > > where ... condiçõesqueidentificamastabs....; > > exit > > > > > > ==> e daí vc roda o script tabs_a_inserir.sql, cabou, morreu, fim de > > papo - no máximo, se desejado quebre o script em n partes para as > > rodar em sessões simultâneas de plus, faça INSERT /*+ APPEND */ se > as > > tabelas estão em nologging, PARALLEL se for mas a base é essa aí de > > cima.... > > > > Caso vc REALMENTE queira fazer via programação, como sempre quando > se > > fala em SQL dinâmico vc VAI ter que codificar PRACAS, não é muito > > simples, E ainda além disso vc VAI ter que conviver com um monte de > > parses extras. O primeiro ponto é que vc não sabe o número de > colunas > > pra cada SQL gerado, então ao invés de EXECUTE IMMEDIATE vc vai ter > > que usar DBMS_SQL, procure em http://asktom.oracle.com por DYNAMIC > > DYNAMIC SQL que vc acha alguns textos. Depois, vc vai ter o problema > > de que vais ter colunas de diversos datatypes, ou vc usa ANYDATA > > (procure no asktom que vc acha algo), ou abre uma série de IFs, > > provavelmente recuperando o datatype de cada coluna na > > DBA_TAB_COLUMNS. > > > > []s > > > > Chiappa > > > > --- Em oracle_br@yahoogrupos.com.br, José Resende Neto > > <[EMAIL PROTECTED]> escreveu > > > > > > Pessoal, > > > > > > alguém pode me ajudar com esse problema da minha migração de dados > > descrita > > > no email abaixo? > > > > > > Obrigado. > > > Neto. > > > > > > ----- Original Message ----- > > > From: "ze_neto2002" <[EMAIL PROTECTED]> > > > To: <oracle_br@yahoogrupos.com.br> > > > Sent: Monday, April 03, 2006 11:33 AM > > > Subject: [oracle_br] Migração de dados - SQL Dinamico. > > > > > > > > > BANCO: Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit > > > Production > > > > > > Pessoal, > > > > > > estou precisando fazer uma migração de dados de tabelas idênticas > de > > > uma instância para outra, usando um DB link. > > > > > > Eu quero fazer um código genérico. Ou seja, sem usar nomes ou > tipos > > > relacionados a nomes fixos de tabelas, eu poderia migrar os dados > de > > > todas as tabelas. Elas primeiramente serão carregadas em uma > tabela > > > temporária. Então eu abro um cursor (ou carrego um array) com o > nome > > > de cada uma e daí começo a ler os dados na outra instância e > > carregar > > > na tabela final. > > > > > > Tenho tabelas com muitos dados. Por isso não posso usar > > > simplesmente "INSERT INTO <nome da tabela> SELECT * FROM <nome da > > > tabela>@<DB_LINK>". Mesmo se eu fizesse "INSERT INTO <nome da > > tabela> > > > SELECT * FROM <nome da tabela>@<DB_LINK> WHERE ROWNUM BETWEEN > > > <valor_ini> AND <valor_fim>", neste caso separando o insert em > > blocos > > > de 10000, por exemplo, ficaria muito lento porque teria que ler a > > > tabela a cada 10000 registros. Então Pensei em fazer usando o > BULK e > > > FORALL. > > > > > > Agora vamos aos problemas: > > > > > > 1) Eu teria que jogar o que eu leio em um tipo record genérico. Eu > > > não quero passar o nome da tabela fixo e nem um tipo fixo usando o > > > ROWTYPE. Eu não quero algo do tipo: > > > TYPE cust_rec IS TABLE OF <tabela customer>%ROWTYPE; > > > > > > Qual seria a solução para o tipo genérico, onde eu poderia jogar o > > > registro de qualquer tabela? > > > > > > > > > 2) Tendo o tipo genérico em mãos, eu poderia começar a pensar no > > > FORALL. Mas estou parado no problema de fazer um FORALL usando SQL > > > dinamico, porque o nome da minha tabela de destino não é fixo. > Então > > > tentei: > > > > > > v_sql := 'FORALL indx IN id_first..id_last '|| > > > 'INSERT INTO '||mig_table.table_name(i)||' > > > VALUES '||mig_table.table_name(i)||'_type(indx)'; > > > EXECUTE IMMEDIATE v_sql; > > > > > > onde mig_table.table_name(i)||'_type seria o tipo genérico do item > > 1. > > > Mas não funciona. Dá o erro "ORA-00900: invalid SQL statement". > > > Imagino que seja porque não posso fazer o FORALL dinamicamente. > > > > > > E aí, pessoal? Alguém já passou por este tipo de migração de dados > > > antes? Alguma luz? > > > > > > Estou no aguardo... > > > Neto. > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- -- > -- > > -------- > > > ---------------------------------------------- > > > 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. > > > Links do Yahoo! Grupos > > > > > > > > > > > > > > > > > ------------------------------------------------------------------ -- > -------- > > ---------------------------------------------- > > 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. > > Links do Yahoo! Grupos > > > > > > > > > -------------------------------------------------------------------- -------- > ---------------------------------------------- > 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. > Links do Yahoo! Grupos > -------------------------------------------------------------------------------------------------------------------------- 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. 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: http://br.yahoo.com/info/utos.html
