[Mirroring] Basculement de bases et exécution de procédures

[_-Sky-_]

Bonjour,

J'ai mis en place le mirroring avec SQL Server 2008. J'ai trois serveurs : le principal (SP), le mirroir (SM) et le témoin (ST). Cela concerne 2 bases que j'appelerais BI et BM.

Au niveau d'une des tables de BI, j'ai créer un trigger qui, sur insertion/modification execute une procédure stockée dans BM. Cependant, lorsque j'ai BI en principal sur l'un des serveurs et BM en principal sur l'autre serveur, cela ne fonctionne pas.

D'où mes questions :
1 - Est-il possible de contrôler les basculements, afin que toutes les bases actives soient sur un seul serveur et non une partie active sur l'un et le reste sur l'autre ?
2 - Existe t'il un moyen simple dans mon trigger de déclencher la procédure de BM indépendemment de la base active (que ce soit sur SP ou SM) ? (je pense actuellement à vérifier la base active par le code)

Merci d'avance

[mikedavem]

Bonjour,

Non il n'est pas possible de contrôler le basculement de plusieurs bases en même temps. (ceci sera possible avec la future version sqlserver code denali).

Autre solution :
Vous pouvez utiliser les alertes wmi avec sqlserver pour détecter un failover et faire basculer votre 2ème base de données.

++

[SQLpro]

Si l'une des bases à besoin des données de l'autre de manière synchrone, c'est que votre système est mal conçu et que vous auriez du faire une seule base !

Dans ce cas, la solution consiste à tout ramener dans une même base en jouant sur les schémas SQL et des vues. Avec une telle solution, il n'est pas nécessaire de modifier le code applicatif en aucune manière, sauf en ce qui concerne la connexion, car il faudra définir des nouveaux utilisateurs, avec pour chacun, une affiliation à un schéma SQL particulier.

A +

[_-Sky-_]

Envoyé par SQLpro

Si l'une des bases à besoin des données de l'autre de manière synchrone, c'est que votre système est mal conçu et que vous auriez du faire une seule base !

Dans ce cas, la solution consiste à tout ramener dans une même base en jouant sur les schémas SQL et des vues. Avec une telle solution, il n'est pas nécessaire de modifier le code applicatif en aucune manière, sauf en ce qui concerne la connexion, car il faudra définir des nouveaux utilisateurs, avec pour chacun, une affiliation à un schéma SQL particulier.

A +

L'idée est intéressante et aurait pu être appliquée si nous avions la maitrise intégrale du système. Or, ce n'est pas le cas et nous devons faire avec ce type de contraintes (séparation des sous-systèmes et des données associées).