Colega, vamos tentar te dar alguns elementos mais : 1. pra variar vc Não Diz se está usando 11g ou não, e se for 11g se está usando SECURE FILES ou não : o fato porém é que além da questão da possibilidade de compactação, SECURE FILES são uma opção mais refinada/moderna de controle de espaço - entre outras coisas, não precisam de PCTVERSION declarado no LOB para controlar versionamento/percentual de reuso, por exemplo.... Então considere SERIAMENTE a possibilidade de os usar se vc tá na versão 11g....
2. é Evidente que um CLOB pode possuir *** muito mais ** dados, muito mais caracteres do que todo o resto do seu registro lógico (composto por escalares de pequeno tamanho, como DATE, NUMBER e VARCHAR2), então Totalmente Não faz sentido a comparação que vc faz , tipo "ah, tenho 300 GB de CLOB contra um número muito menor de espaço ocupado por outros dados" : o que vc tem que analisar é a QUANTIDADE DE CARACTERES armazenados versus esses 300 GB, okdoc ?? Digamos que vc tem no total duzentos e muitos GBs de informação gravados nesses LOBs, aí ocupar 300 GB em disco é Totalmente o esperado, sim ?/ Sempre há algum overhead... A questão é que no RDBMS Oracle, por questão de performance, ele NUNCA aloca/grava/usa o espaço em disco byte-a-byte : ele sempre lê/usa/grava uma quantidade fixa de kbytes cahamado BLOCO, e ao pedir espaço em disco pro SO ** nunca ** pede um bloco por vez, mas sim uma quantidade de blocos sequencias/juntinhos, o chamado EXTENT... Assim, mesmo que vc for gravar uma linha que seja de informação, ao menos um extent já terá sido alocado, yep ?? E na hora de gravar a informação em cada bloco dentro de cada extent, o comportamento normal é mesmo deixar um pouco de espaço reservado para futuros UPDATEs... E ** NUNCA ** esqueça, necessariamente o LOB não armazena Só e Apenas o dado : vc vai ter também que manter um segmento de LOB INDEX, vc vai ter estruturas de controle.... Então NUNCA gravar x bytes no LOB significa que vc gastou x bytes em discos, é x bytes + o overhead... Para comparar dados x espaço gasto (se vc não já tiver essa informação) vc pode fazer algo tipo : select sum(dbms_lob.getlength(colunalob)) from tabelaquecontémolob; e comparar contra um SELECT sum(bytes) from DBA_EXTENTS WHERE tablespace_name = nomedatablespacequesócontémLOBsque vc diz que tem.... ==> Então, ** SE ** vc já pediu um SHRINK da coluna CLOB (*** Não É *** shrink da tabela, é DA COLUNA CLOB!!) e não teve grande alteração, eu Suponho que a qunatidade de dados deve ser muito grande, justificando os 300 GB.... Se vc ainda julgar o overhead grande, vc até PODE diminuir isso alterando o porcentual de espaço reservado, o CHUNKSIZE, etc : e como isso não funciona para o passado (o que já está alocado, está alocado), vc pode considerar,depois de ter alterado os parâmetros em questão, criar uma NOVA tablespace (sempre LMT e AutoAllocate, já que vc não sabe o tamanho que o dado LOB terá) e mover os lob segments/lobindexes para ela... 3. Ainda por questão de performance, quando vc deleta os dados (sejam em LOBs ou não) o comportamento do RDBMS é ** deixar ** esse espaço ainda alocado para o mesmo segmento que os usou, pois ele "pensa" que os segmentos são dinãmicos, que brevemente o mesmo segmento que sofreu a deleção VAI sofrer novos INSERTs, e aí esse espaço VAi ser reusado, e o fato dele já estar pré-alocado acelerará EM MUITO essa entrada de dados, sim ???? E isso nem é FRAGMENTAÇÂO propriamente dita, pois esse espaço em branco, REPITO, vai SIM ser reutilizado nos próximos INSERTs, ele Absolutamente não está perdido, não é impossível de ser usado, como ocorre na fragmentação REAL, okdoc ?? O shrink de lob e a movimentação (principalmente esta última) vão ser efetivos também neste caso de reuso de espaço deletado, se for o caso : leia http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:7246820117571 (é uma thread longa mas Absolutamente informativa e importante), http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:3084920323218 , http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:3998444100346949788 e http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:3679447698936 para refs e exemplos... []s Chiappa
