optimisation requête + operateur IN

**bossun** · 22/12/2009, 12h20

Salut j'ai la requete suivante qui me prend 40 sec à s'exécuter.

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
 
 
select A.RefDate, 'Swap' as Product, sum(A.BPV) as BasePV, sum(abs(A.BPV)) as AbsoluteBasePV from
(
select p.ReferenceDate as RefDate,
INS.MaturityDateAdj as Mat, 
 LG.CurrencyID as CCY,   
ROUND(LGD.InterestFixedRate,8) as IFR, 
LG.InterestIndexID as IID, 
sum(VTR.BasePV) as BPV
               from panorama..InstrumentLeg LG,
                    panorama..InstrumentLeg LGD,
                    panorama..Instrument INS,
                    panorama..ValuationTabResults VTR,
                    panorama..PortfolioResults p,
                    panorama..PartitionMapData PMD                   
where p.ResultsID = VTR.ResultsID
and  INS.InstrumentID = LG.InstrumentID
and  INS.InstrumentID = LGD.InstrumentID 
and LG.LegType = 'Flt'
and LGD.LegType = 'Fxd'
and INS.InstrumentID = PMD.Key4
and PMD.Key0 = 'Swap'
and INS.VersionNumber = 0 
and LG.VersionNumber = 0
and LGD.VersionNumber = 0
and VTR.UserPartitionID=PMD.PartitionCode
and p.PortfolioID in  (select PortfolioID from RPTRISK_DeskPortfolioMapping where DeskID='oblig') 
group by p.ReferenceDate,
INS.MaturityDateAdj,  
LG.CurrencyID, 
 ROUND(LGD.InterestFixedRate,8), 
LG.InterestIndexID 
) A
group by A.RefDate

lorsque le remplace cette ligne

Code :

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

p.PortfolioID in  (select PortfolioID from RPTRISK_DeskPortfolioMapping where DeskID='oblig')

par simplement

Code :

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

1
2
p.PortfolioID in  ('ABOBLIG','PRIMOBLI') 
--Ces valeurs étant le resultat envoyé par (select PortfolioID from RPTRISK_DeskPortfolioMapping where DeskID='oblig')

La requete s'exécute en moins 1s

qu'est-ce qui cloche? Ma table RPTRISK_DeskPortfolioMapping contient une 40aine d'enregistrements en tout. J'ai tenté divers variantes en incluant la table RPTRISK_DeskPortfolioMapping dans une jointure mais rien n'y fait....

Merci de votre aide

**Arnaud F.** · 22/12/2009, 12h57

Bonjour,

l'opérateur IN convient pour les valeurs fixe (comme vous l'avez mis dans le second exemple), pour tout le reste, il y a l'opérateur EXISTS.

Transformez :

Code :

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

1
2
3
4
 
AND p.PortfolioID IN  (SELECT PortfolioID
                   FROM RPTRISK_DeskPortfolioMapping
                   WHERE DeskID='oblig')

En :

Code :

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

1
2
3
4
5
 
AND EXISTS (SELECT *
            FROM RPTRISK_DeskPortfolioMapping
            WHERE p.PortfolioID = PortfolioID
              AND DeskID='oblig')

Pour plus de détails : http://sqlpro.developpez.com/cours/s...quetes/#L1.5.1

Cependant, pourquoi ne pas rajouter la table RPTRISK_DeskPortfolioMapping directement dans la requête?

Si c'est toujours aussi lent, c'est que votre requête :

Code :

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

SELECT PortfolioID FROM RPTRISK_DeskPortfolioMapping WHERE DeskID='oblig'

n'est pas optimisée tout simplement et c'est celle-ci qui met le plus de temps...

**mpeppler** · 22/12/2009, 13h25

C'est probablement un problème de selectivité. Lorsque les valeurs sont passées explicitement l'optimiseur peut déterminer exactement le nombre de lignes correspondantes. Lorsque le IN s'appuie sur le résultat d'une requête cela devient un estimation, ce qui a tendance a fausser le travail de l'optimiseur.

Personellement je fairait comme Arnaud le suggère, cad ajouter la table qui génère le IN dans la requêtre principale.

