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 :

The replication agent has not logged a progress message in 10 minutes


Sujet :

Réplications SQL Server

  1. #1
    Membre expérimenté
    The replication agent has not logged a progress message in 10 minutes
    Bonjour à tous,

    Je rencontre pour la 4ème fois ce message dans une réplication par fusion :
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    The replication agent has not logged a progress message in 10 minutes. This might indicate an unresponsive agent or high system activity. Verify that records are being replicated to the destination and that connections to the Subscriber, Publisher, and Distributor are still active.


    Le job est censé tourner 2 secondes, et est exécuté toutes les 5 minutes.

    J'ai eu ça 2 fois aujourd'hui, dont un qui s'est débloqué toute seule après 2h20 !

    Mais là, j'en ai encore un qui tourne depuis 4h15...

    C'est un message assez "connu", mais je trouve beaucoup d'infos sur le net pour expliquer mais on parle souvent de heartbeat_interval.

    Alors, le soucis, c'est qu'impossible de trouver la valeur actuelle de cette propriété.

    Certains conseillent de le passer à 5, d'autres à 20 voir encore un à 30.

    Le code
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    USE master
    exec sp_changedistributor_property
    @property = N'heartbeat_interval',
    @value = 30;
    GO


    Mais de un, je ne veux pas changer sans en connaitre la valeur actuelle, et de deux, en comprendre les conséquences.

    Mes 2 premières solutions, ont été la première fois, le restart de l'agent SQL. La seconde fois, pareil mais là l'agent a bloqué et est resté en status "change pending" et impossible de le débloquer donc restart du serveur et la troisième pareil. Et maintenant, je ne veux plus le faire sans trouver le fond du problème et l'urgence attendra encore quelques heures.

    Merci pour votre aide.
    Ce que nous avons fait pour nous-même meurt avec nous, ce que nous avons fait pour les autres et le monde est immortel. Albert Pike

    http://www.datacrossroad.be

  2. #2
    Expert éminent sénior
    Lorsque tu as ce message il faut surtout regarder pourquoi ton agent a pris du temps pour la réplication. Changer le paramètre que tu cites ne fait que masquer le vrai problème en réalité.
    A la rigueur vaut mieux jouer sur les paramètres de l'agent pour le querytimeout.

    J'ai souvent ce genre de messages dans l'environnement dans lequel j'opère actuellement et en général cela arrive surtout lorsque quelqu'un (personne / application) lance une grosse mise à jour à répliquer.

    Dans ce cas l'agent de réplication peut prendre beaucoup de temps à répliquer et cela peut coincer à différents stades. Voici les raisons principales (non-exhaustif)
    - La création des générations prend du temps (mais dans ce cas ce sont souvent tous les agents merges qui se retrouvent bloqués)
    - L'énumération des changements dans les générations qui prend du temps => dans ce cas tu peux jouer avec le nombre d'enregistrements par génération pour accélérer un peu le process (generation_leveling_threshold)
    - Le nombre de conflits peut aussi influencer car l'agent peut retenter de répliquer à nouveau les lignes concernées ce qui peut faire perdre beaucoup de temps à l'agent de réplication

    ++

  3. #3
    Membre expérimenté
    Salut David,

    Merci je vais regarder, mais sais-tu pourquoi quand je veux stopper le job, il ne se passe rien? Si je tente de redémarrer l'agent SQL, ça coince aussi?
    Y a t'il des transactions que je peux stopper, car je ne vois rien via sp_whoisactive.

    Et si je redémarre le serveur, l'heure à laquelle il coinçait à disparu et on ne voit que l'historique d'avant et après son "plantage" et tous success.
    Donc dans le cas d'hier, il a tourné à 7h35, 7h40, 7h45 et on voit 16h10 et pas celui de 7h50 qui coinçait.
    Ce que nous avons fait pour nous-même meurt avec nous, ce que nous avons fait pour les autres et le monde est immortel. Albert Pike

    http://www.datacrossroad.be

  4. #4
    Expert éminent sénior
    Quand tu dis qu'il ne se passe rien ou que tu redémarres l'agent ca coince qu'est-ce que tu entends par là?

    ++

  5. #5
    Membre expérimenté
    Quand je vais dans le "job activity monitor", je vois le job qui tourne, si je fais un clic droit "stop job", il ne se stoppe pas.

    Et si je vais dans le configuration manager, et que j'essaye d'arrêter l'agent, il met longtemps pour finalement dire qu'il ne sait pas. Si je le force via PowerShell, là il s'arrette mais est en status "change pending" et là je ne sais plus rien faire.
    Ce que nous avons fait pour nous-même meurt avec nous, ce que nous avons fait pour les autres et le monde est immortel. Albert Pike

    http://www.datacrossroad.be

  6. #6
    Expert éminent sénior
    ok c'est autre chose là.

    Tu en configuration push avec beaucoup de jobs SQL Server? Si oui combien de jobs concernant l'agent?
    Une erreur particulière dans les journaux SQL Server? Windows events?

    ++

  7. #7
    Membre expérimenté
    Je ne suis pas un expert dans la réplication, donc j'espère te répondre correctement.

    Il y a 11 jobs pour la réplication, c'est du push

    A 14h40, les 2 mêmes jos durent encore anormalement longtemps, ce sont à chaque fois les mêmes. Ils tournent toutes les 5 minutes.
    Voici ce que je trouve dans le log à 14h43 :

    Replication-Replication Merge Subsystem: agent DMZXXX-DB1-DB1-ZON1SQL50-1462 failed. The merge process could not connect to the Publisher 'DMZXXXB1'. Check to ensure that the server is running.

    Ce que l'on ne comprends pas, c'est que ZON1 vient chercher sur le serveur DMZ et pas le contraire. Les 2 jobs qui plantent envoient vers des DB qui sont en "local", donc à Bruxelles. Et ici, ZON1 (un nom d'emprunt ) est un poste de l'étranger.

    Donc je pense que ce message, est juste une conséquence et pas une cause.

    J'aimerais bien te mettre des printscreens, mais ce sont des ambassades donc un peu confidenciel
    Ce que nous avons fait pour nous-même meurt avec nous, ce que nous avons fait pour les autres et le monde est immortel. Albert Pike

    http://www.datacrossroad.be

  8. #8
    Expert éminent sénior
    11 c'est pas énorme si le serveur de distribution est dimensionné correctement (faut juste s'assurer qu'il ne soit pas en 100% CPU lorsque les jobs s'exécution.

    Ce que tu peux essayer c'est de lancer le l'agent en ligne de commande pour voir si tu as plus d'info.
    1) Pour cela il suffit d'aller sur le distributeur > ouvrir le job SQL concerné > étape 2 et tu copies l'ensemble des paramètres.
    2) Repérer où se trouve l'exécutable replmerg.exe
    3) Dans une fenêtre de commande lancer le replmerg.exe avec les paramètres que tu as copié précédemment.

    Là tu regardes la sortie qu'il te donne

    ++

  9. #9
    Membre expérimenté
    Ok merci, je regarde à ça demain. Car ils se sont "débloqués". L'un après 3h30 et l'autre 4h40 !
    Ce que nous avons fait pour nous-même meurt avec nous, ce que nous avons fait pour les autres et le monde est immortel. Albert Pike

    http://www.datacrossroad.be

  10. #10
    Expert éminent sénior
    Si tu parles des jobs alors oui cela peut prendre du temps en fonction de ce qui s'est passé.
    Il y a quelques tips à appliquer dans le cas où il s'agit de gros volumes de données à répliquer et de la topologie mais pas de miracle cela peut prendre du temps. 03h / 04h c'est pas encore ce que j'ai vu de pire .. quelques fois on a du attendre quelques jours ...

    ++

  11. #11
    Membre expérimenté
    David,

    J'ai lancé cette commande reçu d'un collègue qui gère la réplication :

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    cd C:\Program Files\Microsoft SQL Server\100\COM
    replmerg -Publisher DMZSERVER01 -PublisherDB MyDBv4 -Subscriber SERVER01 -subscriberdb MyDBv4 -Publication MyDBv4_BXL_Publication -distributor DMZSERVER01 -distributorlogin sa -distributorpassword Mypassword -subscriberlogin sa -subscriberpassword Mypassword -publisherlogin sa -publisherpassword Mypassword -logintimeout 30 -querytimeout 1800 -subscriptiontype 0 -DownloadGenerationsPerBatch 100 -DownloadReadChangesPerBatch 100 -DownloadWriteChangesPerBatch 100 -UploadGenerationsPerBatch 100 -UploadReadChangesPerBatch 100 -UploadWriteChangesPerBatch 100


    Et dans le job, c'est cela que j'ai :

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    -Publisher [DMZSERVER01] -PublisherDB [MyDBv4] -Publication [MyDBv4_Bxl_Publication] -Subscriber [SERVER01] -SubscriberDB [MyDBv4] -Distributor [DMZSERVER01] -DistributorSecurityMode 1


    Par contre, dans son document, il met qu'il y a une query "lente" et une "rapide".

    Voici la "rapide" :

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    cd C:\Program Files\Microsoft SQL Server\100\COM
    replmerg -Publisher DMZSERVER01 -PublisherDB VisaNetv4 -Subscriber %COMPUTERNAME% -subscriberdb MyDBv4 -Publication MyDBv4_BXL_Publication -distributor DMZSERVER01 -distributorlogin sa -distributorpassword Mypassword -subscriberlogin sa -subscriberpassword Mypassword -publisherlogin sa -publisherpassword Mypassword -logintimeout 10800 -querytimeout 10800 -subscriptiontype 0 -OutputVerboseLevel 3 -DownloadGenerationsPerBatch 1000 -DownloadReadChangesPerBatch 1000 -DownloadWriteChangesPerBatch 1000 -UploadGenerationsPerBatch 1000 -UploadReadChangesPerBatch 1000 -UploadWriteChangesPerBatch 1000


    Y a t'il quelques choses de mauvais ? Est-ce que la "lente" (la première) peut être contraignante par rapport à la rapide. Je veux dire, y aurai-t-il une vrai différence de rapidité entre les 2?

    Car j'ai lancé la "lente", et c'est très lent. Il met parfois 7 minutes pour "2018-12-12 08:37:44.628 [5%] [48688 sec remaining] Uploaded 100 change(s) in 'Mytable' (100 updates): 708 total"

    Autre question stp : Quand on exécute la réplication, j'ai ceci dans le cmd au fur et à mesure :

    2018-12-12 10:03:56.262 [0%] [11554 sec remaining] Uploaded 25 change(s) in 'Ref01' (25 inserts): 25 total
    2018-12-12 10:03:56.262 [0%] [11554 sec remaining] Uploaded 14 change(s) in 'Ref02' (14 inserts): 14 total
    2018-12-12 10:03:56.263 [0%] [11554 sec remaining] Uploaded 5 change(s) in 'STI01' (5 updates): 5 total

    Si j'arrête la réplication, est-ce que ces changements seront appliqués ou il doit tout faire pour que ce soit "commité" ?

    Merci,
    Ce que nous avons fait pour nous-même meurt avec nous, ce que nous avons fait pour les autres et le monde est immortel. Albert Pike

    http://www.datacrossroad.be

###raw>template_hook.ano_emploi###