[MSSQL]Trage query en het moet anders kunnen.

Pagina: 1
Acties:
  • 105 views sinds 30-01-2008
  • Reageer

  • sopsop
  • Registratie: Januari 2002
  • Laatst online: 07-05 15:06

sopsop

[v] [;,,;] [v]

Topicstarter
Ik heb een Stored Procedure gemaakt die an sich wel doet wat hij moet doen, maar hij is nogal traag en hij vergt wat acties aan de client kant om de gewenste data te verkrijgen.

De functie van deze tabellen is het bijhouden wanneer een applicatie is gestart en wanneer hij is gestopt (tblAppStatus), de tblLog tabel vergaart alle log informatie van een applicatie, maar ook van componenten die door applicaties worden gedaan. Als een component onder een applicatie hangt en een logregel wegschrijft, neemt hij het AppStatusID van de moeder applicatie over. Zo kan ik een compleet beeld krijgen van een run van een applicatie.

De problemen met snelheid doen zich nu voor met het tonen van tblAppStatus records met daarbij de waarden van ID1 t/m 4 uit de logtabel.

De tabelstructuur (vereenvoudigde versie)
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Tabel tblAppStatus
------------------------
AppStatusId
StartTime
EndTime
Source

Tabel tblLog
------------------------
LogId
AppStatusId
LogTime
Source
ID1
ID2
ID3
ID4


Ik wil dus uit deze data een lijst maken met alle appstatusrecords en de gevulde waarde van ID1 t/m ID4 uit de logtabel. Het nadeel is dat die ID-velden niet overal gevuld zijn.

De Querydie ik nu heb:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
SELECT
        tAs.AppStatusId,
        tAs.starttime,
        tAs.endtime,
        tAs.Source,
        tAS.Status, 
        tL.ID1,
        tL.ID2, 
        tL.ID3,
        tL.ID4
FROM tblAppStatus tAS
INNER Join tblLog tL on tAS.AppStatusId=tL.AppStatusId
GROUP BY tAs.AppStatusId,tAS.Source,tAs.starttime,tAs.endtime,tAs.Status,tL.ID1, tL.ID2, tL.ID3, tL.ID4
HAVING ((tAS.Source = @Source) Or (@Source is null))
AND ((tL.ID1 = @ID1) Or (@ID1 is null))
AND ((tL.ID2 = @ID2) Or (@ID2 is null))
AND ((tL.ID3 = @ID3) Or (@ID3 is null))
AND ((tL.ID4 = @ID4) Or (@ID4 is null))
AND ((tL.AppStatusId = @AppStatusId) Or (@AppStatusId is null))
AND ((tAS.status = @AppStatus) Or (@AppStatus is null)) 
AND ((tL.LogTime>= cast(@StartDate as datetime)) 
AND (tL.LogTime<= cast(@EndDate as datetime)))
ORDER BY tAs.AppStatusId DESC


Ik kan dus zoeken op ID1,ID2,ID3,ID4, AppStatusid en LogTime.

Het resultaat dat ik hier uit krijg zijn alle regels waar de dubbele regels gegroepeerd zijn. Ik wil dus hebben dat hij ze op AppStatusID groepeerd en zorgt dat als in die groepering ergens een veld ID1 gevuld is dat die getoond wordt. Zo ook voor ID2, ID3 en ID4. Dit laatste doe ik nu Clientside en dat kan niet de bedoeling zijn.

Ik heb al een werkende versie gehad met subselects, maar die was zo ongelooflijk traag dat het niet werkbaar was.

Welke kant moet ik opzoeken?!

PS: Qua indexen kan ik helaas niets winnen, aangezien die het wegschrijven van logregels zouden vertragen (dat gebeurt namelijk nogal vaak).

  • whoami
  • Registratie: December 2000
  • Laatst online: 01:02
Wat doet die group by en die having daar ?
Je hebt geen aggregate functie, dus heb je die ook niet nodig.

Op welke columns liggen er indexen ?

Waarom gebruik je ene SP, en bouw je die query bv niet client-side op?
In je client kan je nl. nagaan op welke velden de user wil zoeken, en adh daarvan, kan je een veel betere query gaan opbouwen. Dan heb je een helehoop OR's niet meer nodig.