Si cela ne marche toujours pas il faudrait poster le plan d'execution pour comprendre ce qui se passe.

Michael

**bossun** · 22/12/2009, 14h47

Merci à vous 2 pour les réponses.

En fait j'ai déjà essayé d'ajouter la table RPTRISK_DeskPortfolioMapping dans requete principale mais rien n'y change.

voilà la requete

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
 
select A.RefDate, 'Swap' as Product, sum(A.BPV) as BasePV, sum(abs(A.BPV)) as AbsoluteBasePV from
(
select p.ReferenceDate as RefDate, 
INS.MaturityDateAdj as Mat, 
 LG.CurrencyID as CCY,   
ROUND(LGD.InterestFixedRate,8) as IFR, 
LG.InterestIndexID as IID, 
sum(VTR.BasePV) as BPV
               from panorama..InstrumentLeg LG,
                    panorama..InstrumentLeg LGD,
                    panorama..Instrument INS,
                    panorama..ValuationTabResults VTR,
                    panorama..PortfolioResults p,
                    panorama..PartitionMapData PMD
                    ,interfaces..RPTRISK_DeskPortfolioMapping dpm
where dpm.PortfolioID=p.PortfolioID
and dpm.DeskID='oblig'
and p.ResultsID = VTR.ResultsID
and  INS.InstrumentID = LG.InstrumentID
and  INS.InstrumentID = LGD.InstrumentID 
and LG.LegType = 'Flt'
and LGD.LegType = 'Fxd'
and INS.InstrumentID = PMD.Key4
and PMD.Key0 = 'Swap'
and INS.VersionNumber = 0 
and LG.VersionNumber = 0
and LGD.VersionNumber = 0
and VTR.UserPartitionID=PMD.PartitionCode
group by p.ReferenceDate, INS.MaturityDateAdj,  LG.CurrencyID,  ROUND(LGD.InterestFixedRate,8), LG.InterestIndexID 
) A
group by A.RefDate

et son 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
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
 
QUERY PLAN FOR STATEMENT 1 (at line 1).
Executed in parallel by coordinating process and 3 worker processes.
 
 
    STEP 1
        The type of query is INSERT.
        The update mode is direct.
        Executed by coordinating process.
        Worktable2 created for REFORMATTING.
 
        FROM TABLE
            panorama..PartitionMapData
            PMD
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 16 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.
        TO TABLE
            Worktable2.
 
    STEP 2
        The type of query is INSERT.
        The update mode is direct.
        Executed in parallel by coordinating process and 3 worker processes.
        Worktable3 created for REFORMATTING.
 
        FROM TABLE
            panorama..ValuationTabResults
            VTR
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Executed in parallel with a 3-way hash scan.
        Using I/O Size 16 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.
        TO TABLE
            Worktable3.
 
    STEP 3
        The type of query is SELECT (into Worktable1).
        GROUP BY
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
        Executed in parallel by coordinating process and 3 worker processes.
 
        FROM TABLE
            interfaces..RPTRISK_DeskPortfolioMapping
            dpm
        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
            panorama..InstrumentLeg
            LG
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Executed in parallel with a 3-way hash scan.
        Using I/O Size 16 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
 
        FROM TABLE
            panorama..Instrument
            INS
        Nested iteration.
        Using Clustered Index.
        Index : PK_Instrument_1__137
        Forward scan.
        Positioning by key.
        Keys are:
            InstrumentID  ASC
            VersionNumber  ASC
        Using I/O Size 2 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
 
        FROM TABLE
            Worktable2.
        Nested iteration.
        Using Clustered Index.
        Forward scan.
        Positioning by key.
        Using I/O Size 16 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
 
        FROM TABLE
            Worktable3.
        Nested iteration.
        Using Clustered Index.
        Forward scan.
        Positioning by key.
        Using I/O Size 16 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
 
        FROM TABLE
            panorama..PortfolioResults
            p
        Nested iteration.
        Index : PK_PortfolioResults
        Forward scan.
        Positioning by key.
        Keys are:
            ResultsID  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
            panorama..InstrumentLeg
            LGD
        Nested iteration.
        Using Clustered Index.
        Index : PK__InstrumentLeg__79DD1E2D
        Forward scan.
        Positioning by key.
        Keys are:
            InstrumentID  ASC
            VersionNumber  ASC
        Using I/O Size 16 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size 16 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        TO TABLE
            Worktable1.
 
        Parallel work table merge.
 
    STEP 4
        The type of query is SELECT (into Worktable4).
        GROUP BY
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
        Executed by coordinating process.
 
        FROM TABLE
            Worktable1.
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 16 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.
        TO TABLE
            Worktable4.
 
    STEP 5
        The type of query is SELECT.
        Executed by coordinating process.
 
        FROM TABLE
            Worktable4.
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 16 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.
 
