j'ai recu dernierement un message SQLDMO erreur 14258 sur mon serveur
SQL2000 , sur le support j'ai trouvé que la solution etait de
Désactivez la case à cocher Utiliser les fibres Windows NT
en executant le lot suivant:
SP_CONFIGURE 'ALLOW UPDATES', 1
GO
RECONFIGURE WITH OVERRIDE
GO
sp_configure 'lightweight pooling', 0
GO
RECONFIGURE WITH OVERRIDE
GO
je l'ai fait et ca marche , j'ai eu le meme message sur un autre serveur ,
et pareil le probleme est reslolu , par contre je ne comprends pas l'origine
du probleme , d'ou ceci peut venir?? y a til qque chose a fair pour eviter
que ceci se reproduise???
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Philippe TROTIN [MS]
Bonjour,
Normalement l'utilisation des fibres est une option à envisagé uniquement sur un serveur dont le nombre de process actif est très important (plus de 300 par exemple).
Dans ce contexte, les fibres peuvent être utilisées au sein d'un process par processeur et ainsi laisser à l'os faire du contexte switching sur un nombre plus restreint de process et laisser SQL Server se charger de gérer les priorités au sein des fibres.
Cordialement _______________________________
Philippe TROTIN Microsoft Services France _______________________________ "hch" a écrit dans le message de news:
bonjour ,
j'ai recu dernierement un message SQLDMO erreur 14258 sur mon serveur SQL2000 , sur le support j'ai trouvé que la solution etait de Désactivez la case à cocher Utiliser les fibres Windows NT
en executant le lot suivant:
SP_CONFIGURE 'ALLOW UPDATES', 1 GO RECONFIGURE WITH OVERRIDE GO sp_configure 'lightweight pooling', 0 GO RECONFIGURE WITH OVERRIDE GO
je l'ai fait et ca marche , j'ai eu le meme message sur un autre serveur , et pareil le probleme est reslolu , par contre je ne comprends pas l'origine du probleme , d'ou ceci peut venir?? y a til qque chose a fair pour eviter que ceci se reproduise???
SI vous avez des idées ....
Merci d'avance
Bonjour,
Normalement l'utilisation des fibres est une option à envisagé uniquement
sur un serveur dont le nombre de process actif est très important (plus de
300 par exemple).
Dans ce contexte, les fibres peuvent être utilisées au sein d'un process par
processeur et ainsi laisser à l'os faire du contexte switching sur un nombre
plus restreint de process et laisser SQL Server se charger de gérer les
priorités au sein des fibres.
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"hch" <hch@discussions.microsoft.com> a écrit dans le message de
news:BBF577B5-FBB3-44B7-9456-6D326901605D@microsoft.com...
bonjour ,
j'ai recu dernierement un message SQLDMO erreur 14258 sur mon serveur
SQL2000 , sur le support j'ai trouvé que la solution etait de
Désactivez la case à cocher Utiliser les fibres Windows NT
en executant le lot suivant:
SP_CONFIGURE 'ALLOW UPDATES', 1
GO
RECONFIGURE WITH OVERRIDE
GO
sp_configure 'lightweight pooling', 0
GO
RECONFIGURE WITH OVERRIDE
GO
je l'ai fait et ca marche , j'ai eu le meme message sur un autre serveur ,
et pareil le probleme est reslolu , par contre je ne comprends pas
l'origine
du probleme , d'ou ceci peut venir?? y a til qque chose a fair pour eviter
que ceci se reproduise???
Normalement l'utilisation des fibres est une option à envisagé uniquement sur un serveur dont le nombre de process actif est très important (plus de 300 par exemple).
Dans ce contexte, les fibres peuvent être utilisées au sein d'un process par processeur et ainsi laisser à l'os faire du contexte switching sur un nombre plus restreint de process et laisser SQL Server se charger de gérer les priorités au sein des fibres.
Cordialement _______________________________
Philippe TROTIN Microsoft Services France _______________________________ "hch" a écrit dans le message de news:
bonjour ,
j'ai recu dernierement un message SQLDMO erreur 14258 sur mon serveur SQL2000 , sur le support j'ai trouvé que la solution etait de Désactivez la case à cocher Utiliser les fibres Windows NT
en executant le lot suivant:
SP_CONFIGURE 'ALLOW UPDATES', 1 GO RECONFIGURE WITH OVERRIDE GO sp_configure 'lightweight pooling', 0 GO RECONFIGURE WITH OVERRIDE GO
je l'ai fait et ca marche , j'ai eu le meme message sur un autre serveur , et pareil le probleme est reslolu , par contre je ne comprends pas l'origine du probleme , d'ou ceci peut venir?? y a til qque chose a fair pour eviter que ceci se reproduise???
SI vous avez des idées ....
Merci d'avance
SQLpro
Bonjour,
le mode fibre (lightweight pooling) consiste à interdire tout changement de contexte aux processus.
Lorsque vous êtes dans une machine multi processeur, un processus peut être activé sur un processeur puis ne pas avoir finit, être "endormi" par le système et enfin réveillé sur un autre processeur. Si tel est le cas, ce changement de processeur (par exemple le passage du processeur 1 au processeur 2) induit à reclaculer certains éléments de contexte, tels que les registres à utiliser ou encore les translation à effectuer pour les adresses mémoire. C'est le changement de contexte. Pour interdire qu'un tel phénomène se passe et donc avoir l'assurance que le processus soit réveillé toujours sur le même processeur et donc éviter tout changement de contexte, vous devez activer le mode fibre. Cepandant, ce mode est à double tranchant. En effet, si SQL Server coexiste avec de nombreux threads purement système (par exemple du DTS) alors ces derniers risquent d'en pâtir. Vous ne devrier considérer ce mode que si de nombreuses conditions sont réunies : 1) au moins 4 processeur physique sur le serveur 2) avoir dédié 25% de proc au système et les autres à SQL Server (affinity mask) 3) avoir audité et constaté que bien souvent les processeurs sont utilisé à leu maximum (80% au moins) 4) avoir constaté via perfmon qu'il existe un nombre important de changement de contexte 5) que le système n'utilise pas de transactions distribuées avec des serveurs non SQL Server 6) que SQL server n'utilise pas de procédures étendue système (xp_...) 7) qu'il y a peu de process non SQL dans le serveur
En dehors de la simultanéîté de ces considéations, le bénéficie du mode fibdre risque d'être firtement négatif....
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 ***********************
On 5 mar, 20:56, hch wrote:
bonjour ,
j'ai recu dernierement un message SQLDMO erreur 14258 sur mon serveur SQL2000 , sur le support j'ai trouvé que la solution etait de Désactivez la case à cocher Utiliser les fibres Windows NT
en executant le lot suivant:
SP_CONFIGURE 'ALLOW UPDATES', 1 GO RECONFIGURE WITH OVERRIDE GO sp_configure 'lightweight pooling', 0 GO RECONFIGURE WITH OVERRIDE GO
je l'ai fait et ca marche , j'ai eu le meme message sur un autre serveur , et pareil le probleme est reslolu , par contre je ne comprends pas l'orig ine du probleme , d'ou ceci peut venir?? y a til qque chose a fair pour eviter que ceci se reproduise???
SI vous avez des idées ....
Merci d'avance
Bonjour,
le mode fibre (lightweight pooling) consiste à interdire tout
changement de contexte aux processus.
Lorsque vous êtes dans une machine multi processeur, un processus peut
être activé sur un processeur puis ne pas avoir finit, être "endormi"
par le système et enfin réveillé sur un autre processeur. Si tel est
le cas, ce changement de processeur (par exemple le passage du
processeur 1 au processeur 2) induit à reclaculer certains éléments de
contexte, tels que les registres à utiliser ou encore les translation
à effectuer pour les adresses mémoire. C'est le changement de
contexte. Pour interdire qu'un tel phénomène se passe et donc avoir
l'assurance que le processus soit réveillé toujours sur le même
processeur et donc éviter tout changement de contexte, vous devez
activer le mode fibre.
Cepandant, ce mode est à double tranchant. En effet, si SQL Server
coexiste avec de nombreux threads purement système (par exemple du
DTS) alors ces derniers risquent d'en pâtir.
Vous ne devrier considérer ce mode que si de nombreuses conditions
sont réunies :
1) au moins 4 processeur physique sur le serveur
2) avoir dédié 25% de proc au système et les autres à SQL Server
(affinity mask)
3) avoir audité et constaté que bien souvent les processeurs sont
utilisé à leu maximum (80% au moins)
4) avoir constaté via perfmon qu'il existe un nombre important de
changement de contexte
5) que le système n'utilise pas de transactions distribuées avec des
serveurs non SQL Server
6) que SQL server n'utilise pas de procédures étendue système (xp_...)
7) qu'il y a peu de process non SQL dans le serveur
En dehors de la simultanéîté de ces considéations, le bénéficie du
mode fibdre risque d'être firtement négatif....
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
***********************
On 5 mar, 20:56, hch <h...@discussions.microsoft.com> wrote:
bonjour ,
j'ai recu dernierement un message SQLDMO erreur 14258 sur mon serveur
SQL2000 , sur le support j'ai trouvé que la solution etait de
Désactivez la case à cocher Utiliser les fibres Windows NT
en executant le lot suivant:
SP_CONFIGURE 'ALLOW UPDATES', 1
GO
RECONFIGURE WITH OVERRIDE
GO
sp_configure 'lightweight pooling', 0
GO
RECONFIGURE WITH OVERRIDE
GO
je l'ai fait et ca marche , j'ai eu le meme message sur un autre serveur ,
et pareil le probleme est reslolu , par contre je ne comprends pas l'orig ine
du probleme , d'ou ceci peut venir?? y a til qque chose a fair pour eviter
que ceci se reproduise???
le mode fibre (lightweight pooling) consiste à interdire tout changement de contexte aux processus.
Lorsque vous êtes dans une machine multi processeur, un processus peut être activé sur un processeur puis ne pas avoir finit, être "endormi" par le système et enfin réveillé sur un autre processeur. Si tel est le cas, ce changement de processeur (par exemple le passage du processeur 1 au processeur 2) induit à reclaculer certains éléments de contexte, tels que les registres à utiliser ou encore les translation à effectuer pour les adresses mémoire. C'est le changement de contexte. Pour interdire qu'un tel phénomène se passe et donc avoir l'assurance que le processus soit réveillé toujours sur le même processeur et donc éviter tout changement de contexte, vous devez activer le mode fibre. Cepandant, ce mode est à double tranchant. En effet, si SQL Server coexiste avec de nombreux threads purement système (par exemple du DTS) alors ces derniers risquent d'en pâtir. Vous ne devrier considérer ce mode que si de nombreuses conditions sont réunies : 1) au moins 4 processeur physique sur le serveur 2) avoir dédié 25% de proc au système et les autres à SQL Server (affinity mask) 3) avoir audité et constaté que bien souvent les processeurs sont utilisé à leu maximum (80% au moins) 4) avoir constaté via perfmon qu'il existe un nombre important de changement de contexte 5) que le système n'utilise pas de transactions distribuées avec des serveurs non SQL Server 6) que SQL server n'utilise pas de procédures étendue système (xp_...) 7) qu'il y a peu de process non SQL dans le serveur
En dehors de la simultanéîté de ces considéations, le bénéficie du mode fibdre risque d'être firtement négatif....
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 ***********************
On 5 mar, 20:56, hch wrote:
bonjour ,
j'ai recu dernierement un message SQLDMO erreur 14258 sur mon serveur SQL2000 , sur le support j'ai trouvé que la solution etait de Désactivez la case à cocher Utiliser les fibres Windows NT
en executant le lot suivant:
SP_CONFIGURE 'ALLOW UPDATES', 1 GO RECONFIGURE WITH OVERRIDE GO sp_configure 'lightweight pooling', 0 GO RECONFIGURE WITH OVERRIDE GO
je l'ai fait et ca marche , j'ai eu le meme message sur un autre serveur , et pareil le probleme est reslolu , par contre je ne comprends pas l'orig ine du probleme , d'ou ceci peut venir?? y a til qque chose a fair pour eviter que ceci se reproduise???
