الحد الأقصى لمبلغ البيانات التي يمكن معالجتها بواسطة رسالة ICM MDS
المقدمة
يوضح هذا المستند الحد الأقصى لمقدار البيانات الذي يمكن معالجته من خلال رسالة خدمة توصيل الرسائل (MDS) الخاصة بإدارة الاتصال الذكية (ICM) والبنية الأساسية التي تقوم عليها.
معلومات أساسية
عند إجراء عمليات البحث في قاعدة البيانات باستخدام ICM (باستخدام dbworker.exe كعملية لتوفير الواجهة بين الموجه وقاعدة البيانات الخارجية)، يوجد حد أقصى لمبلغ البيانات الذي يمكن معالجته من خلال رسالة MDS.
لا يمكن أن يتجاوز إجمالي مبلغ رأس إستجابة لغة الاستعلام المهيكلة (SQL) + معالجة عامل DBW (DBW) 4096 بايت. هذا حد مشفر لرسالة MDS.
المكونات المستخدمة
تستند المعلومات الواردة في هذا المستند إلى ICM، الإصدار 11.6
المشكلة
إذا تم إرجاع بيانات كثيرة جدا إلى dbw من SQL Server، وتعذر على DBW تمريرها إلى الموجه (RTR)، يتم إنشاء حالة خطأ، مشابهة لهذا:
06:33:38:639 RA-DBW تتبع: قائمة الانتظار طلب بحث
06:33:38:644 ra-dbw Trace: DBWorker Thread 4 (ID 5612 Table:Stores_Receive_BT.SRDB_NEW): تم تلقي الطلب: TransactionID 14583170
06:33:38:658 ra-dbw Trace: DBWorker Thread 4 (ID 5612)،TransactionID 14583170، محاولة قراءة السجل:
06:33:38:679 ra-dbw Trace: DBWorker Thread 4 (ID 5612)،TransactionID 14583170، نجح(...)
06:33:38:735 ra-dbw Trace: DBWorker transactionID 14583170، فشل! النتيجة=10
06:33:38:745 تتبع RA-DBW: قائمة الانتظار طلب بحث
"10" - يعني أن بيانات كثيرة جدا تم إرجاعها إلى وضع البيانات (DBW) من SQL Server، ولا يمكن أن تنقلها DBW إلى RTR
لطباعة الخطأ، يتم إستخدام مستوى التتبع هذا:
مستوى التتبع DBW إلى 3 عبر Portico (مستوى التتبع 3 سيتم إستخدامه فقط بناء على توصية Cisco TAC)، ومستوى التتبع هذا ل RTR عبر أداة التتبع RTRTRACE (c:\icm\bin):
فيما يلي مثال على كيفية تكوين رسالة MDS بواسطة عملية DBW:
02:22:01:273 ra-dbw Trace: DBWorker Thread 2 (ID 15100 Table:ICM_LOOKUP_1): الطلب المستلم: TransactionID 3
02:22:01:273 ra-dbw Trace: DBWorker Thread 2 (ID 15100)،TransactionID 3، محاولة قراءة السجل:
02:22:01:273 ra-dbw Trace: نجح DBWorker Thread 2 (ID 15100)،TransactionID 3.
02:22:01:273 ra-dbw Trace: MDS: إدخال MDSAllocBuffer
02:22:01:273 ra-dbw Trace: SQLConnection::SetupColumnData: بيانات العمود للعمود 1 الطول = 5
02:22:01:273 ra-dbw Trace: SQLConnection::SetupColumnData: بيانات العمود للعمود 2 الطول = 0
02:22:01:273 ra-dbw Trace: SQLConnection::SetupColumnData: بيانات العمود للعمود 3 الطول = 0
تتبع رسائل 02:22:01:273 ra-dbw: MDS: إدخال MDSSendInput02:22:01:273 ra-dbw: العميل: يرسل DBW رسالة إلى عملية MDS.
EMT: الفئة=2 النوع=1 bodysize=116
MDS: rsrvd=0 hdrsize=16 bodysize=100 src=56 dst=1 priority=high
MDS: flags=02 { side_a } vtime=0006f03b seqno=0000 class=4 type=16
0000 03 00 000 000 00 |........|
0008 03 00 000 8e 13 000 |........|
00010 02 00 000 000 00 |........|
00018 000 000 000 00 |........|
00020 000 000 5 00 38 30 |......80|
00028 31 30 34 00 8c 13 000 |104.....|
00030 02 00 000 000 |........|
00038 000 000 000 00 |........|
00040 000 000 000 00 |........|
00048 8d 13 00 002 00 000 |........|
00050 000 000 000 00 |........|
00058 000 000 000 00 |........
00060 00 00 00 00
في هذا المثال، هناك 3 أعمدة نتيجة لاستعلام SQL إلى جدول تم تكوينه، تحتوي جميع الأعمدة على نوع VARCHAR(50) في DB.
تحتوي الاستجابة على 5 بايت من العمود الأول و 0 بايت في العمودين الآخرين.
استنادا إلى هذه الاستجابة، يقوم DBW بتكوين رسالة MDS حيث يتم تجميع كل عمود في حقل يتكون من 24 بايت رأس + 2 بايت طول + الحمولة + الإزاحة.
إذا لم يحتوي العمود على بيانات، على سبيل المثال، الطول = 0، فإنه سيظل يشغل: 24 بايت رأس + 2 بايت طول + 2 بايت إزاحة = 28 بايت.
الحل
لحل هذا السيناريو، ستحتاج إلى إزالة الأعمدة غير المستخدمة من الجداول/التكوين أو تقليص أسماء الأعمدة أو تقليص أحجام بيانات الأعمدة.
المستندات ذات الصلة:
التعليقات