Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

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

1 réponse
Avatar
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.

1 réponse

Avatar
Fred BROUARD
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" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">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/" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">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 *************************