[ASE 12.5] problème de performances [Résolu]

[bossun]

Salut,

J'ai un serveur avec une 10aine de bases.

Sur une base j'ai 2 vues qui m'affichent les données de 2 systèmes, ce qui représentent environs 600 lignes par vue.

J'ai 2 autres vues, qui se basent sur mes 2 vues citées plus haut, qui s'exécutent très lentement. mais quand je dis très c'est très lentement.

mes vues de base s'executent très rapidement si je les lance individuellement.

voilà le code :

Code :

1
2
3
4
5
6
7
8
9
10
11
CREATE VIEW dbo.VW_CC_DEVONPANO_NotInDevon
AS
    SELECT P.OriginalID, P.CurrencyID, P.CurrencyID2, P.TraderID, P.TradeDate, P.PutOrCall,
    P.StrikeRate, P.LastExerciseDate, P.MaturityDateAdj, P.Position, 
    P.PrincipalAmount, P.PrincipalAmount2, P.PremiumCCY,
    P.BackOfficePremium, P.PremiumDate, P.Type_,
    P.AccountingGroupID, P.InstrumentID, P.CounterpartyID,
    P.BOCustomer, P.CurrentDate FROM VW_CC_DEVONPANO_DealsFromPano P
    WHERE NOT EXISTS(SELECT 'X' FROM VW_CC_DEVONPANO_DealFromDevon D
                        WHERE D.OriginalID =P.OriginalID)
GO

l'autre vue fait le test inverse.

Je me demande si l'origine de l'a lenteur n'est pas le fait que la vue "VW_CC_DEVONPANO_DealFromDevon" n'est pas chargée à chaque record de ma vue "VW_CC_DEVONPANO_DealFromPano"

[fadace]

Question bateau : avez-vous rejoué les statistiques sur les tables utilisées par les vues ? Avez-vous fait un sp_recompile ensuite ?

[mpeppler]

Il faudrait exécuter ces requêtes avec "set showplan on" pour voir le plan qui est utilisé. Ce plan montrera les accès aux tables sous-jaçante, avec les plans d'accès et identifiera les problèmes.

Michael

[bossun]

Salut,

Voilà le plan d'éxecution... Mais j'ai un peu de mal à voir où ça cloche.

Code :

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
 
QUERY PLAN FOR STATEMENT 1 (at line 1).
 
 
    STEP 1
        The type of query IS SET OPTION ON.
 
 
QUERY PLAN FOR STATEMENT 1 (at line 1).
 
 
    STEP 1
        The type of query IS SELECT.
 
        FROM TABLE
            DDS334..futures
            f
        Nested iteration.
        TABLE Scan.
        Forward scan.
        Positioning at start of TABLE.
 
        Run subquery 1 (at nesting level 1).
        USING I/O Size 16 Kbytes FOR DATA pages.
        WITH MRU Buffer Replacement Strategy FOR DATA pages.
    STEP 1
 
NESTING LEVEL 1 SUBQUERIES FOR STATEMENT 1.
 
  QUERY PLAN FOR SUBQUERY 1 (at nesting level 1 AND at line 7).
 
    Correlated Subquery.
    Subquery under an EXISTS predicate.
 
 
    STEP 1
        The type of query IS SELECT.
        Evaluate Ungrouped ANY AGGREGATE.
 
        FROM TABLE
            PANORAMA..Optn
            O
        EXISTS TABLE : nested iteration.
        TABLE Scan.
        Forward scan.
        Positioning at start of TABLE.
        USING I/O Size 16 Kbytes FOR DATA pages.
        WITH LRU Buffer Replacement Strategy FOR DATA pages.
 
        FROM TABLE
            PANORAMA..Instrument
            I
        EXISTS TABLE : 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
            IL1
        EXISTS TABLE : nested iteration.
        USING Clustered INDEX.
        INDEX : PK__InstrumentLeg__79DD1E2D
        Forward scan.
        Positioning BY KEY.
        INDEX contains ALL needed COLUMNS. Base TABLE will NOT be READ.
        KEYS are:
            InstrumentID  ASC
            VersionNumber  ASC
            LegNumber  ASC
        USING I/O Size 16 Kbytes FOR INDEX leaf pages.
        WITH MRU Buffer Replacement Strategy FOR INDEX leaf pages.
 
        FROM TABLE
            PANORAMA..InstrumentLeg
            IL0
        EXISTS TABLE : nested iteration.
        USING Clustered INDEX.
        INDEX : PK__InstrumentLeg__79DD1E2D
        Forward scan.
        Positioning BY KEY.
        INDEX contains ALL needed COLUMNS. Base TABLE will NOT be READ.
        KEYS are:
            InstrumentID  ASC
            VersionNumber  ASC
            LegNumber  ASC
        USING I/O Size 16 Kbytes FOR INDEX leaf pages.
        WITH LRU Buffer Replacement Strategy FOR INDEX leaf pages.
 
  END OF QUERY PLAN FOR SUBQUERY 1.

