ASP/SQL2005 - Ce serveur SQL n'existe pas ou son accès est refusé

Pour reprendre le sujet du problème au complet:

Microsoft OLE DB Provider for SQL Server erreur '80004005'.
[DBNETLIB][ConnectionOpen (Connect()).] Ce serveur SQL n'existe pas ou son
accès est refusé.

--------------------

J'obtiens régulièrement ce problème avec mon site Web dynamique (Windows
2003 SP1, IIS 6 et SQL 2005 SP1 avec Pentium D 3.4 Ghz, 80 Go RAID1 et 1
Go
RAM) lorsque des requête plus ou moins volumineuses sont demandées. Et
lorsque ça se produit les utilisateurs sont incapables de se connecter au
site pour environ 30 à 45 secondes... puis ensuite tout redeviens normal.
Il
arrive parfois qu'entre temps si des usagers essaient de se conencter, il
y
a des erreurs :

Microsoft OLE DB Provider for SQL Server erreur '80004005' différentes, du
genre: délai expiré, erreur de handshake, ...

Après les diagnostics que j'ai fais, il semble que le serveur SQL2005
flanche et rompe toute connexion pendant quelques secondes lorsqu'une
requête est trop grosse à son goût. Ce qui m'intrigue c'est que je n'ai
pas
ce problème avec un autre système monté en parallèle avec les même données
et requêtes depuis ASP... mais c'est SQL2000 et je n'ai pas de problème.

En faisant quelques tests, j'ai vérifié l'utilisation CPU pour voir ce qui
se passait. Lorsque je demande une grosse requête le CPU ne dépasse pas
les
60-65% dans les 2 cores, ça dure 10-15 secondes et après ce délai Poufff
!!!
le CPU tombe à 0% d'utilisation, mais là j'ai pas reçu rien à l'écran du
client Web... j'attends encoe 15-20 secondes et voilà j'obtiens alors
l'erreur: Microsoft OLE DB Provider for SQL Server erreur '80004005'.
[DBNETLIB][ConnectionOpen (Connect()).] Ce serveur SQL n'existe pas ou son
accès est refusé.

Donc on peut remarquer que le traitement des données par SQL s'est
interrompu bien avant le retour de l'information et il y a eu un moment de
"réflexion" à SQL ou IIS avant de retrourner l'erreur.


Avez-vous une idée (ou encore mieux une solution) à ce problème ?

Merci

Bonjour,

Avez-vous installé le SP1 sur votre installation SQL 2005 ?

--
Cordialement.

Romelard Fabrice [MVP]

"Glenn Gagné" <glenn_gagne@hotmail.com> wrote in message
news:u4A4lkjGHHA.1248@TK2MSFTNGP02.phx.gbl...
> Pour reprendre le sujet du problème au complet:
>
> Microsoft OLE DB Provider for SQL Server erreur '80004005'.
> [DBNETLIB][ConnectionOpen (Connect()).] Ce serveur SQL n'existe pas ou

> accès est refusé.
>
> --------------------
>
> J'obtiens régulièrement ce problème avec mon site Web dynamique (Windows
> 2003 SP1, IIS 6 et SQL 2005 SP1 avec Pentium D 3.4 Ghz, 80 Go RAID1 et 1
> Go
> RAM) lorsque des requête plus ou moins volumineuses sont demandées. Et
> lorsque ça se produit les utilisateurs sont incapables de se connecter

> site pour environ 30 à 45 secondes... puis ensuite tout redeviens

> Il
> arrive parfois qu'entre temps si des usagers essaient de se conencter,

> y
> a des erreurs :
>
> Microsoft OLE DB Provider for SQL Server erreur '80004005' différentes,

> genre: délai expiré, erreur de handshake, ...
>
> Après les diagnostics que j'ai fais, il semble que le serveur SQL2005
> flanche et rompe toute connexion pendant quelques secondes lorsqu'une
> requête est trop grosse à son goût. Ce qui m'intrigue c'est que je n'ai
> pas
> ce problème avec un autre système monté en parallèle avec les même