The sort for Worktable2 is done in Serial
 
 
The sort for Worktable3 is done in Parallel
 
 
Table: InstrumentLeg scan count 6, logical reads: (regular=152882 apf=0 total=152882), physical reads: (regular=13844 apf=0 total=13844), apf IOs used=0
Table: InstrumentLeg scan count 65, logical reads: (regular=224 apf=0 total=224), physical reads: (regular=1 apf=0 total=1), apf IOs used=0
Table: Instrument scan count 1608, logical reads: (regular=9502 apf=0 total=9502), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: ValuationTabResults scan count 3, logical reads: (regular=43686 apf=0 total=43686), physical reads: (regular=4656 apf=0 total=4656), apf IOs used=0
Table: PortfolioResults scan count 7224, logical reads: (regular=9812 apf=0 total=9812), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: PartitionMapData scan count 1, logical reads: (regular=188227 apf=0 total=188227), physical reads: (regular=17384 apf=0 total=17384), apf IOs used=0
Table: RPTRISK_DeskPortfolioMapping scan count 3, logical reads: (regular=3 apf=0 total=3), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: Worktable4  scan count 1, logical reads: (regular=21 apf=0 total=21), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: Worktable1  scan count 4, logical reads: (regular=325 apf=0 total=325), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: Worktable2  scan count 1608, logical reads: (regular=20414 apf=0 total=20414), physical reads: (regular=34 apf=0 total=34), apf IOs used=0
Table: Worktable3  scan count 11046, logical reads: (regular=1160127 apf=0 total=1160127), physical reads: (regular=34 apf=0 total=34), apf IOs used=0
Total writes for this command: 9287

**Arnaud F.** · 22/12/2009, 14h52

Avez-vous tenté avec le EXISTS comme suggéré plus haut?

**bossun** · 22/12/2009, 14h55

Oui tout à fait mais le restultat attendu n'est pas bon.

ce que je souhaiterais c'est faire la somme pour les portfolios "ABoblig" et "primobli"

Or si je mets la clause EXISTS il me fait la somme pour tout les portefeuils

**mpeppler** · 23/12/2009, 08h14

Quel est le plan quand tu spécifie les PortfolioID explicitement?

Le plan que tu as posté est plutôt compliqué, avec du parallelism, et il commence par faire un table scan de PartitionMapData, ce qui fait déjà 188k IO, et il fait aussi un table scan de ValuationTabResults vers une Worktable, ce qui n'est vraiment pas bon.

Est-ce que les datatypes des colonnes utilisées dans les jointures sont toutes du même type à gauche et à droite? (on sait que Sybase est très sensible au datatype mis-match)

Pourt mieux comprendre la requête, je l'ai réécrite en ANSI:

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
 
