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
