Opa, blz ? Só umas infos adicionais... => Primeiro, o funcionamento do gerenciamento de espaço nos blocos em disco pelo RDBMS Oracle é : conforme vão entrando dados na tabela, o RDBMS aloca um EXTENT (ie, um conjunto de blocos contíguos em disco, que pode ser de tamanho fixo OU variável, cfrme vc criou a tabela e a tablespace) e vai usando o espaço alocado (e usando o espaço dentro dos blocos da maneira que vc indicou com PCTFREE/PCTUSED na hora de criar a tabela OU via algoritmo próprio se vc usa a opção de gerenciamente automático), mais pra frente quando mais dados chegam e o extent cresceu ele aloca outro extent, depois outro... Quando há DELETEs (reconhecendo que comumente no futuro breve vão entrar novos dados) ao invés de devolver esse espaço que ficou em branco/não usado, o RDBMS ainda o deixa reservado, ALOCADO para a tabela - aí, quando (em brve, normalmente) chegarem os novos dados não vai ser preciso o RDBMS formatar/alocar novos blocos, ele só reusa esses que ficaram reservados, é MUITO mais rápido... OK ? A teoria explicada aí fica mais fácil de entender... A questão é que vc tem que identificar o COMPORTAMENTE DE USO das suas tabelas - afinal , FACILMENTE pode acontecer de vc encontrar uma tabela X que tem não-sei-quantos-muitosmegabytes de espaço reservado mas não usado, mas NADA IMPEDE de que ela seja uma tabela de carga, por exemplo : nesse cenário vc vai ter um trabalhinho pra desalocar o espaço reservado, aí amanhã chega uma carga de dados e a tabela CRESCE tudo de novo, vc teve um trabalho *** INÚTIL ***.... E além disso liberando o espaço que estava reservado para X, vc ainda ** forçou ** o RDBMS a formatar NOVOS blocos para recepcionar os novos dados que entraram em X, possivelmente INTERFERINDO na performance.... OU seja, vc gastou o seu tempo (que Custa dinheiro) e ainda por cima Interferiu na performance - nada bom, né ??? Então, ** ANTES ** de sair Analisando as tabelas para ver se tem espaço não-usado mas alocado (que vou indicar Brevemente mais abaixo) e sair fazendo SHRINK ou MOVE ou seja o que for feito um doido, PLEASE conheça e entenda o seu ambiente, Explique o conceito acima pro pessoal da Aplicação, para poder Receber deles as dicas de uso das tabelas.... OK ? A outra possibilidade de vc estar com espaço não-usado é extent de tamanho muito grande ou blocos com politicas de uso inadequadas (por exemplo, uma tabela que só faz sempre INSERTs por carga de dados está com espaço reservado para futuros UPDATEs via pctfree/pctused) : é estudar os conceitos de extent e storage dentro dos blocos e ver o que mais se adequa pra vc.. ==> Para Analisar se uma tabela contém espaço não-usado , vc usa a DBMS_SPACE, veja nos links de ref para alguns exemplos de uso. ==> Mecanismos : uma vez concluído que uma tabela (ou uma tablespace) pode se beneficiar de reorganização (ie, vc fez a Análise necessária, encontrou espaço não usado e vc ** SABE **, por uma regra de negócio, que NUNCA MAIS vão vir novos dados que precisem/reusem esse espaço sem uso) vc pode usar os comandos de COALESCE, SHRINK, ALTER xx DEALLOCATE UNUSED ou mover os dados (com MOVE, DBMS_REDEFINITION e similares) : além da Documentação, os links de refs falam a respeito delas. Como refs, posso indicar (ALÉM da Documentação) http://www.oracle.com/technetwork/articles/database/fragmentation-table-shrink-tips-2330997.html , https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:1388955800346448370 , https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:266215435203, https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:2929412562998 e https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:649658900346125677
[]s Chiappa
