changer la priorité d'un SPID de SQL Server

Bonjour,

Je dirais que çà n'est pas possible actuellement.

Cordialement

Christian Robert
MVP SQL Server

"Eric Belhomme" <{rico}+no/spam@ricospirit.net> a écrit dans le message de
groupe de discussion : Xns996370743627Bericbelhommefreefr@212.27.60.40...

Bonjour,

Je vais avoir besoin de lancer de tres grosses procédures stockées sur un
serveur de prod (procédure de migration). Le temps d'exécution de cette
procédure est évalué à plusieurs centaines d'heures !
Bien entendu, pendant ce laps de temps, le serveur continue de fournir le
service habituel, et se usagers ne doivent pas être impactés...

bien que le goulot d'étranglement soit surtout situé au niveau des
tranferts (beaucoup d'I/O sur une baie de disque attachée au serveur, et
de
gros tranferts réseau) je souhaite pouvoir attribuer une priorité basse à
ma procédure.

En regardant dans la doc de sql server, je n'ai trouvé que le "priority
boost" qui permet de modifier la priorité de l'instance de sql server,
mais
rien sur la façon de changer la priorité d'une procédure stockée...

D'où ma question : est-ce-que c'est possible ? et si oui, comment ?

--
Rico

Eric Belhomme a écrit :

Bonjour,

Je vais avoir besoin de lancer de tres grosses procédures stockées sur un
serveur de prod (procédure de migration). Le temps d'exécution de cette
procédure est évalué à plusieurs centaines d'heures !
Bien entendu, pendant ce laps de temps, le serveur continue de fournir le
service habituel, et se usagers ne doivent pas être impactés...

bien que le goulot d'étranglement soit surtout situé au niveau des
tranferts (beaucoup d'I/O sur une baie de disque attachée au serveur, et de
gros tranferts réseau) je souhaite pouvoir attribuer une priorité basse à
ma procédure.

En regardant dans la doc de sql server, je n'ai trouvé que le "priority
boost" qui permet de modifier la priorité de l'instance de sql server, mais
rien sur la façon de changer la priorité d'une procédure stockée...

D'où ma question : est-ce-que c'est possible ? et si oui, comment ?

non, c'est en cours de rélaisation pour la version 2008.

Cepandant si vous pouvez découper votre maj en petits lots de l'ordre de
64 ko ce sera mieux.
De même dimensionnez les fichiers de votre base à leur taille à terme
(data et tran)

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************

Bonjour,

Découper par lot de 64Ko, c'est à dire ? ... ce sont les données qui ne
doivent pas exceder 64ko ? Y'a t'il un moyen simple de determiner la
taille des données que l'on manipule dans une transaction ?

Merci
cdlt
Dimitri


Fred BROUARD a écrit :

Eric Belhomme a écrit :

Bonjour,

Je vais avoir besoin de lancer de tres grosses procédures stockées sur
un serveur de prod (procédure de migration). Le temps d'exécution de
cette procédure est évalué à plusieurs centaines d'heures !
Bien entendu, pendant ce laps de temps, le serveur continue de fournir
le service habituel, et se usagers ne doivent pas être impactés...

bien que le goulot d'étranglement soit surtout situé au niveau des
tranferts (beaucoup d'I/O sur une baie de disque attachée au serveur,
et de gros tranferts réseau) je souhaite pouvoir attribuer une
priorité basse à ma procédure.

En regardant dans la doc de sql server, je n'ai trouvé que le
"priority boost" qui permet de modifier la priorité de l'instance de
sql server, mais rien sur la façon de changer la priorité d'une
procédure stockée...

D'où ma question : est-ce-que c'est possible ? et si oui, comment ?

non, c'est en cours de rélaisation pour la version 2008.

Cepandant si vous pouvez découper votre maj en petits lots de l'ordre de
64 ko ce sera mieux.
De même dimensionnez les fichiers de votre base à leur taille à terme
(data et tran)

A +

Fred BROUARD <brouardf@club-internet.fr> wrote in
news:OXfMvCuvHHA.3560@TK2MSFTNGP02.phx.gbl:

non, c'est en cours de rélaisation pour la version 2008.

C'est bien dommage (et aussi tres étonnant pour un developpeur plus habitué
au c qu'au SQL, qu'un SGBDR dit "sérieux" ne voie ce type de fonction
apparaître qu'après plus de 10 ans d'existence !)

Cepandant si vous pouvez découper votre maj en petits lots de l'ordre
de 64 ko ce sera mieux.
De même dimensionnez les fichiers de votre base à leur taille à terme
(data et tran)

En fait, je fais très peu de modifications sur la base elle-même : ma
procédure balaie mes enregistrements et appelle une fonction utilisateur
qui déplace des fichiers d'une baie de stockage vers une autre, et met à
jour une colonne d'une table pour pointer vers le nouvel emplacement du
fichier. Il y a 10To à déplacer...

Comme j'ai plusieurs bases de données à mouliner de la sorte, j'ai tenté de
lancer en parallèle mon script sur 2 bases différentes, mais j'ai obtenu
une violation d'accès dans ma dll qui contient mes FU... Quelles sont les
précautions à prendre afin de bien isoler les appels à la FU ? Ma dll est
multithreadée, mais peut-être que le protocole d'appel de sqlserver ne
l'est pas ? dans ce cas il me faudrait placer des sémaphores sur mes points
d'entrée afin d'éviter l'accès concurrent à une même fonction ?

Qui a des infos à ce sujet ?

--
Rico