Menu de navegação

[guilhermeParticipante]

Olá pessoal,
Gostaria de saber se há alguma maneira rápida e fácil de reorganizar os datafiles (oracle 10g e 11g)?
Por exemplo: Foi criado um schemas com várias tabelas e dados, após determinado tempo, visto que não seria mais necessário/utilizado, este schema foi dropado… Acredito que tenha criado diversas fragmentação nos datafiles…
É possível reorganizar isso??

Pesquisei e verifiquei a possibilidade de utilizar a opção shrink, porém teria que mover cada tabela ou até mesmo recriar o datafile. Teria alguma alternativa mais simples?

Meu objetivo é “reorganizar” a base, trazendo economia de disco…

Valeu!!

[Nelson AnchiteParticipante]

Talvez esses links possam te ajudar.

http://imasters.com.br/artigo/3194/oracle/metodos-de-movimentacao-de-datafiles
http://eduardolegatti.blogspot.com.br/2008/06/reorganizando-o-tablespace.html

[guilhermeParticipante]

Nelson
Obrigado, porém precisava de alguma alternativa mais fácil, pois a base possui mais de 2000 tabelas, ficando complicado “alterar” uma a uma manualmente…

[José Laurindo ChiappaModerador]

Bom, primeiro FRAGMENTAÇÃO propriamente dita (ie, espaço que nunca pode ser reusado após remoção dos dados de segmentos por causa de tamanhos de extents incompatíveis) acontece APENAS e TÃO SOMENTE com tablespaces que não usem gerenciamento automático de extent size : como isso é o padrão (junto com tablespaces LMT) desde muito tempo, eu ENTENDO que não é isso o seu caso, vou responder com isso em mente…
Segundo, ** Não EXISTE ** DROP SCHEMA no RDBMS Oracle – SE com isso vc quis dizer que fez um DROP USER nomedoowner CASCADE; (ou mesmo um DROP TABLE nomedatatabela; para cada tabela/segmento do schema que não quer mais), aí vc NECESSARIAMENTE dropou os objetos TODOS, e com isso liberou AUTOMATICAMENTE o espaço TODINHO que os segmentos TODOS do owner dropado ocupavam dentro dos datafiles, right ?? Nesse cenário, se o espaço liberado vai continuar registrado nas mesmas tablespaces que ocupavam antes, vc NÃO PRECISA FAZER NADINHA DE NADA , o espaço livre na tablespace vai SIM ser Automaticamente reusado pelos novos DMLs dos novos objetos dos outros schemas que ocupam/ocuparão a tablespace em questão.

Algumas possíveis exceções para este cenário, que aí sim implicariam em ações necessárias :

a. vc necessita que o espaço livre nesses datafiles seja devolvido ao sistema operacional, para ser usado em OUTRAs tablespaces/datafiles no futuro (as tablespaces que continham os objetos originais não vai ser mais usada, digamos) : pra isso vc tem que diminuir o tamanho dos datafiles, e aí ** SIM ** vêm a baila a POSIÇÃO dos extents de cada segmento, pois o SHRINK de um datafile só pode ser feito até o bloco imediatamente superior ao último bloco em uso, se por azar existem trocentos blocos mais no começo do datafile sem uso, o SHRINK ** não vai ** permitir a diminuição máxima possível do datafile para no futuro embora vc fale de drop, se na verdade vc usou um DELETE para as tabelas se ao invés do DROP em uso alocado que quando vc dropou o schema vc Não sei se seria ** FRAGMENTAÇÃO ** a expressão correta, já que Fragmentação normalmente se refere ao espaço que ** nunca mais ** poderá ser reusado (digamos, o espaço está formatado em extents de x kbytes e os objetos estão pedindo por extents de y kbytes, sendo y não-múltiplo de x)… Nesse caso a ação necessária vai ser MOVER os extents/blocos dos segmentos mais para o início do datafile, via MOVE, DBMS_REDEFINE, ou outros : https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:54178027703899 e https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:7149039425561 falam a respeito

b. embora vc fale em DROP, na verdade vc fez um DELETE nas tabelas todas do schema (ou talvez um TRUNCATE com opção de REUSE STORAGE, que não libera completamente os extents que estavam em uso) : com certeza nesse caso o espaço CONTINUA alocado, aí 9se vc tem 100% de certeza que o espaço NUNCA MAIS vai ser reusado, que os objetos deletados nunca mais vão receber novos dados) aí a ação seria um shrink ou um truncate sem reuse

