Discussion :

[Daeron]

Bonjour,
J'ai un soucis avec le tablespace SYSTEM. Malgré un flux constant et un archivage, la partie "donnée" de ma BD ne grandit pas mais l'ensemble oui.
Le coupable le tablespace SYSTEM

Ma base Oracle est est un v11.2 qui fonctionne sur du Solaris.
Dans OEM on voit pour mon tablespace SYSTEM:
30.08 : 2278 MB
31.08 : 2298 MB
02.09 : 2308 MB
chaque jour on gagne entre 10 et 20 MB.

select segment_name, segment_type, tablespace_name, (bytes/1048576) "size (MB)" from dba_segments
where tablespace_name = 'SYSTEM'
order by bytes desc

La requête nous montre qu'il s'agit de C_OBJ# les autres ne bougent pas.
C_OBJ# passe de 559MB à 567MB puis à 575MB

select table_name, tablespace_name, num_rows, blocks from dba_tables
where table_name in ( 'TAB$', 'CLU$', 'ICOL$', 'IND$', 'COL$' )
order by num_rows desc

Autre donnée : il s'agit bien de IND$ et COL$ qui changent énormément.
+700 blocs (sur 70,000 blocks soit +1%) en 3 jours.

Une idée du pourquoi ? est ce vraiment normal car les données de ma base de données restent vraiment au même niveau (ce qui rentre est compensé par l'archivage ) ?

[mnitu]

C_OBJ# est un cluster qui contient parmi autres les tables col$ et ind$ du méta dictionnaire.

[Daeron]

oui et une idée pourquoi mon dictionnaire grandirait à ce point ?
Y a t'il un manière d'y remédier ?

on a grandit en un mois de près de 1/2 Go !

[Mohamed.Houri]

oui et une idée pourquoi mon dictionnaire grandirait à ce point ?
Y a t'il un manière d'y remédier ?

on a grandit en un mois de près de 1/2 Go !

Que donne la requête suivante:

Code :

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

1
2
3
4
5
6
7
 
select owner,segment_name,segment_type  
  ,bytes/(1024*1024) size_m  
  from dba_segments  
  where tablespace_name = 'SYSTEM' 
 and    bytes/(1024*1024) > 1  
 order by size_m desc

Cela peut être du au calcul des histogrammes, à l'AUDIT, etc..

[mnitu]

Que donne la requête suivante:
...Cela peut être du au calcul des histogrammes, à l'AUDIT, etc..

Non ce n’est ni l’audit ni les histogrammes dans ce cas (des autres objets sortirais leurs têtes si c'était le cas).
Je pense que Col$ sont tous les colonnes et Ind$ tous les colonnes qui composent les indexes. Vous devez investiguer.

[Mohamed.Houri]

Non ce n’est ni l’audit ni les histogrammes dans ce cas (des autres objets sortirais leurs têtes si c'était le cas).
Je pense que Col$ sont tous les colonnes et Ind$ tous les colonnes qui composent les indexes. Vous devez investiguer.

Conseillez le vivement de nous montrer le contenu du select que j'ai proposé plus haut.En suite d'affiner sa recherche avec le select suivant

Code :

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

1
2
3
4
 
select owner,table_name  
 from dba_tables  
where cluster_name = 'C_OBJ#...?'

On aura une vue beaucoup plus claire

[pachot]

Bonjour,
Si le nombre de tables et index (TAB$ IND$) augmente aussi, alors là c'est plus facile car ce sont des objects référencés dans DBA_OBJECT où il y a une une date de CREATION et un LAST_DDL_TIME
Cordialement,
Franck.

[Daeron]

Le coupable serait les tables, en effet nous avons pas mal de scripts et autres procédures PL/SQL qui créent des tables temporaires. Je suppose que les tables sont effectivement détruites mais que le "garbage collector" n'est pas activé.

Pourriez vous m'indiquer comment trouver le mode "garbage collector" (je nomme ainsi le process qui nettoierait les tables temp. supprimées) ?

merci !

[mnitu]

L'appli est mal foutue!
Purge recyclebin.

[Daeron]

merci à tous ! on a trouvé peut être un coupable un méchant script spécifique qui fabriquait beaucoup de tables temporaires... sans les détruire !

Merci encore !