SELECT A.RefDate, 'Swap' AS Product, sum(A.BPV) AS BasePV, sum(abs(A.BPV)) AS AbsoluteBasePV
FROM
    (
        SELECT
            p.ReferenceDate AS RefDate,
            INS.MaturityDateAdj AS Mat,
            LG.CurrencyID AS CCY,
            ROUND(LGD.InterestFixedRate,8) AS IFR,
            LG.InterestIndexID AS IID,
            sum(VTR.BasePV) AS BPV
        FROM
            RPTRISK_DeskPortfolioMapping dpm
            join panorama..PortfolioResults p
                on  p.PortfolioID = dpm.PortfolioID
            join panorama..ValuationTabResults VTR
                on  VTR.ResultsID = p.ResultsID
            join panorama..PartitionMapData PMD
                on  PMD.PartitionCode = VTR.UserPartitionID
                and PMD.Key0 = 'Swap'
            join panorama..Instrument INS
                on  INS.InstrumentID = PMD.Key4
                and INS.VersionNumber = 0
            join panorama..InstrumentLeg LG
                on  LG.InstrumentID = INS.InstrumentID
                and LG.LegType = 'Flt'
                and LG.VersionNumber = 0
            join panorama..InstrumentLeg LGD
                on  LGD.InstrumentID = INS.InstrumentID
                and LGD.LegType = 'Fxd'
                and LGD.VersionNumber = 0
        where
            dpm.DeskID='oblig'
        GROUP BY
            p.ReferenceDate,
            INS.MaturityDateAdj,
            LG.CurrencyID,
            ROUND(LGD.InterestFixedRate,8),
            LG.InterestIndexID
    ) A
GROUP BY A.RefDate

J'ai mis les tables dans l'ordre "logique" (pour moi, en tous cas :-)

Evidemment - il faudrait aussi connaitre les indexes qui existent sur les tables, cela permettrait éventuellement de trouver le plan optimal, et de le forcer le cas échéant.

Michael

**bossun** · 23/12/2009, 09h03

Volà le plan d'exécution quand je mets les portfolioID explicitement.

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
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
 
QUERY PLAN FOR STATEMENT 1 (at line 1).
 
 
    STEP 1
        The type of query is SELECT (into Worktable1).
        GROUP BY
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
 
        FROM TABLE
            panorama..PortfolioResults
            p
        Nested iteration.
        Using 2 Matching Index Scans
        Index : PortfolioResults_PortfolioID
        Forward scan.
        Positioning by key.
        Keys are:
            PortfolioID  ASC
        Index : PortfolioResults_PortfolioID
        Forward scan.
        Positioning by key.
        Keys are:
            PortfolioID  ASC
        Using I/O Size 16 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
 
        FROM TABLE
            panorama..ValuationTabResults
            VTR
        Nested iteration.
        Using Clustered Index.
        Index : PK_ValuationTabResults
        Forward scan.
        Positioning by key.
        Keys are:
            ResultsID  ASC
        Using I/O Size 16 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size 16 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
 
        FROM TABLE
            panorama..PartitionMapData
            PMD
        Nested iteration.
        Index : IDX_PartitionMapData
        Forward scan.
        Positioning by key.
        Keys are:
            PartitionCode  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
            panorama..Instrument
            INS
        Nested iteration.
        Using Clustered Index.
        Index : PK_Instrument_1__137
        Forward scan.
        Positioning by key.
        Keys are:
            InstrumentID  ASC
            VersionNumber  ASC
        Using I/O Size 2 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
 
        FROM TABLE
            panorama..InstrumentLeg
            LG
        Nested iteration.
        Using Clustered Index.
        Index : PK__InstrumentLeg__79DD1E2D
        Forward scan.
        Positioning by key.
        Keys are:
            InstrumentID  ASC
            VersionNumber  ASC
        Using I/O Size 16 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size 16 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
 
        FROM TABLE
            panorama..InstrumentLeg
            LGD
        Nested iteration.
        Using Clustered Index.
        Index : PK__InstrumentLeg__79DD1E2D
        Forward scan.
        Positioning by key.
        Keys are:
            InstrumentID  ASC
            VersionNumber  ASC
        Using I/O Size 16 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size 16 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        TO TABLE
            Worktable1.
 
    STEP 2
        The type of query is SELECT (into Worktable2).
        GROUP BY
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
 
        FROM TABLE
            Worktable1.
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 16 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.
        TO TABLE
            Worktable2.
 
    STEP 3
        The type of query is SELECT.
 
        FROM TABLE
            Worktable2.
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 16 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.
 