[ Voor 81% gewijzigd door whoami op 05-04-2005 12:06 ]

https://fgheysels.github.io/


  • whoami
  • Registratie: December 2000
  • Laatst online: 01:02
boppert schreef op dinsdag 05 april 2005 @ 11:59:

PS: Qua indexen kan ik helaas niets winnen, aangezien die het wegschrijven van logregels zouden vertragen (dat gebeurt namelijk nogal vaak).
Heb je dmv de profiler al eens gekeken hoeveel dit vertraagd ?

Een clustered index op starttime of endtime of op de combinatie (afhankelijk of er nu meer op starttime, endtime of beiden gezocht wordt), zou al nuttig kunnen zijn.
Het zal zeker voor snelheidswinst zorgen, maar volgens mij is de grootste boosdoener (naast het afwezig zijn van indexen), die vele OR's.

[ Voor 33% gewijzigd door whoami op 05-04-2005 12:12 ]

https://fgheysels.github.io/


  • sopsop
  • Registratie: Januari 2002
  • Laatst online: 07-05 15:06

sopsop

[v] [;,,;] [v]

Topicstarter
Die group by reduceert de output met 70/80% aangezien in het resultaat alleen ID1,ID2,ID3 en ID4 verschillend zijn.

Clientside opbouwen mag ik niet. Alles werkt hierzo met parameterized queries.

De indexen zitten alleen op de PK's (AppStatusID & LogId), dat ik daar niets aan kan doen ligt aan het feit dat de snelheid van het wegschrijven van logrecords erg belangrijk is. De performance wordt een stuk slechter als indexen op andere (combinaties van) velden continu moeten worden bijgewerkt.

Maar mijn eigenlijke vraag is dus: Hoe selecteer uit de bovenstaande tabellen de gevulde waarde van ID1, ID2, ID3 en ID4 uit de records van de tblLog tabel waar de appstatusID gelijk is aan de appstatus, gegroepeerd op appstatusId.

[ Voor 49% gewijzigd door sopsop op 05-04-2005 12:22 ]


  • whoami
  • Registratie: December 2000
  • Laatst online: 01:02
boppert schreef op dinsdag 05 april 2005 @ 12:15:

Clientside opbouwen mag ik niet. Alles werkt hierzo met parameterized queries.
Het is niet omdat je een query clientside opbouwt, dat het daarom geen parametrized query is.

https://fgheysels.github.io/


  • whoami
  • Registratie: December 2000
  • Laatst online: 01:02
boppert schreef op dinsdag 05 april 2005 @ 12:15:
Die group by reduceert de output met 70/80% aangezien in het resultaat alleen ID1,ID2,ID3 en ID4 verschillend zijn.
Die group by is gewoon verkeerd.
Je hebt een distinct nodig in dit geval.
Een group by gebruik je enkel icm met aggregate functies zoals sum(), max(), etc...

https://fgheysels.github.io/


  • sopsop
  • Registratie: Januari 2002
  • Laatst online: 07-05 15:06

sopsop

[v] [;,,;] [v]

Topicstarter
Qua distinct heb je gelijk, maar dat lost mijn probleem niet op.
De geparametreerde queries moeten op de (SQL)server worden opgeslagen.

  • OZ-Gump
  • Registratie: November 2002
  • Laatst online: 14-05-2024

OZ-Gump

terug van weggeweest

De geparametreerde queries moeten op de (SQL)server worden opgeslagen
Dan werk je met Stored Procedures. Een parameterized query is een query waarin je paramteres gebruikt in plaats van string concattenatie om de benodigde where condities in te vullen. En die heb je dus lokaal (client side) staan.

Mijn idee zou ook zijn om dynamisch een parameterized query op te bouwen aan de hand van de door de gebruiker ingevulde velden. Lijkt me stukken sneller.

Overigens cast je de doorgegeven parameters in je SP naar DateTime...? Kun je niet beter de parameter meegeven in het juiste type? Dat zal je ook nogal wat tijdswinst opleveren. Je doet namelijk 2 casts in je SP...

[ Voor 8% gewijzigd door OZ-Gump op 05-04-2005 12:44 ]

