Bonjour,
J'ai une table dans ma base Oracle 9.2 qui s'est étendue. J'ai fait un export de ma table. Je l'ai récréer avec INITIAL 500M mais lorsque je l'import elle est toujours autant fractionnée. Comment faire ?
Merci
Version imprimable
Bonjour,
J'ai une table dans ma base Oracle 9.2 qui s'est étendue. J'ai fait un export de ma table. Je l'ai récréer avec INITIAL 500M mais lorsque je l'import elle est toujours autant fractionnée. Comment faire ?
Merci
comment regardes-tu le "fractionnement" ?
Normalement, avec la 9.2, on est en LMT par défaut, non ? Donc le problème de fragmentation n'a plus lieu d'être normalement.
Après, si tu veux regrouper ta table dans des extents tous contingüs, c'est autre chose... Il faut exporter/dropper les objets/réimporter tous les objets du tablespace, ou faire un tablespace supplémentaire et faire des
alter table ... move ...
alter index ... rebuild tablespace ...
pour déplacer tes tables dans le nouveau tablespace (et tes indexes s'ils sont dans le même tablespace que tes tables...)
j'utilise cette requete :
select segment_name,tablespace_name,segment_type,extents,max_extents,bytes,owner
from sys.dba_segments
where owner != 'SYS' or ( owner = 'SYS' and segment_type = 'ROLLBACK')
order by owner,segment_Type desc, segment_name
Le problème n'est donc pas la fragmentation, mais le fait d'avoir des extents contigüs pour tes objets...
En gros, ton tablespace est comme cela en LMT
U U U U U U U U U U F F F F F
Les U pour USED...
Imaginons que tu créé une table qui prend 2 extents dans un tablespace :
U U F F F F F F F F F F F F F F F
Tu rajoutes d'autre objets :
U U U U U U F F F F F F F F F F F
Ta table s'étend (en bleu pour la table, noir pour le reste) :
U U U U U U U U U U U U F F F F F
Elle prend maintenant 6 extents. Si tu l'exportes et que tu l'efface, le LMT va mettre à Free tous les extents qui composaient cette table. Quand tu la recréé avec ton INITIAL = 500M il va reprendre autant d'extents nécessaires pour avoir les 500M. Dans notre cas, il va reprendre les 6 premiers extents de disponible. Résultat, ta table n'aura pas d'extents contigüs comme c'était le cas en DMT.
Pour avoir ta table avec tes extents contigüs, il faut faire un :
et là, ta table aura tous ses extents contigüs. Après, si tu veux réorganiser tout ton tablespace, il faut faire un alter table move de toutes tes table de ce même tablespace.Code:alter table MaTable move TablespaceQuiVaBien
Merci de vos réponses.
Pour le moment ça n'a rien changé.
Si je fais : alter table article move tbs_data, j'ai l'erreur suivante : ORA-14133: impossible de combiner ALTER TABLE MOVE avec d'autres opérations
Alors j'ai fait : alter table article move
mais lorsque je repasse ma requete je ne vois toujours pas de changement :
SEGMENT_NAME Tablespace Type Seg Ext Mext BYTES ---------- ------------- --------- ----- ------ ---------- ------
ARTICLE TBS_DATA TABLE 106 ###### 528482304
Oui, j'ai été un peu vite dans l'écriture de la commande, il manque la clause tablespace :
Par contre, si vous faites un alter table ... move tablespace ... sur le même tablespace, on revient exactement au même point que l'import où il prendra les 500M d'extents libre depuis le début du tablespace, donc il replacera la table au même endroit...Code:alter table article move tablespace nouveautablespace
Il faut donc absolument créer un nouveau tablespace vierge de tout objet pour avoir des extents contigüs.
Attention aux raccourcis quand même ;)Citation:
Envoyé par CD
La gestion LMT réduit la fragmentation mais ne peux en aucun cas l'erradique complétement ;)
Moi ce que j'aimerai c'est les clauses storages du tablespace et de la table parce que je vois mal comment on pourrait apporter un semblant de réponse sans cela :?
tablespace nouveautablespace n'est pas utile pour défragmenter ;)Citation:
Envoyé par CD
ça n'a d'intérêt que pour déplacer la table.
Oui, mais si on fait un alter table move tablespace sur toutes les tables du tablespace, ça va défragmenter le tablespace en question... Enfin on partira d'un tablespace fragmenté pour arriver à un tablespace défragmenté au final.Citation:
Envoyé par orafrance
Au regard de la requête qui est lancé, le problème n'est pas dans le tablespace mais dans la table article ;)
ou alors c'est pas la bonne requête :aie:
Attendons d'avoir toutes les infos ;)
Le tablespace et la table ont été créé depuis au moins 1 an et demi. Maintenant il y a 1 452 348 enregistrements.
Code:
2
3
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[Modération, Orafrance : Pensez à utiliser la balise [CODE] qui améliore la lisibilité, merci]
8O le NEXT de la table est plus grand que le NEXT du tablespace :?
Pourquoi ne pas utiliser les mêmes clause storage et surtout pourquoi ne pas créer un tablespace LMT ?
http://oracle.developpez.com/guide/a...e/tablespaces/
La base était à l'origine en 7.3.4 puis 8i puis pour le moment en 9.2
Nous n'avons pas suivi les nouvelles fonctionnalités apportée par ces nouvelles versions.
Je vais essayer de mettre en place un tablespace avec l'option AUTOALLOCATE.
Comment est ce que je peux regler mon problème d'extend pour le moment ?
j'ai créer un nouveau tablespace
CREATE TABLESPACE TBS_DATA03 DATAFILE
'F:\BASE\TBS_data03.dbf' SIZE 700M EXTENT MANAGEMENT LOCAL AUTOALLOCATE;
et j'ai fait : alter table article move tablespace tbs_data03;
lorsque je repasse ma requete pour les extends, j'ai toujours le même nombre d'extends.
Et en quoi le nombre d'extents est problèmatique ?
Je pensai que cela pouvez jouer sur les performances d'accès aux données.
si tu avais lu le lien que je t'ai laissé, tu aurais pu lire ceci : http://oracle.developpez.com/guide/a...lespaces/#L5.1 ;)
J'avais pas encore pris le temps de le lire jusqu'au bout :oops: . Merci