c. vc vaiz fazer muitos INSERTs em APPEND-MODE nalgum dos objetos dessa tabelspace, e o high-water mark está ultra-alto porque por azar os objetos dropados estavam bem no começo do datafile : aí a ação é mover/reordenas os blocos/extents remanecentes, de modo que eles passem a ocupar as porcões iniciais do datafile

Então, o resumo da ópera é : SE vc fez drop mesmo E os novos DMLs (normais) vão acontecer na mesma tablespace onde estavam os objetos dropados, NADA A FAZER, o espaço vai ser usado automagicamente, e SE não é isso, veja lá em qual das alternativas citadas vc cai, que se for preciso a gente te dá sintaxes e dicas para a Ação exigida….

[]s

Chiappa

[guilhermeParticipante]

@jlchiappa

Quando relatei ao fato de dropar o schema, me referi exatamente ao comando DROP USER nomeowner CASCADE. Na verdade acredito que o espaço será usado em um determinado tempo, porém, devido ao schema criado, foram adicionados demasiados datafiles para que comportassem os dados. A partir da deleção deste schema, sobraram muitos espaços, apesar do datafile ter ficado com tamanho de 4G (seu tamanho limite). A grande questão que eu gostaria de solucionar é reorganizar os dados de forma que este datafile (de 4G), diminua até o damanho real de dados presentes nele.
A solução mais fácil e rápida (eu acredito) seria criar outra base e realizar um import com datapump. O que acha? Acredito que com este procedimento, teríamos exatamente o tamanho real dos datafiles…

Muito obrigado!
Abs

[José Laurindo ChiappaModerador]

Ah sim : como eu disse, vc TEM uma necessidade REAL de diminuir os datafiles ? Ou seja, em primeiro lugar é é verdade que os espaços em branco somam um GRANDE, SIGNIFICATIVO volume ??
Se sim, adicionalmente SAIBA que os outros objetos que estavam na mesma tablespace vão sofrer DMLs (e portanto vão ter que usar o espaço que ficou em branco) estão na MESMA TABLESPACE que está com esses brancos, aí não faz o MENOR SENTIDO vc fazer o shrink dos datafiles e daqui a pouco ter que os aumentar, sim ??? Vc não ganha ABSOLUTAMENTE NADA fazendo isso nesse cenário, o espaço em branco VAI ser automagicamente REUSADo pelos outros objetos se a tablespace for a mesma, ** E ** (importante!!) a presença desses espaços em branco NÃO VAI INFLUENCIAR EM NADA a performance, sim sim sim ?????? Por isso que eu disse que nesse cenário vc ABSOLUTAMENTE NÃO TEM “fragmentação”, pois NEM o espaço tá perdido e NEM a presença do espaço em branco implica em qquer coisa para performance…

Já SE vc precisa devolver o espaço de volta ao SO (para poder ser usado em OUTRA tablespace, digamos), OU talvez se os segmentos que sobraram NÃO VÃO, com 100% de certeza absoluta, sofrer mais DMLs (e portanto esse espaço em branco NUNCA mais vai ser necessário/vai ser reusado), aí SIM vc tem que “migrar”/mover os blocos para o início dos datafiles, depois permitindo o SHRINK, ok ? Que fique CLARO, isso é uma Exceção, que só vai ser necessária nesse caso não-comum, que vc TEM certeza que o espaço não vai ser reusado…
Realmente vc poderia, sim, salvar os dados (num export via datapump, numa outra tabela via copy, qquer meio), dropar tudo, criar vazio e trazer os dados de volta, mas IMHO isso **** não é ****, de jeito nenhum, o mais prático : se vc suporta indisponibilidade, imho o mais prático é vc criar uma nova tablespace (usando a opção de AUTOEXTEND, se vc não sabe exatamente o espaço que os dados que sobraram vão ocupar) e aí MOVER as tabelas pra nova tablespace/fazer REBUILD dos índices pra nova tablespace, e depois sim vc dropa a tablespace original que estava com brancos….

[]s

Chiappa

[Autor]

Posts