> et requêtes depuis ASP... mais c'est SQL2000 et je n'ai pas de problème.
>
> En faisant quelques tests, j'ai vérifié l'utilisation CPU pour voir ce

> se passait. Lorsque je demande une grosse requête le CPU ne dépasse pas
> les
> 60-65% dans les 2 cores, ça dure 10-15 secondes et après ce délai Poufff
> !!!
> le CPU tombe à 0% d'utilisation, mais là j'ai pas reçu rien à l'écran du
> client Web... j'attends encoe 15-20 secondes et voilà j'obtiens alors
> l'erreur: Microsoft OLE DB Provider for SQL Server erreur '80004005'.
> [DBNETLIB][ConnectionOpen (Connect()).] Ce serveur SQL n'existe pas ou

> accès est refusé.
>
> Donc on peut remarquer que le traitement des données par SQL s'est
> interrompu bien avant le retour de l'information et il y a eu un moment

> "réflexion" à SQL ou IIS avant de retrourner l'erreur.
>
>
> Avez-vous une idée (ou encore mieux une solution) à ce problème ?
>
> Merci
>
>

Pour reprendre le sujet du problème au complet:

Microsoft OLE DB Provider for SQL Server erreur '80004005'.
[DBNETLIB][ConnectionOpen (Connect()).] Ce serveur SQL n'existe pas ou son
accès est refusé.

--------------------

J'obtiens régulièrement ce problème avec mon site Web dynamique (Windows
2003 SP1, IIS 6 et SQL 2005 SP1 avec Pentium D 3.4 Ghz, 80 Go RAID1 et 1
Go
RAM) lorsque des requête plus ou moins volumineuses sont demandées. Et
lorsque ça se produit les utilisateurs sont incapables de se connecter au
site pour environ 30 à 45 secondes... puis ensuite tout redeviens normal.
Il
arrive parfois qu'entre temps si des usagers essaient de se conencter, il
y
a des erreurs :

Microsoft OLE DB Provider for SQL Server erreur '80004005' différentes, du
genre: délai expiré, erreur de handshake, ...

Après les diagnostics que j'ai fais, il semble que le serveur SQL2005
flanche et rompe toute connexion pendant quelques secondes lorsqu'une
requête est trop grosse à son goût. Ce qui m'intrigue c'est que je n'ai
pas
ce problème avec un autre système monté en parallèle avec les même données
et requêtes depuis ASP... mais c'est SQL2000 et je n'ai pas de problème.

En faisant quelques tests, j'ai vérifié l'utilisation CPU pour voir ce qui
se passait. Lorsque je demande une grosse requête le CPU ne dépasse pas
les
60-65% dans les 2 cores, ça dure 10-15 secondes et après ce délai Poufff
!!!
le CPU tombe à 0% d'utilisation, mais là j'ai pas reçu rien à l'écran du
client Web... j'attends encoe 15-20 secondes et voilà j'obtiens alors
l'erreur: Microsoft OLE DB Provider for SQL Server erreur '80004005'.
[DBNETLIB][ConnectionOpen (Connect()).] Ce serveur SQL n'existe pas ou son
accès est refusé.

Donc on peut remarquer que le traitement des données par SQL s'est
interrompu bien avant le retour de l'information et il y a eu un moment de
"réflexion" à SQL ou IIS avant de retrourner l'erreur.


Avez-vous une idée (ou encore mieux une solution) à ce problème ?

Merci

Le fait que le maximum de CPU stagne à 65% peut indiquer que le problème

situe au niveau des Input/Output ou que vous avez des problèmes de lock.

première chose à faire serait évidemment d'augmenter la mémoire; ce qui
devrait aider autant les I/O que les locks.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Glenn Gagné" <glenn_gagne@hotmail.com> wrote in message
news:u4A4lkjGHHA.1248@TK2MSFTNGP02.phx.gbl...
> Pour reprendre le sujet du problème au complet:
>
> Microsoft OLE DB Provider for SQL Server erreur '80004005'.
> [DBNETLIB][ConnectionOpen (Connect()).] Ce serveur SQL n'existe pas ou

