[MSSQL]Query op view langzaam op 1 id

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • urk_forever
  • Registratie: Juni 2001
  • Nu online
Nevermind, ik heb de indexen gerebuild en gereorganized en nu lijkt het wel goed te gaan.

Hallo allemaal, in een MsSQL database hebben wij een view die de laatste records per id ophaalt een een tabel met veel records. De view ziet er als volgt uit:

SQL:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SELECT TOP (100) PERCENT 
  vehicleengineer,
  positionlongtitude,
  positionlatitude,
  speed,
  course,
  track,
  datetime,
  oid
FROM   dbo.positionlog
WHERE  ( oid IN (SELECT MAX(oid) AS oid
                 FROM   dbo.positionlog AS positionlog_1
                 GROUP  BY vehicleengineer) )
       AND ( NOT ( vehicleengineer IS NULL ) )
       AND (vehicleengineer = hetid)
ORDER  BY datetime DESC


Deze view werkt goed, alleen bij één bepaald record duurt het uitvoeren 22 seconden, terwijl hij voor de andere records binnen een paar milliseconden klaar is.

Als ik de executions plans van beide query's naast elkaar zet dan zit daar inderdaad wat verschil in. Om dat te vergelijken heb ik beide plans opgeslagen en met WinMerge vergeleken. Bij het plan van de snelle query zie ik vervolgens het volgende staan:

code:
1
StatementOptmEarlyAbortReason="GoodEnoughPlanFound"


Dit staat bij de langzame query er niet bij. Heeft iemand tips hoe ik er achter kan komen waarom de query voor het ene id wel een goed plan vindt en voor de andere niet?

[ Voor 10% gewijzigd door NMe op 06-08-2010 13:13 . Reden: Even het doorstrepen weggehaald. ;) ]

Hail to the king baby!


Acties:
  • 0 Henk 'm!

  • PolarBear
  • Registratie: Februari 2001
  • Niet online
Waarom sorteer je de view?

Acties:
  • 0 Henk 'm!

  • P_de_B
  • Registratie: Juli 2003
  • Niet online
Update je statistieken eens.

Oops! Google Chrome could not find www.rijks%20museum.nl


Acties:
  • 0 Henk 'm!

  • urk_forever
  • Registratie: Juni 2001
  • Nu online
@PolarBear: Waarom niet, maakt dat wat uit voor de snelheid?

@P_de_B: Zou dat uit maken voor de snelheid?

Zoals ik heb aangegeven werkt de query nu weer snel na het rebuilden/reorganizen van de indexen.

Hail to the king baby!


Acties:
  • 0 Henk 'm!

  • P_de_B
  • Registratie: Juli 2003
  • Niet online
urk_forever schreef op zaterdag 07 augustus 2010 @ 15:59:
@P_de_B: Zou dat uit maken voor de snelheid?
Zoals ik heb aangegeven werkt de query nu weer snel na het rebuilden/reorganizen van de indexen.
De Query Governor bepaald op basis van de statistieken een executieplan, als de statistieken niet meer up-to-date zijn zou je vreemde resultaten kunnen krijgen. Hij zegt ook dat een goed executieoplan is gevonden en stopt met het zoeken naar een betere. Het zou dus kunnen zijn dat om een of andere reden de statistieken niet meer goed waren.

Oops! Google Chrome could not find www.rijks%20museum.nl