Discussion :

[Ryo_san]

Bonjour à tous !

Voilà j'ai un problème assez surprenant avec BODI (en version XI 11.5) : j'ai une Query qui se révèle être atrocement coûteuse en temps alors qu'il n'y a qu'une simple jointure (soit prêt de 11h au total pour cette partie du Job). Pourriez-vous me dire ce qui ne vas pas dans mon flux ??
Voici comment il est construit :

1. Je pars d'une table de l'ODS que l'on appelera TT_ODS_SPA_IND_ECCORD_TMP3
2. Je fais, dans une première Query, un mapping standard sur touts les champs hormis deux : l'un est obtenu à partir d'un lookup sur une table extérieure au flux, l'autre contient simplement un "day_in_week"...
3. Je fais une deuxième Query où je remape tous mes champs et à l'aide d'une autre table source contenant les années, je mappe mon champ ID_JRN à l'aide d'un "ifthenelse"...
4. Enfin je fais une troisième (et dernière) Query qui est celle qui semble poser problème. Dans cette Query, je remape tous mes champs à partir de Query2 sauf pour un champ où je fais intervenir une 3ème table source contenant des tranches horaires de 5min (00:00 - 00:05 ; 00:05 - 00:10...) afin de mapper tout simplement mon ID_HRE05, je rajoute tout de même la clause WHERE suivante pour faire la jointure :
   

   Code :

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

   1
   2
   3
   4
   5
    
   Query_2.ID_HRE >= TT_SPA_HRE_05M.HRE_DEB
   AND 
   (Query_2.ID_HRE < TT_SPA_HRE_05M.HRE_FIN
   OR TT_SPA_HRE_05M.HRE_FIN = '00.00.00')

5. Au final, j'alimente ma table cible avec les options standard et en Delete before Loading...

Pour vous rendre mieux compte, j'ai recomposé la requête complète à l'aide de BODI :

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
29
30
 
SELECT  TT_ODS_SPA_IND_ECCORD_TMP3.ID_VOL  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_CMP  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_JRN  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_HRE  , 
		TR_DWH_SPA_ANN.DEB_DAT_ETE  , 
		TR_DWH_SPA_ANN.FIN_DAT_ETE  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_SCE_IAT  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_VER_COH  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_AEP  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_SAI_IAT  , 
		TT_SPA_HRE_05M.ID_HRE_05M  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_SRC  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_TAS_COH  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_VER  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_TYP_MVT  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_SOU_TYP_AVI  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_CLR  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.NB_MVT  , 
		TT_SPA_HRE_05M.HRE_DEB  , 
		TT_SPA_HRE_05M.HRE_FIN 
FROM 	SPA_DATA.TR_DWH_SPA_ANN TR_DWH_SPA_ANN, 
 	 	SPA_ODS.TT_ODS_SPA_IND_ECCORD_TMP3 TT_ODS_SPA_IND_ECCORD_TMP3, 
 	 	SPA_ODS.TT_SPA_HRE_05M TT_SPA_HRE_05M 
WHERE 	TR_DWH_SPA_ANN.ID_ANN  = to_char(TT_ODS_SPA_IND_ECCORD_TMP3.ID_JRN , 'YYYY') 
AND		TT_ODS_SPA_IND_ECCORD_TMP3.ID_HRE >= TT_SPA_HRE_05M.HRE_DEB 
AND 	( 
			TT_ODS_SPA_IND_ECCORD_TMP3.ID_HRE < TT_SPA_HRE_05M.HRE_FIN 
		OR 	TT_SPA_HRE_05M.HRE_FIN = '00.00.00' 
		)

Quand je la lance directement sur Oracle, elle s'exécute en seulement 600ms !

J'aimerais bien comprendre ce qui fait prendre autant de temps à ma Query sous BODI...

Merci d'avance pour votre aide !

[Prjprj]

Hello

Il est fort probable que cela vienne de ton lookup

