Discussion :

[elkamaro]

Voilà plusieurs semaines que vous avez posé cette question de purge et il me semble que vous êtes toujours au point mort.

Bonjour Mohamed,

Non je ne suis pas au point mort, j'ai finaliser tous mes scripts et je les ai tester et ils sont fonctionnel, la seul chose qu'il me reste a faire, c'est les excuter pour faire une redefinition de toutes mes tables et ensuite tester mes applications dessus pour voir que deviennent les performances.

Si votre client prévoyait de faire une purge tous les 6 mois, pourquoi alors avoir attendu jusqu’à la mise en production pour commencer à envisager une solution de purge très efficace ?

Mon client n'a rien prévu depuis le debut de la base concernant une quelconque purge, ce n'est que maintenant qu'il demande a ce qu'elle soit prise en compte.
Erreur de conception au debut, je vous l'admet et je n etais pas présent non plus au debut pour le leur proposer.
Mais maintenant c'est a moi qu'on demande de trouver des solutions.

Je suppose que vous allez faire un partitionnement par date (range partition) et que vous allez considérer le critère de date qui sert à la purge comme clé de partitionnement. Très bien. Dans ce cas il vous faudra simplement supprimer les partitions que vous n’utilisez plus avec un simple:

Code :

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

1
2
 
alter table ma_nouvelle_tab_part drop partition p2010 update global indexes ;

Je ne passerai pas sans vous signaler que, comme vous avez certainement des tables liées entre elles par des clés étrangères, vous devriez d’abord ‘’disabler’’ ces contraintes d’intégrité avant de supprimer les partitions et de les ‘’ré-enabler’’ à la fin sans validation bien évidemment.

Merci pour cette précision, c'est exactement ce qui m'est arrivé et c est comme ca que j'ai resolu le probleme de suppression des partitions.

Par contre, en passant à ce nouveau schéma, vous pourriez (au conditionnel) bien aussi complètement détériorer la performance de votre application. La raison dans ce cas n’aura rien à voir avec la fragmentation des indexes basés sur le critère de date (‘’sweeper indexes’’ ou ‘smashed indexes’’ ou ‘’right hand indexes’’) mais plutôt avec le comportement des anciennes requêtes par rapport au partitionnement. Toute requête ne faisant pas appel à la clé de partitionnement fera un ''PARTITION RANGE ALL'' ce qui n’est pas du tout le but du partitionnement à savoir:

Alors le critere de mes partitions se base non sur des dates mais sur une valeur

Code :

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

PARTITION PART_2006 VALUES LESS THAN (64231324),

C'est une colonne qui est clé primaire de certaine tables mais parfois elle fait seulement partie de la clé primaire.
Effectivement, je ne maitrise pas ce qu'il va en advenir une fois partitionné, et c'est le but de ce post afin que vous m'aidiez.



Mais je t'avouerai que la méthode de paritionner pour purger et plus simple et plus rapide que celle avec des deletes (avec des deletes il me faut une vingtaine de scripts sur plus de deux/trois semaine, alors qu'avec les partitions, il me faut 3/4heures grand maximum)


il faut donc, selon tes conseils, que je regarde aussi comment réorganiser mes index ... sachant qu'on ne peut plus toucher au requetes qui les utilisent ?

[Dajon]

dbms_redefinition.copy_table_dependents() ne copie pas les contraintes système.

Je n'ai pas eu le problème:

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
28
CREATE TABLE ADA_TEST1 
(
  ID NUMBER NOT NULL 
, VAL VARCHAR2(15 BYTE) 
, UNE_DATE DATE 
, CONSTRAINT ADA_TEST1_PK PRIMARY KEY (ID) ENABLE 
) 
;
 
ALTER TABLE ADA_TEST1
ADD CONSTRAINT ADA_TEST1_CHK1 CHECK 
(UNE_DATE IS NOT NULL)
ENABLE;
 
 
select constraint_name, constraint_type, table_name, SEARCH_CONDITION from user_constraints where table_name='ADA_TEST1';
 
CONSTRAINT_NAME                CONSTRAINT_TYPE TABLE_NAME                     SEARCH_CONDITION    
------------------------------ --------------- ------------------------------ --------------------
SYS_C0045016                   C               ADA_TEST1                      "ID" IS NOT NULL    
ADA_TEST1_CHK1                 C               ADA_TEST1                      UNE_DATE IS NOT NULL
ADA_TEST1_PK                   P               ADA_TEST1                                          
 
select count(*) from USER_TAB_PARTITIONS where table_name = 'ADA_TEST1';
 
COUNT(*)               
---------------------- 
0

On a une contrainte not null ajoutée à la création et une autre ajoutée en tant que check.

