[ASP & MS SQL 2005] Heel raar probleem met COUNT queries

[Urk]

Ik heb echt een heel vaag probleem hier, ik draait Windows Server 2003 R2 + MS SQL 2005 (+SP1).
Sinds gisteravond heb ik een probleem met een van de door mij ontwikkelde websites, het lijkt allemaal te zijn begonnen na de installatie van een Trial versie van Symantec BackupEXEC 11d.
Deze website is geprogrammeerd in classic ASP.

Ik heb gisteravond en vannacht uren gezocht maar krijg het probleem niet opgelost... Ook support.microsoft.com, GoT en Google vind ik geen soortgelijk probleem.

Er is 1 website die flinke performance problemen geeft, in een producten overzicht zitten namelijk een aantal SQL SELECT COUNT queries. Gisteren middag werkte dit nog allemaal perfect, maar opeens sinds gisteravond duurt het minstens 80 seconden om deze pagina te laden en te parsen.
Het bleek na veel debuggen in de SELECT COUNT queries te zitten, als ik deze namelijk uitzet (als commmentaar) dan laadt de pagina heel snel en binnen 1 sec.

Deze queries zien er als volgt uit:

ASP:

Set RS_counter = Server.CreateObject("ADODB.Recordset")
RS_counter.Open "SELECT COUNT(*) AS counter FROM producten WHERE product_subcategorie = " & CInt(RS("productsubcat_id")), DBCon
aantal_totaal = RS_counter("counter")
RS_counter.Close
Set RS_counter = nothing

Het ligt dus niet aan de browser (zoals IE, FF als Opera) geven hetzelfde probleem, ook op een ander systeem en publieke bezoekers krijgen hiermee te maken.
Ook ligt het niet aan de database, alle andere pagina's met diverse queries werken prima en de SELECT COUNT statement direct uitvoeren in SQL Server Management Studio gaat prima zonder problemen.
Het vreemde is dus dat de code ook niet technisch verkeerd is, hij geeft geen foutmelding en het heeft voor gisteravond altijd prima en snel gewerkt! Bizar....

Een aantal van de SELECT COUNT queries zitten in een While loop van een andere recordset, maarja, voor gisteravond maakte dat ook niet uit...

Het lijkt misschien wel te liggen aan een component wat BackupEXEC heeft geupdate (deze maakt namelijk ook een SQL database aan op de SQL server) en wellicht heeft deze communicatie componenten gewijzigd waardoor e.e.a. mis gaat?
Het zit in mijn ogen dus puur in de communicatie tussen de ASP VBScript code en de SQL DB.

Iemand die enig idee heeft wat hier in vredesnaam aan de hand is? Ik heb al diverse dingen geprobeerd (incl. herinstallatie SP1 voor MS SQL 2005) e.d.

Alvast

[ Voor 11% gewijzigd door Urk op 01-02-2007 11:51 ]

[BtM909]

echo eens wat timestamps in je while loop zodat je kan zien of het voor, tijdens of na je iteratie een impact op de performance heeft?

[Urk]

BtM909 schreef op donderdag 01 februari 2007 @ 11:49:
echo eens wat timestamps in je while loop zodat je kan zien of het voor, tijdens of na je iteratie een impact op de performance heeft?

Volgende code:

ASP:

Response.Write "stap 1: " & Now() & "<br />"
RS_counter.Open "SELECT COUNT(*) AS counter FROM producten WHERE product_subcategorie = " & CInt(RS("productsubcat_id")), DBCon
Response.Write "stap 1 " & Now() & "<br />"
 aantal_totaal = RS_counter("counter")
Response.Write "stap 3 " & Now() & "<br />"
RS_counter.Close
Response.Write "stap 4 " & Now() & "<br />"
RS_counter.Open "SELECT COUNT(*) AS counter FROM producten WHERE product_subcategorie = " & CInt(RS("productsubcat_id")) & " AND product_damesheer = 0", DBCon
Response.Write "stap 5 " & Now() & "<br />"
 aantal_dames = RS_counter("counter")
