Hardware- und Software-Ausfälle

Sie können die Informationen in diesem Thema verwenden, um Hardware- und Softwareprobleme zu erkennen und zu beheben.

Tabelle 1. Hardware- und Software-Probleme
Problem	Erkennung	Lösung
Ein NPS®-Knoten erlebt einen Host-Failover.	Die Erkennung erfolgt automatisch, allerdings mit HA-Funktionalität.	Die Auflösung erfolgt automatisch: Der sekundäre Host übernimmt und startet den NPS.
Ein NPS-Knoten hat einen Hardware- oder Software-Fehler, der dazu führt, dass Abfrage- oder Aktualisierungstransaktionen vorübergehend nicht verarbeitet werden können.	Die Erkennung von Knotenausfällen kann durch eine Kombination von Eventmgr-Berichten, Zustandsübergangsereignissen, Hardware-Benachrichtigungsereignissen und benutzerentwickelten Lösungen erfolgen. Es werden keine zusätzlichen Erkennungs- oder automatischen Wiederherstellungsfunktionen hinzugefügt.	Sie können eine der folgenden Methoden anwenden: Beheben Sie das Problem, damit der NPS-Knoten wieder online ist. Wenn es sich bei dem NPS-Knoten um einen primären Knoten handelt, ändern Sie die Konfiguration des Replikationssets (mithilfe der bereitgestellten Verwaltungsbefehle), um den alten primären Knoten zu degradieren und einen neuen primären Knoten zu aktivieren.
Der Replikations-Capture- oder -Apply-Agent auf einem NPS-Primärknoten fällt aus, was dazu führt, dass keine Transaktionen repliziert werden können.	Die entsprechenden Erfassungs- und Anwendungsprozesse werden von der lokalen startupsvr verwaltet.	Der startupsvr erkennt das Problem und startet die Prozesse replcapture und replapply neu.
Ein NPS-Knoten kann aufgrund eines Konnektivitätsproblems oder eines Hardware- oder Software-Problems mit der lokalen Log-Server-Komponente nicht in den Replikations-Queue-Manager schreiben oder von ihm lesen.	Der Capture/Apply Agent erhält einen Fehler von einem API-Aufruf, wenn er versucht, eine Transaktion zu lesen oder zu schreiben oder die neuesten Metadateninformationen abzurufen. Ein ReplPTSError wird über eventmgr gemeldet. Alle Aktualisierungstransaktionen auf einer Primärseite schlagen fehl, bis dieses Problem behoben ist. Sowohl auf einer Primär- als auch auf einer Replikation ist die Replikation effektiv blockiert, bis das Problem behoben ist. Alle Abfragetransaktionen funktionieren weiterhin ordnungsgemäß.	Sie können eine der folgenden Methoden anwenden: Beheben Sie das Problem, damit die Replikation automatisch wieder aufgenommen werden kann. Im Falle eines primären Systems ist ein manueller Failover auf ein neues primäres System in einem Teilnetz durchzuführen, in dem das Problem der Konnektivität oder des Replikationswarteschlangenmanagers nicht besteht.
Ein Kommunikationsfehler tritt zwischen den Komponenten des Replikationswarteschlangenmanagers auf.	Das System erzeugt ReplMissedMetadataHeartbeat, wenn es ein Kommunikationsproblem zwischen den Knoten in einem Replikationssatz feststellt. Das heißt, eine bestimmte Anzahl von Metadaten-Heartbeats wird nacheinander nicht empfangen, oder ein Metadaten-Heartbeat wird zu spät empfangen. Weitere Informationen zum Ereignis ReplMissedMetadataHeartbeat und zur Konfiguration der Bedingungen für seine Erzeugung finden Sie in Tabelle 1. Sie können detaillierte Informationen über verpasste Heartbeats anzeigen, indem Sie den Befehl nzreplstate -heartbeat auf jedem der betroffenen Knoten verwenden; überprüfen Sie die Befehlsausgabe, um die kürzlich gesendeten und empfangenen Heartbeats zu ermitteln.	Sie können das Problem beheben, indem Sie die Netzwerkprobleme lösen. Sie können beschließen, die Replikation auf dem primären Knoten vorübergehend auszusetzen, um den Aufbau eines Rückstands an nicht verarbeiteten Transaktionen zu vermeiden. Die RQM-Software (Replication Queue Manager) versucht automatisch und wiederholt, die Verbindung wiederherzustellen, wenn eine Verbindung unterbrochen wurde oder nicht antwortet, und setzt die Verarbeitung normal fort, nachdem die Verbindung wiederhergestellt wurde.
Die Daten eines Knotens sind beschädigt oder korrumpiert.	Der NPS erkennt und meldet diese Art von Problemen.	Nachdem der NPS-Knoten wieder in Betrieb genommen wurde, verwenden Sie die Befehle nzreplanalyze, nzreplbackup und nzreplrestore, um die beschädigten Datenbanken wiederherzustellen.
Die Daten eines Replikationswarteschlangenmanagers sind irreparabel beschädigt oder korrumpiert.	Es gibt eine Reihe von Bedingungen, die darauf hindeuten, darunter die folgenden: Das Gerät fährt nicht mehr hoch. Das Betriebssystem meldet Fehler beim Lesen von der Partition oder dem Laufwerk, auf dem der RQM installiert ist. Der RQM-Daemon läuft nicht und meldet Ausnahmen oder Fehlermeldungen, die auf Probleme hinweisen.	Sie müssen den Replikationswarteschlangenmanager-Host neu initialisieren oder einen neuen initialisieren und seinen Inhalt mit den anderen Replikationswarteschlangenmanager-Hosts neu synchronisieren. Einzelheiten finden Sie unter Initialisierung eines Replikationsknotens. Wenn der entsprechende NPS-Knoten der aktuelle primäre ist, müssen Sie ihn zum Replikat degradieren und die Befehle nzreplanalyze, nzreplbackup und nzreplrestore verwenden, um die beschädigten Datenbanken wiederherzustellen.
Eine Tabelle wird zu einer versionierten Tabelle, wenn Benutzer Spalten zu der Tabelle hinzufügen oder aus ihr entfernen. Das Aktualisieren von Zeilen in einer versionierten Tabelle kann dazu führen, dass das Replikat angehalten wird.	Das Replikat wird mit dem folgenden Fehler angehalten:`Versioned tables do not support DELETE operations that join again to the versioned table`.	Führen Sie auf dem Replikationsknoten die folgenden Schritte aus: Geben Sie den Befehl GROOM TABLE mit der Option VERSIONS ein. Aktivieren Sie das Replikat und starten Sie die Replikation neu, indem Sie den Befehl ALTER REPLICATION NODE repslet. `<subordinatenodename>` STATE ACTIVE eingeben.