Architecture et Contraintes Techniques

Lors de la mise en place d'une solution de réplication entre deux bases de données distinctes sur des serveurs physiques différents, des complications surviennent lorsque l'environnement source contient plusieurs instances SQL Server. Le cas spécifique abordé ici concerne un serveur source hébergeant une instance par défaut ainsi qu'une instance nommée configurée sur le même port TCP que l'instance classique.

L'objectif est de publier des objets spécifiques depuis la base SourceTasks vers une base CibleInfos distante. La complexité réside dans l'établissement de la connexion entre l'agent de distribution et le serveur abonné lorsqu'un conflit d'identification d'instance ou de port existe.

Paramétrage de l'Environnement

• Système d'exploitation : Windows Server 2008 R2
• Moteur de base de données : Microsoft SQL Server 2008 R2
• Nœud Éditeur (Publisher) : Instance nommée active sur le port standard 1433
• Nœud Abonné (Subscriber) : Serveur distant avec une configuration standard

Gestion des Identifiants de Sécurité

Afin de séparer les droits d'accès de l'application métier des besoins de la infrastructure de réplication, il est impératif de créer un compte dédié. Ce compte devra être provisionné tant sur le serveur éditeur que sur le serveur abonné. Voici une approche sécurisée pour générer ces comptes :

-- Vérification préalable pour éviter les erreurs lors d'exécutions répétées IF NOT EXISTS (SELECT name FROM sys.server_princlips WHERE name = N'SecRepli') BEGIN CREATE LOGIN [SecRepli] WITH PASSWORD = N'MonMotDePasseComplex!2024', DEFAULT_DATABASE = MasterDB, CHECK_EXPIRATION = OFF;

-- Ajout au rôle système pour garantir les accès nécessaires aux agents
EXEC master.dbo.sp_addsrvrolemember 
    @loginame = N'SecRepli', 
    @rolename = N'sysadmin';

END GO

-- Mapping utilisateur dans la base source USE BaseSources; GO CREATE USER [SecRepli] FOR LOGIN [SecRepli]; ALTER USER [SecRepli] WITH DEFAULT_SCHEMA = [dbo];

</div>Configuration Réseau et Partage de Fichiers
-------------------------------------------

Pour le stockage des instantanés (snapshots), l'utilisation d'un chemin local relatif (ex: E:\\Temp) est insuffisante si le distributeur et l'éditeur ne partagent pas le même espace disque physique accessible par tous les agents. Il est nécessaire d'utiliser une ressource réseau universelle (UNC).

1. Créer un dosseir partagé sécurisé sur le serveur éditeur (ex: \\\\ServeurEditeur\\DonneesRepli).
2. Configurer les permissions NTFS et de partage pour permettre l'accès en écriture/lecture au compte utilisé par le SQL Server Agent.
3. Dans les propriétés de l'Agent SQL Server, s'assurer que l'identifiant de connexion possède les droits d'accès à ce dossier partagé.

Si le chemin reste local alors que l'abonné est distent, l'agent de demande (Pull Subscription) échouera à télécharger les métadonnées de synchronisation.

Résolution des Conflits d'Identification de Serveur
---------------------------------------------------

Un problème fréquent apparaît lors de la détection de l'instance éditrice depuis le côté abonné : l'erreur de découverte de l'hôte. Cela se produit souvent lorsque le nom de l'instance ne correspond pas au nom enregistré dans les propriétés du serveur SQL interne.

Pour diagnostiquer cet état, exécutez l'interrogation suivante sur le serveur éditeur :

<div class="code-block">```
SELECT 
    CONVERT(SYSNAME, SERVERPROPERTY('InstanceName')) AS NomInstanceDetectee,
    @@SERVERNAME AS NomEnregistre;
GO

DECLARE @nomCourant SYSNAME;
DECLARE @nomAttendu SYSNAME;

SET @nomCourant = @@SERVERNAME;
SET @nomAttendu = CAST(SERVERPROPERTY('MachineName') AS SYSNAME);

IF (@nomCourant <> @nomAttendu AND SERVERPROPERTY('IsSingleUser') = 0)
BEGIN
    -- Suppression de l'entrée incorrecte
    EXECUTE master.dbo.sp_dropserver @server = @nomCourant;
    
    -- Ajout du bon nom localement
    EXECUTE master.dbo.sp_addserver 
        @server = @nomAttendu, 
        @local = 'LOCAL';
        
    COMMIT TRANSACTION CorrectifNomServeur;
    PRINT 'Correction appliquée. Redémarrage du service conseillé.';
END
ELSE
BEGIN
    ROLLBACK TRANSACTION CorrectifNomServeur;
    PRINT 'Aucune modification requise, les noms correspondent.';
END

</div>Utilisation des Alias Clients
-----------------------------

Lorsque le nom de l'instance nommée provoque des conflits ou des impossibilités de connexion directe depuis l'outil de gestion des abonneés, la méthode recommandée consiste à utiliser les Alias SQL Client.

Sur le serveur abonné, vous devez configurer un alias qui masque la complexité de l'instance. Notez que sur les systèmes d'exploitation 64 bits, la configuration doit être effectuée simultanément dans les utilitaires de configuration client 32 bits et 64 bits.

- **Nom d'alias :** Un nom logique sans caractère spécial problématique.
- **Nom de serveur réel :** Utiliser la notation complète NomHôte\\nomInstance (ex: TZ08\\SQLEXPRESS).
- **Port :** Si une redirection manuelle est nécessaire, spécifier le numéro (ex: 1433).

L'alias permet ensuite de pointer directement la configuraton de l'abonnement vers ce pseudo-nom, contournant ainsi les problèmes de résolution DNS ou de broadcast RPC inhérents aux instances nommées.

Mise en Garde Opérationnelle
----------------------------

Faire attention lors de la modification manuelle des dossiers d'instantanés dans les propriétés de la publication. Une modification erronée peut entraîner un blocage de l'initialisation future.

De plus, assurez-vous que le compte exécutant le service SQL Server Agent sur le nœud abonné possède bien les droits sur le dossier partagé de l'éditeur. Sinon, vous rencontrerez des erreurs d'accès refusé lors des tentatives de synchronisation.

Enfin, dans un environnement de production critique, l'installation multiple d'instances sur une seule machine est déconseillée pour des architectures de réplication complexes, car cela multiplie les points de défaillance potentiels liés à la configuration réseau et aux alias clients.