RS_counter.Close
RS_counter.Open "SELECT COUNT(product_id) AS counter FROM producten WHERE product_subcategorie = " & CInt(RS("productsubcat_id")) & " AND product_damesheer = 1", DBCon
 aantal_heren = RS_counter("counter")
RS_counter.Close

Geeft het volgende resultaat:

code:

stap 1: 01/02/2007 12:00:43
stap 2: 01/02/2007 12:00:44
stap 3: 01/02/2007 12:00:44
stap 4: 01/02/2007 12:00:44
stap 5: 01/02/2007 12:00:45
   stap 1: 01/02/2007 12:00:46
stap 2: 01/02/2007 12:00:48
stap 3: 01/02/2007 12:00:48
stap 4: 01/02/2007 12:00:48
stap 5: 01/02/2007 12:00:49
   stap 1: 01/02/2007 12:00:50
stap 2: 01/02/2007 12:00:51
stap 3: 01/02/2007 12:00:51
stap 4: 01/02/2007 12:00:51
stap 5: 01/02/2007 12:00:52
   stap 1: 01/02/2007 12:00:53
stap 2: 01/02/2007 12:00:54
stap 3: 01/02/2007 12:00:54
stap 4: 01/02/2007 12:00:54
stap 5: 01/02/2007 12:00:55
  stap 1: 01/02/2007 12:00:56
stap 2: 01/02/2007 12:00:57
stap 3: 01/02/2007 12:00:57
stap 4: 01/02/2007 12:00:57
stap 5: 01/02/2007 12:00:58
   stap 1: 01/02/2007 12:00:59
stap 2: 01/02/2007 12:01:00
stap 3: 01/02/2007 12:01:00
stap 4: 01/02/2007 12:01:00
stap 5: 01/02/2007 12:01:01
   stap 1: 01/02/2007 12:01:02
stap 2: 01/02/2007 12:01:03
stap 3: 01/02/2007 12:01:03
stap 4: 01/02/2007 12:01:03
stap 5: 01/02/2007 12:01:05
   stap 1: 01/02/2007 12:01:06
stap 2: 01/02/2007 12:01:07
stap 3: 01/02/2007 12:01:07
stap 4: 01/02/2007 12:01:07
stap 5: 01/02/2007 12:01:08
  stap 1: 01/02/2007 12:01:09
stap 2: 01/02/2007 12:01:10
stap 3: 01/02/2007 12:01:10
stap 4: 01/02/2007 12:01:10
stap 5: 01/02/2007 12:01:11
   stap 1: 01/02/2007 12:01:12
stap 2: 01/02/2007 12:01:13
stap 3: 01/02/2007 12:01:13
stap 4: 01/02/2007 12:01:13
stap 5: 01/02/2007 12:01:14
   stap 1: 01/02/2007 12:01:15
stap 2: 01/02/2007 12:01:16
stap 3: 01/02/2007 12:01:16
stap 4: 01/02/2007 12:01:16
stap 5: 01/02/2007 12:01:17
   stap 1: 01/02/2007 12:01:18
stap 2: 01/02/2007 12:01:19
stap 3: 01/02/2007 12:01:19
stap 4: 01/02/2007 12:01:19
stap 5: 01/02/2007 12:01:20
  stap 1: 01/02/2007 12:01:21
stap 2: 01/02/2007 12:01:22
stap 3: 01/02/2007 12:01:22
stap 4: 01/02/2007 12:01:22
stap 5: 01/02/2007 12:01:23
   stap 1: 01/02/2007 12:01:24
stap 2: 01/02/2007 12:01:25
stap 3: 01/02/2007 12:01:25
stap 4: 01/02/2007 12:01:25
stap 5: 01/02/2007 12:01:26
   stap 1: 01/02/2007 12:01:27
stap 2: 01/02/2007 12:01:28
stap 3: 01/02/2007 12:01:28
stap 4: 01/02/2007 12:01:28
stap 5: 01/02/2007 12:01:29
   stap 1: 01/02/2007 12:01:30
stap 2: 01/02/2007 12:01:31
stap 3: 01/02/2007 12:01:31
stap 4: 01/02/2007 12:01:31
stap 5: 01/02/2007 12:01:32

