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

Réplications SQL Server Discussion :

Sql server: perte transaction


Sujet :

Réplications SQL Server

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    Août 2010
    Messages
    31
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2010
    Messages : 31
    Points : 24
    Points
    24
    Par défaut Sql server: perte transaction
    Bonjour,

    J'ai actuellement une base de production et N bases répliquées. Chaque base répliquée est synchronisée avec la base de production, elle envoit et reçoit ses/les données.

    J'ai remarqué dans une base répliquée qu'il y avait des lignes dans certaines tables qui n'avaient pas été envoyées sur la base de production. Du coup, j'ai une perte de données puisque les N autres bases répliquées n'ont pas accès aux lignes non répliquées vu qu'elle ne sont pas dans la base de production.

    Je voulais savoir quelle est la meilleur stratégie pour remettre les données non répliquées vers la base de production.
    Une sorte de merge entre les deux bases et plutôt qu'une insertion de la donnée non répliquée sur la base de production et suppression de la donnée sur la base répliquée pour éviter des conflits.

    Merci d'avance

  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
    21 763
    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 : 21 763
    Points : 52 554
    Points
    52 554
    Billets dans le blog
    5
    Par défaut
    Il faudrait commencer par indiquer quel type de réplication vous utilisez et quels sont les flux.

    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 à l'essai
    Profil pro
    Inscrit en
    Août 2010
    Messages
    31
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2010
    Messages : 31
    Points : 24
    Points
    24
    Par défaut
    Sur le serveur de production, il y a du sql server 2008 R2 10.50.1600 et du sql express sur les base de données clientes.
    Il s'agit d'une réplication transactionnelle, d'une publication transactionnel avec abonnement pouvant être mis à jour avec un réplication du schéma.
    La stratégie de résolution de conflit est que le serveur de production est gagnant.

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 763
    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 : 21 763
    Points : 52 554
    Points
    52 554
    Billets dans le blog
    5
    Par défaut
    Dans une réplication transactionnelle les mises à jour locale ne sont pas propagée en retour. La gestion de conflit ne sert qu'à la réplication de fusion.

    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/ * * * * *

  5. #5
    Membre à l'essai
    Profil pro
    Inscrit en
    Août 2010
    Messages
    31
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2010
    Messages : 31
    Points : 24
    Points
    24
    Par défaut
    Oui je sais qu'elles ne sont pas propagées. Je voulais savoir s'il existait une méthode/action ou s'il faut créer une procédure pour le faire.
    Le but étant de récupérer les données non répliquées du client vers le serveur de production.

Discussions similaires

  1. [WD15] Erreur accès Natif SQL Server en transaction
    Par L.nico dans le forum WinDev
    Réponses: 2
    Dernier message: 01/10/2010, 11h56
  2. [SQL SERVER 2005] Transactions entre Oracle et SQL Server
    Par K'aza dans le forum MS SQL Server
    Réponses: 3
    Dernier message: 08/07/2010, 09h25
  3. [SQL SERVER 2000] Transaction, verrous et utilisation de NOLOCK
    Par luimême dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 18/02/2009, 17h21
  4. [Requête] SQL SERVER 2000 / Transact SQL
    Par plutonium719 dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 11/09/2007, 17h56
  5. [SQL Server 2000] Transaction deadlocked
    Par CyrilT dans le forum MS SQL Server
    Réponses: 1
    Dernier message: 25/09/2006, 15h49

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