> accès est refusé.
>
> --------------------
>
> J'obtiens régulièrement ce problème avec mon site Web dynamique (Windows
> 2003 SP1, IIS 6 et SQL 2005 SP1 avec Pentium D 3.4 Ghz, 80 Go RAID1 et 1
> Go
> RAM) lorsque des requête plus ou moins volumineuses sont demandées. Et
> lorsque ça se produit les utilisateurs sont incapables de se connecter

> site pour environ 30 à 45 secondes... puis ensuite tout redeviens

> Il
> arrive parfois qu'entre temps si des usagers essaient de se conencter,

> y
> a des erreurs :
>
> Microsoft OLE DB Provider for SQL Server erreur '80004005' différentes,

> genre: délai expiré, erreur de handshake, ...
>
> Après les diagnostics que j'ai fais, il semble que le serveur SQL2005
> flanche et rompe toute connexion pendant quelques secondes lorsqu'une
> requête est trop grosse à son goût. Ce qui m'intrigue c'est que je n'ai
> pas
> ce problème avec un autre système monté en parallèle avec les même

> et requêtes depuis ASP... mais c'est SQL2000 et je n'ai pas de problème.
>
> En faisant quelques tests, j'ai vérifié l'utilisation CPU pour voir ce

> se passait. Lorsque je demande une grosse requête le CPU ne dépasse pas
> les
> 60-65% dans les 2 cores, ça dure 10-15 secondes et après ce délai Poufff
> !!!
> le CPU tombe à 0% d'utilisation, mais là j'ai pas reçu rien à l'écran du
> client Web... j'attends encoe 15-20 secondes et voilà j'obtiens alors
> l'erreur: Microsoft OLE DB Provider for SQL Server erreur '80004005'.
> [DBNETLIB][ConnectionOpen (Connect()).] Ce serveur SQL n'existe pas ou

> accès est refusé.
>
> Donc on peut remarquer que le traitement des données par SQL s'est
> interrompu bien avant le retour de l'information et il y a eu un moment

> "réflexion" à SQL ou IIS avant de retrourner l'erreur.
>
>
> Avez-vous une idée (ou encore mieux une solution) à ce problème ?
>
> Merci
>
>

Je ne comprends pas trop là....

J'ai pourtant des requêtes qui font monter le CPU à 80-90% également, ce
sont des requêtes qui exigent beaucoup de calculs, sans être
nécessairement
lourde et dans ce cas je n'ai pas de problème.

Dans mon problème, je voyait plutôt qu'après les 10-15 secondes que SQL
décidait simplement d'arrêter le traitement... et ça de façon aléatoire
(car
des fois en essayant à plusieurs reprises, ça passe).

NOTE: J'ai fais des tests avec quelques requêtes depuis ODBC (via des
feuilles Excel) et j'ai jamais de problèmes.

Je crois vraiment qu'il y a un problème de traitement entre SQL et
ASP(IIS),
je sais pas si ASP ou SQL a des paramètres configurables pour ce genre de
connexions spécifiques (connexions entre les 2).

À priopri, je ne crois pas que ce soit un manque de mémoire vive (j'ai 1
Go
RAM) et l'utilisation de la RAM ne bouge pas lors de ces requêtes.

J'attends d'autres suggestions, merci du coup de pouce !

Glenn



"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:eWy1BrvGHHA.4652@TK2MSFTNGP04.phx.gbl...

Le fait que le maximum de CPU stagne à 65% peut indiquer que le problème

se

situe au niveau des Input/Output ou que vous avez des problèmes de lock.

La

première chose à faire serait évidemment d'augmenter la mémoire; ce qui
devrait aider autant les I/O que les locks.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Glenn Gagné" <glenn_gagne@hotmail.com> wrote in message
news:u4A4lkjGHHA.1248@TK2MSFTNGP02.phx.gbl...
> Pour reprendre le sujet du problème au complet:
>
> Microsoft OLE DB Provider for SQL Server erreur '80004005'.
> [DBNETLIB][ConnectionOpen (Connect()).] Ce serveur SQL n'existe pas ou

