Discussion :

[regal]

Bonjour,

Nous avons un script de retour arrière qui supprime 5 nouvelles colonnes sur notre table partitionnée dont une sur laquelle porte un index bitmap.
Sur notre serveur de développement cela prend 1h10 environ.
Sur le serveur de recette de notre client, au bout de 10 heures environ, cette suppression des colonnes n'est toujours pas terminée et s'arrête suite à l'arrêt quotidien de la base de données.

Le volume de données est plus important sur la base de notre client (à la louche le double)
Est-ce que cela pourrait expliquer la différence de temps de réponse ?
Agrandir les tablespaces tempo et/ou undo peut-il améliorer les performances ?
Quelles solutions peuvent-elles être apportées pour améliorer les temps de réponses ?

[Mohamed.Houri]

Bonjour,

Nous avons un script de retour arrière qui supprime 5 nouvelles colonnes sur notre table partitionnée dont une sur laquelle porte un index bitmap.
Sur notre serveur de développement cela prend 1h10 environ.
Sur le serveur de recette de notre client, au bout de 10 heures environ, cette suppression des colonnes n'est toujours pas terminée et s'arrête suite à l'arrêt quotidien de la base de données.

Le volume de données est plus important sur la base de notre client (à la louche le double)
Est-ce que cela pourrait expliquer la différence de temps de réponse ?
Une suppression d'une colonne est-elle plus rapide qu'une suppression des cinq colonnes en parallèle ?
Agrandir les tablespaces tempo et/ou undo peut-il améliorer les performances ?

Supprimer une colonne d’une table n’est pas une chose à prendre à la légère. De plus, si votre intention de supprimer une colonne d’une table est dictée par le désir de gagner de l’espace, cette suppression doit être alors inévitablement suivie d’une réorganisation de la table.

Je pense, comme vous avez des tables partitionnées, qu'une solution à envisager serait de faire ceci:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
mhouri.world> desc RANG_PART_TAB
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 ID                                        NOT NULL NUMBER
 MUSE_DATE                                 NOT NULL DATE
 NAME                                               VARCHAR2(10)
 
mhouri.world> alter table RANG_PART_TAB set unused column name;
 
Table altered.
 
mhouri.world> select * from user_unused_col_tabs;
 
TABLE_NAME                          COUNT                                       
------------------------------ ----------                                       
RANG_PART_TAB                           1                                       
 
mhouri.world> alter table RANG_PART_TAB move partition p1;
 
Table altered.
 
mhouri.world> alter table RANG_PART_TAB move partition p2;
 
Table altered.
 
mhouri.world> alter index ind_1 rebuild partition p1;

Et vous pouvez faire cela en parallèle partition par partition

Sinon, vous avez aussi l'option de créer une vue sur votre table qui exclue cette colonne (mais je pense que cela ne vous convient pas)

[ojo77]

comme toujours, un problème, plusieurs solutions.

De mon coté je recréerait un table avec un "create table as select" pour je recréerait les index sur cette nouvelle table pour enfin faire un "rename" de la table obtenue au final. Ça implique une indisponibilité en écriture le temps de l'opération et ça consomme somme toute de l'espace mais la table créée n'est pas fractionnée et les index sont équilibrés (surtout si vous utilisez des bitmaps index qui supportent très mal les mises à jour).

[regal]

J'ai testé la suppression d'une seule colonne, c'est aussi lent que plusieurs.
J'ai testé une désactivation des index, suite à une suggestion de notre client, cela ne modifie pas le temps de réponse du drop.
Ce drop de colonne est effectué dans une procédure de retour arrière dont le but est de remettre la table de la base dans son état antérieur à l'installation d'une évolution, uniquement si cette installation provoque une erreur (ce qui a été malheureusement le cas pour nous, voir http://www.developpez.net/forums/d11...ild-partition/)
Un ordre

Code :

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

alter table ... set unused column

ne supprime pas la colonne. Bien entendu il serait possible ensuite de retester le script d'installation mais nous préférerions remettre la base dans son état initial (et récupérer l'espace disque).
Il semble que le move des partitions ne change rien au statut de la colonne unused qui n'est pas droppé et nécessiterait donc un

Code :

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

alter table ... drop unused columns

[regal]

Il n'est pas possible de recréer la table avec un "create as select ..." nous n'avons pas l'espace - et j'ai bien peur que le temps de réponse soit encore plus long.
Reconstruire l'ensemble des index (via rebuild partition) nécessite nettement plus de temps (sur notre base de développement) que la suppression des colonnes.
Pour information nous avons 157 partitions dans la base de notre client (1 par mois depuis janvier 1999).
Et ces partitions contiennent en moyenne 8 à 9 millions de lignes entre 2000 et mi 2008 (un peu moins pour fin 1999 et 2000, peu pour début 1999 et depuis mai 2008).
Nous avons analysé les temps de réponses via la vue v_$session_longops
Pour traiter le même nombre de bloc (les partitions jusque mi 2005 sont identiques sur nos bases, notre base de développement étant une copie de leur base effectuée à cette date), le temps de réponse est environ 6 fois plus long sur leur serveur.
Le serveur est mutualisé. Le fait que d'autre traitements tournent en parallèle pourrait peut-être expliquer la différence de performance.
Peut-on jouer sur des paramètres Oracle pour améliorer le temps de traitement ?