Discussion :

[kyrilkarlier]

Bonjour à tous,

dans mon entreprise, il a été fait le choix d'acheter un serveur quadri processeur dual-care avec 12Go de RAM.

Dessus j'ai un SQLServer 2005.

Le problème que nous ayons est que dès qu'une "grosse" requête (un renvoie de plusieurs 10aine de millier de lignes) passe sur le serveur et occupe 10 à 15% des ressources processus (sqlservr.exe), cela ralenti toute la boite.

Savez-vous pourquoi et vers quelle piste dois-je me tourner ?

merci,

[dbaffaleuf]

Il peut y avoir des dizaines de raisons différentes. Je commencerais par vérifier la présence de sessions bloquées pendant l'exécution de cette requête:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
SELECT 
    t1.resource_type as lock_type
  , db_name(resource_database_id) as DB
  , t1.resource_associated_entity_id as blkd_obj
  , t1.request_mode as lock_req          -- lock requested
  , t1.request_session_id as waiter_sid-- spid of waiter
  , t2.wait_duration_ms as waittime
  , (SELECT text FROM sys.dm_exec_requests as r  --- get sql for waiter
        CROSS APPLY sys.dm_exec_sql_text (r.sql_handle) 
            WHERE r.session_id = t1.request_session_id) as waiter_batch
  , (SELECT SUBSTRING(qt.text , r.statement_start_offset/2
          , (CASE WHEN r.statement_end_offset = -1 
                THEN LEN(CONVERT(nvarchar(MAX), qt.text)) * 2 
                ELSE r.statement_end_offset END - r.statement_start_offset)/2) 
        FROM sys.dm_exec_requests as r
            CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) as qt
            WHERE r.session_id = t1.request_session_id) as waiter_stmt    --- this is the statement executing right now
   , t2.blocking_session_id as blocker_sid -- spid of blocker
   , (SELECT text FROM sys.sysprocesses as p       --- get sql for blocker
            CROSS APPLY sys.dm_exec_sql_text(p.sql_handle) 
            WHERE p.spid = t2.blocking_session_id) as blocker_stmt
FROM sys.dm_tran_locks as t1 
    JOIN sys.dm_os_waiting_tasks as t2 
        ON t1.lock_owner_address = t2.resource_address

Sur des dizaines de milliers de lignes il peut y avoir une escalade de verrous sur certains objets, mais tout dépend de la requête. Si tu sais déjà de quelle requête il s'agit, essayes d'afficher le plan d'exécution estimé par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
set showplan_text on
<la grosse requête ....>
GO

- Quels sont les critères de recherche ?
- Enuméres les tables impliquées dans la requête. Quelles sont leur volumétrie respective, quels sont les indexes positionnés, sur quelles colonnes, quelle est la dernière date de mise à jour des statistiques sur ces indexes ?

[mikedavem]

Bonjour,

Identifiez la requête qui vous pose problème et regardez le plan d'exécution de celle-ci ..

++

[kyrilkarlier]

En fait cela le fait quelque soit la "grosse" requête passée nous constatons un ralentissement sur les autres postes.

N'est-il pas possible d'avoir plusieurs "instances" en parallèle ?

(je vais voir pour la première piste de mon côté)

Encore merci pour vos réponses

[iberserk]

N'est-il pas possible d'avoir plusieurs "instances" en parallèle ?

Inutile d'en arriver là!

Il y a clairement un soucis au niveau de votre requête comme viennent de vous l'expliquer mikedavem et dbaffaleuf.

Heureusement qu'on ne double pas les serveurs a chaque grosse requête trouvée :-).

Postez ici le plan d’exécution de votre requête ainsi que les information d'IO
en faisant précéder votre requête de SET STATISTICS IO ON puis voyez le résultat dans l'onglet message de SSMS.

[SQLpro]

Vous utilisez CROSS APPLY dans cette requête ce qui dé parallélise. Soit vous supprimez CROSS APPLY et trouvez une autre solution, soit vous ajoutez l'option MAXDOP = 1
En sus vous pouvez faire cette requête au niveau d'isolation READ UNCOMMITTED voire snapshot.

A +