Optimisation performance MS SQL2008

Bonjour,

Nous venons de migrer notre BdD (ERP) d'un WIN SERVER 2003 32 BITS / 4Go RAM / MS SQL 2000 vers un serveur WIN SERVER 2008 64 BITS / 16Go RAM / MS SQL 2008 64 BITS

Je cherche à optimiser le paramétrage de MS SQL pour bénéficier à plein de la nouvelle architecture.
La base n'est pas très grosse (8-9 Go).


Or j'ai quelques questions:

-Comment charger l'intégralité de la base en RAM pour éviter les accès disques.
-Lorsque que je lance une requête, seule un seul des 4 cœurs fonctionne, je n'utilise donc qu'un 1/4 de la puissance. Y-a-t'il un paramétrage pour augmenter le nombre de cœur utilisés?
-Y-a-t'il une limitation de débit réseau dans SQL car lors de certaine taches l'utilisation du réseau reste à 1Mbits au lieur d'exploiter la totalité de la BP.


Je suis désolé si certaine de ces questions vous paraissent idiotes, mais je ne suis pas un expert.

Merci d'avance pour votre aide.

Citation:

---

Envoyé par k-lendos

-Comment charger l'intégralité de la base en RAM pour éviter les accès disques.

---

elle se chargea toute seule à l'usage

Citation:

---

-Lorsque que je lance une requête, seule un seul des 4 cœurs fonctionne, je n'utilise donc qu'un 1/4 de la puissance. Y-a-t'il un paramétrage pour augmenter le nombre de cœur utilisés?

---

tout dépend de la requête. Si elle est d'un cout faible, elle ne sera pas parallélisé. D'autre part, pour bénéficier du parallélisme il faut que TOUT SOIT PARALLÉLISÉ à même niveau. Autrement dit il faut que les, données votre base de production soient répartis sur 4 fichiers disposés sur 4 axes physiques différents (disque). Même chose pour la tempdb.

Citation:

---

-Y-a-t'il une limitation de débit réseau dans SQL car lors de certaine taches l'utilisation du réseau reste à 1Mbits au lieur d'exploiter la totalité de la BP.

---

C 'est l'OS qui s'occupe de la partie réseau... Mais ce n'est pas parce que vous avez telle ou telle BD que vous en bénéficiez automatiquement. Si le système n'a pas besoin ou n'est pas capable de plus, alors il se limitera de lui même...
Question, avez vous achetez un serveur dans une gamme constructeur prévu pour l'usage des SGBDR ? L'architecture interne, notamment au niveau des bus y est différente et spécialement adaptée !

Enfin, la première des optimisation commence par la qualité du modèle relationnel. Si il n'a pas été modélisé en respectant notamment les formes normales et si la base n'a pas été bien indexée, alors vous pourrez toujours mettre un super serveur physique, ce sera comme pisser dans un violon !

A +

Citation:

---

Envoyé par k-lendos

Comment charger l'intégralité de la base en RAM pour éviter les accès disques

---

Le mécanisme est géré par SQL Server. Les seuls paramètres sur lesquels on peut jouer sont relatifs à la taille du cache de données, donc si tu es en 64 bits sur une install standard avec 16 Gb de RAM, SQL Server va allouer au besoin, jusqu'à ce que potentiellement toutes les pages de données et d'index aient suivi au moins un cycle en mémoire.

Citation:

---

Envoyé par k-lendos

Lorsque que je lance une requête, seule un seul des 4 cœurs fonctionne, je n'utilise donc qu'un 1/4 de la puissance. Y-a-t'il un paramétrage pour augmenter le nombre de cœur utilisés?

---

Un batch SQL correspond à une tâche dans SQL Server, et une tâche est associée à un worker (en gros ce qui porte l'exécution du batch dans le moteur relationnel). Intrinsèquement, un worker ne s'exécute que sur un seul CPU à la fois, sauf dans un cas où le coût de la requête est tel que l'optimiseur choisit de compiler un plan en utilisant plusieurs workers, mais encore une fois c'est SQL Server qui cuisine et tu n'as que peu d'influence là-dessus. Donc c'est normal. SQL Server est écrit pour tirer pleinement partie de multiples processeurs, pas de soucis là dessus.

Citation:

---

Envoyé par k-lendos

-Y-a-t'il une limitation de débit réseau dans SQL car lors de certaine taches l'utilisation du réseau reste à 1Mbits au lieur d'exploiter la totalité de la BP.

---

Il y a un paramètre qui définit la taille du paquet échangé entre le serveur et le client. Il est fixé par défaut à 4Kb ce qui convient bien à la plupart des situations. Encore une fois s'il a besoin de prendre plus, il prendra plus.

J'espère que ça t'aide un peu à y voir plus clair.

A+. David B.

Ah désolé Fred j'avais pas vu ta réponse.

David B.

Code:

---

la première des optimisation commence par la qualité du modèle relationnel.

---

Oui c'est vraiment le nerf de la guerre(un modèle de données, des index et un code aux petits oignons) et encore plus avec SQL Server qui ne permet pas ou très peu d'artifices pour contourner certaines mauvaises conceptions...

Et des procédures stockées !!


De quel type d'application s'agit-il ? Nombre d'utilisateurs ?

Citation:

---

Envoyé par kagemaru

[code]
Et des procédures stockées !!

---

Pourquoi tu parles des PS ?

Merci à tous pour vos réponses.

C'est la BdD de notre ERP, je ne suis donc pas maitre du modèle relationnel.
Il y a entre 20 et 30 utilisateurs.
Ce n'est pas énorme, mais aujourd'hui j'ai quand même des perf assez faibles et des temps de réponse assez longs.
Et surtout je ne vois pas d'amélioration de perf lors de ce changement!
C'est un serveur DELL, qui n'est pas spécialement prévu pour les SGBDR.

Je commence à penser que cette base est codée avec les pieds!

Pour info, j'avais fait des tests pour migrer une base sous Win 2003 SQL 2000 et avait fait les constatations suivantes :

> Migrations vers un autre serveur (théoriquement moins puissant) sous Win 2003 SQL 2000 à iso-config (a priori) --> Gain de 24% sur une transaction de référence

> Migrations vers cet autre serveur (théoriquement moins puissant) sous Win 2003 SQL 2008 à iso-config (a priori) --> Gain de 55% sur la même transaction de référence

J'aurais bien fait la migration mais son coût a posé un petit frein à mes velléités !


Et crois-moi, notre ERP n'est même pas codé avec les pied ...... !!!!

regardez le nombre de table temporaire et de curseurs créé. Si c'est lent, il y a de fortes chances que l'on ait utiliser systématiquement ces deux objets....

Auquel cas, les optimisation possibles, même matérielles sont assez inefficaces

A +