My personal website


  • sopsop
  • Registratie: Januari 2002
  • Laatst online: 07-05 15:06

sopsop

[v] [;,,;] [v]

Topicstarter
Ik ben verplicht om alle queries middels een stored procedure aan te roepen. Dat heeft architectuur hier bepaald. Die cast zal ik iig meenemen.

  • P_de_B
  • Registratie: Juli 2003
  • Niet online
Heb je al eens met Query Analyzer gekeken waar de bottleneck ligt?

Je probleem is denk ik toch het ontbreken van indexen op velden die je in je WHERE statement opneemt. Er zal in vrijwel alle gevallen een tablescan gedaan worden, iets dat in een grote tabel erg vertragend zal werken. In sommige gevallen moet je helaas een keus maken tussen INSERT performance en SELECT performance. Ik denk niet dat je het met de opgelegde (enigzins vreemde) beperkingen sneller zult krijgen.

Je kunt overwegen de live data bijvoorbeeld 's nachts naar een tabel te kopieeeren waarop je deze query weer uitvoerd. Je zult in die tabel wel indexen aan kunnen leggen.

Overigens zou ik toch nog even gaan testen hoe erg een index de insert's vertraagd. Misschien valt het wel mee.

[ Voor 4% gewijzigd door P_de_B op 05-04-2005 13:25 ]

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


  • OZ-Gump
  • Registratie: November 2002
  • Laatst online: 14-05-2024

OZ-Gump

terug van weggeweest

Mogelijke extra oplossing is om een aantal vaste SP's te definieren en runtime te bepalen welke van die SP's je nodig hebt. Hiermee kun je enerzijds toch het aantal OR-statements per stored procedure drastisch terugbrengen en anderzijds voldoen aan de opgelegde (inderdaad vreemde) beperkingen.

Ik zeg expres 'mogelijke extra oplossing' omdat het belangrijkste volgens mij toch ook de indexen zullen zijn.

[ Voor 22% gewijzigd door OZ-Gump op 05-04-2005 13:36 ]

My personal website


  • tijn
  • Registratie: Februari 2000
  • Laatst online: 22-03 21:36
Als je performance wilt moet je sowieso af van de 'column_name = @param OR @param IS NULL' constructies. De query optimizer weet hier totaal geen raad mee is mijn ervaring. Daar kan geen index wat aan doen.

Cuyahoga .NET website framework


  • D4Skunk
  • Registratie: Juni 2003
  • Laatst online: 20-10-2025

D4Skunk

Kind of Blue

Met het risico de bal volledig mis te slaan :
Kijk eens of je query een full table scan doet (ik veronderstel het wel gezien de "or x is null"), en er geen indexen op liggen.
Gezien je query toch al een full table scan doet, kun je hem even goed laten vgl met een concatinated string :

SQL:
1
2
3
4
5
Select *
from tbllog
where ID1 & "___" & ID2 & "___" & ID3 & "___" & ID4 & "___" &  AppStatusid =
        @ID1 & "___" & @ID2 & "___" & @ID3 & "___" & @ID4 & "___" &  @AppStatusid 
and logtime between @dateFrom and @dateTo


Dit zien er nogal rare constructs uit, en hebben theoretisch nogal wat bezwaren, maar blijken in de praktijk regelmatig als laatste redmiddel van pas te komen.
Verder stel ik voor dat je leert hoe je een 'explain plan' moet lezen, en de implicaties hiervan snapt; zo is bv een table scan niet altijd de slechtste oplossing.
Voorts is het misschien aan te raden om je tabel in clusters op te slaan, wanneer je geen extra indexen mag aanmaken mbt performantie, kan dit meestal een oplossing vormen. wanneer je bv bijna altijd de tijdsspanne opgeeft mbt het loggen.
Verder zou ik ff aanraden om even met de dba te gaan samenzitten, en hem/haar te vragen wat hij/zij hiervoor de beste oplossing zou vinden.

Succes !!

Verwijderd

Wat is je execution plan, ... waar worden table scans uitgevoerd, etc. Basiskennis bij optimaliseren van queries mbv query analyzer.

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Having clause moven naar de WHERE clause? maar inderdaad, zonder execution plan analyze is het onbegonnen werk.

