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
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.
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
Super article, merci pour le partage de ces informations!
Attention qu’en désactivant les redo logs, on perd d’autres fonctionalités (pas de recovery en cas de crash à moins d’avoir fait un full backup et impossibilité d’utiliser Data Guard, Streams ou GoldenGate). Il ne faut donc pas prendre cette décision à la légère.
Pour le parallélisme, les Load Plans – apparus avec ODI 11.1.1.5 – sont aussi une bonne alternative aux packages, généralement offrant plus de contrôles.
Un autre point important pour les performances, c’est de définir sa topology correctement : http://www.rittmanmead.com/2014/12/data-integration-tips-one-data-server/
Merci pour ce complément d’information 🙂