Il existe plusieurs façons de gérer la gestion du cache dans les lookups : la première consiste à rapatrier toutes les données de la table sur laquelle tu pointes pour chaque ligne (en gros pas de cache), une autre où tu gardes en cache les dernière lignes prises en compte (algo LIFO), une dernière où tu fais un select avec des conditions assez barbares pour chaque ligne

Je donne ces infos de mémoire étant donné que je n'ai pas eu une version fonctionnelle de BODI à portée de souris depuis 2 mois.

L'important est aussi de voir sur combien de lignes tu as dans les tables sur lesquelles pointent le lookup

En général, on essaie d'éviter les lookup dans les alim BODI, c'est très consommateur en ressources

En espérant t'avoir aidé

[Ryo_san]

Je te remercie Prjprj de t'intéresser à mon problème, et ça me permet d'en apprendre un peu plus sur les caches associés au lookups.

Néanmoins je ne pense pas qu'il s'agisse des lookups ici et pour cause, j'avais une autre clause WHERE avant dans ma Query3, et le flux tournait assez rapidement, ce qui me fait penser que depuis ma modif, ce sont ces nouvelles jointures dans la clause WHERE qui prennent du temps...

Donc voilà, je ne vois pas le problème en fait surtout que j'ai mis des index sur ces champs...

[Prjprj]

Effectivement en relisant ton post, j'ai vu que ta condition de jointure était relativement peu optimisée. Voir même pas du tout.

Le fait de créer des indexes ne fait pas gagner automatiquement des perfs, il faut que Data Integrator génère le code SQL qu'il faut pour que ton SGBD utilise les bons indexes.
Dans ton cas, une condition sur un intervalle, je pense qu'Oracle considère qu'il est plus rapide de faire un scan complet de la table plutôt que d'utiliser l'index, étant donné que la requête se base sur un ensemble de valeurs.

Quand tu fais des requêtes avec des clauses where contenant une valeur dans un intervalle, tu as un joli produit cartésien, à chaque fois qu'une ligne arrive, elle est comparée à l'ensemble des lignes de ta table d'heures, ce qui n'est pas optimal à l'origine.
De plus, étant donné que tu fais plusieurs query dans le même traitement, BODI est obligé de traiter les lignes au fur et à mesure qu'elles sont produites par les autres transformations, il n'a pas de table temporaire où stocker les lignes générées et ensuite faire une jointure SQL normale.

Une solution possible serait de scinder ton DataFlow en 2 en stockant les données générées dans la première partie dans une table temporaire (template table), tu n'aurais ensuite qu'à récupérer cette table en entrée de ton 2ième DataFlow, je pense que la jointure se ferait correctement de cette façon (mais ça reste à prouver)

Plus tu fais des DataFlows compliqués, moins ils sont performants et moins ils sont maintenables, à toi de voir ce que tu préfères, un confort de lecture ou moins de boulot dans quelques mois quand les (inévitables) retours viendront.

[mdenier]

je dirais si il existe l'objet SQL dans cette version de bodi ????
tu colle le sql dans l'objet sql en entrée
sinon une vue database faisant cet sql, mapping de la vue

voila si ça peut !!!!
dmx

Bonjour à tous !

Voilà j'ai un problème assez surprenant avec BODI (en version XI 11.5) : j'ai une Query qui se révèle être atrocement coûteuse en temps alors qu'il n'y a qu'une simple jointure (soit prêt de 11h au total pour cette partie du Job). Pourriez-vous me dire ce qui ne vas pas dans mon flux ??
Voici comment il est construit :

