valeu Chiappa... é o 8i EE, vou fazer isto então (Alter table nnn move tablespace...).
sds Gibon ----- Original Message ----- From: jlchiappa To: oracle_br@yahoogrupos.com.br Sent: Friday, July 28, 2006 4:29 PM Subject: [oracle_br] Re: Parâmetros de Storage x Imp Colega, "inclusão de dados" não tem NADA a ver com params de storage, storage só entra em consideração quando vc cria o objeto ou o move/rebuilda - sim, se vc quiser vc pode dropar o objeto, CRIÁ-LO com as opções que quiser de storage, e depois trazer os dados via imp, só especificando o IGNORE=Y, sim - UMA VEZ QUE ele foi criado com o storage que vc quer, vc pode incluir dados (ie, fazer INSERT) como quiser, com o que quiser, que os params de storage serão mantidos.. É claro, SE o seu banco, que vc não diz a versão, permite (as versões mais recentes permitem) vc pode simplesmente ao invés de dropar , RECONSTRUIR os objetos, aí os dados que já estão lá serão mantidos, isso se faz com ALTER TABLE nnn MOVE TABLESPACE nomedatablespace STORAGE(INITIAL initdesejado NEXT nextdesejado) .... , e/ou ALTER INDEX nnn REBUILD ... pros índices... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Fábio Gibon - Comex System <[EMAIL PROTECTED]> escreveu > > valeu Chiappa, > quanto ao último item, realmente me expressei mal, me referia a schema e não a banco. Mas no caso de eu NÃO desejar que o parâmetro seja o do .dmp, eu tenho que criar o objeto (table) primeiro e depois importar com um ignore=y ? ou a inclusão dos dados não pode ser via imp ? > > sds > Fábio Gibon > ----- Original Message ----- > From: jlchiappa > To: oracle_br@yahoogrupos.com.br > Sent: Friday, July 28, 2006 3:36 PM > Subject: [oracle_br] Re: Parâmetros de Storage x Imp > > > --- Em oracle_br@yahoogrupos.com.br, Fábio Gibon - Comex System > <[EMAIL PROTECTED]> escreveu > > > > Pessoal, > > em relação a valores default de storage, eu tenho um caso > onde foi feito um exp com a opção compress=y e no imp cada table > (algumas bem grandes) ficou num único extent, isto é o normal de > ocorrer neste caso, não ? > > Sim, o compress serve EXATAMENTE pra isso, o "comprimir" aí se refere > a comprimir tudo num extent só, isso é um resquício da época em que o > número de extents tinha importância, que havia um limite pequeno para > o máximo de extents que uma tabela podia ter, láááá nas versões 7.x e > pré-históricas do tipo. > > > > > Agora uma table grande num único extent pode afetar a performance, > não é a prática recomendável, certo ? > > Num bd moderno, com tablespaces LMT, em princípio não tem ** NADA A > VER ** a quantidade de extents com a performance, seja 1 extent, seja > dez, cem - muito mais relevante é o TAMANHO do extent, se ele for > MENOR e/ou ou não-múltiplo do multiblock read size desse banco, vc > não vai aproveitar a máxima performance em casos de full scan, mas é > só, num banco OLTP, onde tipicamente é acesso keyed, isso vai ser > imperceptível.... Só num caso realmente já quase patológico, de > objeto composto de MILHARES de extents, há alguma chance de queda de > performance, e mesmo assim isso pode variar. > > > > > Qual seria o modo de eu recriar este banco (usando exp do antigo > (que agora já tem cada table num extent) e imp no novo) sem ficar com > estes extents gigantes, ou seja, usar os valores de storage default > do banco e não os que vêm no .dmp ? > > banco vc ** NÃO ** recria só com exp/imp, exp & imp criam apenas os > dados (E no caso de imp full as tablespaces), o banco em si NÃO É > criado por exp/imp. No caso em questão, porém, não faz o menor > sentido vc recriar o banco, se vc tem objetos com extent-size que não > quer, vc RECRIA os objetos em questão apenas. > > []s > > > Chiappa > > > > sds > > Fábio Gibon > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > [As partes desta mensagem que não continham texto foram removidas] -------------------------------------------------------------------------------------------------------------------------- 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