Discussion :

[Kropernic]

Bonjour,

Après avoir lu cette discussion (sur laquelle je suis tombé en cherchant pourquoi un serveur sur lequel je fais tourner un job oneshot qui dure plusieurs jours devient lent) où sql pro préconise de limiter la mémoire à disposition de sql server, j'ai voulu faire pareil sur nos nouveaux serveurs que je suis chargé d'installer (ça s'est fait) et configurer (ça s'est en cours).

Tout comme dans la discussion, mon serveur dispose de 16Gb de RAM. J'ai donc limité à 14000Mb la mémoire du serveur (je l'ai encore fait que sur un seul et pas celui sur lequel je job tourne car je me méfie). Pour cela, j'ai fait dans SSMS :
- clic droit sur le nom du serveur
- choisir Properties
- aller dans la page Memory
- modifier la case Maximum server memory (in MB)
- cliquer sur ok.

N.B. : avant modification, voici la valeur qu'il y avait : 2147483647

Depuis, je n'arrive plus à me connecter à ce serveur... J'ouvre SSMS et j'ai bien le petit pop-up Connect to Server dans lequel on entre le nom du serveur et le moyen par lequel on s’authentifie. J'encode tout comme il faut et je clique sur Connect. Après plus rien... SSMS n'expand jamais le serveur comme on peut le voir sur la pièce jointe (j'ai juste masqué le nom du serveur et le nom d'utilisateur).

Quelqu'un aurait-il une suggestion ? Que dois-je faire pour débloquer cette situation ?

Et depuis peu, j'ai le même problème avec le serveur sur lequel le job tourne (alors que je n'ai pas changé son max memory). N'étant pas du tout DBA, je patauge royalement...

[SQLpro]

Je suppose que vous utilisez SSMD sur le serveur lui même, ce qui n'est JAMAIS une bonne pratique.

Utilisez un SSMS distant sur votre poste de travail.

Dans le pire des cas, utilisez SQLcmd en mode DAC en local (sur le serveur).

A +

[Kropernic]

Après un reboot du serveur sur lequel j'ai changé le max memory, j'ai peux de nouveau me connecter.

Je vais donc vérifier dans les propriétés du serveur les paramètres de la mémoire et j'ai bien le 14000 que j'ai entré dans la page mémoire. Par contre, dans la General (où tout est grisé), il affiche 16373 (MB) sur la ligne Memory.

Je ne comprends pas....

[Kropernic]

J'ignorais ce détail.

Pour le serveur (sql2 pour lui donné un nom) sur lequel j'avais changé la mémoire, je tentais effectivement de m'y connecter depuis lui-même (en remote desktop). Depuis, je l'ai redémarré et ça va mieux. Mais j'ai cette incohérence sur la mémoire que j'explique dans mon message précédent.

Par contre, pour le serveur qui exécute ce job interminable (d'après mes estimations, il devrait durer 6 jours ), pas moyen de m'y connecter depuis mon laptop...
Par contre, mon collègue passe mais n'a pas grand chose comme droit sur ce serveur... (il est encore plus noob que moi alors j'ai limité ses droits pour éviter les problèmes).
Est-ce possible que le problème vienne du fait que ce job bouffe toute la mémoire disponible ?
Quand je tente de me connecter avec le compte sa, j'obtiens un timeout car le serveur ne réponds pas... (avec un user windows, ça se connecte mais ça reste en expanding indéfiniment)

[SQLpro]

En 64 bits, si vous laissez faire, le système peut devenir instable et vous pouvez obtenir de sérieux problèmes de performances, voire un "trou noir" du serveur...

En effet, SQL Server consomme toute la RAM, même au détriment de Windows.... Il est prioritaire devant l'OS Windows ! (d'ou machine dédié, avec AUCUNE application dessus !)

Dans le cas ou l'OS en ait besoin, par exemple pour SSMS... S'il n'a pas suffisamment de RAM, il va déclarer un stress mémoire. Dans ce cas, SQL Server va devoir en restituer, ce qu'il fera dès que possible, c'est à dire une fois ses transactions achevées....