son

> accès est refusé.
>
> --------------------
>
> J'obtiens régulièrement ce problème avec mon site Web dynamique
> (Windows
> 2003 SP1, IIS 6 et SQL 2005 SP1 avec Pentium D 3.4 Ghz, 80 Go RAID1 et
> 1
> Go
> RAM) lorsque des requête plus ou moins volumineuses sont demandées. Et
> lorsque ça se produit les utilisateurs sont incapables de se connecter

au

> site pour environ 30 à 45 secondes... puis ensuite tout redeviens

normal.

> Il
> arrive parfois qu'entre temps si des usagers essaient de se conencter,

il

> y
> a des erreurs :
>
> Microsoft OLE DB Provider for SQL Server erreur '80004005' différentes,

du

> genre: délai expiré, erreur de handshake, ...
>
> Après les diagnostics que j'ai fais, il semble que le serveur SQL2005
> flanche et rompe toute connexion pendant quelques secondes lorsqu'une
> requête est trop grosse à son goût. Ce qui m'intrigue c'est que je n'ai
> pas
> ce problème avec un autre système monté en parallèle avec les même

données

> et requêtes depuis ASP... mais c'est SQL2000 et je n'ai pas de
> problème.
>
> En faisant quelques tests, j'ai vérifié l'utilisation CPU pour voir ce

qui

> se passait. Lorsque je demande une grosse requête le CPU ne dépasse pas
> les
> 60-65% dans les 2 cores, ça dure 10-15 secondes et après ce délai
> Poufff
> !!!
> le CPU tombe à 0% d'utilisation, mais là j'ai pas reçu rien à l'écran
> du
> client Web... j'attends encoe 15-20 secondes et voilà j'obtiens alors
> l'erreur: Microsoft OLE DB Provider for SQL Server erreur '80004005'.
> [DBNETLIB][ConnectionOpen (Connect()).] Ce serveur SQL n'existe pas ou

son

> accès est refusé.
>
> Donc on peut remarquer que le traitement des données par SQL s'est
> interrompu bien avant le retour de l'information et il y a eu un moment

de

> "réflexion" à SQL ou IIS avant de retrourner l'erreur.
>
>
> Avez-vous une idée (ou encore mieux une solution) à ce problème ?
>
> Merci
>
>

Alors, allons-y par supposition afin de déterminer si ce serait possible
que
ce soit un problème de performance.

-------------------------------------------------------------

Croyez-vous que: "un serveur HP Proliant DL320 G3 avec 1 Go de RAM, 2
disques durs SATA 80 Go en RAID-1, un processeur Pentium D (IV) 3.4 Ghz et
Windows 2003 Server SP1 Edition Standard en standalone n'ayant que seules
applications en marche IIS 6.0 et SQL 2005 Server SP1 Standard Edition 32
bits (pas de DNS, DHCP, AD ou autre service ni antivirus).

Les 2 disques ne font qu'une unité logique (RAID-1) et est divisée en 2
partitions, Une de 20 Go pour le C: et l'autre de 60 Go pour les fichiers
de
BD SQL.

La mémoire virtuelle fait 1800 Mo fixe.

En temps d'inactivité, l'utilisation CPU est à 0% et l'utilisation du
fichier d'échange est à 920 Mo dont SQL Server s'aproprie 460 Mo, IIS 92
Mo,
ReportingService 46 Mo et le reste sur des tranches de 1 à 20 Mo pour les
services comme lsass, explorer, svchost, ..."

puisse n'être pas suffisant pour une base de donnée que le fichier .MDF
pèse
au total 2 Go seulement et le .LDF 6 Mo ?

---------------------------------------------------------------

Je ne peux pas voir comment une requête ou une procédue stockées puisse
atteindre une limite dans un environnement comme celui là ...