1. Je pars d'une table de l'ODS que l'on appelera TT_ODS_SPA_IND_ECCORD_TMP3
2. Je fais, dans une première Query, un mapping standard sur touts les champs hormis deux : l'un est obtenu à partir d'un lookup sur une table extérieure au flux, l'autre contient simplement un "day_in_week"...
3. Je fais une deuxième Query où je remape tous mes champs et à l'aide d'une autre table source contenant les années, je mappe mon champ ID_JRN à l'aide d'un "ifthenelse"...
4. Enfin je fais une troisième (et dernière) Query qui est celle qui semble poser problème. Dans cette Query, je remape tous mes champs à partir de Query2 sauf pour un champ où je fais intervenir une 3ème table source contenant des tranches horaires de 5min (00:00 - 00:05 ; 00:05 - 00:10...) afin de mapper tout simplement mon ID_HRE05, je rajoute tout de même la clause WHERE suivante pour faire la jointure :
   

   Code :

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

   1
   2
   3
   4
   5
    
   Query_2.ID_HRE >= TT_SPA_HRE_05M.HRE_DEB
   AND 
   (Query_2.ID_HRE < TT_SPA_HRE_05M.HRE_FIN
   OR TT_SPA_HRE_05M.HRE_FIN = '00.00.00')

5. Au final, j'alimente ma table cible avec les options standard et en Delete before Loading...

Pour vous rendre mieux compte, j'ai recomposé la requête complète à l'aide de BODI :

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
29
30
 
SELECT  TT_ODS_SPA_IND_ECCORD_TMP3.ID_VOL  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_CMP  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_JRN  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_HRE  , 
		TR_DWH_SPA_ANN.DEB_DAT_ETE  , 
		TR_DWH_SPA_ANN.FIN_DAT_ETE  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_SCE_IAT  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_VER_COH  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_AEP  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_SAI_IAT  , 
		TT_SPA_HRE_05M.ID_HRE_05M  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_SRC  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_TAS_COH  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_VER  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_TYP_MVT  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_SOU_TYP_AVI  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.ID_CLR  , 
		TT_ODS_SPA_IND_ECCORD_TMP3.NB_MVT  , 
		TT_SPA_HRE_05M.HRE_DEB  , 
		TT_SPA_HRE_05M.HRE_FIN 
FROM 	SPA_DATA.TR_DWH_SPA_ANN TR_DWH_SPA_ANN, 
 	 	SPA_ODS.TT_ODS_SPA_IND_ECCORD_TMP3 TT_ODS_SPA_IND_ECCORD_TMP3, 
 	 	SPA_ODS.TT_SPA_HRE_05M TT_SPA_HRE_05M 
WHERE 	TR_DWH_SPA_ANN.ID_ANN  = to_char(TT_ODS_SPA_IND_ECCORD_TMP3.ID_JRN , 'YYYY') 
AND		TT_ODS_SPA_IND_ECCORD_TMP3.ID_HRE >= TT_SPA_HRE_05M.HRE_DEB 
AND 	( 
			TT_ODS_SPA_IND_ECCORD_TMP3.ID_HRE < TT_SPA_HRE_05M.HRE_FIN 
		OR 	TT_SPA_HRE_05M.HRE_FIN = '00.00.00' 
		)

Quand je la lance directement sur Oracle, elle s'exécute en seulement 600ms !

J'aimerais bien comprendre ce qui fait prendre autant de temps à ma Query sous BODI...

Merci d'avance pour votre aide !

[Prjprj]

Bonjour mdenier,

En fait, la réponse de Ryo_san à mon post à été effacée par les soucis du forum durant le week-end dernier.

Il avait changé sa jointure sur les heures de façon à ne plus faire de produit cartésien.

Effectivement avec BODI tu peux utiliser une vue comme source pour un mapping, mais si la requête intègre un produit cartésien, le problème restera le même; il faut que la requête soit correcte.
De plus, le fait de créer une vue en base rend les développements moins facilement maintenables étant donné qu'il faut maintenir les vues en base de données et les alimentations dans BODI.

La transformation SQL est aussi utilisable, mais le code de ton SQL est spécifique à la base que tu utilises, tes développements ne seront donc pas portables en cas de migration.