Einführung
In diesem Dokument werden die Schritte zur Fehlerbehebung beschrieben, wenn die UCCE-Protokollierung A und B in einem Initialisierungszustand bleiben.
Mitarbeiter: Pratham Prakash, Cisco Software Engineer.
Voraussetzungen
Anforderungen
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
- Cisco UCCE
- Microsoft Structured Query Language (SQL)
Verwendete Komponenten
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Problem
Die Protokollanalyse zeigte, dass die UCCE-Protokollierung A und B in einem Initialisierungszustand stecken. Die Protokollierung auf beiden Seiten wird nicht aktiv, und die Protokollierung stürzt mit einer Ausnahme ab, wenn die bcp-Verbindung erschöpft ist. Ein Beispiel für eine Fehlermeldung für diese Bedingung finden Sie in den Protokolldateien.
14:09:45:286 la-rcv Trace: SQL Server User Error: 2627, State 1, Severity: 14, Message:
Violation of PRIMARY KEY constraint 'XPKPeripheral_Interval'. Cannot insert duplicate key
in object 'dbo.t_Peripheral_Interval'. The duplicate key value is (Jul 3 2015 12:30PM,
5002, 300, 1).
14:09:45:335 la-rcv Trace: Duplicate key ignored because the record already exist in the
database.
14:09:45:335 la-rcv Trace: bcp_done failed
Dies geschieht, weil in der Tabelle t_Persistent_Variable doppelte Schlüssel gefunden wurden. Keine der beiden Protokollierungseinheiten A und B kann die Initialisierung abschließen.
Lösung
Diese Bedingung kann auftreten, wenn persistente Variablen in UCCE Release 10.x ThedDefect "CSCuw02024 t_Persistent_Variable table deleting and readding record" (CSCuw02024 t_Persistent_Variable-Tabelle löschen und neue Datensätze hinzufügen) verwendet werden.
Durchführen der folgenden Problemumgehung
Schritt 1: Legen Sie den folgenden Registrierungsschlüssel auf der Anmelderseite A und der Protokollierungsseite B von Wert 1 auf 0 fest
HKEY_LOCAL_MACHINE\Software\Geotel\ICR\Customerinstance\LoggerB\Logger\HistoricalData\Persistent
Schritt 2: Nehmen Sie eine Seite nach unten
1) die Tabellen Persistent_VariableTmp1, Persistent_VariableTmp2 und t_Persistent_Variable auf der Unterseite abschneiden.
2) die Tabellen Persistent_VariableTmp1, Persistent_VariableTmp2 und t_Persistent_Variable auf der aktiven Seite abschneiden.
Schritt 3 Starten Sie den Protokollierungsdienst auf Seite A und Seite B neu.
Schritt 4 Führen Sie einen Test durch, um sicherzustellen, dass Benutzer Konfigurationsänderungen vornehmen können.
Schritt 5 Führen Sie einen Testanruf in das System ein, um sicherzustellen, dass die Anrufe funktionieren.
Schritt 6 Möglicherweise ist es auch weiterhin erforderlich, Exit_Router auszuführen. Es wurde festgestellt, dass das System betriebsbereit ist und beide Seiten von Routern die Statusübertragung abgeschlossen haben, indem sie die Konfiguration von Seite A Logger übernommen haben. Obwohl das Contact Center-System läuft und funktioniert, befindet sich die SID-B-Protokollierungs-DB noch im Initialisierungsstatus. Dies geschah, wenn der Wiederherstellungs-Schlüssel der Seite B der Protokollierung um eine enorme Menge verzögert ist.
Schritt 7 Durchführen der manuellen Konfiguration db von A —> B
Manuelle Export-/Import-Konfigurationsdaten von A —> B
Obwohl lastUpdatekey zwischen Seite A und B abgeglichen wird, beschwerte sich Logger B clgr über einen Prüfsummenfehler. Führen Sie eine db-Synchronisierung mit der manuellen Protokollierungskonfiguration durch ICMDBA durch, um Prüfsummenfehler zu vermeiden.
Später wurden folgende Schritte ausgeführt, um das Prüfsummenproblem zu beheben
1. Konfig.-Änderung durch Ändern des DBMaintnance-Registrierungsschlüssels in 1 angehalten
2. Die gesamte Protokollierungs-A-Datenbank auf MSSQL gesichert. und übertrug die DB-Sicherung an den Logger B-Server.
3. Logger B-Datenbank gelöscht und Logger B-Datenbank neu erstellt.
4. Logger db auf Logger B von der db-Sicherung von Logger A wiederhergestellt.
5. Powered Logger B Service Backup.
6. Setzen Sie den DBMaintenance-Registrierungsschlüssel auf 0 zurück.
Verifiziert
1. Der Router-Test hat erfolgreich die MDS-Verbindung mit Logger-B-Prozessen hergestellt, einschließlich CLGR, HLGR, RCV etc.
2. Protokollierung B wird aufgrund eines Datenprüfsummenfehlers nicht von MDS gelöscht.
3. Da sich Logger B seit einigen Tagen im heruntergefahrenen Zustand befindet, synchronisiert das System jetzt aktiv historische Daten mit HDS.
4. Konfigurationsänderung funktioniert noch.
Feedback