Replikationsproblem

[sequelcoder]

Hallo, allerseits!

Vielleicht kann mir da einer bei dem Problem helfen - wäre ich sehr dankbar.

Nach einer Schema-Änderung (Transaktionsreplikation/MS-SQL Server 2005) erscheint die untenstehende Fehlermeldungen bei jedem Durchlauf des Warteschlangenlese-Agenten im Eventlog des Verlegers:

Replikations-Subsystem des Transaktionswarteschlangenlesers für die Replikation: Fehler beim [S12345678].6-Agent. Beim Herstellen der Verbindung mit DRBASE'' auf ' S12345678' wurde vom Warteschlangenlese-Agent der Fehler ''Für die Prozedur oder Funktion sp_MSsync_upd_F8341B2B_883C_4C1B_9A67_9DECA95D1025 wurden zu viele Argumente angegeben.'' festgestellt.

Daten werden noch vom Verleger zum Abonnenten repliziert, aber nicht mehr umgekehrt. Über das Profil habe ich das Log aktiviert in dem dann auch nur folgenden Meldung zu sehen ist:

2009-07-02 05:28:12.179 Beim Herstellen der Verbindung mit DRBASE' auf 'S15223621' wurde vom Warteschlangenlese-Agent der Fehler 'Für die Prozedur oder Funktion sp_MSsync_upd_F8341B2B_883C_4C1B_9A67_9DECA95D1025 wurden zu viele Argumente angegeben.' festgestellt. Stellen Sie sicher, dass die Publikation und das Abonnement ordnungsgemäß definiert sind und dass beide Server ausgeführt werden.

2009-07-02 05:28:14.679 Fehler beim Abrufen der Nachrichteneigenschaften für die in der Warteschlange aktuelle Nachricht.
2009-07-02 05:28:14.913 Fehler beim Lesen der aktuellen Nachricht aus der Warteschlange.
2009-07-02 05:28:15.132 Arbeitsthread 2396 : Taskfehler.
2009-07-02 05:28:16.366 Warteschlangenlese-Agent wird abgebrochen

Hat mal bitte jemand einen Tipp, wo ich in den MS-SQL Untiefen ab besten die Fehlersuche starte?

Viele Grüße

[Bernhard Geyer]

Hast du schon probiert die replikationeinstellungen komplett zu löschen und neu anzulegen? Ich hätte auch gedacht das bei aktiver Replikation keine Schemaänderungen möglich wären.

[sequelcoder]

Ja, das war dann auch mein erster Versuch. Die Neuanlage hat ohne weitere Fehler geklappt. Mit dem Neustart des Lese Agents kam dann der beschriebene Fehler trotzdem immer.

[O. Helper]

Hallo sequelcoder,

sp_MSsync_upd_F8341B2B_883C_4C1B_9A67_9DECA95D1025

es hat schon so seinen Grund, warum die SP für die Replikation eine GUID im Namen haben, sie werden bei der Einrichtung der Replikation dynamisch anhand des DBs-Design generiert.

Wenn es Änderungen am Design gibt, ist das Vorgehen wie folgt:
- Replikation vollständig auflösen; nicht vergessen die Abonnenten kontrollieren, ob alles in Ordnung ist
- Änderungen vornehmen
- Am besten die DBs auf den Abonennten löschen
- Replikation wieder einrichten
- Snapshot deployen

Und schon läuft es wieder; jedenfalls hat es bei mir bisher so funktioniert.

Wenn man eine Meldung a la "...wurden zu viele Argumente angegeben." heisst das, dass ein Abonnent auf einem alten Stand ist; der Verleger übergibt mehr Daten (mehr Tabellen-Felder) als dem Abo bekannt sind.

[sequelcoder]

Hallo Olaf,

vielen Dank für Deine Hilfe! Ich hatte schon erwartet, dass ich letztlich die komplette Replikation auflösen muss. Im wesentlichen habe ich 2 Publikationen mit jeweils 5 Abonnenten. Da nur die Abos der zweiten Publikation nicht mehr repliziert wurden, wollte ich es mir ersparen, die Abonnenten des ersten Abos ebenfalls aufzulösen. Zumal das bei laufendem Betrieb und egal zu welcher Uhrzeit immer Probleme verursacht Aber es führt wohl kein Weg dran vorbei.

Was mir an dieser Lösung schon seit längerem Bauchschmerzen bereitet, ist die Tatsache, das bei meinem aktuellen Setup alles mit dem einen Verleger steht und fällt.

Gibt es eigentlich einen vernünftigen und gangbaren Weg einen zweiten SQL-Server ("Backup-Verleger") so einzubinden, dass man die Abonnenten beim nächsten "GAU" mit wenigen Schritten (also ohne erst dann neue Abos etc. erstellen zu müssen) auf den Backup-Verleger umstellen kann (quasi on-the-fly)?

Im Normalfall könnte sich der Backup-Verleger ja so wie die Abonnenten mit dem "Haupt-Verleger" abgleichen. In dem Fall ist mir nur nicht ganz klar, wie ich die Abonnenten einrichten muss, um Sie im Bedarfsall "einfach" auf den zweiten umstellen zu können.

Bin für jeden Tipp dankbar...

Gruß,
Mathias

[O. Helper]

Morgen Mathias,

