Discussion :

[mariachi]

Bonjour


J'ai des table fragmentée a plus de 10 %

j'essaye de les defragmenter via shrink compact

1 : j'ai bien des tablespace en auto extend
2 : j'ai bien acitver le row movement.
3 : j'ai pas d'index ni rien sur ma table

le shrink compact prend 1 seconde et il me dit que c'est bon


je fais ca :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
alter table MA TABLE enable row movement
alter table MA TABLE shrink SPACE compact
exec dbms_stats.gather_table_stats(MA TABLE);

et quand je fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
select 
owner,table_name,round((blocks*8),2)||'kb' "Fragmented size", 
round((num_rows*avg_row_len/1024),2)||'kb' "Actual size", 
round((blocks*8),2)-round((num_rows*avg_row_len/1024),2)||'kb',
((round((blocks*8),2)-round((num_rows*avg_row_len/1024),2))/round((blocks*8),2))*100-10 "reclaimable space %" 
from dba_tables where table_name ='Ma table'

il me dit que je peut recupérer 10 % d'espace.

j'ai changé le PCFREE de la table qui etait a 10 %. je me disais que ca venait de là.

j'ai mis le PCFREE a 2 % pour voir si la procedure prendrait du temps. mais rien n'y fait.


Dois je en déduire que ma table est optimisée niveau defrag ?

il y a t'il un problème quelque part ?


merci de m'aider

[Heaven93]

bonsoir,

10% ? elle est très bien cette table.
diminuer à 2% le PCTFREE? pourquoi? les données d'une ligne n'évoluent pas?
quelle est la problématique, réellement?
ce n'est pas un but en soi de faire qu'une base soit constituée de blocs full à 100%, car si les données évoluent vous vous exposez à d'autres problèmes : les lignes qui grossissent le feront dans d'autres blocs puisqu'elles n'auront plus de place pour le faire dans leur propre bloc. si la table est énorme et que les données n'évoluent pas, ça vaut peut-être le coup. mais si vous avez du temps, mieux vaut le passer sur le tuning des requêtes et des accès aux tables.
bonne nuit