[oracle 8.0.5] insert très (trop) lent

**remi4444** · 11/10/2006, 20h04

et l'explain plan du select seul ???

Pour moi quand tu as une différence telle entre 2 traitement, la premiere des chose à faire est de comparer les explain plan.... enfin moi j'ai toujours fait comme ça en tout cas....

100000 lignes c'est que dale à notre époque... avec des bons index et un bon plan ça doit forcement etre possible....

Je suis d'accord avec Hugues_78, le seul critère discriminant qui vaille est celui sur la colonne G_T3.ID_TPS_JOU. ça se devine fonctionnellement parcequ'on se doute que si tu ne prends que les lignes des 2 derniers jours, ça restreindra pas mal, mais ça l'optimiseur ne peux pas le deviner, à priori il considère qu'un critère ">=" ne filtre qu'un tiers des données (enfin je crois) du coup il ne s'interresse pas à l'index. Pour qu'il le sache, il faut faire un histogramme sur la colonne (trés régulièrement) ou bien tout simplement forcer l'index comme l'a indiqué Hugues_78....

**icoons** · 11/10/2006, 21h07

bon, là c'est très clair le /*+LEADING(table index)*/ a donné un résultat incroyablement rapide.
( moins de 10 minutes)
J'en ai laissé tomber l'analyse des current_waits tant les bras m'en sont tombés !
bien joué Hugues et Rémi !

Le problème maintenant c'est que je ne sais pas comment passer cette clause dans le traitement Genio, ou comment forcer (d'une autre façon) la requête a utiliser cet index

Et le tablespace temporaire situé sur le tablespace système ? dois-je faire quelque chose ?

**orafrance** · 12/10/2006, 08h15

faut faire une vue non ?

**Hugues_78** · 12/10/2006, 11h14

Pour l'implementation dans genio, je n'ai pas souvenir que l'on puisse ajouter des commentaires.

Tu peux donc soit faire une vue qui va correspondre à ce que tu veux (attention aux plans si tu ne veux pas mettre tout le traitement dedans)

ou alors créer une histograme sur la colonne (faire un test sous toad)
analyze index xxx estimate statistics size 64 ou un truc du genre

ou alors créer une procédure stockée que tu appelera et qui fera
truncate table toto reuse storage (une table de même structure que t_g3, mais temporaire)... Dans un execute immediate
insert into toto select * from t_g3
analyze table toto estimate statistics (execute immediate)
et tu fais ton module genio avec une jointure sur toto

tu peux aussi essayer de faire : jour = sysdate -2 or jour=sysdate-1 or jour=sysdate (pareil tester sous toad)

Le tablespace XSYT01, c'est ton tablespace system ?

ça veut dire que chaque fois que tu tri, ou que tu fais une jointure, il va aller swapper dans le tablespace system si ça tiens pas en mémoire
==> contention sur le tablespace system qui n'est pas fait pour ça
==> tu risques de fragmenter inutilement system
==> il y a toute la sécurité oracle (redolog, etc...) sur les tablespaces