De OR is null clauses maken het overigens traag denk ik.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


  • curry684
  • Registratie: Juni 2000
  • Laatst online: 07-05 22:49

curry684

left part of the evil twins

boppert schreef op dinsdag 05 april 2005 @ 13:16:
Ik ben verplicht om alle queries middels een stored procedure aan te roepen. Dat heeft architectuur hier bepaald.
Idiots.

Daarnaast: ik zie dat je je tabellen een 'tbl' prefix geeft (zwaar pointless imho), gebruik je voor je SP's ook een prefix? En die is toch hopelijk niet 'sp_'? ;)

[ Voor 4% gewijzigd door curry684 op 07-04-2005 09:32 ]

Professionele website nodig?


  • EfBe
  • Registratie: Januari 2000
  • Niet online
curry684 schreef op donderdag 07 april 2005 @ 09:32:
Daarnaast: ik zie dat je je tabellen een 'tbl' prefix geeft (zwaar pointless imho)
Niet helemaal, je kunt die prefix gebruiken om een table en een view te hebben van dezelfde data, waarbij de tbl prefix de table aangeeft en een vw prefix de view, zodat je beide in een join kunt gebruiken zonder problemen.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

EfBe schreef op donderdag 07 april 2005 @ 11:08:
Niet helemaal, je kunt die prefix gebruiken om een table en een view te hebben van dezelfde data, waarbij de tbl prefix de table aangeeft en een vw prefix de view, zodat je beide in een join kunt gebruiken zonder problemen.
't Idee van een view was toch juist dat het transparant met tables te gebruiken is? Waarom dan verschillende prefixes om aan te geven of iets een view of table is?
Als je exact dezelfde data viewed als je table, dan kan je net zo goed een tweede keer die tabel joinen met een alias en als het andere data is, dan is het zinvol om ook een andere naam te geven.

  • sopsop
  • Registratie: Januari 2002
  • Laatst online: 07-05 15:06

sopsop

[v] [;,,;] [v]

Topicstarter
Och. Ze hebben het gepresteerd dat ze geheugen in een machine hebben bijgeplaatst omdat er een proces met een memory-leak op draaide. |:(
Daarnaast: ik zie dat je je tabellen een 'tbl' prefix geeft (zwaar pointless imho), gebruik je voor je SP's ook een prefix? En die is toch hopelijk niet 'sp_'? ;)
Die prefixen is meer welke voorkeur je hebt. Dat zijn gewoon afspraken hier. En of het nou zinvol is of niet, iedereen doet het wel hetzelfde. En dat heeft weer veel meer voordelen dan nadelen.

Overigens heb ik al 50% snelheidswinst d.m.v. de DISTINCT. Die "group by" zonder aggregate functie was een overblijfsel van een eerdere poging om wel de juiste data binnen te krijgen. Die krijg ik nu ook wel binnen, maar daar zit ook nog wat zooi omheen die ik er clientside weer af moet snoepen.

  • curry684
  • Registratie: Juni 2000
  • Laatst online: 07-05 22:49

curry684

left part of the evil twins

boppert schreef op donderdag 07 april 2005 @ 11:44:
[...]

Och. Ze hebben het gepresteerd dat ze geheugen in een machine hebben bijgeplaatst omdat er een proces met een memory-leak op draaide. |:(
Heb ik meer gehoord :z
Die prefixen is meer welke voorkeur je hebt. Dat zijn gewoon afspraken hier. En of het nou zinvol is of niet, iedereen doet het wel hetzelfde. En dat heeft weer veel meer voordelen dan nadelen.
De reden echter dat ik dit zei is dat SP's met een 'sp_' prefix langzamer worden uitgevoerd dan als je ze een 'gewone' naam geeft ;)

Professionele website nodig?


  • curry684
  • Registratie: Juni 2000
  • Laatst online: 07-05 22:49

curry684

left part of the evil twins

EfBe schreef op donderdag 07 april 2005 @ 11:08:
[...]

Niet helemaal, je kunt die prefix gebruiken om een table en een view te hebben van dezelfde data, waarbij de tbl prefix de table aangeeft en een vw prefix de view, zodat je beide in een join kunt gebruiken zonder problemen.
Wat is het punt van een view als ie dezelfde data afdekt als een table? En als ie niet dezelfde data afdekt, dan mag ie niet dezelfde naam hebben omdat anders 1 van de 2 geen dekkende naam heeft ;)

Professionele website nodig?


  • koli-man
  • Registratie: Januari 2003
  • Laatst online: 01-04 11:43

koli-man

Bartender!!!!

Zou je dit eens toe kunnen lichten?
Ik bedoel voor een insert/update/delete zou ik toch graag SP's willen gebruiken.

[ Voor 32% gewijzigd door koli-man op 07-04-2005 12:02 ]

Hey Isaac...let's go shuffleboard on the Lido - deck...my site koli-man => MOEHA on X-Box laaaiiiff


  • curry684
  • Registratie: Juni 2000
  • Laatst online: 07-05 22:49

curry684

left part of the evil twins

koli-man schreef op donderdag 07 april 2005 @ 12:00:
[...]

Zou je dit eens toe kunnen lichten?
Ik ben groot voorstander van 'Front 'Nee' Tegen Stored Procedures', maar da's hier een beetje offtopic :)

Professionele website nodig?


  • koli-man
  • Registratie: Januari 2003
  • Laatst online: 01-04 11:43

koli-man

Bartender!!!!

curry684 schreef op donderdag 07 april 2005 @ 12:02:
[...]

Ik ben groot voorstander van 'Front 'Nee' Tegen Stored Procedures', maar da's hier een beetje offtopic :)
Die discussie laten we dan hier ook maar zitten :) Maar er moet zeker per situatie naar gekeken worden.

