none
SQL Server et performance RRS feed

  • 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 !
    mardi 17 janvier 2012 12:22

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
    mardi 17 janvier 2012 13:25
  • 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
    mardi 17 janvier 2012 14:20
  • Bonjour à vous deux,

    J'utilise SQL Server 2005.

    Ma VM possède 4 processeurs.

    Comment vérifier si le parallélisme est activé?

    Merci par avance pour votre aide.

    mardi 17 janvier 2012 16:07
  • 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
    mardi 17 janvier 2012 21:26
  • Bonsoir,

    J'ai 4 processeurs physiques.

    Dans les propriétés de mon serveur, via Management Studio, j'obtiens les résultats suivants:

    Cost Threshold for Parallelism: 5

    Locks: 0

    Max Degree of Parallelism: 0

    Query Wait: -1

    Cordialement

    mercredi 18 janvier 2012 16:20
  • 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.
    jeudi 19 janvier 2012 17:28
  • 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
    vendredi 20 janvier 2012 19:30
    Modérateur
  • 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.
    lundi 23 janvier 2012 08:06
  • 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
    lundi 23 janvier 2012 10:00
    Modérateur