Optimisation des traitements ODI

Comme pour tout projet d’alimentation des données, on peut parfois être confronté à des problèmes de performance. Voici quelques pistes qui pourraient vous aider à optimiser vos traitements sous ODI:

Utiliser des indexs

Un index est une structure de données utilisé dans les SGBD. Il permet de trouver plus rapidement l’information recherchée. Il peut être comparé à une table des matières ; au lieu de parcourir toute la table, il va se contenter de regarder cette « table des matières » et localiser rapidement l’information recherchée.

Pour mieux comprendre comment fonctionne un index et comment l’utiliser, rendez-vous sur cette page : http://blog.developpez.com/sqlpro/p9816/langage-sql-norme/tout_sur_l_index

Limiter le nombre d’écriture des logs

Oracle logue les changements intervenus sur ses objets (tables, index, …) de manière à pouvoir restaurer ces objets en cas de besoin. Cette écriture dans les REDO a un coût. Pour limiter le nombre d’écriture des logs, plusieurs paramètres entrent en jeu

  • Créer les tables en mode NOLOGGING

CREATE TABLE no_logging_table NOLOGGING(…);

  • Faire des insertions en mode append :

INSERT /*+ APPEND */ INTO nom_table

  • Modifier le mode d’archivage de la base de données : NOARCHIVELOG

http://myadmin.wordpress.com/2007/02/25/setting-oracle-db-into-noarchivelog-mode/

J’ai trouvé ce tableau sur le forum de developpez.net , ça peut aider :

Table mode Insert Mode  ArchiveLog mode     result
LOGGING APPEND ARCHIVE LOG redo generated
NOLOGGING APPEND ARCHIVE LOG no redo
LOGGING no append «  » redo generated
NOLOGGING no append «  » redo generated
LOGGING APPEND noarchive log mode no redo
NOLOGGING APPEND noarchive log mode no redo
LOGGING no append noarchive log mode redo generated
NOLOGGING no append noarchive log mode redo generated

 

Utiliser le KM Incremental Update (MERGE)

plutôt que le KM Incremental Update OU modifier/créer un KM qui utilise la fonction MERGE plutôt qu’UPDATE

Attention, le MERGE n’est pas toujours plus performant … à tester donc . Pour vous aider :

http://lnavarro.developpez.com/oracle/updatemerge/

Eviter les jointures externes

notamment en passant par plusieurs interfaces

Supprimer les contrôles dans les interfaces (CKM)

s’ils ne sont pas exploités. Dans les options du KM, passer le flow control à false

flow_control

Calculer les statistiques

permet à Oracle de définir le plan d’exécution le moins coûteux. Cette opération devenant parfois très coûteuse en temps, il n’est pas envisageable de le faire à chaque modification de la base. Pour savoir comment calculer les statistiques :

http://blog.guiona.com/2010/02/oracle-statistiques_schema/

Exemple de calcul de statistiques pour une table donnée :

begin
DBMS_STATS.GATHER_TABLE_STATS (
ownname => ‘OWNER’,
tabname => ‘TABLE’,
estimate_percent => 30);
end;

Modifier  les propriétés des jointures de l’interface

notamment en utilisant des jointures ordonnées et des indexs temporaires.

jointure

Exécuter les traitements en parallèle

Voir la page suivante :

http://sonra.io/executing-interfaces-and-procedures-in-parallel-in-a-package-with-odi/

 

Bien entendu cette liste n’est pas exhaustive, donc si vous avez d’autres idées pour optimiser les traitements ODI, merci de les partager notamment en laissant un commentaire

2 Comments

Add a Comment

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *