IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration SQL Server Discussion :

[Linked server] Strategie


Sujet :

Administration SQL Server

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre Expert

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2007
    Messages
    1 216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Suisse

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : Août 2007
    Messages : 1 216
    Par défaut [Linked server] Strategie
    Bonjour,

    J'aimerais vous demander votre avis sur une implementation de linked serveur que j'aimerais mettre en place.
    Pour chaque instance de production, nous avons une instance de developpement et une instance d'integration.

    Afin de faciliter la migration des sp/vues utilisants des linked servers d'un environment à l'autre (dev -> int, int -> prod) et aussi faciliter la maintenance en cas de changement de serveur/migration, je souhaite créer par instance de production un linked serveur "ALIAS" spécifique à chaque instance de production.

    Imaginons ceci :
    Production server name : serverProd1 - alias VENTE
    integration server name : serverInt1 - alias VENTE
    development server name : serverDev1 - alias VENTE

    Production server name : serverProd2 - alias HRDATA
    integration server name : serverInt1 - alias HRDATA
    development server name : serverDev1 - alias HRDATA

    Lors de developpement sur le serveur serverDev1, si l'on veut acceder une table d'une base de donnée "de vente" via une sp stockée dans une DB de "HRDATA" l'utilisation d'un linked server est inutile car comme l'on peut le voir, les données HRDATA et VENTE se trouvent sur le même serveur. On pourra simplement y acceder en utilisant :
    dbname.schema.table

    Ceci reste vrai en integration.
    Lors du passage en production, les bases de données se retrouvent sur 2 serveurs distincts et l'on doit donc ici utiliser un linked serveur. (linkedServer.dbname.schema.table).
    Si l'on définit un linked server sur base du nom du serveur au niveau de la sp, dans tous les environments, cela sera different.
    D'ou l'idée de créer un linked server "alias" pointant sur le serveur que l'on souhaite.
    Nous pourrions très bien imaginer en développement utiliser un linked server pointant sur le serveur lui même et portant le même nom que le linked server de production pointant lui sur un autre serveur.

    Je ne sais pas si mes explications sont très claires...
    Ce que je demande ici ce sont vos avis, vos pros & cons... Est ce une idée interessante ? Y voyez vous une alternative ? Comment gerez vous vos linked server ?

    Dje

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 002
    Billets dans le blog
    6
    Par défaut
    La question principale est : pourquoi avez vous dissocié sur deux serveurs ? Y a t-il un intérêt majeur à le faire, hormis dépenser deux licences, un serveur de plus et assurer plus de boulot au dba, et donc faire plaisir à Microsoft, aux marchands de serveur et baisser les stats du chomage ???

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Membre Expert

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2007
    Messages
    1 216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Suisse

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : Août 2007
    Messages : 1 216
    Par défaut
    La question posée ici concerne les linked serveurs, pas l'architecture sous-jacente, et leur implementation dans les stored procedures ainsi que la facilité de changer le serveur vers lequel pointe celui ci sans devoir adapter les stored procedure en cas par exemple de migration ainsi que facilité les deployments.

    C'est sur ce point précis que je demande l'avis des lecteurs.

Discussions similaires

  1. migration de oracle vers sql server 2005 - linked server
    Par aemag dans le forum MS SQL Server
    Réponses: 1
    Dernier message: 16/10/2006, 15h31
  2. Timeout avec un linked server
    Par Wisefool dans le forum MS SQL Server
    Réponses: 3
    Dernier message: 02/09/2005, 15h35
  3. Requete sur un linked server
    Par Wisefool dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 02/09/2005, 11h53
  4. Pb cast date sur un linked Server Oracle
    Par bran_noz dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 13/07/2005, 15h50
  5. Utilisation linked server et procédure stockée ?
    Par |DUCATI| DesMo dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 03/03/2005, 12h47

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo