• Bei konfigurierter asynchroner Replikation muss der OLTP SyncAgent Dienst aktiv sein – ansonsten wird bei der Anmeldung an infra:NET
  oder beim Zugriff auf die Datenbank mit einem Fehler (Code 2229) abgebrochen.
• Die Totalreplikation (manuell und automatisch) erfolgt zunächst noch synchron. Anstehende und fehlerhafte Replikationsereignisse werden dann automatisch vom OLTP SyncAgent verworfen.
• Die Arbeit des OLTP SyncAgent kann mit der infra:NET Server Management Konsole überwacht werden.
  Dort sind Zustand, aktuelle Statistiken und aufgelaufenen Replikationsfehler sichtbar.
  Fehlerhafte Replikationsereignisse können korrigiert, verworfen oder erneut an den SQL-Server gesandt werden.
• Bei Bedarf kann der Dienst über die Windows Dienstverwaltung angehalten – also „pausiert“ werden.
  Eingehende Replikationsereignisse des infra:NET Datenbank-Servers werden dann weiterhin gepuffert, aber nicht mehr an die SQL-Datenbank übermittelt.
• Beim Beenden des Dienstes werden nicht verarbeitete und fehlerhafte Ereignisse gesichert und beim nächsten Start des Dienstes wieder berücksichtigt.
  Verbindungsinformationen werden in der Registry unter folgendem Schlüssel zwischengespeichert:
  HKEY_LOCAL_MACHINE\SOFTWARE(\Wow6432Node)\infra.NET\Server\OLTPSyncAgent\“Datenquelle“
• Bei einem Verbindungsfehler wird nur das Verbindungsereignis (oder bei fehlendem Verbindungsereignis das erste Synchronisationsereignis) als fehlerhaft markiert und für die Bearbeitung in der infra:NET Server Management Konsole angeboten.
  Alle anderen Ereignisse laufen in den Standardpuffer und warten, bis die Verbindung hergestellt werden kann.
• Der ADO-Connectionstring unterstützt zwar standardmäßig keine Timeout-Properties.
  Der angegebene ConnectionString wird vom OLTP SyncAgent jedoch nicht 1:1 weitergegeben, sondern teilweise – zum Beispiel bezüglich der Properties „Command Timeout“ und „Connection Timeout“ – direkt interpretiert und verarbeitet.
  Das heißt, die Timeout-Einstellungen sollten eigentlich auch bei den ADO-Verbindungen greifen.
• Bei Verwendung der asynchronen Replikation über den OLTP SyncAgent werden die Stored Procedures „IP_DBConnections“, „IP_DBisSingleUser“ und „IP_DDTimeStamp“ nicht verwendet.
  Dahinter steckt Folgendes:
  Wenn bei der asynchronen Replikation kein Fehler auftritt, passen die Strukturen der beteiligten Datenbank-Tabellen zusammen – ansonsten gibt es SQL-Fehler, die der SyncAgent meldet. Spätestens dann wird der zuständige Admin erkennen, dass er evtl. vergessen hat, die SQL-Datenbankstruktur mit sibddgen anzupassen oder nach der Rücksicherung keine Totalreplikation gemacht hat.
  Die nachträgliche Anpassung der SQL-Datenbankstruktur und anschließende Wiederholung der fehlerhaften SQL-Kommandos ist bei der asynchronen Replikation jederzeit möglich – ohne Einfluss auf die infra-Clients.
  Das hat unter anderem den großen Vorteil, dass nicht bei jeder DD-Änderung (zum Beispiel an Tabellen, die gar nicht repliziert werden) die SQL-Struktur abgeglichen und der Timestamp geändert werden muss. Bei der synchronen Replikation sieht das natürlich ganz anders aus:
  hier wirkt sich jeder SQL-Fehler gleich auf die infra-Clients aus – daher müssen hier (z.B. über den Timestamp) solche Situation von vornherein verhindert werden.