Notion de thread dans SqlServer existe ?

**berceker united** · 28/10/2010, 14h36

Bonjour,

J'ai une simple question dont j'ai pas trouvé réponse sur Google. Peut être que je donne pas le bon mot clé.
Dans une procédure stocké je souhaite lancer une autre procédure stocké mais que la procédure stocké hôte n'attende pas la fin de celle qui été executé.
En gros. proc A appelle une proc B et pendant que B finit sont boulot A fait la suite.

Je sais qu'il possible de le faire ainsi en passant par un job. Proc A lance le Job qui contient la Proc B. J'aurais souhaité une autre solution que celle-ci.
Donc, est-ce que la notion de thread existe ?

Merci

**Bluedeep** · 28/10/2010, 14h46

Bonjour

Envoyé par berceker united

Donc, est-ce que la notion de thread existe ?

Non, ou, du moins, SQL Server n'expose pas de mécanisme programmatique permettant de travailler explicitement au niveau d'un thread (et c'est assez logique, car, qui dit thread dit présence de mécanismes de synchro - sémaphore, mutex, etc .... - sinon c'est inutilisable).

Ceci dit il y a d'autres moyens de faire cela que le lancement d'un job (enfin, au moins un

).

On va considérer que tu as un traitement principal et un traitement secondaire que tu veux paralléliser. (bien entendu, le principe est ensuite extensible).

Par exemple, ton traitement secondaire est une PS.

Tu va créer une SSBQ qui activera la PS quand un message arrive.

Quand tu veux lancer ton traitement secondaire , ton traitement principal envoit un message sur la SSB Queue en question, ton traitement secondaire démarre, et ton traitement principal continue.

Tu as en même temps un mécanisme de synchro (une deuxième SSBQ où la PS "secondaire" pourra poster son résultat et que ton traitement principal lit quand il en a besoin, en attendant dessus avec WAITFOR par exemple).

**berceker united** · 28/10/2010, 15h25

Merci pour cette information, je vais continuer mes recherches du coté de SSB !...

**SQLpro** · 28/10/2010, 17h08

Quel est le but ? Parce ce que à part faire une usine à gaz transactionnelle de façon à casser les performances, je voit pas trop l'intérêt !

A +

**Bluedeep** · 28/10/2010, 17h15

Envoyé par SQLpro

Quel est le but ? Parce ce que à part faire une usine à gaz transactionnelle de façon à casser les performances, je voit pas trop l'intérêt !

A +

Il peut y avoir un tas de raisons; un cas typique : traitement préalable au lancement d'un ordonnancement Biztalk, alors qu'une autre partie du traitement peut être faite en avance de phase avant la fin de l'exécution de l'ordonnancement.

**SQLpro** · 28/10/2010, 19h09

J'espère que vous ne faites pas ça dans le SGDBDR !

A +

**Bluedeep** · 28/10/2010, 19h32

Envoyé par SQLpro

J'espère que vous ne faites pas ça dans le SGDBDR !

A +