Table: InstrumentLeg scan count 78, logical reads: (regular=414 apf=0 total=414), physical reads: (regular=4 apf=0 total=4), apf IOs used=0
Table: InstrumentLeg scan count 78, logical reads: (regular=414 apf=0 total=414), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: Instrument scan count 205, logical reads: (regular=1091 apf=0 total=1091), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: ValuationTabResults scan count 34, logical reads: (regular=2373 apf=0 total=2373), physical reads: (regular=134 apf=0 total=134), apf IOs used=0
Table: PortfolioResults scan count 2, logical reads: (regular=27 apf=0 total=27), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: PartitionMapData scan count 9924, logical reads: (regular=49853 apf=0 total=49853), physical reads: (regular=202 apf=0 total=202), apf IOs used=1
Table: Worktable2  scan count 1, logical reads: (regular=23 apf=0 total=23), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: Worktable1  scan count 1, logical reads: (regular=194 apf=0 total=194), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Total writes for this command: 0

C'est sûr que ce n'est pas le même plan..

Est-ce que les datatypes des colonnes utilisées dans les jointures sont toutes du même type à gauche et à droite? (on sait que Sybase est très sensible au datatype mis-match)

Oui ce sont tous les mêmes... je me suis déjà posé cette question.

Evidemment - il faudrait aussi connaitre les indexes qui existent sur les tables, cela permettrait éventuellement de trouver le plan optimal, et de le forcer le cas échéant.

Il y des index dans

panorama..Instrumets (InstrumentID et Versionnumber)
panorama..InstrumentLeg (InstrumentID,Versionnumber,InstrumentLeg)
panorama..ValuationTabResults (ResultsID,UserPartitionID)
panorama..PartitionMapData (PartitionCode,PartitionIndex)

**mpeppler** · 23/12/2009, 10h28

C'est un problème de statistiques, et de nombre de valeurs/selectivité.

Personnellement je mettrais un "set forceplan on" avec la requête écrite comme je l'ai fait. Cela devrait donner un plan similaire à celui que tu obtiens avec les PortfolioID explicite.

Tu peux aussi essayer de faire un "update [index] statistics" sur RPTRISK_DeskPortfolioMapping pour que Sybase puisse éventuellement avoir une meilleur idée sur le nombre de ligne qui seront retournées pour DeskID = 'oblig'.

Question stupide: est-ce que il n'y a qu'une ligne par tuple PortfolioID/DeskID dans RPTRISK_DeskPortfolioMapping ?

Michael

**bossun** · 23/12/2009, 10h58

ça n'y change rien...

J'ai remis à jour toutes les stats mais rien n'y change...

Le contenu de RPTRISK_DeskPortfolioMapping.

DeskID PortfolioID
OBLIG ABOBLIG
OBLIG PRIMOBLI
DEVISES DEVBLTS
DEVISES DEVSPOT
DEVISES LODTERM
DEVISES SOPTIONS

Je ne pensais pas que cette table allait me poser autant de soucis....

En tout cas merci de prendre du temps pour moi...

**bossun** · 04/01/2010, 12h19

Bonjour,

Excellente année pour commencer...

et pour revenir à mon problème de lenteur, j'ai trouvé quelque chose qui fait que la requete s'excecute en un temps record... <1 sec à tous les coups...

j'ai juste ajouté un "Set table count 1" au début de mon bloc sql et remis la valeur par défaut à la fin "set table count 0"

pour ceux que ça interesse... voilà un peu de lecture http://manuals.sybase.com/onlinebook...TextView/32117

merci à tous d'avoir pris du temps pour moi

**mpeppler** · 04/01/2010, 12h26

Cela revient presque à faire un "set forceplan on"...

A noter que cette option n'a plus d'effet en version 15.x.

Michael

**bossun** · 04/01/2010, 13h54

Cela revient presque à faire un "set forceplan on"...

peut-être mais un set forceplan ne change pas vraiment le temps d'execution de ma requete .. alors que set table count 1 oui...

Pour l 'instant je suis en 12.5 et à moyen terme on n'envisage pas de migration... au pire je vais adapter la requête si on doit migrer...

mais en tout cas, là, j'ai résolu mon problème

optimisation requête + operateur IN

Adaptive Server Enterprise Sybase

Discussions similaires

Partager

Partager