que a partir da versao 10G, se utilizarmos LMTs, nao precisamos mais nos preocupar "tanto" com fragmentacao de dados, por que ainda ouvimos falar muito disso? Para obter essa resposta, precisamos entender melhor o que a Oracle define como fragmentacao. Segundo a nota Various Aspects of Fragmentation (Doc ID 186826.1), fragmentacao pode ocorrer dentro de Tablespaces, Tabelas Heap e Indices B-Tree, e a propria Oracle diz que existem muitos equivocos sobre os efeitos negativos que ela pode causar (ver Imagem 01). Segundo essa mesma nota, fragmentacao dentro de Tabelas Heap ocorre quando linhas sao deletadas, atualizadas ou inseridas. Bom, a verdade e que, aquilo que normalmente entende-se ainda como problemas de fragmentacao de dados, eu diria que nao sao exatamente problemas, mas sim fenomenos que ocorrem naturalmente em tabelas que sofrem muitos DMLs, e que em poucas ocasioes, representam ainda problemas aos sistemas que acessam estes objetos. Os problemas/fenomenos sao: a) Blocos vazios derivados de dados apagados (DELETEs); Os blocos vazios surgem quando linhas de uma tabela sao apagadas. Estes espacos vazios em blocos formatados dentro do segmento da tabela sao naturalmente reutilizados por futuros INSERTs "convencionais". b) Linhas encadeadas ou migradas (LEMs) derivadas de INSERTs ou UPDATEs: "Linhas migradas" sao geradas quando uma linha esta sendo atualizada (UPDATE) e os dados nao cabem mais no bloco atual em que ela esta armazenada. Neste caso, o Oracle migra a linha para outro bloco dentro do mesmo segmento, e cria uma referencia ou ponteiro para esse novo bloco dentro do bloco antigo. "Linhas encadeadas" sao geradas quando os dados a serem inseridos de uma linha nao cabem em um unico bloco e portanto ele e gravado em N blocos. Tabelas que normalmente geram LEMs: tabelas com mais de 255 colunas (Oracle quebra ela em partes) ou que possuem colunas com tipos de dados LONG, LONG RAW, BLOB ou CLOB.Quando os blocos vazios ou LEMs representam problemas? Os blocos vazios podem prejudicar a performance de operacoes de Full Table Scan (FTS), pois o Otimizador estara lendo estes blocos "desnecessariamente", o que ira gerar mais I/O e maior tempo de processamento. Se apos apagar uma grande quantidade de dados voce souber que novas linhas nao serao inseridas em um futuro proximo, recomendo neste caso, que voce execute um SHRINK na tabela (veremos mais detalhes disso adiante) visando otimizar as operacoes de FTS nela. Se foi apagada uma pequena quantidade de linhas ou se voce sabe que novas linhas serao inseridas em breve, nao se preocupe com os "buracos" (blocos vazios) na tabela, pois eles serao reutilizados naturalmente! As LEMs, por sua vez, normalmente ocasionam problemas de performance em operacoes de "Index Scan" (que realizam single block fecthes), pois no caso de linhas migradas, por exemplo, os indices continuarao referenciando o bloco antigo, e ao acessar estes dados, ao inves do Oracle ler apenas 1 bloco, ele passara a ler 2 blocos. Poucas LEMs normalmente nao representam problemas de performance consideraveis em uma tabela, porem ja tive problemas com elas em um processo diario que gera o dump full de um determinado BD que administro. Existiam