المقدمة
يصف هذا وثيقة الخطوات أن يتحرى عندما يكون مسجل UCCE A و B عالقين في حالة تهيئة.
تمت المساهمة بواسطة براثام براكاش، مهندس برامج Cisco.
المتطلبات الأساسية
المتطلبات
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
- Cisco UCCE
- لغة الاستعلام المنظم ل Microsoft (SQL)
المكونات المستخدمة
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك مباشرة، فتأكد من فهمك للتأثير المحتمل لأي أمر.
المشكلة
كشف تحليل السجل عن أن مسجل UCCE A و B عالقان في حالة تهيئة. لن يصبح المشغلون على كلا الجانبين نشطين ويواصل المشغلون التعطل باستثناء استنفاد اتصال BCP. يمكن العثور على مثال لرسالة الخطأ لهذا الشرط في ملفات السجل.
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
يحدث هذا نظرا لوجود مفاتيح مكررة موجودة في الجدول t_Persistent_Variable. لا يتمكن أي من المسجل A و B من إكمال التهيئة.
الحل
يمكن أن يحدث هذا الشرط عند إستخدام متغيرات مستمرة على UCCE الإصدار 10.x ThedDefect CSCuw02024t_Persistent_Variable الجدول الذي يحذف السجلات ويعاد إضافتها.
تنفيذ الحل التالي
الخطوة 1. قم بتعيين مفتاح التسجيل التالي على المسجل من الجانب "أ" والمسجل من الجانب "ب" من القيمة 1 إلى 0
HKEY_LOCAL_MACHINE\Software\Geotel\ICR\Customerinstance\LoggerB\Logger\HistoricalData\Persistent
الخطوة 2 انزل جانبا واحدا
1) اقتطاع الجداول Persistent_VariableTmp1 و Persistent_VariableTmp2 و t_Persistent_Variable من الجانب السفلي.
2) اقتطاع الجداول Persistent_VariableTmp1 و Persistent_VariableTmp2 و t_Persistent_Variable من الجانب النشط.
الخطوة 3 إعادة تشغيل خدمة المسجل على كل من الجانب A والجانب B
الخطوة 4 قم بإجراء الاختبار للتأكد من قدرة المستخدمين على إجراء تغييرات التكوين.
الخطوة 5 ضع مكالمة إختبار في النظام للتحقق من عمل المكالمات.
الخطوة 6 قد يكون من الصعب تنفيذ exit_router، وتبين أن النظام قيد التشغيل، وقد أكمل كلا جانبي الموجهات عملية نقل الحالة عن طريق أخذ التكوين من الجانب A من المسجل. على الرغم من أن نظام مركز الاتصال يعمل ويعمل، إلا أن المسجل من الجانب ب لا يزال في حالة التهيئة. حدث هذا عندما يكون مفتاح الاسترداد الخاص بالمسجل من الجانب B متخلفا عن المسجل من الجانب A بمقدار كبير.
الخطوة 7 تنفيذ التكوين اليدوي db من a —> b
تم إجراء تصدير/إستيراد بيانات التكوين يدويا من A —> B
على الرغم من تطابق LastUpdatekey بين الجانب A و B، فقد اشتكى المسجل B من خطأ في المجموع الاختباري. قم بإجراء مزامنة المسجل اليدوي ل config db من خلال ICMDBA لمنع خطأ المجموع الاختباري.
تم القيام لاحقا بالخطوات التالية لحل مشكلة المجموع الاختباري
1. تم إيقاف تغيير التكوين عن طريق تغيير مفتاح تسجيل DBMenenance إلى 1
2. قم بإجراء نسخ إحتياطي لقاعدة بيانات المسجل بالكامل على MSSQL. ونقل النسخ الاحتياطي ل DB إلى خادم B المسجل.
3. إسقاط قاعدة بيانات المسجل ب، وإعادة إنشاء قاعدة بيانات المسجل ب.
4. قم باستعادة DB المسجل على المسجل B من النسخة الاحتياطية من قاعدة البيانات من المسجل A.
5. النسخ الاحتياطي لخدمة المسجل المشغل من الفئة "ب".
6. إعادة تعيين مفتاح تسجيل DBMeness إلى 0
دققت
1. نجح الموجه في تأسيس اتصال MDS مع عمليات المسجل B، بما في ذلك CLGR و HLGR و RCV ETCs.
2. لا ينسحب المسجل B من MDS بسبب خطأ المجموع الاختباري للبيانات.
3. نظرا لأن المسجل B كان في حالة إيقاف التشغيل لبضعة أيام، فإن النظام يقوم الآن بمزامنة البيانات التاريخية مع HDS بشكل نشط.
4. لا يزال التغيير في التكوين يعمل
التعليقات