Discussion :

[cquilgars]

Bonjour à tous,

Le contexte :
- Oracle 9i
- OS : solaris 8
- Soit une table MaTable partitionnée (45 partitions)
- Toutes les partitions sont sous-partitionnées (4 sous-partitions)
- Chaque partition (et ses sous-partitions) sont positionnés dans un tablespace spécifique
- Nous avons donc 45 tablespaces de données d'une taille de ~ 1 Go (TBS_DATA_P1 à TBS_DATA_P45)
- Cette même table possèdent aussi des indexes (eux-mêmes partitionnés et sous-partitionnés).
- Nous avons donc 45 tablespaces d'indexes d'une taille de ~400Mo (TBS_IND_P1 à TBS_IND_P45)
- Les 45 tablespaces des données sont répartis (par rotation) sur 10 axes disques /data01 à /data10
- Les 45 tablespaces des indexes sont répartis (par rotation) sur 10 axes disques /index01 à /index10

L'objectif :
Je désire reorganiser le plan de nommage de l'occupation disque pour obtenir un unique axe dédié aux 45 tablespaces de données et un second dédié aux 45 tablespaces d'indexes.

Après avoir consulter la documentation et quelques discussions, je viens vers vous pour connaitre votre avis ou conseil...

J'envisage la chose suivante :

1. Allocation d'un espace temporaire de 50 Go
2. Déplacement des datafiles des tables données dans cette espace temporaire
3. L'équipe technique transforme le plan de nommage /data01 à /data10 en /datauniq
4. Déplacement des datafiles de l'espace temporaire vers /datauniq
5. Même combat pour les tablespaces d'indexes

J'envisage le déplacement des datafiles de la facon suivante :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
-- On s'assure qu'aucune transaction n'est possible le temps de manip
-- Mise hors tension du tablespace
ALTER TABLESPACE <TABLESPACE> OFFLINE NORMAL;
 
-- Deplacement physique des datafiles du tablespace <TABLESPACE> sous l'OS
mv <SOURCE> <CIBLE>
 
-- Deplacement logique des datafiles du tablespace <TABLESPACE>
ALTER DATABASE RENAME FILE '<SOURCE>' TO  '<CIBLE>';
 
-- Mise en ligne du tablespace <TABLESPACE>  
ALTER TABLESPACE <TABLESPACE> ONLINE;

La cible étant une industrialisation du process sur une base en production (600 Go data + indexes), je veux user de prudence en vous consultant sur le sujet...
J'ouvre donc la discussion de manière très ouverte (aware comme dirait l'autre)

• Est-ce une bonne solution ?
• Dois-je préférer reconstruire mes indexes ? Malgré le temps que cela prendra ...
• Avez-vous une meilleure solution ?

Dans tous les cas, je vous remercie d'avance de votre intérêt à ma cause !!!

Christophe

[orafrance]

si le but c'est juste de mettre les datafiles sur un axe du SAN alors ça parait correcte.

[cquilgars]

Bonjour Fre_D,

Tout d'abord merci pour ton intérêt...

si le but c'est juste de mettre les datafiles sur un axe du SAN alors ça parait correcte.

Dois-je lire entre les lignes que ce serait l'occasion de faire une reorganisation des tables elles-mêmes ?

• Changer le initial extend
• Changer le next extend
• Réaliser un rebuild des indexes
• ... ???

Pour les 2 premiers points, la seule solution est de supprimer et recréer la table ??

As-tu des conseils à me donner ? J'ai quelques idées mais je n'ai pas un plan d'actions véritablement construit.

• Par exemple, j'ai dénombré le nombre d'extends (Mes TBS sont en LOCAL MANAGEMENT UNIFORM MANUAL). Il est relativement élevé (plusieurs centaines par sous-partition) : il faudrait augmenter le initial maintenant que je connais la dynamique volumétrique de mes données...
  Est-ce vraiment un paramètre majeur ?
• Les tables partitionnées ne subissent pas de DELETE OU UPDATE. Seulement du TRUNCATE PARTITION voir SUBPARTITION et INSERT (via SQL*Loader). Faut-il augmenter le taux d'occupation du block ? (En l'occurrence, je ne me souviens du paramètre ...) Est-ce que cela à un sens en LOCAL MANAGEMENT UNIFORM ? Je crois que je confonds bcp de notion ..

Est-ce que toutes ces questions t'inspirent des conseils ou remarques à me prodiguer ?

[orafrance]

Dois-je lire entre les lignes que ce serait l'occasion de faire une reorganisation des tables elles-mêmes ?

• Changer le initial extend
• Changer le next extend
• Réaliser un rebuild des indexes
• ... ???

Je n'avais pas suggérer un tel travail qui évidemment est d'une toute autre ampleur, mais c'est sûr que ça ne ferait probablement pas de mal

Pour les 2 premiers points, la seule solution est de supprimer et recréer la table ??

Oui

As-tu des conseils à me donner ? J'ai quelques idées mais je n'ai pas un plan d'actions véritablement construit.

• Par exemple, j'ai dénombré le nombre d'extends (Mes TBS sont en LOCAL MANAGEMENT UNIFORM MANUAL). Il est relativement élevé (plusieurs centaines par sous-partition) : il faudrait augmenter le initial maintenant que je connais la dynamique volumétrique de mes données...
  Est-ce vraiment un paramètre majeur ?
  

• attention, un initial trop élevé génère des problèmes d'espace disque, en effet, chacune des partitions créées occupera la place du INITIAL se qui peut vite s'avérer énorme
  
  Et sinon, c'est surtout le NEXT qui compte mais pourquoi ne pas prendre les paramètres du tablespace ?
  
  

• Les tables partitionnées ne subissent pas de DELETE OU UPDATE. Seulement du TRUNCATE PARTITION voir SUBPARTITION et INSERT (via SQL*Loader). Faut-il augmenter le taux d'occupation du block ? (En l'occurrence, je ne me souviens du paramètre ...) Est-ce que cela à un sens en LOCAL MANAGEMENT UNIFORM ? Je crois que je confonds bcp de notion ..

[cquilgars]

Et sinon, c'est surtout le NEXT qui compte mais pourquoi ne pas prendre les paramètres du tablespace ?

C'est actuellement le cas pour toutes mes tables partitionnées et sous-partitionnées...

Dans ce cas, une compression de la partition quand elle est pleine pourrait être très profitable tant en espace disque qu'en perf

Ahhh Alors là tu m'intéresses... Comment cela une compression peut-elle améliorer l'accès aux données ? ....

Est-ce que tu as pensé au parallélisme sur ta table et ta base pour attaquer tes partitions... en parallèle ?

C'est vrai : cela est peut-être le bon moment... C'est une idée que j'ai mis au fond d'un tiroir... Est-ce que son activation implique une suppression/création de la dite table ?

Merci encore pour ces remarques...

[cquilgars]

Pour tout lecteur de cette discussion, je suis en cours de lecture à cette URL qui me semble une bonne introduction au sujet (Fred_D un avis ???)...
http://www.oracle.com/technology/ora...tech_data.html

[orafrance]

Ahhh Alors là tu m'intéresses... Comment cela une compression peut-elle améliorer l'accès aux données ? ....

Blocs moins chargé donc moins de blocs à ramener donc moins d'I/O donc meilleur perf

Est-ce que son activation implique une suppression/création de la dite table ?

non