Discussion :

[devkais]

Bonjour les Experts ,
J'ai une table partitionnée que je truncate (uniquement une partition à truncater) au début de mon traitement batch.
A un certain moment du traitement un INSERT ...SELECT lourd vient alimenter cette partition de la table.
Puisque ma base est en mode NOARCHIVE et que ce traitement est rejouable si erreur , est-ce que je pourrais envisager :

1/ un INSERT ...SELECT en mode NOLOGGING.
Les redo logs ne sont pas utiles dans mon cas ? risque ?

2/Utiliser aussi le mode APPEND dans cette insertion qui normalement ne devrait locker que la partition en question (Les autres partitions restent accessibles en dml ?).
En plus aucun souci de fragmentation causé par l'append car re-truncate de la partition au prochain passage du même batch.

Bref , le nologging et append est-il dangereux dans mon contexte sachant que la base est sauvegardé chaque soir par une sauvegarde BCV et que en cas de crash matériel un retour à cette sauvegarde est envisagé ...

3/ Pour finir quand une partition d'une table est "truncaté", que se passe-t-il pour l'index local ? est-ce que la partition équivalente de l'index est aussi "truncaté" automatiquement ou je risque d'avoir un index très fragmenté suite à plusieurs truncate de la partition de table ?
merci

[pachot]

Bonjour,

La base n'est pas en archivelog mode. Donc pas besoin de préciser NOLOGGING: tous les chargements en direct-path se feront en NOLOGGING.

La raison: en direct-path on écrit directement dans les datafiles, sans passer par la SGA. Donc pas besoin de redo log en cas de crash d'instance.

Par contre, un insert conventionnel ( INSERT ... SELECT s'il n'y a pas le hint APPEND ) va générer du redo: les modifs se font en mémoire, il faut que ces modifs soient protégées en cas de crash d'instance.

Utiliser aussi le mode APPEND dans cette insertion qui normalement ne devrait locker que la partition en question

Seulement si la partition est précisée dans l'insert avec le nom de la table.

Oui le truncate d'une partition vide l'index aussi.

Donc en bref:

Code :

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

1
2
3
 
ALTER TABLE nom_table TRUNCATE PARTITION nom_partition;
INSERT /*+ APPEND */ INTO nom_table PARTITION(nom_partition) SELECT ...

Cordialement,
Franck.

[rouardg]

Bonjour,

Pour répondre à ta question n°3, c'est oui.

L'avantage d'un index local, c'est que tu n'as pas à t'en soucier. Que tu fasses un TRUNCATE, mais aussi un SPLIT ou un MERGE de partitions sur une table, Oracle effectue la même chose sur les partitions de tous les index locaux de ta table.

Par contre, si ta table possède en plus des index globaux, ou des index non partitionnés, c'est à toi de les gérer.



Sinon je suis d'accord avec les propos de Pachot, à un détail près.

De manière générale, pour faire de l'insertion en Bulk sur une table, il ne faut pas qu'il y ait d'index, ou bien il faut le rendre inutilisable (UNUSABLE).

Dans ton cas donc, avant de faire du Bulk Insert dans la partition de la table, il faut donc penser, sur les index locaux, à passer la partition concernée par le chargement en UNUSABLE.

Une fois le chargement fait, il ne reste plus qu'à rebuilder cette partition.


Sauf erreur de ma part, voilà ce que cela doit donner avec 2 index locaux :

Code :

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

1
2
3
4
5
6
7
8
9
10
ALTER TABLE nom_table TRUNCATE PARTITION nom_partition;
 
ALTER INDEX nom_index_1 MODIFY PARTITION nom_partition UNUSABLE ;
ALTER INDEX nom_index_2 MODIFY PARTITION nom_partition UNUSABLE ;
 
INSERT /*+ APPEND */ INTO nom_table PARTITION(nom_partition) SELECT ...
COMMIT ;
 
ALTER INDEX nom_index_1 REBUILD PARTITION nom_partition ;
ALTER INDEX nom_index_2 REBUILD PARTITION nom_partition ;

[Mohamed.Houri]

Deux remarques s'imposent à mon humble avis

1) il faudrait rappeler que le direct path load peut être silencieusement ignoré si la table possède un trigger ou une contrainte d'intégrité.

2) par rapport à la remarque de rouardg concernant la mise dans un statut UNUSABLE des indexes locaux (uniquement ceux correspondants à la partition touchée par l'insert) c'est exactement ce que j'ai fait et cela a plus ou moins bien fonctionné. Par contre, comme la maintenance des indexes lors d'un direct path load est très performante (bulk insert à la fin), il serait intéressant de comparer les deux cas:

(a) direct path load avec indexes locaux "unusable"
(b) direct path load avec tous les indexes en place.

[pachot]

Bonjour Mohamed,

L'approche unusable/rebuild est à mon avis toujours plus rapide sur une partition vide, d'autant plus qu'on évite de devoir recalculer les stats de la partition d'index.

Cordialement,
Franck.

[devkais]

bonjour
le tablespace , la table et la partition sont en mode logging.
par contre la base est en mode noarchivelog.
un dml sur la table effectue t il une ecriture dans les redo log ?
comment verifier cela ?
merci