[sql server 2000] sommige sp's worden traag uitgevoerd

[LordMorgoth]

ik zit met het volgende probleem.

Een paar stored procedures op een aantal databases op onze SQL 2000 machine zijn af en toe niet vooruit te branden. Een vage omschrijving, ik weet het...

Een stored procedure die normaal gesproken 4 minuten duurt, duurt dan ineens 30 tot 45 minuten. Het gaat om een sp die een berg met data uit leest op de lokale pc en vandaar in de database in de SQL server stopt en die dan vergelijkt met de data in een andere database.

Op de SQL server schiet de cpu usage van beide processoren tijdens het proces naar 30-40%.

Wanneer je tijdens het proces de volgende twee sp's draait, gaat de cpu usage weer omlaag en word het proces wel netjes na een minuut of 3 uitgevoerd. Maar dit werkt dus alleen als je de sp's draait tijdens het uitvoeren van het proces!

code:

sp_createstats 'fullscan'
GO
sp_updatestats 'resample'

Om het nog vager te maken: op sommige databases gaat het wel goed, en alle databases zijn aangemaakt op basis van 1 standaard template database!

De SQL server heeft de volgende specificaties:

HP DL380G4
2 * Xeon 3,4Ghz
2 GB RAM
3 * 72 GB 15k schijven in Raid 5
SQL server 2000 met Service pack 3
Windows 2000 met alle service packs en updates

[LordMorgoth]

*kick* Niemand?

[AcoLyte!]

heb je de 'exectution plan' wel eens bekeken als je deze SP's draait?
draai anders eens de profiler mee.. hoe zit het trouwens met indexeringen? veel tijd
gaat verloren met het zoeken in de 'heap'.. dat zie je trouwens keurig op je
execution plan verschijnen. Prima manier om te tunen..

[StevenK]

LordMorgoth schreef op vrijdag 24 november 2006 @ 10:12:
ik zit met het volgende probleem.

Een paar stored procedures op een aantal databases op onze SQL 2000 machine zijn af en toe niet vooruit te branden. Een vage omschrijving, ik weet het...

Een stored procedure die normaal gesproken 4 minuten duurt, duurt dan ineens 30 tot 45 minuten. Het gaat om een sp die een berg met data uit leest op de lokale pc en vandaar in de database in de SQL server stopt en die dan vergelijkt met de data in een andere database.

Kan het zijn dat je het spul in een volgorde die afwijkt van de clustered index in de DB stampt ? Of ontbreekt er gewoon ergens een index ?

[Paul]

AcoLyte!: Het is zo te horen niet zo dat de SP _altijd_ traag is, maar dat deze meestal normaal werkt, maar af en toe ineens 10x zoveel tijd nodig heeft.

LordMorgoth: Is er een constante te vinden in de keren dat het traag gaat, bij voorkeur iets dat tevens uniek is voor de trage keren ?
Steeds dezelfde client-pc waar de data vandaan moet komen?
Steeds dezelfde bron waar die data vandaan komt?
Steeds op woensdag om 13:56?

[LordMorgoth]

Wat ik echt niet snap van het hele verhaal is waarom de SP in eens wel doorloopt wanneer je *tijdens* het uitvoeren van de SP de volgende sp's draait...

code:

sp_createstats 'fullscan'
GO
sp_updatestats 'resample'

Paul Nieuwkamp schreef op maandag 04 december 2006 @ 11:09:
LordMorgoth: Is er een constante te vinden in de keren dat het traag gaat, bij voorkeur iets dat tevens uniek is voor de trage keren ?
Steeds dezelfde client-pc waar de data vandaan moet komen?
Steeds dezelfde bron waar die data vandaan komt?
Steeds op woensdag om 13:56?

Het enige is dat er iedere avond er een backup gemaakt word van de databases met Veritas Backup Exec 9.1. Veritas maakt gebruik van de SQL agent. Ik heb al gezocht op in de KB's van Veritas, maar kan daar niks gerelateerds vinden.

[ Voor 72% gewijzigd door LordMorgoth op 04-12-2006 12:14 ]