Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

[MSSQL] Stored procedure traag op andere server

Pagina: 1
Acties:

  • jelmervos
  • Registratie: Oktober 2000
  • Niet online

jelmervos

Simple user

Topicstarter
Ik maak gebruik van een stored procedure op een MSSQL 2005 SP2 server welke een nieuw id genereert voor mij. Op mijn server gaat dit super snel (500 keer uitvoeren = 300-400 msecs), maar bij een collega (ook MSSQL 2005 SP2) gaat deze een factor 10 trager. Het gaat om dezelfde database, zelfde server/database instellingen, zelfde computer configuratie.

Hoe kan ik uitzoeken waarom het uitvoeren van dezelfde stored procedure op een andere server veel trager werkt?

Voor de geinteresseerde, hier de stored procedure:
code:
1
2
3
4
5
6
7
8
9
10
11
ALTER PROCEDURE [dbo].[generate_id_internal]
@Generator nvarchar(80)
AS
BEGIN
  DECLARE @Id INT
  BEGIN TRANSACTION
  UPDATE [IdGenerator] SET [LastId] = [LastId] + 1 WHERE [GeneratorName] = @Generator
  SELECT @Id = [LastId] FROM [IdGenerator] WHERE [GeneratorName] = @Generator
  COMMIT TRANSACTION
  RETURN @Id  
END

"The shell stopped unexpectedly and Explorer.exe was restarted."


  • SiErRa
  • Registratie: Februari 2000
  • Laatst online: 29-11 11:11
Zie je verschillen in het queryplan dat gebruikt wordt?

  • jelmervos
  • Registratie: Oktober 2000
  • Niet online

jelmervos

Simple user

Topicstarter
Vergeten te melden inderdaad: het execution plan is precies gelijk, zowel de verschillende nodes als de costs.

Verder zie ik met perfmon dat Batch Requests/sec ook een stuk hoger ligt voor de snelle server.

Zijn er misschien andere interessante MSSQL counters die ik met perfmon even in de gaten kan houden om te achterhalen waarom er zo'n groot verschil is?

[ Voor 52% gewijzigd door jelmervos op 02-11-2007 11:29 ]

"The shell stopped unexpectedly and Explorer.exe was restarted."


  • Niemand_Anders
  • Registratie: Juli 2006
  • Laatst online: 09-07-2024

Niemand_Anders

Dat was ik niet..

En als je de de SQL Server profiler gebruikt? Dan kun je daadwerkelijk zien waar de vertragingen gaan komen. Het query plan is slechts een indicatie. Via de profiler kun je de actuele cijfers terug krijgen zoals CPU time, reads, writes en duration.

Eventueel kun je performance MMC gebruiken om de twee systemen wat beter te vergelijken. Hebben beide dezelfde database, in hoeverre is er al sprake van bestands fragmentatie, hoe vol zijn de hardschrijven, zijn beide systemen op dezelfde manier gepartioneerd?

Er zijn tal van rederen waarom een ander systeem trager kan zijn, maar ik moet toegeven dat een factor 10 wel heel extreem is.

If it isn't broken, fix it until it is..