Discussion :

[tdeco]

Bonjour
Je suis confronté à un problème de performance sur l'exécution d'une requête Select sur une base Sybase. Je ne suis pas à l'origine du modèle de données de la base et de la requête. Cette dernière prend 44 s pour s'éxécuter, ce qui est un peu beaucoup pour l'affichage des résultats via une IHM.

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
 
SELECT distinct SROU.xir_cty_lab + ' ('+ SSIT.eqt_top_nam+')',
    PTH.src_lan_adr,
    DROU.xir_cty_lab + ' ('+ DSIT.eqt_top_nam +')',
    PTH.dst_lan_adr,
       convert(char(12), PTH.pth_cre_dat, 111),
       convert(char(12), PTH.pth_ces_dat, 111),
       SROU.rou_com_cod,
       convert(varchar, PTH.xir_pth_idt)
 
  FROM  XIR_NET_e2e_pth PTH,
     XIR_NET_all_rou SROU,
     XIR_NET_all_rou DROU,
     XIR_NET_top_sit SSIT,
     XIR_NET_top_sit DSIT
 
  WHERE  exists ( SELECT 'x' FROM XIR_NET_e2e_srv
          WHERE xir_obj_typ = 'PATH'
          AND xir_obj_idt = convert (varchar(15),PTH.xir_pth_idt)
          AND xir_cus_cod = @cus_lst_cod
          AND xir_rpt_typ = '2')
    AND PTH.src_sit_nam = SSIT.xir_top_sit
    AND SSIT.xir_top_sit = SROU.xir_top_sit
    AND PTH.dst_sit_nam = DSIT.xir_top_sit
    AND DSIT.xir_top_sit = DROU.xir_top_sit
    AND PTH.xir_pth_typ like '%Availability%'
    AND charindex('IsSW',SROU.xir_rou_mgt) = 0
    AND charindex('Managed Ethernet Link',SROU.rou_pro_nam) = 0
    AND (charindex('CUSTOMER_ACCESS_SWITCH',SROU.rou_sit_cod)=0  OR charindex('IP VPN',SROU.ntw_srv_typ) =0 )
 
 ORDER BY 1, 3

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
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
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
 
QUERY PLAN FOR STATEMENT 1 (at line 1).
 
 
    STEP 1
        The type of query is INSERT.
        The update mode is direct.
        Worktable1 created, in allpages locking mode, for ORDER BY.
 
        FROM TABLE
            XIR_NET_e2e_pth
            PTH
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 2 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
 
        FROM TABLE
            XIR_NET_e2e_srv
        EXISTS TABLE : nested iteration.
        Index : XIR_NET_e2e_srv_u1
        Forward scan.
        Positioning by key.
        Index contains all needed columns. Base table will not be read.
        Keys are:
            xir_obj_typ  ASC
            xir_obj_idt  ASC
            xir_rpt_typ  ASC
        Using I/O Size 2 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
 
        FROM TABLE
            XIR_NET_all_rou
            SROU
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 2 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
 
        FROM TABLE
            XIR_NET_top_sit
            SSIT
        Nested iteration.
        Index : XIR_NET_top_sit_u1
        Forward scan.
        Positioning by key.
        Keys are:
            xir_top_sit  ASC
        Using I/O Size 2 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size 2 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
 
        FROM TABLE
            XIR_NET_top_sit
            DSIT
        Nested iteration.
        Index : XIR_NET_top_sit_u1
        Forward scan.
        Positioning by key.
        Keys are:
            xir_top_sit  ASC
        Using I/O Size 2 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size 2 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
 
        FROM TABLE
            XIR_NET_all_rou
            DROU
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 2 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        TO TABLE
            Worktable1.
 
    STEP 2
        The type of query is SELECT.
        This step involves sorting.
 
        FROM TABLE
            Worktable1.
        Using GETSORTED
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 2 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.
 
The sort for Worktable1 is done in Serial

Index :

Code :

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

1
2
3
4
5
6
7
 
XIR_NET_e2e_pth_u1 on XIR_NET_e2e_pth  (xir_pth_idt)
 
XIR_NET_all_rou_u1 on XIR_NET_all_rou ( xir_rou_nam )
XIR_NET_all_rou_i1 on XIR_NET_all_rou ( rou_com_cod )
 
XIR_NET_top_sit_u1 on XIR_NET_top_sit  ( xir_top_sit )

Je pense que le problème vient du fait qu'elle utilise 2 fois les mêmes tables avec des alias différents.
Exemple : le champ PTH.src_sit_nam -> SSIT.xir_top_sit et PTH.dst_sit_nam -> DSIT.xir_top_sit, SSIT et DSIT alias d'une même table.
Il y a t'il un moyen de contourner ce problème ?

Merci d'avance

[Arnaud F.]

Bonjour,