Si oui, S.V.P. me donner une piste ou un diagnostic qui me permettrait de
déterminer d'où vient le problème.

Merci beaucoup

Glenn Gagné
Technicien MCP/TI

Hum, vous semblez être convaincu d'avoir une Ferrari sous la main.
Cependant, comme je n'ai aucune idée du genre de requête que vous faites,

m'est impossible de vous dire si cette configuration est suffisante ou non
pour vos besoins.

L'idéal pour vous serait de suivre les étapes habituelles: mise-à-jour des
indexes (ou des statistiques), vérification des plans de requête pour voir
s'il n'y aurait pas des anomalies de compilation et profiling afin de
déterminer où se situe le problème. Il existe également sur le marché des
outils pour analyser la performance de SQL-Server (malheureusement, la
plupart de ces outils sont $$$).

Si possible, vérifiez que vous n'avez pas de problème de lock ou de
dead-lock.

Ensuite, il y a la possibilité d'augmenter les délais de connection et de
traitement. Si je me souviens bien, les valeurs par défaut sont de 15
secondes et de 30 secondes (ou 90 secondes???) pour l'ASP; peut-être que
vous devriez augmenter ces valeurs.

Finalement, augmenter la mémoire serait également une piste à envisager.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Glenn Gagné" <glenn_gagne@hotmail.com> wrote in message
news:eqpmUOiHHHA.1044@TK2MSFTNGP02.phx.gbl...
> Alors, allons-y par supposition afin de déterminer si ce serait possible
> que
> ce soit un problème de performance.
>
> -------------------------------------------------------------
>
> Croyez-vous que: "un serveur HP Proliant DL320 G3 avec 1 Go de RAM, 2
> disques durs SATA 80 Go en RAID-1, un processeur Pentium D (IV) 3.4 Ghz

> Windows 2003 Server SP1 Edition Standard en standalone n'ayant que

> applications en marche IIS 6.0 et SQL 2005 Server SP1 Standard Edition

> bits (pas de DNS, DHCP, AD ou autre service ni antivirus).
>
> Les 2 disques ne font qu'une unité logique (RAID-1) et est divisée en 2
> partitions, Une de 20 Go pour le C: et l'autre de 60 Go pour les

> de
> BD SQL.
>
> La mémoire virtuelle fait 1800 Mo fixe.
>
> En temps d'inactivité, l'utilisation CPU est à 0% et l'utilisation du
> fichier d'échange est à 920 Mo dont SQL Server s'aproprie 460 Mo, IIS 92
> Mo,
> ReportingService 46 Mo et le reste sur des tranches de 1 à 20 Mo pour

> services comme lsass, explorer, svchost, ..."
>
> puisse n'être pas suffisant pour une base de donnée que le fichier .MDF
> pèse
> au total 2 Go seulement et le .LDF 6 Mo ?
>
> ---------------------------------------------------------------
>
> Je ne peux pas voir comment une requête ou une procédue stockées puisse
> atteindre une limite dans un environnement comme celui là ...
>
> Si oui, S.V.P. me donner une piste ou un diagnostic qui me permettrait

> déterminer d'où vient le problème.
>
> Merci beaucoup
>
> Glenn Gagné
> Technicien MCP/TI
>
>

Merci Sylvain,

Ce genre de réponse est apprécié ! En passant, non je ne m'imagine pas
avoir
une Ferrari sous la main... mais c'est que ce même genre de requête
fonctionnait sans de problème avec un serveur Pentium III 1200 Mhz,
Windows
2000 et SQL 2000... Alors pourquoi qu'un Pentium D 3.4 Ghz, 1 Go RAM avec
Windows 2003 et SQL 2005 ne pourrais plus répondre .... !

Glenn


"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:uAvxEBnHHHA.1188@TK2MSFTNGP06.phx.gbl...

Hum, vous semblez être convaincu d'avoir une Ferrari sous la main.
Cependant, comme je n'ai aucune idée du genre de requête que vous faites,

il

