De ce que j'ai lu, votre environnement ne dispose pas d'un DBA "officiel". Il est difficile de formuler beaucoup d'affirmations concrètes à cette distance, mais voici quelques réflexions que je soumettrais.
Premièrement, il est tout à fait possible que l'informaticien ait raison et que les données doivent être sur un autre serveur pour des raisons réglementaires. Parfois, les règles sont les règles. Elles peuvent avoir été négociées par des personnes du gouvernement (ou du système juridique) sans se préoccuper de leur mise en œuvre technologique. Même si les règles ne semblent pas faire 100% de sens "logique", vous ne les changerez pas.
Aussi, comme une sorte de chose dominante, je suggérerais que tant que les performances ne sont pas compromises et que le temps de fonctionnement, la reprise après sinistre et les autres éléments couverts par les SLA ne sont pas affectés négativement, c'est vraiment le cou du technicien informatique qui est mis en jeu. Vous n'êtes pas responsable de la conformité réglementaire (ou vous seriez formé pour être plus familier avec les règles, je suppose) et le personnel informatique est responsable de la conformité. Si quelque chose ne va pas avec l'application ou si elles enfreignent une règle réglementaire, elles devront vivre avec les conséquences. Vous pouvez dire "Les informaticiens m'ont dit que ce serait bien." (Si le système rencontre un quelconque problème sur le nouveau serveur, je voudrais certainement savoir si le problème se serait produit si la base de données était restée sur l'ancien serveur.)
En tant que DBA de longue date qui a travaillé sur beaucoup de projets de consolidation, vous voulez généralement moins d'instances, pas plus. (Je ne parle pas des instances dev/test/qa/production; nous ne parlons que de production ici.) C'est plus facile de gérer un nombre plus restreint d'instances et cela maintient les coûts de licence bas. Parfois, certaines personnes tombent amoureuses de l'idée d'avoir un grand nombre de serveurs, en pensant que plus c'est mieux. "100 serveurs avec 1 base de données chacun" est en quelque sorte meilleur que "100 bases de données sur 1 seul serveur".
Vont-ils déplacer ces autres bases de données avec des données réglementaires sur des lames ou la votre a-t-elle été ciblée ? Si d'autres bases de données vont être déplacées, pourquoi la vôtre est-elle la première ?
Quel type de SLA avez-vous pour votre base de données ? Les lames sont-elles capables de le gérer ? Comment le savent-ils ? Si l'ancien serveur est en cluster, les nouvelles lames le sont-elles aussi ? Le temps de fonctionnement sera-t-il le même ? Ou meilleur ? Le stockage sera-t-il le même ?
Y a-t-il des rapports externes ou des applications qui "savent" que toutes ces bases de données sont co-localisées sur la même instance ? Que dire des bases de données MS Access ou des feuilles de calcul Excel qui effectuent des extractions de données ? Oui, ce genre de chose devrait être caché derrière une vue ou une procédure stockée mais j'ai vu de nombreux cas où cela n'était pas le cas. Vous ne voulez pas découvrir que vous devez retravailler le code de l'application après avoir déplacé la base de données. Tout ce travail doit être pris en compte dans l'effort de déplacement de la base de données.
D'une manière plus négative, il est possible que le personnel informatique ne connaissent pas assez SQL Server pour se sentir à l'aise d'utiliser les fonctionnalités de SQL Server (connexions, rôles, permissions, cryptage, instances nommées, etc.) pour séparer correctement ces "données réglementaires" sur une seule instance. Vous pouvez voir cela comme "le personnel informatique a besoin de plus de formation/il faut engager un DBA" ou vous pouvez voir cela comme "le personnel informatique doit être à l'aise d'utiliser ce qu'ils savent déjà pour respecter les règlements". Les deux points de vue sont sains, avec des avantages et des inconvénients.
S'il y a des problèmes de performances sur le serveur actuel, le personnel informatique pourrait s'attendre à améliorer la situation en déplaçant une base de données sur un autre serveur. Cela pourrait être vrai pour au moins certaines fonctionnalités d'une base de données particulière, mais les dépendances inter-base de données peuvent poser de sérieux problèmes. Les performances des requêtes de serveur lié ne correspondent pas aux performances des requêtes locales, en raison de la latence du réseau, d'une capacité réduite à optimiser correctement les requêtes et de la manière dont les données sont parfois récupérées. Parfois, les performances sont correctes, parfois non. Le meilleur moyen de le savoir est de tester votre code avant de passer en production sur le nouveau serveur. Une fois sur le nouveau serveur, il sera plus difficile de faire quelque chose concernant les requêtes qui fonctionnent mal et ce n'est pas le genre de chose dont vous voulez être surpris. J'ai vu des gens rencontrer ce problème dans le passé. La réponse est généralement de copier les données du serveur distant vers le serveur local, généralement par SSIS ou par utilisation d'un serveur lié. C'est un travail supplémentaire et des problèmes de "péremption" des données peuvent survenir.
De plus, les serveurs liés peuvent être des failles de sécurité s'ils sont mal configurés. Si votre équipe informatique se soucie principalement de l'accès aux données réglementaires, cela devrait aussi les préoccuper.
Si une base de données a des dépendances sur les autres bases de données, elles font toutes partie du même système. Déplacer votre base de données vers un autre serveur rendra plus probable l'échec du système car il y a plus de choses à échouer.
Les œufs et les paniers ne sont pas une bonne métaphore, même si elle est souvent utilisée. Les œufs ne dépendent pas les uns des autres. Les bases de données peuvent dépendre les unes des autres. Les bases de données interdépendantes doivent être considérées comme un système. Le déplacement d'une base de données vers un autre serveur rendra plus probable l'échec du système de bases de données car il y a plus de choses à échouer.
La question devient alors : "Si vous mettez l'une de ces bases de données hors ligne au hasard, comment tout le système est-il affecté ?" Autrement dit, que se passe-t-il si l'ancien serveur tombe en panne ? Que se passe-t-il si le nouveau blade tombe en panne ? Si toute l'entreprise cesse de fonctionner si ces neuf autres bases de données sont hors ligne, est-ce important si votre base de données est en ligne ou non ?
