Discussion :

[BIMDF]

bonjour
On dispose d'un système constitué de
- Deux serveurs physique de production (le premier serveur de prod utilise le système de virtualisation sous VMware il contient donc trois serveurs virtuels (1.Active directory et DNS, 2.Base de données , 3.VCenter) et des machines virtuelles utilisateurs, le deuxième serveur de prod n'est pas encore utilisé.

- Il reste encore trois autres serveur destinés pour test, sauvegarde,...

Nous voulons exploiter au max les serveurs, on s'interesse à la mise en place d'un serveur de test dans le but est que les utilisateurs de la base modifient dans ce serveur sans toucher au serveur de production actif, une fois que l'utilisateur a fini la modification on bascule vers le serveur de production.

Es ce que la solution d'un serveur de test convient à nos besoins?
Peut on réaliser cette étape en utilisant le mirroring?
Est-il obligatoir de passer par un serveur witness?

merci de m'éclaircir svp ces points qui me bloque.

[dbaffaleuf]

En général la logique est plutôt inverse: la recette est recopiée depuis la production à intervalles réguliers, on y joue l'avant mise en prod pour tester les éventuelles régressions, et si cela convient alors on relivre le même scénario en production. Un backup / restore peut suffire à alimenter la recette une fois par semaine par exemple...

[BIMDF]

bonjour
si je comprends bien j'entends par la recette la base de données,
et puis vous proposez la solution de travailler sur une deuxième base de données test dans la même instance et puis une fois que c'est prêt la base de test devient la base de prod en utilisant (backup/restore).

[dbaffaleuf]

Non.

Deux instances, deux bases. Une base de production sur laquelle tourne l'application de production. Une base de recette rechargée à partir de la production par un backup / restore pour avoir la même volumétrie et les mêmes conditions de test, et sur laquelle on valide les changements en production, un genre de répétition générale en quelque sorte. La mise en production consiste en une livraison au format de ton choix (script tsql, powershell, .bat, ssis, etc...)

Première phase: recette. On joue la livraison sur la base de recette, et on lance une batterie de tests fonctionnels (ouvrir l'application, effectuer une action dans l'application,...) pour vérifier si tout fonctionne correctement.

Deuxième phase: mise en production. La synchronisation avec la base de production se fait en rejouant la livraison (le script, le powershell, le .bat ou le package ssis) sur la base de production une fois qu'il a été validé que la modification ne donne pas lieu à une régression quelle qu'elle soit.