Notion de thread dans SqlServer existe ?

Version imprimable

28/10/2010, 13h36
berceker united

Notion de thread dans SqlServer existe ?

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
28/10/2010, 13h46
Bluedeep

Bonjour

Citation:

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 :D ).

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).
28/10/2010, 14h25
berceker united

Merci pour cette information, je vais continuer mes recherches du coté de SSB !...:ccool:
28/10/2010, 16h08
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 +
28/10/2010, 16h15
Bluedeep

Citation:

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.
28/10/2010, 18h09
SQLpro

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

A +
28/10/2010, 18h32
Bluedeep

Citation:

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).
28/10/2010, 22h20
berceker united

Citation:

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.
29/10/2010, 14h20
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 ...

@++ ;)
07/11/2010, 19h08
berceker united

Citation:

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 :ccool:

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:

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 +

Citation:
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:

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