du serveur miroir ou du stockage partagé, la continuité de service est assurée. On peut aussi imaginer des solutions de bases mises en miroir et simplement ajouter d’autres réplicas par envoi de journaux ou réplication. On peut aussi obtenir de la haute disponibilité avec répartition de charge en utilisant la réplication et l’équilibrage de charge réseau. Il ne faut pas non plus occulter des possibilités offertes nativement par SQL Server comme les vues partitionnées distribuées, qui vont permettre de répartir les données (et la charge) sur plusieurs instances. Il est aussi intéressant de noter que depuis SQL Server 2005, il est possible d’utiliser la notion de « Scalable Shared Database ».

Les fichiers constituant la base sont stockés sur un disque partagé en lecture seule. Ensuite, il suffit d’attacher cette base en lecture seule sur plusieurs instances SQL, chacune utilisant ses propres ressources matérielles (CPU, mémoire, TempDB). Cette infrastructure procure équilibrage de charge et tolérance de panne pour des bases en lecture seule.

Il n’existe pas de solution idéale en haute disponibilité. D’une part, chaque solution a une granularité différente (publication dans le cadre de la réplication, instance dans le cas d’un cluster et de la virtualisation, base de données pour l’envoi de journaux et la mise en miroir). D’autre part, la haute disponibilité a un coût qu’il ne faut pas négliger et qui doit être en rapport avec les pertes encourues en cas de rupture de service. A chaque situation correspond une stratégie de haute disponibilité. Faites des maquettes, testez les différentes solutions sur un environnement virtuel et prenez conseil auprès de spécialistes pour savoir quelle configuration correspond à vos besoins.