Na medida do possível eu recomendaria que vc tentasse levantar com eles 
exatamente o que eles fazem, e quando/como fazem, de forma que CASO o efeito em 
questão seja algo decorrente de funcionalidade básica do Oracle (ie, de não 
liberar o espaço após um DELETE) E CASO não tenha como eles remodelarem isso, 
que AO MENOS vc possa se programar com o work-around....
 Por exemplo : um modelo Absurdo, mas que já vi implementado numa Aplicação 
(que gerenciava Documentos, tipo Apólices de Seguro) era que, AO INVÉS da data 
de criação ser um atributo da tabela TAB_DOCTOS que continha a coluna LOB com o 
documento, a doida de pedra da aplicação criava uma tabela para cada Semana. 
cada uma com a coluna LON necessária e os demais atributos, assim tínhamos uma 
tabela TAB_DOCTOS_JAN_S1, uma TAB_DOCTOS_JAN_S2 com as MESMAS colunas, 
TAB_DOCTOS_JAN_S3 com as MESMAS colunas, vc entendeu... Além dos Óbvios 
problemas de performance (tais como crescimento do dicionário de dados, 
exigência TOTAL de SQL Dinãmico pois contrariando toda e qquer norma de RDBMS 
não se sabe em qual tabela um dado está, JOINs imensos com uma dúzia ou mais de 
tabelas referenciadas no tal SQL dinãmico, etc, etc) , para Adicionar o modelo 
previa que quando um Documento deixasse de ser válido o registro fosse DELETADO 
da tabela onde ele estava, e quando fosse necessário inserir novamente quase 
com certeza já se passou uma semana, então ele vai ser re-inserido noutra 
tabela... É o caso TÍPICO : a informação foi deletada, o RDBMS Oracle ** 
reservou ** o espaço do DELETE para futuros INSERTs/UPDATEs, mas há uma "regra 
de negócio", uma condição lógica estabelecida FORA DO DATABASE que indica que 
NÃO haverá INSERTs ou UPDATEs : taí, tal espaço reservado é puro desperdício, 
causado por uma Modelagem questionável que não faz o que comumente é feito...
 
  []s
  
    Chiappa

Responder a