Het lijkt dus echt zo lang te duren bij het uitvoeren van het SELECT COUNT statement op de DB...

Volgens mij heeft BackupEXEC gewoon aan MDAC lopen kutten... bij de preinstallation check van Symantec BackupEXEC noemde BackupEXEC namelijk wel MDAC, dus BackupEXEC gebruikt ook de MDAC versie op het systeem, heeft hij deze wellicht veranderd?

[ Voor 3% gewijzigd door Urk op 01-02-2007 12:06 ]

[dominic]

count(*) is echt de performance killer.. Gebruik dan liever count([veldnaam])

[Urk]

dominic schreef op donderdag 01 februari 2007 @ 12:05:
count(*) is echt de performance killer.. Gebruik dan liever count([veldnaam])

Dat ben ik met je eens en zal ik nog veranderen, maar daarvan blijft de performance traag helaas...

[TeeDee]

Zijn de geplaatste queries ook daadwerkelijk de queries?
Je zou namelijk ook kunnen kijken naar bijvoorbeeld een View, her en der een Join en dat je in 1 keer een complete, nette dataset terugkrijgt.

Zou je trouwens ook kunnen verifieren wat je CursorType, CursorLocation en je LockType is?

[Urk]

TeeDee schreef op donderdag 01 februari 2007 @ 12:45:
Zijn de geplaatste queries ook daadwerkelijk de queries?
Je zou namelijk ook kunnen kijken naar bijvoorbeeld een View, her en der een Join en dat je in 1 keer een complete, nette dataset terugkrijgt.

Je bedoeld dat ik i.p.v. 3 aparte queries maar 1 query gebruik met behulp van bijv. joins?

TeeDee schreef op donderdag 01 februari 2007 @ 12:45:
Zou je trouwens ook kunnen verifieren wat je CursorType, CursorLocation en je LockType is?

Die specificeer ik niet op deze queries, default dus neem ik aan??

[TeeDee]

Urk schreef op donderdag 01 februari 2007 @ 12:51:
[...]

Je bedoeld dat ik i.p.v. 3 aparte queries maar 1 query gebruik met behulp van bijv. joins?

Een view kan je in je Management Studio aanmaken. Dan kan je inderdaad middels joins het e.e.a. in 1 dataset uit poepen.
Voorbeeldje van een view:

[...]

Die specificeer ik niet op deze queries, default dus neem ik aan??

Defaults zijn afaik 0, dus adOpenForwardOnly.

code:

rs.CursorType = 0
rs.CursorLocation = 3
rs.LockType = 3

Voor een trage applicatie hebben we bovenstaande settings gebruikt.

[ Voor 13% gewijzigd door TeeDee op 01-02-2007 13:07 ]

[Urk]

Het werkt helaas nog steeds niet, damn ik krijg het gewoon niet meer goed.
Een join of view maken heeft geen zin in mijn ogen, 1 enkele SELECT COUNT query kost al heel veel tijd!

[Urk]

Deinstallatie van BackupEXEC 11d en herinstallatie van Windows Server 2003 SP1 heeft helaas ook niet geholpen. Damn, wat een vaag en waardeloos probleem. Dit kan ik echt niet uitstaan!

Er is gewoon iets op communicatieniveau die deze belachelijke vertraging veroorzaakt.

Zou het helpen denk jullie om Windows Server 2003 SP2 Release Candidate te installeren? Of is de installatie van een RC Service Pack op een productieomgeving niet aan te raden?

[farlane]

TeeDee schreef op donderdag 01 februari 2007 @ 13:02:
Defaults zijn afaik 0, dus adOpenForwardOnly.

Volgens mij krijg je default een server side cursor, misschien dattie de oorzaak is?
Ff checke http://www.w3schools.com/ado/prop_cursorlocation.asp

Misschien heb je hier wat aan?
http://www.sqljunkies.com...F3-8FC5-25E8946C8D0C.scuk

[ Voor 15% gewijzigd door farlane op 01-02-2007 17:47 ]