en 8i, de mémoire, il n'y a pas encore la notion de tempfiles...
Mais tu peux créer un tablespace que tu va noter temp
ensuite alter tablespace temp temporary
alter user xxx temporary tablespace temp (qu'il aille pointer sur temp)

dans le create du tablespace temp, il faut avoir :
initial = next = x fois sort_area_size + db_block_size
(toujours un bloc d'entête d'ou db_block_size, et qu'un extent de swap soit égal à plusieurs fois le sort_area_size)
Ex sort = 256Ko / block = 8K
initial = 8K + 1024K
==> tu peux mettre 4 sort_area_size dans ton extent
si tu avais mis 1024K, tu n'aurais pu en mettre que 3 (8 d'entete + 3*256... Reste 244 qui sont pas utilisé)

**Hugues_78** · 12/10/2006, 11h22

Si... J'ai une autre idée

Essaye le hint /*+ ALL_ROWS */. Avec un peu de chance, ça marchera...

Si ça ça marche, ton process genio va commencer par appeler une proc stocké qui va faire
execute immediate 'alter session set optimizer_mode=all_rows'

**remi4444** · 12/10/2006, 11h48

Moi j'opterais en priorité pour la création d'histogramme, car ça a été inventé très exactement pour ce genre de problématique donc autant faire honneur à cette belle conception

et surtout ça optimisera aussi potentiellement toutes les requêtes du meme style qui pourraient se présenter à l'avenir.

Attention cependant, il faut qu'il soit fait trés régulièrement (apres chaque chargement de tb_o_ent_tkv) car y'a rien de pire qu'un histogramme faux...

.

Exemple de syntaxe:

Code :

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

1
2
3
4
 
 
ANALYZE TABLE tb_o_ent_tkv
   ESTIMATE STATISTICS FOR COLUMNS id_tps_jou SIZE 50;

**orafrance** · 12/10/2006, 11h55

pas sûr que ce soit une bonne idée en 8.0.5... le CBO n'était qu'à ses balbutiements

**remi4444** · 12/10/2006, 12h38

Envoyé par Fred_D

pas sûr que ce soit une bonne idée en 8.0.5... le CBO n'était qu'à ses balbutiements

Ah..... oui j'avais oublié la version d'oracle effectivement....

en tout cas, ça mange pas de pain tester avant de passer au methodes plus radicales

**icoons** · 12/10/2006, 14h28

retour au départ...

j'ai relancé le test d'hier avec la clause leading, et je suis de nouveau face à une requête qui met des heures à s'executer.

Il faudrait, comme me l'a demandé hugues, jeter un oeil sur les waits mais la version de Toad (7.4.0.3) dont je dispose ne semble pas offrir cette fonctionnalité. Existe-t'il une requête qui permet de voir les current_waits d'une session ?

Je pense que pour l'implémentation sous Genio, l'idée de la vue me semble la plus simple à mettre en oeuvre... encore que la dernière expérience sur le /* + leading */ ne permet pas de conclure quoi que ce soit.

En fait le table xsyst01 qui apparaît être utilisé comme tablespace temporaire est effectivement un tablespace temporaire de 8go le sort_area_size mesure, quant à lui désormais 128mo (comme cela m'a été conseillé plus haut).

**remi4444** · 12/10/2006, 14h36

As-tu édité le plan ? attenion avec les HINT, une erreur de syntaxe ne levera aucune exception, la seule manière de vérifier que c'est bien pris en compte est de regarder l'explain plan de la requête............................

**icoons** · 12/10/2006, 15h05

j'ai créé la vue

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
CREATE OR REPLACE FORCE VIEW ALM.VW_WDO_VTE
(ID_TPS_JOU, ID_WDO_VTE_REF_CLA, ID_WDO_VTE_PVT, ID_WDO_VTE_EMP, ID_WDO_VTE_MCI_JOU_HEU, 
 NB_WDO_VTE_PRP, NB_WDO_VTE_TKV, DC_WDO_VTE_MNT_CA_NET_HT, DC_WDO_VTE_MNT_CA_BRT_INI, DC_WDO_VTE_MNT_CA_BRT_BAS, 
 DC_WDO_VTE_MNT_CA_NET_TTC, DC_WDO_VTE_MNT_MRG, DC_WDO_VTE_MNT_RAB_REM, DC_WDO_VTE_MNT_REM, DC_WDO_VTE_VND_HEU, 
 NB_WDO_VTE_RMB, NB_WDO_VTE_ECH, NB_WDO_VTE_RET_CLI, NB_WDO_VTE_QTE, DC_WDO_VTE_MNT_RET_CLI, 
 DC_WDO_VTE_MNT_ECH, DC_WDO_VTE_MNT_RMB, DC_WDO_VTE_AMP_HOR, LB_WDO_VTE_STA, NB_WDO_VTE_CLI)
AS 
SELECT /*+ leading (g_t3 IX_FK_ENT_TKV_TPS_JOU) */  g_t3.id_tps_jou, g_t4.id_ref, g_t3.id_pvt, g_t3.id_emp,
            TO_NUMBER (TO_CHAR (g_t3.dt_ent_tkv, 'yyyymmddHH24')), 0, 0,
            SUM ((  (  (g_t1.dc_lig_tkv_prx_ven_brt * g_t1.nb_lig_tkv_qt)
                     - g_t1.dc_lig_tkv_mnt_rem
                    )
                  - g_t1.dc_lig_tkv_mnt_tva
                 )
                ),
            SUM ((g_t2.dc_prx_brt_ini * g_t1.nb_lig_tkv_qt)),
            SUM ((g_t1.nb_lig_tkv_qt * g_t2.dc_prx_brt_bas)),
            SUM ((  (g_t1.dc_lig_tkv_prx_ven_brt * g_t1.nb_lig_tkv_qt)
                  - g_t1.dc_lig_tkv_mnt_rem
                 )
                ),
            (  SUM ((  (  (g_t1.dc_lig_tkv_prx_ven_brt * g_t1.nb_lig_tkv_qt)
                        - g_t1.dc_lig_tkv_mnt_rem
                       )
                     - g_t1.dc_lig_tkv_mnt_tva
                    )
                   )
             - SUM ((g_t1.nb_lig_tkv_qt * g_t2.dc_prmp))
            ),
            (  SUM ((  (g_t2.dc_prx_brt_bas - g_t1.dc_lig_tkv_prx_ven_brt)
                     * g_t1.nb_lig_tkv_qt
                    )
                   )
             + SUM (g_t1.dc_lig_tkv_mnt_rem)
            ),
            SUM (g_t1.dc_lig_tkv_mnt_rem), 0, 0, 0, 0,
            SUM (g_t1.nb_lig_tkv_qt), 0, 0, 0, 0, 'AA', 0
       FROM ods.tb_o_lig_tkv@xdwa g_t1,
            alm.tb_wdo_prx_ref_jou@xdwa g_t2,
            ods.tb_o_ent_tkv@xdwa g_t3,
            ods.tb_o_uvc@xdwa g_t4
      WHERE g_t3.id_tps_jou = g_t2.id_jou
        AND g_t1.id_uvc = g_t4.id_uvc
        AND g_t3.id_ent_tkv = g_t1.id_ent_tkv
        AND g_t1.cd_lig_tkv_typ <> 'MVTFI'
        AND g_t4.id_ref = g_t2.id_uvc
   GROUP BY TO_NUMBER (TO_CHAR (g_t3.dt_ent_tkv, 'yyyymmddHH24')),
            g_t3.id_tps_jou,
            g_t4.id_ref,
            g_t3.id_pvt,
            g_t3.id_emp;

et voici le plan d'exécution

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Operation	Object Name	Rows	Bytes	Cost	Object Node	In/Out	PStart	PStop
 
SELECT STATEMENT Hint=CHOOSE		1  	 	5988  	 	      	  	 
VIEW	VW_WDO_VTE	1  	207  	5988  	 	      	  	 
SORT GROUP BY		1  	189  	5988  	 	      	  	 
HASH JOIN		1  	189  	5979  	 	      	  	 
NESTED LOOPS		4 K	638 K	5795  	 	      	  	 
HASH JOIN		4 K	386 K	72  	 	      	  	 
TABLE ACCESS FULL	TB_WDO_PRX_REF_JOU	1 K	27 K	3  	 	      	  	 
TABLE ACCESS BY INDEX ROWID	TB_O_ENT_TKV	7 K	446 K	67  	 	      	  	 
INDEX RANGE SCAN	IX_FK_ENT_TKV_TPS_JOU	7 K	 	42  	 	      	  	 
TABLE ACCESS BY INDEX ROWID	TB_O_LIG_TKV	14 M	723 M	2  	 	      	  	 
INDEX RANGE SCAN	IX_LIG_TKV_ID_ENT	14 M	 	3  	 	      	  	 
TABLE ACCESS FULL	TB_O_UVC	99 K	4 M	148

**icoons** · 13/10/2006, 16h16

Envoyé par remi4444

As-tu édité le plan ? attenion avec les HINT, une erreur de syntaxe ne levera aucune exception, la seule manière de vérifier que c'est bien pris en compte est de regarder l'explain plan de la requête............................

bon ben voilà,... Rémy avait raison, j'avais mal écrit mon Hint. J'ai recommencé plusieurs fois le test et j'ai des résultats exceptionnels (seulement quelques secondes lors du traitement de ce matin)

La solution était donc : /*+ LEADING (table index) */

MERCI LES GARS

[oracle 8.0.5] insert très (trop) lent

Oracle

Discussions similaires

Partager

Partager