Discussion :

[NULL008]

Hello ,

Je souhaite minimiser le nombre de verrous sur une table principale , la requ�te qui fait le verou est la suivante

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
UPDATE MAT
  SET 
      MAT.NUM_MAT = NULL, 
      MAT.TXT_ERR = 'Error dans le traitement du LOT 1', 
      TS_MAJ_LIN = CONVERT(VARBINARY(8), NEXT VALUE FOR REPLACEROWVERSION)
FROM NATV_PRC_Statition AS MAT
WHERE NOT EXISTS
(
    SELECT 1
    FROM File  AS DOS
    WHERE DOS.COD_EXP = MAT.COD_EXP_SRC
          AND DOS.COD_CEL = MAT.COD_CEL_SRC
          AND DOS.NUM_File = MAT.NUM_File_SRC
)
      AND NUM_MAT =@NUM_MAT 
      AND COD_ERR IS NULL;

Je pense le remplacer par ce qui suit

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
25
26
27
28
29
30
31
32
33
34
35
-- Step 1: Create a temporary results table
CREATE TABLE #TempResults (
    COD_EXP_SRC VARCHAR(50),  -- Adjust the data type as needed
    COD_CEL_SRC VARCHAR(50),
    NUM_File_SRC VARCHAR(50)
);
 
-- Step 2: Insert the rows to be updated into the temporary table
INSERT INTO #TempResults (COD_EXP_SRC, COD_CEL_SRC, NUM_DOS_SRC)
SELECT MAT.COD_EXP_SRC, MAT.COD_CEL_SRC, MAT.NUM_DOS_SRC
FROM NATV_PRC_Statition  AS MAT
WHERE NOT EXISTS (
    SELECT 1
    FROM File AS DOS
    WHERE DOS.COD_EXP = MAT.COD_EXP_SRC 
      AND DOS.COD_CEL = MAT.COD_CEL_SRC 
      AND DOS.NUM_File= MAT.NUM_File_SRC
)
AND MAT.NUM_MAT = @NUM_MAT
AND MAT.COD_ERR IS NULL;
 
-- Step 3: Perform the UPDATE on the main table
UPDATE MAT
SET 
    MAT.NUM_MAT = NULL, 
    MAT.TXT_ERR = 'Matching en attente, dossier source inexistant', 
    TS_MAJ_LIN = CONVERT(VARBINARY(8), NEXT VALUE FOR REPLACEROWVERSION)
FROM MATV3_PRC_DETAIL AS MAT
JOIN #TempResults AS T ON 
    MAT.COD_EXP_SRC = T.COD_EXP_SRC 
    AND MAT.COD_CEL_SRC = T.COD_CEL_SRC 
    AND MAT.NUM_File_SRC = T.NUM_File_SRC;
 
-- Step 4: Drop the temporary results table
DROP TABLE #TempResults;

Pensez-vous que cela pourrait am�liorer les choses ? Est-ce que vous avez d'autres recommandations?
l'option Read commited snapshot est d�ja activ� et l'index a �t� bien position�
merci pour vos retours

[Michel.Priori]

Bonjour,

Comme toujours dans la recherche d'optimisation, il faut d�terminer en premier lieu quel est le point bloquant.
Ici on est en face d'un Update d�pendant d'un Select
Quelle est la partie "bloquante" ?

Pouvez vous fournir

1. le plan d'ex�cution de l'update initial (en image et en XML)
2. Le temps d'ex�cution du select, isol�ment
3. le temps d'ex�cution de l'update initial
4. le type de verrou dont vous souhaitez minimiser le temps de pr�sence

[Aa�����Aa�����Aa����]

Sans les ddl des tables et une id�e des volum�tries en jeu + les plans d'�x�cution, autant faire appel au vaudou pour t'aider

[SQLpro]

Vous n'allez pas forc�ment r�duire le temps d'ex�cution, mais vous allez sans doute avoir des incoh�rences...

En effet en d�coupant votre processus en deux requ�tes, rien n'emp�che un autre utilisateur concurrent de lancer ce m�me processus et par cons�quent d'interf�rer entre vos requ�tes et ses requ�tes. Pour palier � cet inconv�nient il faudrait g�rer une transaction sur l'int�gralit� de votre code ce qui serait � coup sur beaucoup plus long... que la requ�te unique !!!

Le seul moyen efficace de r�duire le temps de verrouillage est d'indexer. Sans parler que votre table temporaire n'est pas index�e...

Avez vous ces deux index :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
INDEX X1 ON NATV_PRC_Statition (NUM_NAT, COD_ERR, NUM_File_SRC, COD_CEL_SRC, COD_EXP_SRC);
INDEX X2 ON [File] (NUM_File, COD_CEL, COD_EXP);

A +

[escartefigue]

Plut�t que de limiter le nombre de verrous, c'est souvent la dur�e qui peut �tre critique.
En ce sens, il est parfois pr�f�rable de poser un seul verrou exclusif pour r�aliser toutes les M�J au d�triment �videmment des threads concurrents, mais pour une dur�e moindre.
Tout d�pend du contexte.