Auteur de questions
SQL Server et performance

Discussion générale
-
Bonjour,
Mon serveur virtuel (Windows Server 2003) héberge un serveur de base de données SQL Server.
Tous les matins, un job tourne pendant en moyenne 2h.
J'ai voulu raccourcir ce temps en ajoutant un CPU (manipulation faite à distance par quelqu'un d'autre).
Résultat, le job prend 3h maintenant à s'éxécuter.
Je ne sais pas où chercher le problème, avez-vous une piste pour commencer?
Merci par avance !- Déplacé Bechir GharbiModerator mardi 17 janvier 2012 14:57 (Origine :Windows Server 2003 (et versions anterieures: Windows Server 2000, Windows NT Server))
- Type modifié Roxana PANAITMicrosoft employee vendredi 27 janvier 2012 15:41 attente de feedback
- Type modifié Roxana PANAITMicrosoft employee vendredi 27 janvier 2012 15:42 attente de feedback
Toutes les réponses
-
Bonjour,
Vérifier le type de licence SQL installé sur votre serveur, si vous être entrain d'utiliser le mode de licence par processeur vous devez vérifier vos licences installées :
http://www.faqxp.com/f/495.asp
Best Regards- Modifié Thameur BOURBITAMVP mardi 17 janvier 2012 13:28
-
Bonjour,
Vous avez posté votre question dans le forum windows 2003, il fallait la poser sur le forum SQL server.
@Bourbita Thameur: Les licences SQL sont des licences morale.
@Imageek: Quelle est la version de SQL utilisée?
Le nombre de processeur de la VM dépasse il celui de la machine physique?
Avez vous activer le parallelisme?
A+
Best Regards Don't forget to mark it as answer if it helps -
-
Bonsoir,
Combien vous avez de processeur physiques ?
Pour le parallélisme,au niveau de management studio, clic droit sur le nom de serveur, selectionner "propriété", puis "avancé"...
cordialement;
Best Regards Don't forget to mark it as answer if it helps -
-
Regarder les attentes sur l'instance:
WITH Waits AS (SELECT wait_type, wait_time_ms / 1000.0 AS WaitS, (wait_time_ms - signal_wait_time_ms) / 1000.0 AS ResourceS, signal_wait_time_ms / 1000.0 AS SignalS, waiting_tasks_count AS WaitCount, 100.0 * wait_time_ms / SUM (wait_time_ms) OVER() AS Percentage, ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS RowNum FROM sys.dm_os_wait_stats WHERE wait_type NOT IN ( 'CLR_SEMAPHORE', 'LAZYWRITER_SLEEP', 'RESOURCE_QUEUE', 'SLEEP_TASK', 'SLEEP_SYSTEMTASK', 'SQLTRACE_BUFFER_FLUSH', 'WAITFOR', 'LOGMGR_QUEUE', 'CHECKPOINT_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BROKER_TO_FLUSH', 'BROKER_TASK_STOP', 'CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT', 'DISPATCHER_QUEUE_SEMAPHORE', 'FT_IFTS_SCHEDULER_IDLE_WAIT', 'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'BROKER_EVENTHANDLER', 'TRACEWRITE', 'FT_IFTSHC_MUTEX', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP', 'BROKER_RECEIVE_WAITFOR', 'ONDEMAND_TASK_QUEUE', 'DBMIRROR_EVENTS_QUEUE', 'DBMIRRORING_CMD', 'BROKER_TRANSMITTER', 'SQLTRACE_WAIT_ENTRIES', 'SLEEP_BPOOL_FLUSH', 'SQLTRACE_LOCK') ) SELECT W1.wait_type AS WaitType, CAST (W1.WaitS AS DECIMAL(14, 2)) AS Wait_S, CAST (W1.ResourceS AS DECIMAL(14, 2)) AS Resource_S, CAST (W1.SignalS AS DECIMAL(14, 2)) AS Signal_S, W1.WaitCount AS WaitCount, CAST (W1.Percentage AS DECIMAL(4, 2)) AS Percentage, CAST ((W1.WaitS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgWait_S, CAST ((W1.ResourceS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgRes_S, CAST ((W1.SignalS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgSig_S FROM Waits AS W1 INNER JOIN Waits AS W2 ON W2.RowNum <= W1.RowNum GROUP BY W1.RowNum, W1.wait_type, W1.WaitS, W1.ResourceS, W1.SignalS, W1.WaitCount, W1.Percentage HAVING SUM (W2.Percentage) - W1.Percentage < 95; -- percentage threshold GO
Et la date de dernier restart de l'instance :
select create_date from sys.databases where database_id=2
David B. -
On a demandé sur developpez :-)
cf réponse
Mais comme je disais, ce n'est pas forcément significatif si le package SSIS est lancé une fois sur un intervalle important et qu'il existe d'autres attentes qu se produisent à grande quantité On ne verra rien et d'ailleurs c'est le cas dans le résultat.
Est ce que le temps d'exécution de votre lot SSIS diminue en paramétrant l'option max degree of parallelism au nombre de processeurs avant votre changement ?
++
MCDBA | MCITP SQL Server 2005 / SQL Server 2008 | LPI Linux 1 -
Salut David,
En SQL 2005 malheureusement pas de xevents donc pas beaucoup de moyens de tracer les attentes par session sinon de poller sys.dm_os_waiting_tasks pour le session_id correspondant, mais avec deux inconvénients: on rate des évènements et on freine encore plus le traitement...
Après comme le traitement est lancé tous les matins, et si ça ne pose pas trop de problème, on peut faire un dbcc sqlperf('sys.dm_os_wait_stats',clear) juste avant et resampler la vue juste à la fin du traitement ?
David B. -
C'est vrai on risque de freiner un peu mais bon avec 2005 ...
Effectivement j'avais pensé au clear des stats mais en production avant et récupération des données avant et après traitement pour avoir qqch de plus précis .. A voir si cela est possible dans le contexte de production de Imageek1337.
++
MCDBA | MCITP SQL Server 2005 / SQL Server 2008 | LPI Linux 1