peut être que rajouter un index sur le champ xir_top_sit de la table XIR_NET_all_rou ne serait pas mauvais.

Mais pour une meilleure vision de la chose, pourriez-vous poster les I/O de cette requête afin de voir le poids des différentes tables dans la jointure?

Pour réaliser cela :

Code :

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

set statistics io on

++

[tdeco]

Code :

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

1
2
 
SET statistics io ON

Code :

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

1
2
3
4
5
6
7
8
9
10
 
Table: XIR_NET_e2e_pth scan count 1, logical reads: (regular=1822 apf=0 total=1822), physical reads: (regular=1822 apf=0 total=1822), apf IOs used=0
Table: XIR_NET_all_rou scan count 64, logical reads: (regular=761920 apf=0 total=761920), physical reads: (regular=761920 apf=0 total=761920), apf IOs used=0
Table: XIR_NET_all_rou scan count 64, logical reads: (regular=761920 apf=0 total=761920), physical reads: (regular=630113 apf=0 total=630113), apf IOs
used=0
Table: XIR_NET_top_sit scan count 64, logical reads: (regular=256 apf=0 total=256), physical reads: (regular=132 apf=0 total=132), apf IOs used=0
Table: XIR_NET_top_sit scan count 64, logical reads: (regular=257 apf=0 total=257), physical reads: (regular=185 apf=0 total=185), apf IOs used=0
Table: XIR_NET_e2e_srv scan count 2490, logical reads: (regular=10107 apf=0 total=10107), physical reads: (regular=1067 apf=0 total=1067), apf IOs used=0
Table: Worktable1  scan count 0, logical reads: (regular=83 apf=0 total=83), physical reads: (regular=72 apf=0 total=72), apf IOs used=0
Total writes for this command: 119

[rberthou]

Je ne pense pas que le problème vienne des utilisations double de deux tables

Par contre je penche plus pour

Code :

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

1
2
3
4
5
 
    AND PTH.xir_pth_typ LIKE '%Availability%'
    AND charindex('IsSW',SROU.xir_rou_mgt) = 0
    AND charindex('Managed Ethernet Link',SROU.rou_pro_nam) = 0
    AND (charindex('CUSTOMER_ACCESS_SWITCH',SROU.rou_sit_cod)=0  OR charindex('IP VPN',SROU.ntw_srv_typ) =0 )

Je ne pense pas que un like de ce type passe par un index (mais je en suis pas un spécialiste Sysbase)

Je crains également que l'ensemble des "charindex" n'utilise aucun indexe
(je crois que cela est équivalent à not like '%expr1%' avec peux etre une optimisation)

[dbaffaleuf]

Hello,

Y-at-il autant de physical reads à chaque exécution sur XIR_NET_all_rou ? De toute façons la table est scannée, les deux colonnes indexées ne sont pas utilisées comme prédicats. Dans l'état, on peut ajouter un index sur la colonne de jointure (XIR_NET_all_rou.xir_top_sit).

David B.

[Arnaud F.]

Bonjour,

Je ne pense pas que le problème vienne des utilisations double de deux tables

Par contre je penche plus pour

Code :

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

1
2
3
4
5
 
    AND PTH.xir_pth_typ LIKE '%Availability%'
    AND charindex('IsSW',SROU.xir_rou_mgt) = 0
    AND charindex('Managed Ethernet Link',SROU.rou_pro_nam) = 0
    AND (charindex('CUSTOMER_ACCESS_SWITCH',SROU.rou_sit_cod)=0  OR charindex('IP VPN',SROU.ntw_srv_typ) =0 )

Je ne pense pas que un like de ce type passe par un index (mais je en suis pas un spécialiste Sysbase)

Je crains également que l'ensemble des "charindex" n'utilise aucun indexe
(je crois que cela est équivalent à not like '%expr1%' avec peux etre une optimisation)

Vous avez raison, à partir du moment que l'on utilise une fonction sur un prédicat, plus aucun index n'est utilisé(*), les charindex pourraient s'écrire en "NOT LIKE" mais ne changerait pas le résultat.

(*) En V15 (ou 12.5.1, je sais plus), il est possible de créer des index sur les colonnes en se basant sur des fonctions.

Par exemple :

Code :

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

1
2
3
4
CREATE INDEX idx1 ON myTable (SUBSTRING(col1, 1, 5)
go
-- Utilisera l'index...
SELECT * FROM myTable WHERE SUBSTRING(col1, 1, 5) = "abcde"

Hello,

Y-at-il autant de physical reads à chaque exécution sur XIR_NET_all_rou ? De toute façons la table est scannée, les deux colonnes indexées ne sont pas utilisées comme prédicats. Dans l'état, on peut ajouter un index sur la colonne de jointure (XIR_NET_all_rou.xir_top_sit).

David B.

+1