Vous pouvez préciser votre pensée ? je ne doute pas de votre connaissance parfaite de Sql Server (et, très sincérement, elle m'impressionne) mais j'ai l'impression que vous faites semblant d'ignorer par moment que cela ne constitue pas l'alpha et l'omega d'un système d'information.

Donc, en résumé, je ne vois pas ce qu'il y a d'illogique à déclencher un ordonnancement biztalk sur un évenement interne au SGBD.

J'ai même un cas très concret ici (j'entend par là, un cas sur lequel je suis à l'instant).

- Réplication de fusion depuis des bases mobiles.

- Un ordonnancement Biztalk doit effectuer un traitement dès la remontée d'info depus les bases mobiles. (contacter divers applications pour leur dispatcher des infos ).

- Vous pouvez m'expliquer comment je peux le déclencher autrement que via l'envoi d'un message dans une SSBQ, envoi lui même déclenché via un trigger ? (la queue étant écoutée par BZT).

(les problèmes que je rencontre vont d'ailleurs faire l'objet d'une série de questions, car la plateforme de réplication est plus qu'instable en mirroring, à tel point que le mirroring a été suspendu temporairerment).

**berceker united** · 28/10/2010, 23h20

Envoyé par SQLpro

Quel est le but ? Parce ce que à part faire une usine à gaz transactionnelle de façon à casser les performances, je voit pas trop l'intérêt !

A +

En faite, il y a une application qui va lancer un processus qui peut être long je souhaite pas que l'application reste figé le temps du traitement. Nous ne pouvons pas modifier l'application aussi rapidement que modifier une proc. D'où l'idée de lancer un traitement en asynchrone dans le SQL dont le résultat final de ce processus nous intéresse pas.
Pour l'instant c'est en étude mais même si pas utilisé au moins j'aurais appris quelque chose.

**elsuket** · 29/10/2010, 15h20

Bonjour,

Si vous souhaitez faire cela, il vous faut dans votre procédure stockée principale appeler la procédure stockée système msdb.dbo.sp_start_job, et dans ce job (dont vous ne planifiez pas l'exécution) appeler la procédure stockée secondaire ...

@++

**berceker united** · 07/11/2010, 20h08

Envoyé par elsuket

Bonjour,

Si vous souhaitez faire cela, il vous faut dans votre procédure stockée principale appeler la procédure stockée système msdb.dbo.sp_start_job, et dans ce job (dont vous ne planifiez pas l'exécution) appeler la procédure stockée secondaire ...

@++

Bonjour,
En faite, c'était ma première idée. Mais je souhaite l'éviter "pour l'instant". Mais merci de confirmer que ma première idée est viable

**SQLpro** · 07/11/2010, 22h18

Pour tout un tas de raison dont la plus importante est que les SGBDR ont tous un OS interne avec un pas d'horloge qui n'a rien à voir avec celui d'un OS, les interruptions ne doivent en aucun cas être faite à la légère. Et s'amuser à piloter les threads de le sorte peut s'avérer catastrophique.

Le mieux est toujours de se reposer sur l'ordonnanceur propre au SGBDR que vous avez, ici SQL Server, quitte à faire une boucle d'écoute infinie dans une procédure stockée. C'est d'ailleurs comme cela que l'on fait pour écouter des messages Service Broker...

Exemple :

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
36
37
CREATE PROC sp_mytableServiceProgram
AS
SET NOCOUNT ON;
 
DECLARE
    @XML XML,
    @MessageBody VARBINARY(MAX),
    @MessageTypeName nvarchar(256),
    @Dialog UNIQUEIDENTIFIER;
 
-- This procedure continues to process messages in the queue until the
-- queue is empty.
 
WHILE (1 = 1)
BEGIN
    BEGIN TRANSACTION;
    --BEGIN DISTRIBUTED TRANSACTION; --Tried this but didn't help.
 
    -- Receive the next available message
    WAITFOR (
        RECEIVE TOP(1) -- just handle one message at a time
            @MessageTypeName = message_type_name,
            @MessageBody = message_body,
            @Dialog = conversation_handle
            FROM mytableQueue
    ), TIMEOUT 2000 ;
 
    -- If RECEIVE did not return a message, roll back the transaction
    -- and break out of the while loop, exiting the procedure.
    IF (@@ROWCOUNT = 0)
    BEGIN
        ROLLBACK TRANSACTION;
        BREAK;
    END ;
 
    SET @XML = CAST(@MessageBody AS XML);
 ...

A +

**berceker united** · 07/11/2010, 22h33

Envoyé par SQLpro

Pour tout un tas de raison dont la plus importante est que les SGBDR ont tous un OS interne avec un pas d'horloge qui n'a rien à voir avec celui d'un OS, les interruptions ne doivent en aucun cas être faite à la légère. Et s'amuser à piloter les threads de le sorte peut s'avérer catastrophique.

Le mieux est toujours de se reposer sur l'ordonnanceur propre au SGBDR que vous avez, ici SQL Server, quitte à faire une boucle d'écoute infinie dans une procédure stockée. C'est d'ailleurs comme cela que l'on fait pour écouter des messages Service Broker...

Exemple :

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
36
37
CREATE PROC sp_mytableServiceProgram
AS
SET NOCOUNT ON;
 
DECLARE
    @XML XML,
    @MessageBody VARBINARY(MAX),
    @MessageTypeName nvarchar(256),
    @Dialog UNIQUEIDENTIFIER;
 
-- This procedure continues to process messages in the queue until the
-- queue is empty.
 
WHILE (1 = 1)
BEGIN
    BEGIN TRANSACTION;
    --BEGIN DISTRIBUTED TRANSACTION; --Tried this but didn't help.
 
    -- Receive the next available message
    WAITFOR (
        RECEIVE TOP(1) -- just handle one message at a time
            @MessageTypeName = message_type_name,
            @MessageBody = message_body,
            @Dialog = conversation_handle
            FROM mytableQueue
    ), TIMEOUT 2000 ;
 
    -- If RECEIVE did not return a message, roll back the transaction
    -- and break out of the while loop, exiting the procedure.
    IF (@@ROWCOUNT = 0)
    BEGIN
        ROLLBACK TRANSACTION;
        BREAK;
    END ;
 
    SET @XML = CAST(@MessageBody AS XML);
 ...

A +

Ha oauis, pas mal comme idée.
Merci

Notion de thread dans SqlServer existe ?

Développement SQL Server

Discussions similaires

Partager

Partager