eigentlich eine sinnige und interessante Frage; da fragt man sich, wieso es kein Boardmittel gibt (um die Frage gleich im ersten Satz zu beantworten ).

Es gibt ein paar Sachen, die man zum "Tricksen" nutzen kann.
* Über "CliConfg.exe" kann man am Client ein Serveralias anlegen, also eine Alias hinter dem der richtige Servername/ IP+Port liegt, über den man auf den Sql Server zugreifen kann. Im Failover ändern man im Alias den richtigen Server auf den Failover um und alle Applikationen, die den Alias verwenden, laufen wieder. Hat 2 Haken: Hast Du 200 Clients, musst Du es an 200 Clients änder; ist aber bloß ein RegistryKey, den man mit entsprechenden Mitteln deployen könnte. Nun, Du hast 5 Abonnenten, da hält es sich vom Aufwand in Grenzen. Ich habe gerade es mit Sql Server 2008 / Windows Vista probiert, da jammert es rum, es möchte unbedingt den realen Server Namen haben ....Ich bin mir aber recht sicher, das es geht, in der Firma läuft eine Replikation mit Sql Server 2000 (+Msde) / Win 2003 über WAN und da per Firewall alles geblockt ist, nutze ich da Aliase und da funktioniert es.

* Ab Sql Server 2008 kann man im ConnectionString eine FailOver-Server mit angeben; gibt es eine ConnectionTimeOut, wird versucht, sich an den FailOver anzumelden. Bei der Replikationseinrichtung gibt es aber leider diese Möglickeit nicht (zumindest habe ich nichts dergleichen gesehen).

Wie ein Failover / Backup System aussehen & funktionieren sollte, müsste man erst mal genauer ausarbeiten.
Ich habe mir bisher noch keine Gedanken dazu gemacht, den:
Es fällt & steht nicht nur mit dem Verleger, sondern mt * der replizierten Datenbank + Verleger + Verteiler, also dem ganzen System.
Sich Gedanken nur über den Verleger zu machen, ist damit eine etwas zu eingeschränkte Sicht und die Verfügbarkeit eines ganzen Systems sicher zu stellen, dafür gibt es Mittel, wie etwa Cluster-System, Hot-Standby mit z.B. Log-Shipping, Cold-Standby System mit den entsprechenden Restore-Scenarien etc.
Kostet aber halt alles entsprechend Geld und da ist dann wieder die Frage von Anforderung / Nutzen / Aufwand und wie die zueinander im Verhältnis stehen.

[sequelcoder]

Hallo Olaf,

vielen Dank für Deine ausführlichen Tipps und Hinweise!!

Den Weg über den Serveralias werde ich direkt mal ausprobieren, denn bei der geringen Anzahl von Abonnenten wäre das ein durchaus gangbarer Weg. Und natürlich hast Du Recht, dass das ganze System nicht nur mit dem Verleger steht und fällt. Meine Aussage hat sich da mehr auf eine spezielle Sichtweise im Hinblick auf die Nutzung unserer DBs bezogen. Rückblickend ist das aber wirklich der falsche Denkansatz.

Nach den GAU-Erfahrungen der letzten Tage werde ich mir mal intensiv Gedanken über die zukünftige Backup-Struktur machen. Da es offensichtlich keine Bordmittel gibt (puhhh zum Glück habe ich zumindest an der Stelle nichts übersehen ), werde ich mal versuchen, mit den von Dir genannten Optionen eine für unseren Bedarf passende Strategie zu entwickeln. Nochmals vielen Dank für Deine Ausführungen und abschließend noch die Info was nun aus meinen Replikationsproblem geworden ist.

Bereits mein erster Versuch die Replikation auf dem Verleger vollständig aufzulösen war "augenscheinlich" erfolgreich. Alles aufgelöst und auch keine auffälligen Überbleibsel (bspw. bei den SPs). Sobald ich aber wieder nach Neuanlage der Publikation einen Abonnenten hinzugefügt hatte, traten die genannten "sp_MSsync_upd_xxxxxxxxx" Fehler mit unterschiedlichen GUIDs trotzdem immer wieder auf .

Ok, dann eben nochmal alles aufgelöst und nochmal alles kontrolliert. Dabei ist mir dann aufgefallen, dass ich weder Tabellen löschen noch umbenennen kann (Fehler:...wird für Replikation verwendet (!?!), ... es bestehen Abhängigkeiten...). Uhhps, aber für keine der Tabellen wurden mir letztlich irgendwelche Abhängigkeiten dediziert angezeigt/ausgegeben...

Gut, an der Stelle habe ich es dann auch aufgrund des Zeitdrucks aufgegeben Ursachenforschung zu betreiben. Ich habe die Datenbank komplett neu angelegt und die Daten von der alten importiert. Dabei sind keine Fehler aufgetreten. Mit der neuen DB habe ich die Replikation erneut eingerichtet und seit dem funktioniert wieder alles so wie es soll. Das ist zwar insgesamt hocherfreulich , dennoch hätte ich gerne rausbekommen, durch was dieses Problem letztlich entstanden ist. Nachdem die "alte" Replikation über zwei Jahre problemlos funktioniert hat, hoffe ich bis zum nächsten GAU ein einsatzfähiges Backup-System umgesetzt zu haben.

Viele Grüße,
Mathias