Replikation – läuft. Bis sie’s nicht mehr tut.

Merge, Snapshot oder Transactional Replication – egal.
Solange sie läuft, denkt keiner drüber nach.
Aber wenn was klemmt, steht oft alles.

Und die Fehlerursache?
Nicht immer offensichtlich.

Darum brauchst Du Monitoring. Frühwarnsysteme. Und ein Plan B.

Welche Replikation? Welche Fehler?

ReplikationstypTypische Fehlerursache
SnapshotZeitüberschreitung, Rechte, Locking
TransactionalLog Reader/Distributor-Fehler
MergeKonflikte, Zeitzonen, Replikations-GUIDs

Häufige Symptome:

  • Subscriber bleibt hinterher
  • Agenten stoppen kommentarlos
  • Konflikte oder „missing row for update“
  • Fehler 20598 oder 54005

Status prüfen: alle Agents im Blick

EXEC distribution.dbo.sp_help_agent;

Oder für den Log Reader:

EXEC sp_helplogreader_agent;

Aktuelle Meldungen findest Du so:

SELECT 
    agent_name,
    run_status,
    run_duration,
    comments,
    [time] = start_time
FROM msdb.dbo.sysreplicationalerts
ORDER BY start_time DESC;

Agent-Status überwachen

SELECT 
    name,
    status,
    last_run_outcome,
    last_run_date,
    last_run_time
FROM msdb.dbo.sysjobservers
WHERE EXISTS (
    SELECT 1 FROM msdb.dbo.sysjobs
    WHERE job_id = sysjobservers.job_id AND name LIKE '%REPL%'
);

Wenn last_run_outcome = 0, dann hat der Agent zuletzt versagt.

Alerts automatisieren (z. B. via Job + Mail)

IF EXISTS (
    SELECT * FROM msdb.dbo.sysreplicationalerts
    WHERE comments LIKE '%error%' AND start_time > DATEADD(MINUTE, -10, GETDATE())
)
BEGIN
    EXEC msdb.dbo.sp_send_dbmail
        @profile_name = 'SQL-Mail',
        @recipients = 'dba@firma.de',
        @subject = 'Replikation hat gestottert',
        @body = 'Bitte Agenten prüfen.';
END

Cronjob alle 10 Minuten. Und Du weißt Bescheid, bevor der Vertrieb sich meldet.

Konflikte in der Merge-Replikation erkennen

SELECT 
    conflict_table,
    conflict_type,
    conflict_description,
    origin_datasource,
    conflict_loser_reason
FROM conflict_data;

Die conflict_data-Sicht gibt’s nur, wenn Du sie im Setup aktivierst.
Kein Standard. Aber Pflicht bei Merge.

Subscriber synchronisieren prüfen

EXEC sp_replmonitorhelpsubscription
    @publisher = 'DeinPublisher',
    @publication = 'DeinePublication';

Gibt Dir:

  • Latenz
  • Status
  • Fehlercode
  • Synchronisierungsverzögerung

Maßnahmen bei bekannten Problemen

FehlerbildLösungsidee
Subscriber bleibt hinterherNetzwerk prüfen, Agent-Puffer erhöhen
Log Reader stoppedJob manuell starten, Loggröße prüfen
Missing row for update/deleteData mismatch prüfen, NOT FOR REPLICATION prüfen
Snapshot zu langsamSnapshot-Agent-Zeitfenster anpassen
KonflikteMerge-Konflikt-Viewer nutzen, Regeln setzen

Notfallplan: Reinitialisieren

Wenn gar nichts mehr geht:

EXEC sp_reinitmergesubscription 
    @publication = 'DeinePublication',
    @subscriber = 'DeinSubscriber',
    @publication_type = 'merge';

-- Danach Snapshot neu erzeugen
EXEC sp_startpublication_snapshot 'DeinePublication';

Achtung: Alle Daten werden neu gezogen.
Nur nach Absprache mit den Nutzern.

Mein Fazit

Replikation ist mächtig – aber sensibel.
Du brauchst Sichtbarkeit. Monitoring. Und einen Plan.

Wenn Du nur wartest, bis der Kunde sagt „die Daten stimmen nicht“, ist’s zu spät.
Wenn Du willst, bau ich Dir ein leichtes Replikations-Monitoring auf.
Klein, effizient, ehrlich. Passt auch in ein KMU.

Tags:

No responses yet

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert