Discussion :

[mad_martigan]

Bonjour,

Je dois mettre en place un plan de continuité d'activité pour une base de données qui contient plus de 76000 tables entre un serveur A et un serveur B.
L'activité doit reprendre dans les 10 minutes sur le serveur B si le serveur A a crashé.

Cette base est utilisée par un logiciel de compta, donc pas modifiable.

Chaque année de nouvelles tables sont créées par le logiciel.

Certaines tables font référence au nom du serveur, il faut donc que celui-ci soit filtré et changé lorsque la table est répliquée.

Ma question est la suivante : est-ce que la réplication de fusion peut gérer 76000 tables et plus?

Merci d'avance!

[SQLpro]

Bonjour,

Je dois mettre en place un plan de continuité d'activité pour une base de données qui contient plus de 76000 tables entre un serveur A et un serveur B.

Il y a de toute évidence un problème de conception car le nombre de table est exagéré et pénalise les performances... Pensez simplement au nombre de métadonnées à décrire pour 76000 tables qui de toute évidences doivent avoir des structures similaires.

Je me souviens d'un ERP de nom ADONIX qui faisait une horreur pareille ! Création d'un schéma SQL pour chaque client avec création de n tables dedans.... identiques aux autres clients.... Bref non maintenable !

L'activité doit reprendre dans les 10 minutes sur le serveur B si le serveur A a crashé.

Cette base est utilisée par un logiciel de compta, donc pas modifiable.

Chaque année de nouvelles tables sont créées par le logiciel.

Certaines tables font référence au nom du serveur, il faut donc que celui-ci soit filtré et changé lorsque la table est répliquée.

Ma question est la suivante : est-ce que la réplication de fusion peut gérer 76000 tables et plus?

Merci d'avance!

La réplication, qu'elle qu'en soit la forme, n'est pas destiné à assurer une solution de continuité (haute dispo), mais à étendre la surface d'attaque de la base (scale out).
Compte tenu du nombre d'objet et de la création permanente des tables, la réplication de toute la base qu'elle qu'en soit sa forme (fusion, transactionnelle, snapshot) n'est pas adaptée.
En particulier la réplication de fusion est la pire de toute compte tenu de sa complexité et des conflits de réplication qu'elle engendre inéxorablement.
En sus elle ne permet pas de répliquer les modification de structure (ajout de table par exemple).

La seule réplication qui pourrait être entreprise serait la transactionnelle en ce sens que c'est la seule à permettre de répliquer le DDL (CREATE, ALTER, DROP).

Mais comme je vous l'ais dit, c'est pas adapté et avec 76 000 tables, vous allez mettre à genous le serveur et passer 200 heures à préparer le terrain, sauf si vous avez un super serveur, genre 16 CPU et RAM à donf....

En revanche il est possible de faire de la haute dispo avec différentes techno : cluster, log shipping et mirroring. Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/s...disponibilite/

Comme vous ne nous avez pas indiqué quelle version de SQL Server (2000, 2005, 2008, Express, standard, Enterprise) difficile de vous aider plus.

A +

[mad_martigan]

Bonjour,

Merci pour votre réponse.

La version de SQL Server est dans le titre du message (2005).

Cet ERP est en effet mal conçu... mais il faut malheureusement que nous fassions avec...

Je vais essayer d'être un peu plus précis :

Comme je vous ai dit, le but est que le département compta puisse continuer de travailler si le serveur principal où réside la base de données tombe en rade.

Nous utilisons la réplication (transactionnelle et de fusion) pour d'autres bases de données sur d'autres serveurs mais il n'y a pas 76000 table (maximum une centaine)...

Dans le cas de la base de compta, il y a plusieurs spécificités:
1) De nouvelles tables sont créées à chaque nouvelle année.
2) Certaines tables (4 tables) font référence au nom du serveur, c'est pour cette raison que nous avions pensé à la réplication puisque certains champs peuvent être filtrés.

Peut-être pourrions-nous mettre en place un serveur avec mise en mirroir de la base, puis si le serveur A tombe, on exécute un script pour mettre à jour les champs de ces 4 tables.
Qu'en pensez-vous?

Merci

[kagemaru]

bonjour

C'est clair que la répli n'est pas un bon plan dans ton cas...

Peut-être pourrions-nous mettre en place un serveur avec mise en mirroir de la base, puis si le serveur A tombe, on exécute un script pour mettre à jour les champs de ces 4 tables.

Cela me parait un bon plan. Il faut également veiller à ce que les logins SQL s'il y a, aient les mêmes SID.

[SQLpro]

Peut-être pourrions-nous mettre en place un serveur avec mise en mirroir de la base, puis si le serveur A tombe, on exécute un script pour mettre à jour les champs de ces 4 tables.
Qu'en pensez-vous?

Merci

C'est la solution adéquate. Vous pouvez même automatiser ce scénario via une routine de l'agent SQL qui va checker toutes les minutes si la base est celle qui produit ou bien si elle est esclave.
Il suffit de lire la colonne mirroring_role = 1 dans SELECT * FROM sys.database_mirroring

A +

[mad_martigan]

Finalement, nous allons partir sur une solution de cluster.

Je voulais justement avoir votre opinion là dessus.

Que préconisez-vous pour la mise en cluster d'un ERP, cluster Windows ou VMWare?

Merci d'avance