m'est impossible de vous dire si cette configuration est suffisante ou
non
pour vos besoins.

L'idéal pour vous serait de suivre les étapes habituelles: mise-à-jour
des
indexes (ou des statistiques), vérification des plans de requête pour
voir
s'il n'y aurait pas des anomalies de compilation et profiling afin de
déterminer où se situe le problème. Il existe également sur le marché
des
outils pour analyser la performance de SQL-Server (malheureusement, la
plupart de ces outils sont $$$).

Si possible, vérifiez que vous n'avez pas de problème de lock ou de
dead-lock.

Ensuite, il y a la possibilité d'augmenter les délais de connection et de
traitement. Si je me souviens bien, les valeurs par défaut sont de 15
secondes et de 30 secondes (ou 90 secondes???) pour l'ASP; peut-être que
vous devriez augmenter ces valeurs.

Finalement, augmenter la mémoire serait également une piste à envisager.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Glenn Gagné" <glenn_gagne@hotmail.com> wrote in message
news:eqpmUOiHHHA.1044@TK2MSFTNGP02.phx.gbl...
> Alors, allons-y par supposition afin de déterminer si ce serait
> possible
> que
> ce soit un problème de performance.
>
> -------------------------------------------------------------
>
> Croyez-vous que: "un serveur HP Proliant DL320 G3 avec 1 Go de RAM, 2
> disques durs SATA 80 Go en RAID-1, un processeur Pentium D (IV) 3.4 Ghz

et

> Windows 2003 Server SP1 Edition Standard en standalone n'ayant que

seules

> applications en marche IIS 6.0 et SQL 2005 Server SP1 Standard Edition

32

> bits (pas de DNS, DHCP, AD ou autre service ni antivirus).
>
> Les 2 disques ne font qu'une unité logique (RAID-1) et est divisée en 2
> partitions, Une de 20 Go pour le C: et l'autre de 60 Go pour les

fichiers

> de
> BD SQL.
>
> La mémoire virtuelle fait 1800 Mo fixe.
>
> En temps d'inactivité, l'utilisation CPU est à 0% et l'utilisation du
> fichier d'échange est à 920 Mo dont SQL Server s'aproprie 460 Mo, IIS
> 92
> Mo,
> ReportingService 46 Mo et le reste sur des tranches de 1 à 20 Mo pour

les

> services comme lsass, explorer, svchost, ..."
>
> puisse n'être pas suffisant pour une base de donnée que le fichier .MDF
> pèse
> au total 2 Go seulement et le .LDF 6 Mo ?
>
> ---------------------------------------------------------------
>
> Je ne peux pas voir comment une requête ou une procédue stockées puisse
> atteindre une limite dans un environnement comme celui là ...
>
> Si oui, S.V.P. me donner une piste ou un diagnostic qui me permettrait

de

> déterminer d'où vient le problème.
>
> Merci beaucoup
>
> Glenn Gagné
> Technicien MCP/TI
>
>

La première réponse qui vient à l'esprit serait de dire que les besoins

SQL-2005 sont plus importants que pour SQL-2000 et que SQL-2005 travaille
mal avec seulement 1Gigs.

La réponse suivante serait que vous avez un problème de lock ou de
dead-lock. C'est une chose amusante que des problèmes de lock peuvent
apparaître simplement en changeant de machine; cela même lorsque la

machine est plus rapide que l'ancienne; avec comme résultat le problème

l'on connaît.

Finalement, si vous avez tout copié de la première à la deuxième machine;
vous avez peut-être oublié de créer certains indexes ou de recompiler les
statistiques.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Glenn Gagné" <glenn_gagne@hotmail.com> wrote in message
news:uYwzyzrHHHA.2236@TK2MSFTNGP02.phx.gbl...
> Merci Sylvain,
>
> Ce genre de réponse est apprécié ! En passant, non je ne m'imagine pas
> avoir
> une Ferrari sous la main... mais c'est que ce même genre de requête
> fonctionnait sans de problème avec un serveur Pentium III 1200 Mhz,
> Windows
> 2000 et SQL 2000... Alors pourquoi qu'un Pentium D 3.4 Ghz, 1 Go RAM

