Boa tarde! Chiappa, segue as respostas dos seus questionamentos/duvidas
"vc TEM CERTEZA que as tabelas que "seguram" o espaço que hoje está em branco/não está em uso mas reservado ** REALMENTE ** nunca mais vão sofrer carga de dados ???" => Sim, as tabelas irão sofrer carga novamente, mas tenho que fazer uma rotina que apague os dados mais antigos, a cada dia. Então hoje é dia 28/05/2015, a rotina vai fazer o backup do dia 28/05/2014 e depois vai apagar os dados do dia 28/05/2014 das tabelas, com este delete, teremos blocos que poderão ser utilizados novamente, então o crescimento dos datafiles não será como hoje, eles irão crescer de forma mais lenta. Mas antes de fazer isso preciso devolver o espaço reservado para o S.O. "se depois de todo o trabalho acontecer de vc não sabia que semana que vem vai haver uma carga grande de dados aí as tabelas crescem tudo de novo, foi INÚTIL o seu trabalho todo ... Yep ??" => O crescimento é gradativo, em média uns 2GB por dia, não temos cargas muito grande nestas tabelas, então não vai crescer 100GB de um dia para outro, por exemplo. " vc quer/precisa que esse espaço hoje sem uso mas reservado REALMENTE seja devolvido ao Sistema Operacional (para ser usado alhures) OU simplesmente ter esse espaço constando na DBA_FREE_SPACE dessa mesma tablespace (e portanto podendo ser reusado por qquer Segmento dessa tablespace) ??" Sim, realmente eu preciso que o espaço reservado volte para o sistema operacional, para que possa ser utilizado por outros segmentos. Eu preciso realmente diminuir o tamanho dos datafiles. " iirc vc tá usando a Standard Edition, onde não há Parallel SQL, então esse INSERT não poderá ser paralelizado E a busca dos dados a serem salvos/inseridos nas tabs de trabalho também não poderá ser paralelizado: vc TEM que usar então INSERT em APPEND-MODE, BULK ARRAY, Paralelismo DIY e etc onde possível " => Eu estou utilizando insert em APPEND-MODE para inserir os dados nas novas tabelas. "Muito certamente TEM que ser TRUNCATE, pois como dito anteriormente com o DROP vc PERDE as contsraints, permissões/grants que haviam sido feitas anteriormente, perde os objetos secundários da tabela (como ÍNDICES).... OK ? E muito provavelmente vc terá que DESABILITAR temporariamente as FKs relacionadas, pois o RDBMS não deixa vc fazer TRUNCATE com FKs habilitadas. Este último ponto é importante : enquanto vc estiver com as FKs desabilitadas, ÓBVIO que vc não vai deixar as aplicações fazerem DMLs, pois podem entrar dados inválidos : pra isso vc vai ter que aplicar manualmente um LOCK nas tabelas e/ou temporariamente revokar os privs de DMLs.. Tecnicamente pra consulta tudo bem (já que a ESTRUTURA das tabelas, ie, colunas/datatypes, não está mudando) - só o que vai acontecer é que os dados que foram Consultados antes do TRUNCATE ** obviamente ** não mais estarão presentes depois dele para serem localizados e alterados, mas a Query que estiver rodando não vai ter problemas..." => Vou fazer um TRUNCATE nas tabelas antigas e depois um delete , já que estou recriando tudo novamente nas tabelas novas(PK/FK/INDEX), que estão na nova tablespace e a intenção não é colocar estas tabelas de volta na mesma tablespace aonde estão as outra 62 tabelas. Pois se for necessário realizar esta manobra novamente, só serão afetados as tabelas que estarão separadas das demais, sem a necessidade de move nas outras 62 tabelas. "Aqui ficou uma dúvida : essas 62 tabelas (que são pequenas, pelo que entendi) não precisam sofrer qquer tipo de DELETE, correto ? Se sim OK, em sendo necessário o RESIZE do datafile vc as vai mover.... Observo apenas que, se for Enterprise Edition, o database já permite que essa movimentação seja feita ONLINE, mas se for Standard Edition aí não.." => Isso mesmo, elas não irão sofrer qualquer alteração, o move é apenas para realizar o RESIZE do datafile. Reverente ao move das tabelas com o DBMS_REDEFINE é não possível no Standard, então minha opção fica em realizar o move OFFLINE nas tabelas envolvidas.
