2 instances SQL 2005 sur 2 serveurs : 1 pour écrire et 1 pour lire sur une base centrale. Stupide ? Réalisable ? Autre solution ?

Le
PatriceH
Bonjour à tous,

Nous avons une opération qui s'est montée dernièrement et les performances
de notre serveur SQL ne donne pas entière satisfaction. Outre la recherche
par les développeurs pour l'amélioration des reqûetes et le dimensionnement
supérieur de notre serveur à prévoir, je me demandais s'il était possible
d'avoir une sorte de "cluster" SQL (pas de failover qui sera mis en place de
toute façon ni réplication) qui permettrait d'attaquer une seule base par 2
instances sur 2 serveurs dédiés : 1 instance sur le serveur A dédié aux
écritures sur la base et 1 instance sur le serveur B dédié à la lecture. La
base se trouvant sur le serveur A par exemple.

Est-ce que cela existe ? Il y a-t'il d'autres solutions de ce type ? Si pas
possible, comment optimiser ma solution ?

La config serveur actuelle :
Intel Xeon 3Ghz x 2

4Go RAM

HD 2x300Go en RAID1

OS : Windows 2003 Server SP2FR

SQL Server 2005 SP2 FR.



Merci pour votre aide.

Patrice.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Fred BROUARD
Le #19825351
Bonjour,

PatriceH a écrit :
Bonjour à tous,

Nous avons une opération qui s'est montée dernièrement et les performances
de notre serveur SQL ne donne pas entière satisfaction. Outre la recherche
par les développeurs pour l'amélioration des reqûetes et le dimensionnement
supérieur de notre serveur à prévoir, je me demandais s'il était possible
d'avoir une sorte de "cluster" SQL (pas de failover qui sera mis en place de
toute façon ni réplication) qui permettrait d'attaquer une seule base par 2
instances sur 2 serveurs dédiés : 1 instance sur le serveur A dédié aux
écritures sur la base et 1 instance sur le serveur B dédié à la lecture. La
base se trouvant sur le serveur A par exemple.



A priori ce sera pire, car le système pour recopier des données va
prendre beaucoup de ressources en sus au détriment global (réplication,
service broker, triggers....)

Les causes de mauvaises performances sont nombreuses, et parfois simple.
Le moyen le plus pratique et le plus économique avant des actions tout
azimuts dans le vide est de faire un audit complet. Racheter un serveur
plus costaud alors que ce n'est pas le principal goulet d'étranglement
de votre solution constitue généralement de l'argent jeté par la fenêtre.

Lisez les articles que j'ai écrit sur l'audit et son utilité :
http://www.sqlspot.com/sites/sqlspot.com/IMG/pdf/AuditBaseDeDonnees-3.pdf
et plus encore sur l'optimisation en général de SQL Server.
http://sqlpro.developpez.com/optimisation/

A +


Est-ce que cela existe ? Il y a-t'il d'autres solutions de ce type ? Si pas
possible, comment optimiser ma solution ?

La config serveur actuelle :
Intel Xeon 3Ghz x 2

4Go RAM

HD 2x300Go en RAID1

OS : Windows 2003 Server SP2FR

SQL Server 2005 SP2 FR.



Merci pour votre aide.

Patrice.






--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Publicité
Poster une réponse
Anonyme