Re: [oracle_br] Re: Migração de base de dados gran de
Grande Chiappa!!! Mais uma vez obrigado pelo interesse em responder/ajudar. Então os dados que não falei: São no mesmo SO, porém em servidores diferentes, e ainda no 9i está em estrutura de FS e na 10G vai para RAC com ASM. Ah também vão de 32 para 64 bits. Att. Raul Em 8 de abril de 2010 14:21, José Laurindo escreveu: > > > Bem, vc não dá os detalhes cruciais (ie, se é migração pro mesmo servidor > ou pra um outro, os Sistemas Operacionais exatos envolvidos e > características de hardware se forem servers diferentes), mas de modo geral > : > > a) se for no mesmo servidor E no mesmo SO/etc, sem dúvida a maneira mais > fácil é vc fazer a migração (ie, a Conversão) desse banco de dados pra 10g > (só lembrando, a definição de "banco de dados" é que ele é a soma dos > ARQUIVOS, como datafiles, controlfiles, redo files, etc, e a Instância são > os binários, fazendo a Instância ler os arqs vc tem um banco Aberto). O > procedimento é relativamente simples, vc instala os binários 10g, starta a > instância 10g e aí pede para ela ler os arquivos 9i, convertendo-os para o > formato 10g via STARTUP MIGRATE . Consulte no metalink a nota metalink > 466181.1 "10g Upgrade Companion", que ela dá os detalhes todos > > b) se for de um server pra outro a´pode haver variações , dependendo se o > So muda, se a qruitetura (32/64 bits) muda... Se for isso, passa os dets, > plz. > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br , > "Raul Francisco Costa F. de Andrade, DBA" escreveu > > > > > Pessoal, estou com um problema que talvez possam me ajudar. > > Preciso fazer a migração de uma base de dados do Oracle 9i para 10G > > (10.2.0.4). > > Porém a base tem 300GB e não tenho este espaço em hd para gerar o EXPORT > > para depois fazer o import. > > Também não posso usar o Datapump por ser Oracle 9i a base origem. > > > > Gostaria de algumas dicas se possível. > > > > > > Att. > > > > Raul > > > > -- > > -- > > Raul Francisco da Costa Ferreira de Andrade > > DBA - OCA - Oracle Certified Associate > > COBIT Foundation 4.1 > > Fone: (41)8855-8874 Brt > > email: raulf...@... > > > Skype: raul.andrade > > www.clickdba.com > > "Para conhecermos os amigos é necessário passar > > pelo sucesso e pela desgraça. > > No sucesso, verificamos a quantidade e, > > na desgraça, a qualidade. " Confúcio > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > -- -- Raul Francisco da Costa Ferreira de Andrade DBA - OCA - Oracle Certified Associate COBIT Foundation 4.1 Fone: (41)8855-8874 Brt email: raulf...@gmail.com Skype: raul.andrade www.clickdba.com "Para conhecermos os amigos é necessário passar pelo sucesso e pela desgraça. No sucesso, verificamos a quantidade e, na desgraça, a qualidade. " Confúcio [As partes desta mensagem que não continham texto foram removidas] -- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >http://www.oraclebr.com.br/ 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: oracle_br-unsubscr...@yahoogrupos.com.br <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
Re: [oracle_br] Re: Migração de base de dados gran de
E ai bunitão da pra fazer export e import compactado com pipe isso se o seu sistema operacional for um Linux ou Unix. voce gera o dump ja compactado. sai mais ou menos umas 7 menor que o tamanho original, se tiver interessado me da um toque eu te mando o script de como fazer! porem o seu downtime sera maior doque se voce fizer um upgrade. Em 8 de abril de 2010 17:45, José Laurindo escreveu: > > > Colega, se é outro equipamento, E (obviamente) deve haver comunicação de > rede entre os dois, sem criar arqs intermediários grandes, uma opção que > salta aos olhos em primeiro lugar é vc instalar os binários , criar uma > instância 10g, criar um database vazio, criar as estruturas do 9i nele e > trazer os dados do bd original : criar a estrutura seria um export com > ROWS=N CONSTRAINTS=N INDEXES=N (isso ocuparia uns poucos Mbs, um export sem > dados é bem pequeno), e depois ir trazendo os dados (via INSERT /*+ APPEND > */ into tabela select * from tab...@dblinkparao9i , pequenos exports > feitos a partir do 10g conectando no 9i via dblink, E quando os dados > estarem ok aí vc executa um script que crie os índices em parallel e > nologging e crie as constraints SEM validar os dados (que vc já sabe que > estão bons) - via de regra essa opção é bem rápida, em especial se a sua > rede e o I/O são bons, vc pod ter várias sessões trazendo dados do 9i ao > mesmo tempo... Pra te ajudar a extrair os scripts de criação de estruturas, > índices e constraints vc pode usar o freeware DDL Wizard em > http://ddlwizard.com/ . E é claro, ainda sem trafegar grandes arqs, vc Não > vai deixar de mensurar as outras possibilidades já citadas na thread por > ouros colegas, como voltar um backup do RMAN no novo servidor (ele tem > comandos para fazer o upgrade dos arqs), se for em fita e a fita puder ser > atachada no novo server Se nenhuma das duas outras possibilidades for > viável, aí caímos na necessidade de se Transferir os arquivos do 9i pro 10g > e lá fazer o upgrade/conversão deles, via de regra isso deve ser um pouco > mais demorado... > > O resumo da ópera é , então, é : no SEU ambiente, teste quanto tempo leva > (sob condições ótimas, com o mínimo de usuários usando, com Parallel DML > ativo, com db_file_multiblock_read_count no talo máximo, etc) quanto tempo > leva um INSERT /*+ APPEND */ via dblink, quanto tempo leva o restore dos > maiores arqs e quanto tempo leva a transferência de arqs via rede (o > upgrade/conversão é rapidinho) , que aí vc terá condição de dizer qual é o > melhor em tempo ... > > É claro, vc TEM que dar uma gordurinha na sua estimativa total clause > ativada seja qual for o método (pois no caso de INSERT vc terá que rebuildar > os índices, no caso de conversão de datafiles normalmente após o STARTUP > UPGRADE vc tem que recriar parte do dicionário/catálogo, recompilar objs > inválidos, E no seu caso sendo 32 -> 64 bits a conversão vai ter que > recompilar PL/SQLs)... Blz ? > > []s > > Chiappa > > > --- Em oracle_br@yahoogrupos.com.br , > "Raul Francisco Costa F. de Andrade, DBA" escreveu > > > > > Grande Chiappa!!! Mais uma vez obrigado pelo interesse em > responder/ajudar. > > > > Então os dados que não falei: > > São no mesmo SO, porém em servidores diferentes, e ainda no 9i está em > > estrutura de FS e na 10G vai para RAC com ASM. > > Ah também vão de 32 para 64 bits. > > > > Att. > > > > Raul > > > > Em 8 de abril de 2010 14:21, José Laurindo escreveu: > > > > > > > > > > > > Bem, vc não dá os detalhes cruciais (ie, se é migração pro mesmo > servidor > > > ou pra um outro, os Sistemas Operacionais exatos envolvidos e > > > características de hardware se forem servers diferentes), mas de modo > geral > > > : > > > > > > a) se for no mesmo servidor E no mesmo SO/etc, sem dúvida a maneira > mais > > > fácil é vc fazer a migração (ie, a Conversão) desse banco de dados pra > 10g > > > (só lembrando, a definição de "banco de dados" é que ele é a soma dos > > > ARQUIVOS, como datafiles, controlfiles, redo files, etc, e a Instância > são > > > os binários, fazendo a Instância ler os arqs vc tem um banco Aberto). O > > > procedimento é relativamente simples, vc instala os binários 10g, > starta a > > > instância 10g e aí pede para ela ler os arquivos 9i, convertendo-os > para o > > > formato 10g via STARTUP MIGRATE . Consulte no metalink a nota metalink > > > 466181.1 "10g Upgrade Companion", que ela dá os detalhes todos > > > > > > b) se for de um server pra outro a´pode haver variações , dependendo se > o > > > So muda, se a qruitetura (32/64 bits) muda... Se for isso, passa os > dets, > > > plz. > > > > > > []s > > > > > > Chiappa > > > > > > --- Em oracle_br@yahoogrupos.com.br > > > 40yahoogrupos.com.br>, > > > "Raul Francisco Costa F. de Andrade, DBA" escreveu > > > > > > > > > > > Pessoal, estou com um problema que talvez possam me ajudar. > > > > Preciso fazer a migração de uma base de dados do Oracle 9i para 10G > > > > (10.2.0.4). > > > > Porém a base tem 300GB e não tenho este espa
Re: [oracle_br] Re: Migração de base de dados gran de
Raul Um note que pode te ajudar bastante: Best Practices to Minimize Downtime During Upgrade [ID 455744.1] Este note ja aborda praticamente tudo o que você precisa para passar de 9i para 10g com o mínimo de downtime. Além disso, o que "pega" na tua migração é a transferencia dos dados de FS para ASM. Vejo duas opções para contornar isso: 1) Migrar inicialmente para FS, depois com RMAN transferir os datafiles para ASM via "backup as copy". Ao final, fazer o switch para a copia - Neste caso você precisa de mais espaço em disco. 2) Fazer upgrade na maquina atual. Criar no RAC um standby do banco de produção atual usando ASM. Baixar o banco atual, aplicar os archives restantes e subir o "standby RAC" como produção. Pra qualquer um dos cenários, muito teste! att Ivan R. Schuster OCP 10g/11g OCE RAC 2010/4/8 Duilio Bruniera Junior : > E ai bunitão da pra fazer export e import compactado com pipe isso se o seu > sistema operacional for um Linux ou Unix. > voce gera o dump ja compactado. sai mais ou menos umas 7 menor que o tamanho > original, se tiver interessado me da um toque eu te mando o script de como > fazer! > porem o seu downtime sera maior doque se voce fizer um upgrade. > > > > Em 8 de abril de 2010 17:45, José Laurindo escreveu: > >> >> >> Colega, se é outro equipamento, E (obviamente) deve haver comunicação de >> rede entre os dois, sem criar arqs intermediários grandes, uma opção que >> salta aos olhos em primeiro lugar é vc instalar os binários , criar uma >> instância 10g, criar um database vazio, criar as estruturas do 9i nele e >> trazer os dados do bd original : criar a estrutura seria um export com >> ROWS=N CONSTRAINTS=N INDEXES=N (isso ocuparia uns poucos Mbs, um export sem >> dados é bem pequeno), e depois ir trazendo os dados (via INSERT /*+ APPEND >> */ into tabela select * from tab...@dblinkparao9i , pequenos exports >> feitos a partir do 10g conectando no 9i via dblink, E quando os dados >> estarem ok aí vc executa um script que crie os índices em parallel e >> nologging e crie as constraints SEM validar os dados (que vc já sabe que >> estão bons) - via de regra essa opção é bem rápida, em especial se a sua >> rede e o I/O são bons, vc pod ter várias sessões trazendo dados do 9i ao >> mesmo tempo... Pra te ajudar a extrair os scripts de criação de estruturas, >> índices e constraints vc pode usar o freeware DDL Wizard em >> http://ddlwizard.com/ . E é claro, ainda sem trafegar grandes arqs, vc Não >> vai deixar de mensurar as outras possibilidades já citadas na thread por >> ouros colegas, como voltar um backup do RMAN no novo servidor (ele tem >> comandos para fazer o upgrade dos arqs), se for em fita e a fita puder ser >> atachada no novo server Se nenhuma das duas outras possibilidades for >> viável, aí caímos na necessidade de se Transferir os arquivos do 9i pro 10g >> e lá fazer o upgrade/conversão deles, via de regra isso deve ser um pouco >> mais demorado... >> >> O resumo da ópera é , então, é : no SEU ambiente, teste quanto tempo leva >> (sob condições ótimas, com o mínimo de usuários usando, com Parallel DML >> ativo, com db_file_multiblock_read_count no talo máximo, etc) quanto tempo >> leva um INSERT /*+ APPEND */ via dblink, quanto tempo leva o restore dos >> maiores arqs e quanto tempo leva a transferência de arqs via rede (o >> upgrade/conversão é rapidinho) , que aí vc terá condição de dizer qual é o >> melhor em tempo ... >> >> É claro, vc TEM que dar uma gordurinha na sua estimativa total clause >> ativada seja qual for o método (pois no caso de INSERT vc terá que rebuildar >> os índices, no caso de conversão de datafiles normalmente após o STARTUP >> UPGRADE vc tem que recriar parte do dicionário/catálogo, recompilar objs >> inválidos, E no seu caso sendo 32 -> 64 bits a conversão vai ter que >> recompilar PL/SQLs)... Blz ? >> >> []s >> >> Chiappa >> >> >> --- Em oracle_br@yahoogrupos.com.br , >> "Raul Francisco Costa F. de Andrade, DBA" escreveu >> >> > >> > Grande Chiappa!!! Mais uma vez obrigado pelo interesse em >> responder/ajudar. >> > >> > Então os dados que não falei: >> > São no mesmo SO, porém em servidores diferentes, e ainda no 9i está em >> > estrutura de FS e na 10G vai para RAC com ASM. >> > Ah também vão de 32 para 64 bits. >> > >> > Att. >> > >> > Raul >> > >> > Em 8 de abril de 2010 14:21, José Laurindo escreveu: >> >> > >> > > >> > > >> > > Bem, vc não dá os detalhes cruciais (ie, se é migração pro mesmo >> servidor >> > > ou pra um outro, os Sistemas Operacionais exatos envolvidos e >> > > características de hardware se forem servers diferentes), mas de modo >> geral >> > > : >> > > >> > > a) se for no mesmo servidor E no mesmo SO/etc, sem dúvida a maneira >> mais >> > > fácil é vc fazer a migração (ie, a Conversão) desse banco de dados pra >> 10g >> > > (só lembrando, a definição de "banco de dados" é que ele é a soma dos >> > > ARQUIVOS, como datafiles, controlfiles, redo files, etc, e a Instância >> são >> > > os binários, fazen
Re: [oracle_br] Re: Migração de base de dados gran de
Bom dia amigo!!! Estou interessado no script sim, por favor se puder me mandar irá me ajudar muito. Att. Raul Em 8 de abril de 2010 18:39, Duilio Bruniera Junior escreveu: > E ai bunitão da pra fazer export e import compactado com pipe isso se o seu > sistema operacional for um Linux ou Unix. > voce gera o dump ja compactado. sai mais ou menos umas 7 menor que o > tamanho > original, se tiver interessado me da um toque eu te mando o script de como > fazer! > porem o seu downtime sera maior doque se voce fizer um upgrade. > > > > Em 8 de abril de 2010 17:45, José Laurindo >escreveu: > > > > > > > Colega, se é outro equipamento, E (obviamente) deve haver comunicação de > > rede entre os dois, sem criar arqs intermediários grandes, uma opção que > > salta aos olhos em primeiro lugar é vc instalar os binários , criar uma > > instância 10g, criar um database vazio, criar as estruturas do 9i nele e > > trazer os dados do bd original : criar a estrutura seria um export com > > ROWS=N CONSTRAINTS=N INDEXES=N (isso ocuparia uns poucos Mbs, um export > sem > > dados é bem pequeno), e depois ir trazendo os dados (via INSERT /*+ > APPEND > > */ into tabela select * from tab...@dblinkparao9i , pequenos exports > > feitos a partir do 10g conectando no 9i via dblink, E quando os dados > > estarem ok aí vc executa um script que crie os índices em parallel e > > nologging e crie as constraints SEM validar os dados (que vc já sabe que > > estão bons) - via de regra essa opção é bem rápida, em especial se a sua > > rede e o I/O são bons, vc pod ter várias sessões trazendo dados do 9i ao > > mesmo tempo... Pra te ajudar a extrair os scripts de criação de > estruturas, > > índices e constraints vc pode usar o freeware DDL Wizard em > > http://ddlwizard.com/ . E é claro, ainda sem trafegar grandes arqs, vc > Não > > vai deixar de mensurar as outras possibilidades já citadas na thread por > > ouros colegas, como voltar um backup do RMAN no novo servidor (ele tem > > comandos para fazer o upgrade dos arqs), se for em fita e a fita puder > ser > > atachada no novo server Se nenhuma das duas outras possibilidades for > > viável, aí caímos na necessidade de se Transferir os arquivos do 9i pro > 10g > > e lá fazer o upgrade/conversão deles, via de regra isso deve ser um pouco > > mais demorado... > > > > O resumo da ópera é , então, é : no SEU ambiente, teste quanto tempo leva > > (sob condições ótimas, com o mínimo de usuários usando, com Parallel DML > > ativo, com db_file_multiblock_read_count no talo máximo, etc) quanto > tempo > > leva um INSERT /*+ APPEND */ via dblink, quanto tempo leva o restore dos > > maiores arqs e quanto tempo leva a transferência de arqs via rede (o > > upgrade/conversão é rapidinho) , que aí vc terá condição de dizer qual é > o > > melhor em tempo ... > > > > É claro, vc TEM que dar uma gordurinha na sua estimativa total clause > > ativada seja qual for o método (pois no caso de INSERT vc terá que > rebuildar > > os índices, no caso de conversão de datafiles normalmente após o STARTUP > > UPGRADE vc tem que recriar parte do dicionário/catálogo, recompilar objs > > inválidos, E no seu caso sendo 32 -> 64 bits a conversão vai ter que > > recompilar PL/SQLs)... Blz ? > > > > []s > > > > Chiappa > > > > > > --- Em oracle_br@yahoogrupos.com.br , > > "Raul Francisco Costa F. de Andrade, DBA" escreveu > > > > > > > > Grande Chiappa!!! Mais uma vez obrigado pelo interesse em > > responder/ajudar. > > > > > > Então os dados que não falei: > > > São no mesmo SO, porém em servidores diferentes, e ainda no 9i está em > > > estrutura de FS e na 10G vai para RAC com ASM. > > > Ah também vão de 32 para 64 bits. > > > > > > Att. > > > > > > Raul > > > > > > Em 8 de abril de 2010 14:21, José Laurindo escreveu: > > > > > > > > > > > > > > > > > Bem, vc não dá os detalhes cruciais (ie, se é migração pro mesmo > > servidor > > > > ou pra um outro, os Sistemas Operacionais exatos envolvidos e > > > > características de hardware se forem servers diferentes), mas de modo > > geral > > > > : > > > > > > > > a) se for no mesmo servidor E no mesmo SO/etc, sem dúvida a maneira > > mais > > > > fácil é vc fazer a migração (ie, a Conversão) desse banco de dados > pra > > 10g > > > > (só lembrando, a definição de "banco de dados" é que ele é a soma dos > > > > ARQUIVOS, como datafiles, controlfiles, redo files, etc, e a > Instância > > são > > > > os binários, fazendo a Instância ler os arqs vc tem um banco Aberto). > O > > > > procedimento é relativamente simples, vc instala os binários 10g, > > starta a > > > > instância 10g e aí pede para ela ler os arquivos 9i, convertendo-os > > para o > > > > formato 10g via STARTUP MIGRATE . Consulte no metalink a nota > metalink > > > > 466181.1 "10g Upgrade Companion", que ela dá os detalhes todos > > > > > > > > b) se for de um server pra outro a´pode haver variações , dependendo > se > > o > > > > So muda, se a qruitetura (32/64 bits) muda... Se for isso, passa os > > dets,
Re: [oracle_br] Re: Migração de base de dados gran de
Vai lá então. < export > 1.> primeiro voce cria um arquivo de pipe $ mknod pipe p 2. depois voce cria um arquivo parfile para chamar do export (se quiser fazer um string só tambem pode) ## vi exp_dump_full.par userid='/ as sysdba' file= pipe log= dump_full.log full=y statistics=none compress=N direct=Y # 3.> Agora voce da um gzip no arquivo de pipe e aponta ele para o nome que voce quer gerar seu dump. $ gzip < pipe > exp_dump_full.dmp.gz & 4.> execute o commando de export apontando para o arquivo de parametro que voce criou. (o nohup é para não ter perigo de cair a sessão) $ nohup exp parfile=exp_dump_full.par & 5.> beleza agora voce da um tail no arquivo do nohup para assistir o log passar. $ tail -f nohup.out < fim > < import > 1.> crie o arquivo parfile para chamar o import ### vi imp_dump_full.par userid='/ as sysdba' file=pipe log=imp_full.log full=y ignore = Y statistics=none commit=y # 2.> se voce não tem crie o arquivo de pipe $ mknod pipe p 3.> descompacte seu arquivo zipado apontando para o arquivo pipe $ gunzip -c exp_dump_full.dmp.gz > pipe & 4.> execute o comando de import apontando para o arquivo de parametro que voce criou. $ nohup imp parfile=imp_dump_schemas.par & 5.> beleza agora voce da um tail no arquivo do nohup para assistir o log passar. e fim. $ tail -f nohup.out Lembre isso só funciona em ambiente Unix/Linux, talves seja possivel em Windows porem não tenho conhecimento sobre isso. Duvidas mandem um e-mail. Em 9 de abril de 2010 09:45, Raul Francisco Costa F. de Andrade, DBA < raulf...@gmail.com> escreveu: > > > Bom dia amigo!!! > > Estou interessado no script sim, por favor se puder me mandar irá me ajudar > muito. > > Att. > > Raul > > Em 8 de abril de 2010 18:39, Duilio Bruniera Junior > >escreveu: > > > > E ai bunitão da pra fazer export e import compactado com pipe isso se o > seu > > sistema operacional for um Linux ou Unix. > > voce gera o dump ja compactado. sai mais ou menos umas 7 menor que o > > tamanho > > original, se tiver interessado me da um toque eu te mando o script de > como > > fazer! > > porem o seu downtime sera maior doque se voce fizer um upgrade. > > > > > > > > Em 8 de abril de 2010 17:45, José Laurindo > > > > >escreveu: > > > > > > > > > > > Colega, se é outro equipamento, E (obviamente) deve haver comunicação > de > > > rede entre os dois, sem criar arqs intermediários grandes, uma opção > que > > > salta aos olhos em primeiro lugar é vc instalar os binários , criar uma > > > instância 10g, criar um database vazio, criar as estruturas do 9i nele > e > > > trazer os dados do bd original : criar a estrutura seria um export com > > > ROWS=N CONSTRAINTS=N INDEXES=N (isso ocuparia uns poucos Mbs, um export > > sem > > > dados é bem pequeno), e depois ir trazendo os dados (via INSERT /*+ > > APPEND > > > */ into tabela select * from tab...@dblinkparao9i , pequenos exports > > > feitos a partir do 10g conectando no 9i via dblink, E quando os dados > > > estarem ok aí vc executa um script que crie os índices em parallel e > > > nologging e crie as constraints SEM validar os dados (que vc já sabe > que > > > estão bons) - via de regra essa opção é bem rápida, em especial se a > sua > > > rede e o I/O são bons, vc pod ter várias sessões trazendo dados do 9i > ao > > > mesmo tempo... Pra te ajudar a extrair os scripts de criação de > > estruturas, > > > índices e constraints vc pode usar o freeware DDL Wizard em > > > http://ddlwizard.com/ . E é claro, ainda sem trafegar grandes arqs, vc > > Não > > > vai deixar de mensurar as outras possibilidades já citadas na thread > por > > > ouros colegas, como voltar um backup do RMAN no novo servidor (ele tem > > > comandos para fazer o upgrade dos arqs), se for em fita e a fita puder > > ser > > > atachada no novo server Se nenhuma das duas outras possibilidades > for > > > viável, aí caímos na necessidade de se Transferir os arquivos do 9i pro > > 10g > > > e lá fazer o upgrade/conversão deles, via de regra isso deve ser um > pouco > > > mais demorado... > > > > > > O resumo da ópera é , então, é : no SEU ambiente, teste quanto tempo > leva > > > (sob condições ótimas, com o mínimo de usuários usando, com Parallel > DML > > > ativo, com db_file_multiblock_read_count no talo máximo, etc) quanto > > tempo > > > leva um INSERT /*+ APPEND */ via dblink, quanto tempo leva o restore > dos > > > maiores arqs e quanto tempo leva a transferência de arqs via rede (o > > > upgrade/conversão é rapidinho) , que aí vc terá condição de dizer qual > é > > o > > > melhor em tempo ... > > > > > > É claro, vc TEM que dar uma gordurinha na sua estimativa total clause > > > ativada seja qual for o método (pois no caso de INSERT vc terá que > > rebuildar > > >