[ Voor 5% gewijzigd door koli-man op 07-04-2005 12:05 ]

Hey Isaac...let's go shuffleboard on the Lido - deck...my site koli-man => MOEHA on X-Box laaaiiiff


  • EfBe
  • Registratie: Januari 2000
  • Niet online
ACM schreef op donderdag 07 april 2005 @ 11:19:
[...]
't Idee van een view was toch juist dat het transparant met tables te gebruiken is? Waarom dan verschillende prefixes om aan te geven of iets een view of table is?
Als je exact dezelfde data viewed als je table, dan kan je net zo goed een tweede keer die tabel joinen met een alias en als het andere data is, dan is het zinvol om ook een andere naam te geven.
Kan, maar je kunt rechten definieren op een view die anders zijn dan die van de table :). Het was een hypothetisch geval overigens. Normaliter zie ik het nut van prefixes zoals 'tbl' ook niet echt in.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
EfBe schreef op donderdag 07 april 2005 @ 12:43:
[...]

Kan, maar je kunt rechten definieren op een view die anders zijn dan die van de table :). Het was een hypothetisch geval overigens. Normaliter zie ik het nut van prefixes zoals 'tbl' ook niet echt in.
Een view is ook niet altijd updateable :Y)

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


  • curry684
  • Registratie: Juni 2000
  • Laatst online: 07-05 22:49

curry684

left part of the evil twins

RobIII schreef op donderdag 07 april 2005 @ 13:34:
[...]

Een view is ook niet altijd updateable :Y)
Als de view identiek is aan de table voldoet ie per definitie aan de criteria voor updatability ;)

Professionele website nodig?


  • whoami
  • Registratie: December 2000
  • Laatst online: 01:02
RobIII schreef op donderdag 07 april 2005 @ 13:34:
[...]

Een view is ook niet altijd updateable :Y)
Een INSTEAD OF trigger kan heel wat oplossen dacht ik .... ;)

https://fgheysels.github.io/


  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
curry684 schreef op donderdag 07 april 2005 @ 16:38:
[...]

Als de view identiek is aan de table voldoet ie per definitie aan de criteria voor updatability ;)
whoami schreef op donderdag 07 april 2005 @ 16:40:
[...]


Een INSTEAD OF trigger kan heel wat oplossen dacht ik .... ;)
*mompelt* ja ja jaaaaaa weet ik ... mierenneukers betweters ;) *mompelt*

* RobIII stands corrected...

[ Voor 3% gewijzigd door RobIII op 07-04-2005 16:48 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Pagina: 1