J'ai ensuite exécuté le script que j'ai mis dans mon précédent message, puis

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
select constraint_name, constraint_type, table_name, SEARCH_CONDITION from user_constraints where table_name='ADA_TEST1';
 
 
CONSTRAINT_NAME                CONSTRAINT_TYPE TABLE_NAME                     SEARCH_CONDITION      
------------------------------ --------------- ------------------------------ ----------------------
SYS_C0046412                   C               ADA_TEST1                      "ID" IS NOT NULL      
ADA_TEST1_CHK1                 C               ADA_TEST1                      UNE_DATE IS NOT NULL  
ADA_TEST1_PK                   P               ADA_TEST1                                            
 
select count(*) from USER_TAB_PARTITIONS where table_name = 'ADA_TEST1';
 
COUNT(*)               
---------------------- 
1

Les contraintes sont bien toutes là. La contrainte SYS_$ a changé de nom, mais elle a bien été "copiée".

Je pense que cette différence de comportement doit venir de la version d'Oracle. Je suis en

Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options

[elkamaro]

Je pense que cette différence de comportement doit venir de la version d'Oracle. Je suis en

Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options

Bonjour Dajon,

effectivement cela change tout que tu sois en 11g
d'aprés mes recherches, redefinir une table avec des colonnes not null :
- ne fonctionne pas en 10g (ma version), on est obligé de faire des register de ces contraintes (systeme) sinon ca plante avec une erreur ORA-12091
- a partir de la 11g (je ne sais plus quel version exacte), un patch est disponible pour remedier a cela
- à partir d'Oracle 12, cette contrainte sera native

[elkamaro]

j'ai l'impression que des messages ont disparu dans ce poste

Notament celui de Mohamed d'aujourd'hui ??

[Mohamed.Houri]

Bonjour Mohamed,
C'est une colonne qui est clé primaire de certaine tables mais parfois elle fait seulement partie de la clé primaire.

Voilà par exemple une remarque qui mérite que l'on s'arrête à son niveau. La clé de partitionnement est une clé primaire ou fait partie d'une clé primaire.

Donc, l'indexe couvrant la clé primaire, sera t-il local ou global?

Vous avez une restriction importante à ce niveau qui est la suivante:

L'index couvrant une clé primaire ou une clé unique ne peut être local que s'il inclue la clé de partitionnement dans sa définition.

https://kr.forums.oracle.com/forums/...rt=15&tstart=0

Il y a aussi une discussion intéressante dans le lien suivant à propos des indexes partitionnés

https://forums.oracle.com/forums/thr...art=0&tstart=0

En conclusion, je veux vous faire passer deux messages:

1. Oui, quand il s'agit de purge ou d'archivage le partitionnement est la solution adéquate
2. Lorsque le système est déjà en production passer d'un mode sans partitionnement à une mode avec partitionnement doit être considéré avec une extrême précaution

[orafrance]

Personnellement, je n'ai jamais rencontré de problème à partitionner après coup, il faut juste en effet être prudent sur les indexes et tester. Ceci dit, j'ai toujours profité de l'opération pour faire une réorganisation de l'espace.

[elkamaro]

Bonjour et merci pour vos réponses

Cela dit, je butte sur votre dernier conseil a savoir tester les index et dans ce domaine j'ai encore beaucoup de chose a apprendre.


OraFrance, dans les partitionnements que tu as déjà effectués, as-tu eu a redéfinir les index ou a y toucher ? si oui, comment as-tu determiner l'action a entreprendre ?

pour ma part, je pensais tout simplement redefinir les tables avec des partitions et y remettre les index comme il etait au depart sans y toucher, je pensais que le partitionnement n'avait aucune incidence sur les indexes

As-tu eu d'autres soucis/contraintes/imprévus qui se seraient révéler lors de tes opérations de partitionnements.

Je te demande tout cela afin que je sois orienté sur le maximum de tests et de possibilités a entreprendre pour que ma procédure de redéfinition soit en béton.

Je vous remercie

[elkamaro]

Donc, l'indexe couvrant la clé primaire, sera t-il local ou global?

Comment puis je determiner cela ou quel test faire pour le determiner ?

En conclusion, je veux vous faire passer deux messages:

1. Oui, quand il s'agit de purge ou d'archivage le partitionnement est la solution adéquate
2. Lorsque le système est déjà en production passer d'un mode sans partitionnement à une mode avec partitionnement doit être considéré avec une extrême précaution

Merci Mohamed,
Actuellement, j'ai fini de peaufiner mes scripts de redefinition, je suis donc dans une phase de test et de recherche de tout problème qui pourrait survenir.

en gros, je recherche toutes les précautions a prendre comme tu me le suggere ... donc si tu as des pistes, je suis preneur