Vous commencez à comprendre ce qui va se passer si vous ne réglez pas la RAM : SQL Server va reprendre la RAM rétro cédée et l'on rentre dans un cycle infernal...

A +

[Kropernic]

Tout en étant débutant, j'avais correctement déduis et compris cela.

Concernant le serveur avec le job, il semblerait finalement que le fait que je ne puisse m'y connecter soit du à un problème réseau car je ne pouvais même pas faire un ping (en même temps, je ne touche pas une bille en réseau non plus donc je balance un peu ça dans le vent, j'en saurai plus demain).

Concernant le serveur où j'ai changé le max memory, je ne comprends pas pourquoi je ne pouvais plus m'y connecter qu'après avoir redémarrer la machine. Et même après, pourquoi la mémoire affiché dans la première page est différente de cette affichée dans la page dédiée à la mémoire ?
Je posterai des screenshots demain matin.

Bref, je patauge encore un peu...

[Kropernic]

Et voilà les screenshots promis hier soir.

- sql.jpg où on peut voir le serveur qui reste sur expanding (c'est celui avec le job dont la durée d'exécution est très longue (plusieurs jours)).
Une solution pour récupérer l'accès à ce serveur sans avoir à le restarter ?

- general.jpg où on peut voir la page principale des propriétés du serveur avec, encerclé en rouge, la valeur de la ligne memory.

- memory.jpg où on peut voir la page mémoire des propriétés du serveur avec, encerclé en rouge, la valeur paramétrée.

Pourquoi cette différence dans ces deux derniers screenshots ?

[SQLpro]

Ceci est parfaitement normal.
Le 16 Go est tiré de l'exécution de xp_msver qui donne la mémoire physique du serveur Windows sur lequel est installlée votre instance SQL.
L'autre, le réglage que vous avez effectué.

Bref, au lieu de passer par les IHM qui ne sont pas toujours très compréhensibles (et souvent mal traduites) et qui plus est limitée, utilisez des proc et des requêtes SQL....

A +

[Kropernic]

Ceci est parfaitement normal.
Le 16 Go est tiré de l'exécution de xp_msver qui donne la mémoire physique du serveur Windows sur lequel est installlée votre instance SQL.
L'autre, le réglage que vous avez effectué.

Ok donc c'est correct alors. Je vais faire la modification sur les autres serveurs dans ce cas.

Bref, au lieu de passer par les IHM qui ne sont pas toujours très compréhensibles (et souvent mal traduites) et qui plus est limitée, utilisez des proc et des requêtes SQL....

A +

Je suis bien d'accord avec vous mais il faut les connaître ces procédures stockées et requêtes. 90% de ce que je connais aujourd'hui, je l'ai appris par moi-même sur le tas (et avec l'aide du forum). Les 5% restants venant d'une formation où j'ai appris à faire des procédures stockées '-_-.

Quand il n'y a pas de DBA là où on bosse et qu'on a des serveurs à administrer, on fait avec les moyens qu'on a

[SQLpro]

Il faut envisager sérieusement une formation DBA...

Par exemple votre demande d'arrêter le processus qui vous gène et dure depuis des heures à toute les chances de conduire à une situation bien pire :
soit votre traitement est bloqué et quelques requête dans les tables systèmes vous l'indiquera, soit le traitement s'exécute bien et un arrêt du processus comme du serveur se traduire par un ROLLBACK qui a toute les chances de durer plus encore que ce qui a déjà été fait....

A +

[Kropernic]

Il faut envisager sérieusement une formation DBA...

Je la réclame depuis 2 ans... Vous donnez ce genre de formation ?
J'ai tendance à ne pas faire confiance aux boites dont les formations est leur core business car ils proposent des formations aux programmes alléchant avec plein de mots savants mais qui au final, ne correspondent pas vraiment au besoin...

[SQLpro]

Rudi Bruchez, Arian Papillon et moi même donnons des formations de DBA à Orys ou nous avons monté les cours MS SQL Server de A à Z...

A +

[Kropernic]

Ok bin faudra que je regarde s'ils donnent des formations sur bruxelles...
M'étonnerait que ma boite me paie une semaine à paris