[Roller]

Sinon, pour essayer de changer la stratégie d'accès, avez-vous essayé un:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
 
CREATE VIEW dbo.VW_CC_DEVONPANO_NotInDevon
AS
    SELECT P.OriginalID, P.CurrencyID, P.CurrencyID2, P.TraderID, P.TradeDate, P.PutOrCall,
    P.StrikeRate, P.LastExerciseDate, P.MaturityDateAdj, P.Position, 
    P.PrincipalAmount, P.PrincipalAmount2, P.PremiumCCY,
    P.BackOfficePremium, P.PremiumDate, P.Type_,
    P.AccountingGroupID, P.InstrumentID, P.CounterpartyID,
    P.BOCustomer, P.CurrentDate FROM VW_CC_DEVONPANO_DealsFromPano P
    WHERE P.OriginalID NOT IN ( SELECT OriginalID FROM VW_CC_DEVONPANO_DealFromDevon )
    -- WHERE NOT EXISTS(SELECT 'X' FROM VW_CC_DEVONPANO_DealFromDevon D
    --                  WHERE D.OriginalID =P.OriginalID)
GO

Un plan d'exécution de chaque vue lorsqu'elles sont lancées de manière individuelle et sans problèmes de perf peut aussi aider.
Pourriez-vous aussi faire un 'set statistics io on' que l'on aie le nombre de scan de chaque index/tables?

[bossun]

Salut Roller,

Alors le Not IN(SELEC *..) ne change rien.. toujours aussi lent..

Voilà les stats pour l'exec de la requete que tu suggéré..

Code :

1
2
3
4
5
6
7
8
Total writes FOR this command: 0
Total writes FOR this command: 0
TABLE: futures scan count 1, logical reads: (regular=11205 apf=0 total=11205), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
TABLE: Instrument scan count 13620199, logical reads: (regular=77688679 apf=0 total=77688679), physical reads: (regular=5821 apf=1057 total=6878), apf IOs used=1044
TABLE: InstrumentLeg scan count 542, logical reads: (regular=2168 apf=0 total=2168), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
TABLE: InstrumentLeg scan count 542, logical reads: (regular=2168 apf=0 total=2168), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
TABLE: Optn scan count 547, logical reads: (regular=2387352 apf=0 total=2387352), physical reads: (regular=5518 apf=0 total=5518), apf IOs used=0
Total writes FOR this command: 3

[Roller]

13620199 de scans de la table instrument, de quoi manger pas mal de cpu.
Petit rappel: il faut éviter d'utiliser les vues car ça limite la possibilité de forcer l'ordre de jointure.
Je n'ai pas eu le plan d'exécution avec le not in, ni celui d'un select(*) pour chacune des vues (êtes-vous sûr qu'elles ne ramènent que 600 lignes?)
Il faudrait si possible l'accompagner du résultat du 'set statistics io on'.

[bossun]

au fait les tables qui composent mes 2 vues de base, contiennent plus de 200'000 lignes en moyenne..

je crois que je vais faire par une autre methode.. je vais faire mes tests dans une procédure en passant par des tables temporaires..

je vais remplir mes tables temporaires depuis mes vues et faire le test directement sur mes tables temporaires..

je vais voir si ça resoud mon problème.

[mpeppler]

Il doit manquer un certain nombre d'indexes...

Il faudrait voir le DDL de chacune des vues, et des tables sous-jacentes (y compris les indexes) pour pouvoir éventuellement donner quelques conseils.

Michael

[bossun]

Je n'ai qu'un accès en lecture sur mes tables sous-jacentes. malheureusement je ne peux rien changer dessus...

Mais il est vrai que la conception de la base est quelques peu spéciale.. L'éditeur ouvre les accès à la base mais pour éviter de copier son schéma, il n'a intégré aucune relation, contrainte, etc.. je ne connais pas tout mais j'ai vu que c'était très très spécial.

Sinon est-ce qu'on peut ajouter des indexes sur les vues?