> Windows 2003 et SQL 2005 ne pourrais plus répondre .... !
>
> Glenn
>
>
> "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>

> écrit dans le message de news:uAvxEBnHHHA.1188@TK2MSFTNGP06.phx.gbl...
>> Hum, vous semblez être convaincu d'avoir une Ferrari sous la main.
>> Cependant, comme je n'ai aucune idée du genre de requête que vous

> il
>> m'est impossible de vous dire si cette configuration est suffisante ou
>> non
>> pour vos besoins.
>>
>> L'idéal pour vous serait de suivre les étapes habituelles: mise-à-jour
>> des
>> indexes (ou des statistiques), vérification des plans de requête pour
>> voir
>> s'il n'y aurait pas des anomalies de compilation et profiling afin de
>> déterminer où se situe le problème. Il existe également sur le marché
>> des
>> outils pour analyser la performance de SQL-Server (malheureusement, la
>> plupart de ces outils sont $$$).
>>
>> Si possible, vérifiez que vous n'avez pas de problème de lock ou de
>> dead-lock.
>>
>> Ensuite, il y a la possibilité d'augmenter les délais de connection et

>> traitement. Si je me souviens bien, les valeurs par défaut sont de 15
>> secondes et de 30 secondes (ou 90 secondes???) pour l'ASP; peut-être

>> vous devriez augmenter ces valeurs.
>>
>> Finalement, augmenter la mémoire serait également une piste à

>>
>> --
>> Sylvain Lafontaine, ing.
>> MVP - Technologies Virtual-PC
>> E-mail: sylvain aei ca (fill the blanks, no spam please)
>>
>>
>> "Glenn Gagné" <glenn_gagne@hotmail.com> wrote in message
>> news:eqpmUOiHHHA.1044@TK2MSFTNGP02.phx.gbl...
>> > Alors, allons-y par supposition afin de déterminer si ce serait
>> > possible
>> > que
>> > ce soit un problème de performance.
>> >
>> > -------------------------------------------------------------
>> >
>> > Croyez-vous que: "un serveur HP Proliant DL320 G3 avec 1 Go de RAM, 2
>> > disques durs SATA 80 Go en RAID-1, un processeur Pentium D (IV) 3.4

> et
>> > Windows 2003 Server SP1 Edition Standard en standalone n'ayant que
> seules
>> > applications en marche IIS 6.0 et SQL 2005 Server SP1 Standard

> 32
>> > bits (pas de DNS, DHCP, AD ou autre service ni antivirus).
>> >
>> > Les 2 disques ne font qu'une unité logique (RAID-1) et est divisée en

>> > partitions, Une de 20 Go pour le C: et l'autre de 60 Go pour les
> fichiers
>> > de
>> > BD SQL.
>> >
>> > La mémoire virtuelle fait 1800 Mo fixe.
>> >
>> > En temps d'inactivité, l'utilisation CPU est à 0% et l'utilisation du
>> > fichier d'échange est à 920 Mo dont SQL Server s'aproprie 460 Mo, IIS
>> > 92
>> > Mo,
>> > ReportingService 46 Mo et le reste sur des tranches de 1 à 20 Mo pour
> les
>> > services comme lsass, explorer, svchost, ..."
>> >
>> > puisse n'être pas suffisant pour une base de donnée que le fichier

>> > pèse
>> > au total 2 Go seulement et le .LDF 6 Mo ?
>> >
>> > ---------------------------------------------------------------
>> >
>> > Je ne peux pas voir comment une requête ou une procédue stockées

>> > atteindre une limite dans un environnement comme celui là ...
>> >
>> > Si oui, S.V.P. me donner une piste ou un diagnostic qui me

> de
>> > déterminer d'où vient le problème.
>> >
>> > Merci beaucoup
>> >
>> > Glenn Gagné
>> > Technicien MCP/TI
>> >
>> >
>>
>>
>
>