Opa, no final do item 4) ficou faltando uma parte do texto , ele deveria estar :
" ... Devo dizer também que a opção de se ter uma única tablespace TB_USUARIOS (digamos) também Poderia Sim te servir, pois (SE criada corretamente, com extent size correto, etc) após o drop de um usuário e seus objetos , a recriação de um novo na mesma tablespace VAI SIM reusar o espaço anteriormente em uso, sim... " []s Chiappa --- Em oracle_br@yahoogrupos.com.br, José Laurindo <jlchia...@...> escreveu > > Colega, ao que parece ninguém te respondeu, vou tentar o fazer : de cara > porém tenho que avisar que é ** Impossível ** te dar um passo-a-passo exato e > preciso, não há tempo nem espaço disponíveis, e nem é esse o foco do Grupo - > sendo assim, vou dar DICAS, diretivas, que depois vc ** TEM QUE ** > complementar estudando os manuais e bons livros de referência, pra poder > entender do que estou falando...Lembro também que a esmagadora maioria das > interfaces gráficas Não Te Dão a informação completa, elas 'escondem' parte > da info, então vou nesta resposta sempre sugerir a Consulta nas fontes Reais > de informação (tabelas/views internas do Sistema) onde cabível. Segue : > > 1) extents : o conceito fundamental é que quando o bd Oracle precisa alocar > espaço, ele aloca ** não ** em bytes, nem em blocos, mas sim aloca um > 'pedação' de blocos contíguos em disco, o chamado EXTENT - o tamanho de cada > extent é definido na criação dos objetos (tabelas/índices/o que for), se não > especificado usa o default da tablespace. Isso n > os leva à distorções do tipo, tabela minúscula com extent size enorme, esse > espaço VAI ser alocado e o RESIZE *** Não tem como *** diminuir, não tem como > quebrar um extent, ele tem o tamanho que tem...Num caso desses, só recriando > o objeto, veja 3) para opções. Consulte a DBA_EXTENTS/DBA_SEGMENTS para as > tablespaces em questão, veja se os tamanhos são razoáveis em face dos dados > > 2) tablespace LMT ou DMT : derivado do fato acima, quando o espaço é liberado > é o EXTENT que é marcado como livre, e quem precisar de espaço adicional vai > tentar usar extents também - sendo assim, Óbvio, se vc tiver um espaço livre > de X bytes em extents liberados ** mas ** o objeto sendo aumentado requer Y > bytes como tamanho de extent, esse extent livre Não Vai Ser re-usado... Se vc > estiver usando as (horrivelmente velhas e não-recomendadas) tablespaces > gerenciadas pro Dicionário (DMT) vc pode ter valores os mais esdrúxulos e > DIFERENTES para tamanhos de extents, podendo levar ao cenário descrito. Já SE > vc estiver usando as modernas e Recomendadas tablespaces gerenciadas por > bitmap local (LMT), com elas OU vc tem extents sempre iguais (usando a opção > de UNIFORM SIZE na criação) , OU vc tem extents de Poucos tamanhos diferentes > e sempre múltiplos entre si (usando a opção de AUTOALLOCATE/gerenciamente > automático) na criação, consulte a DBA_TABLESPACES pra ver o que vc tem > hoje... A recomendação quanto a isso é, SE vc sabe exatamente o tamanho que > vai usar, avalie a hipótese de tablespace LMT uniform size, se não > souber/tiver como saber (ex, são dados 'aleatórios', enviados pelos usuários, > digamos), avalie AUTOALLOCATE > > 3) sim, é ** péssimo ** deixar se criar o que for que não seja interno na > tablespace SYSTEM, vc terá que corrigir isso re-criando os objetos, mas usar > o exp como vc pensa é TOTALMENTE DESNECESSÁRIO : gerar um dump file tem > sentido se vc quer recriar o objeto em OUTRO DATABASE, sendo no mesmo banco > vc tem Diversas outras opções, como o comando ALTER TABLE nnn MOVE/ALTER > INDEX nn REBUILD, ou o DBMS_REDEFINE, ou o CREATE nn AS (select dos dados > atuais), cheque as docs pra sintaxes e restrições > > 4) absolutamente ****** NÃO É VERDADE ****** que após a exclusão de usuários > (supondo DROP USER, com a opção PURGE se for bd 10g ou superior) deixe espaço > não usável : SENDO o extent de tamanho correto, o espaço dentro da tablespace > vai ser SIM re-usado.... > Outra coisa que pode acontecer no cenário que vc descreve (de cada usuário > ter a sua tablespace) é que, quando vc dropa o usuário, a tablespace que ele > usava NÃO É DROPADA automaticamente, o espaço em disco continua sendo > alocado, vc TEM que fazer a Remoção dos datafiles, normalmente com o comando > DROP TABLESPACE nnn INCLUDING DATAFILES; , cheque o manual de SQL Reference > para detalhes. > Devo dizer também que a opção de se ter uma única tablespace TB_USUARIOS > (digamos) > > 5) uma tablespace tempo pra cada usuário **** NÃO FAZ O MENOR SENTIDO ****, > pois o comportamento Natural delas é Automaticamente liberar o espaço quando > do COMMIT, o reuso é Automático e Natural : as views V$SORT_SEGMENT e > V$SORT_USAGE mostram o consumo/liberação... > > 6) SE vc tem espaço limitado em disco, as opções de Compactação vão ser > Cruciais, e na sua maioria elas dependem da VERSÃO DE BANCO, que vc pra > variar não cita : cheque as docs da sua versão > > 7) controle de espaço dentro dos blocos : uma vez alocado o extent, cada > registro vai sendo gravado nos blocos do extent, começando pelo primeiro > bloco, depois qundo esse enche o segundo, etc - além disso vc tem como > controlar o espaço reservado em cada bloco para futuros UPDATEs, numa > situação de espaço ultra-limitado é Crítico que isso esteja ajustado > corretamente, veja as opções de PCTFREE/PCTUSED e STORAGE para a > criação/recriação de objetos. > > 8) Finalmente, embora como disse acima não é aplicável no seu caso afaik o > exp, só respondendo : é *** IMPOSSÍVEL *** se estimar com alguma exatidão o > tamanho da importação a partir do tamanho do dump file, pelo seguinte : o > dump file (pode comprovar abrindo-o num editor binário) é composto por > INSTRUÇÕES, tipo : > > INSERT INTO minhatabeladeteste values(1, 'Linha1'); > > a linha acima ocupou 52 bytes ** mas ** os dados '1' ocuparia 1 byte > (digamos) e 'Linha 1' ocuparia 8, no total coisa de dez bytes contra os 52 > da instrução... Ou ainda é FÁCIL termos situação onde os dados ocupam MAIS > que o texto do DML contido no dump file... Em resumo, **** NÃO DÁ *** pra > estimar a partir do tamanho do dump file, yes ??? A Única maneira mais > confiável de se estimar isso é importar um pedaço apenas dos dados e > extrapolar, OU então totalizar o tamanho dos dados na Origem, o espaço > necessário no Destino deve ser similar - não digo IDÊNTICO porque como disse > acima há opções de Compactação, de uso de espaço nos blocos, etc, que PODEM > estar em efeito num banco e não em outro... > > []s > > Chiappa > > > --- Em oracle_br@yahoogrupos.com.br, "Israel Borges" <israelborgess@> escreveu > > > > Bom dia amigos, vou explicar a minha situação, e ja lhes digo que tenho > > muito pouco conhecimento em Oracle, por isso estou aqui pedindo a ajuda de > > vocês. > > > > Assumi a empresa a um mês, e tenho um servidor suse com o oracle 10g > > instalado e funcionando. A empresa é desenvolvedora de sistemas, portanto > > possui vários usuários criados. Os usuários foram criados todos com a mesma > > tablespace temporary. Em relação a default tablespace foi criado uma e > > vários usuarios utilizam a mesma. Alguns usuários usam a tablespace em que > > o oracle útiliza para gerencia interna a SYSTEM e SYSAUX. Em suma, tenho > > dois problemas. > > 1) Com a criação e exclusão de usuários, o espaço alocado das tablespaces > > assumiram um tamanho muito grande porém com pouca utilização. Portanto > > preciso reduzir esse espaço que a tablespace assumiu. Creio que um resize > > resolveria esse meu problema, porém ai surge o problema numero 2. > > 2) Com o resize, temporariamente resolveria meu problema, se eu fosse > > continuar com o banco como está hoje. Porém, a empresa precisa duplicar > > todos os usuários, e eu não sei qual é o real espaço ocupado dos usuarios > > em cada tablespace. Portanto não posso falar que o meu disco rigigo, hoje > > não suporta esse procedimento. Para resolver o problema numero 1 em > > definitivo, pensei em criar uma tablespace dos datafile e uma tablespace > > temporary para cada usuário. Assim com as diversas criações e exclusões de > > usuários, não precisaria me preocupar com esse acumulo de espaço alocado > > sem uso novamente. > > > > PROBLEMA: No intuito de executar a resolução descrita no problema 2. Tenho > > também dúvidas de como proceder. Fiz um exp de todos os usuários do banco > > de dados. > > exp usuario/se...@database file=usuario.dmp > > usuario.dmp com o tamanho de 1,6G. > > Qual deve ser o tamanho da tablespace datafile e temporary que eu deveria > > criar para comportar esse dump? > > > > > > Bom, desculpa pelas várias duvidas e questionamentos, porém tentei > > descrever o que ja pensei sobre o assunto. Aguardo auxilio. > > > > Atenciosamente, > > > > Israel Borges. > > >
