الأداء واستكشاف الأخطاء وإصلاحها لاستخراج بيانات SAP
هذه المقالة هي جزء من سلسلة مقالة "توسيع SAP للبيانات والابتكار: أفضل الممارسات".
- تحديد مصادر بيانات SAP
- اختيار أفضل موصل SAP
- الأداء واستكشاف الأخطاء وإصلاحها لاستخراج بيانات SAP
- أمان تكامل البيانات ل SAP على Azure
- بنية عامة لدمج بيانات SAP
هناك العديد من الطرق للاتصال بنظام SAP لتكامل البيانات. تصف الأقسام أدناه الاعتبارات والتوصيات العامة والموصلة الخاصة.
الأداء
من المهم تكوين الإعدادات المثلى للمصدر والهدف حتى تتمكن من تحقيق أفضل أداء أثناء استخراج البيانات ومعالجتها.
اعتبارات عامة
- تأكد من تعيين معلمات SAP الصحيحة لاتصال متزامن أقصى.
- ضع في اعتبارك استخدام نوع تسجيل الدخول إلى مجموعة SAP للحصول على أداء أفضل وتوزيع تحميل.
- تأكد من حجم الجهاز الظاهري لوقت تشغيل التكامل المستضاف ذاتيا (SHIR) بشكل كاف ومتاح بشكل كبير.
- عند العمل مع مجموعات بيانات كبيرة، تحقق مما إذا كان الموصل الذي تستخدمه يوفر إمكانية التقسيم. تدعم العديد من موصلات SAP قدرات التقسيم والتوازي لتسريع أحمال البيانات. عند استخدام هذا الأسلوب، يتم حزم البيانات في مجموعات أصغر يمكن تحميلها باستخدام العديد من العمليات المتوازية. لمزيد من المعلومات، راجع الوثائق الخاصة بالموصل.
التوصيات العامة
استخدم معاملة SAP RZ12 لتعديل قيم الحد الأقصى للاتصالات المتزامنة.
معلمات SAP ل RFC - RZ12: يمكن للمعلمة التالية تقييد عدد استدعاءات RFC المسموح بها لمستخدم واحد أو تطبيق واحد، لذا تأكد من أن هذا التقييد لا يسبب ازدحاما.
الاتصال ب SAP باستخدام مجموعة تسجيل الدخول: يجب أن يتصل SHIR (وقت تشغيل التكامل المستضاف ذاتيا) ب SAP باستخدام مجموعة تسجيل دخول SAP (عبر خادم الرسائل) وليس بخادم تطبيق معين لضمان توزيع حمل العمل عبر جميع خوادم التطبيقات المتوفرة.
ملاحظة
نظام مجموعة Dataflow Spark وSHIR قويان. يمكن تشغيل العديد من أنشطة نسخ SAP الداخلية، على سبيل المثال 16، وتنفيذها. ولكن إذا كان رقم الاتصال المتزامن لخادم SAP صغيرا، على سبيل المثال 8، يقرأ perf البيانات من جانب SAP.
ابدأ ب 4vCPUs وأجهزة ظاهرية بسعة 16 غيغابايت ل SHIR. توضح الخطوات التالية اتصال عملية عمل مربع الحوار في SAP مع SHIR.
- تحقق مما إذا كان العميل يستخدم جهازا ماديا ضعيفا لإعداد SHIR وتثبيته لتشغيل نسخة SAP داخلية.
- انتقل إلى مدخل Azure Data Factory وابحث عن خدمة SAP CDC المرتبطة ذات الصلة المستخدمة في تدفق البيانات. تحقق من اسم SHIR المشار إليه.
- تحقق من إعدادات وحدة المعالجة المركزية والذاكرة والشبكة والقرص للجهاز الفعلي حيث يتم تثبيت SHIR.
- تحقق من عدد
diawp.exe
الذين يتم تشغيلهم على جهاز SHIR. يمكن للمرءdiawp.exe
تشغيل نشاط نسخة واحدة. يعتمد عددdiawp.exe
على إعدادات وحدة المعالجة المركزية والذاكرة والشبكة والقرص للجهاز.
إذا كنت تريد تشغيل أقسام متعددة بالتوازي على SHIR في نفس الوقت، فاستخدم جهازا ظاهريا قويا لإعداد SHIR. أو استخدم توسيع النطاق باستخدام ميزات قابلية الوصول العالية وقابلية التوسع SHIR للحصول على عقد متعددة. لمزيد من المعلومات، راجع التوافر العالي وقابلية التوسع العالية.
التقسيمات
يصف القسم التالي عملية التقسيم لموصل SAP CDC. العملية هي نفسها لموصل SAP Table وSAP BW Open Hub.
يمكن إجراء التحجيم على وقت تشغيل التكامل المستضاف ذاتيا أو وقت تشغيل تكامل Azure اعتمادا على متطلبات الأداء الخاصة بك. راجع استهلاك وحدة المعالجة المركزية ل SHIR لعرض المقاييس لمساعدتك في اتخاذ قرار بشأن نهج التحجيم الخاص بك. يمكن تحجيم SHIR عموديا أو أفقيا بناء على احتياجاتك. نوصي بنشر وقت تشغيل تكامل Azure في وحدة SKU أقل. قم بالتوسيع لتلبية متطلبات الأداء الخاصة بك كما هو محدد من خلال اختبار التحميل، بدلا من البدء في النهاية الأعلى دون داع.
ملاحظة
إذا كنت تصل إلى سعة 70٪، فقم بتوسيع نطاق SHIR أو توسيعه.
التقسيم مفيد للأحمال الكاملة الأولية أو الكبيرة وعادة ما لا يكون مطلوبا لأحمال دلتا. إذا لم تحدد القسم، بشكل افتراضي، فإن 1 "منتج" في نظام SAP (عادة عملية دفعة واحدة) يجلب البيانات المصدر في قائمة انتظار البيانات التشغيلية (ODQ)، ويجلب SHIR البيانات من ODQ. بشكل افتراضي، يستخدم SHIR أربعة مؤشرات ترابط لجلب البيانات من ODQ، لذلك من المحتمل أن تكون أربع عمليات مربع حوار مشغولة في SAP في ذلك الوقت.
فكرة التقسيم هي تقسيم مجموعة بيانات أولية كبيرة إلى مجموعات فرعية أصغر متعددة مفككة متساوية من الناحية المثالية في الحجم ويمكن معالجتها بالتوازي. يقلل هذا الأسلوب من الوقت المستغرق لإنتاج البيانات من الجدول المصدر إلى ODQ بطريقة خطية. يفترض هذا الأسلوب وجود موارد كافية على جانب SAP للتعامل مع الحمل.
ملاحظة
- عدد الأقسام المنفذة بالتوازي محدود بعدد الذاكرات الأساسية لبرنامج التشغيل في Azure IR. هناك حل لهذا القيد قيد التنفيذ حاليا.
- كل وحدة أو حزمة في معاملة SAP ODQMON هي ملف واحد في المجلد المرحلي.
اعتبارات التصميم عند تشغيل البنية الأساسية لبرنامج ربط العمليات التجارية باستخدام CDC
تحقق من SAP لمرحلة المدة.
تحقق من أداء وقت التشغيل في المتلقي.
ضع في اعتبارك استخدام ميزة التقسيم لتحسين الأداء لتحسين معدل النقل.
إذا كانت مدة إعداد SAP بطيئة، ففكر في تغيير حجم SHIR إلى مواصفات أعلى.
تحقق مما إذا كان وقت معالجة المتلقي بطيئا جدا.
إذا تم استخدام مجموعة صغيرة لتشغيل تدفق بيانات التعيين، فقد يؤثر ذلك على الأداء في المتلقي. استخدم مجموعة كبيرة، على سبيل المثال 16 + 256 نواة، بحيث يقرأ perf البيانات من المرحلة ويكتب في المتلقي.
بالنسبة إلى وحدات تخزين البيانات الكبيرة، نوصي بتقسيم الحمل لتشغيل مهام متوازية، ولكن مع الاحتفاظ بعدد الأقسام أقل من أو يساوي ذاكرة Azure IR الأساسية، التي تسمى أيضا نواة نظام مجموعة Spark.
استخدم علامة التبويب تحسين لتعريف الأقسام. يمكنك استخدام تقسيم المصدر في موصل CDC.
ملاحظة
- هناك ارتباط مباشر بين عدد الأقسام مع مراكز SHIR وعقد وقت تشغيل التكامل Azure.
- يتم سرد موصل SAP CDC كنوع مشترك Odata "وصول Odata لتوفير البيانات التشغيلية" ضمن ODQMON في نظام SAP.
اعتبارات التصميم عند استخدام موصل جدول
- تحسين التقسيم للحصول على أداء أفضل.
- ضع في اعتبارك درجة التوازي من جدول SAP.
- ضع في اعتبارك تصميم ملف واحد للمتلقي الهدف.
- قياس معدل النقل عند استخدام وحدات تخزين البيانات الكبيرة.
تصميم التوصيات عند استخدام موصل جدول
قسم: عند التقسيم في موصل جدول SAP، فإنه يقسم عبارة تحديد أساسية واحدة إلى عدة عبارات باستخدام حيث توجد عبارات في حقل مناسب، على سبيل المثال حقل ذو علاقة أساسية عالية. إذا كان جدول SAP يحتوي على حجم كبير من البيانات، فقم بتمكين التقسيم لتقسيم البيانات إلى أقسام أصغر. حاول تحسين عدد الأقسام (المعلمة
maxPartitionsNumber
) بحيث تكون الأقسام صغيرة بما يكفي لتجنب تفريغ الذاكرة في SAP ولكنها كبيرة بما يكفي لتسريع الاستخراج.التوازي: تعمل درجة توازي النسخ (المعلمة
parallelCopies
) جنبا إلى جنب مع التقسيم وترشد SHIR لإجراء استدعاءات RFC متوازية إلى نظام SAP. على سبيل المثال، إذا قمت بتعيين هذه المعلمة إلى 4، تقوم الخدمة بشكل متزامن بإنشاء وتشغيل أربعة استعلامات استنادا إلى خيار القسم المحدد والإعدادات. يسترد كل استعلام جزءا من البيانات من جدول SAP.للحصول على النتائج المثلى، يجب أن يكون عدد الأقسام مضاعفا لعدد درجة توازي النسخ.
عند نسخ البيانات من جدول SAP إلى متلقيات ثنائية، يتم تعديل العدد المتوازي الفعلي تلقائيا استنادا إلى مقدار الذاكرة المتوفرة في SHIR. سجل حجم SHIR VM لكل دورة اختبار ودرجة توازي النسخ وعدد الأقسام. لاحظ أداء SHIR VM، وأداء نظام SAP المصدر، ودرجة التوازي المطلوبة مقابل الدرجة الفعلية للتوازي. استخدم عملية تكرارية لتحديد الإعدادات المثلى والحجم المثالي لجهاز SHIR الظاهري. ضع في اعتبارك جميع مسارات الاستيعاب التي تقوم بتحميل البيانات في وقت واحد من نظام SAP واحد أو عدة أنظمة.
لاحظ العدد الملحوظ لاستدعاءات RFC إلى SAP مقابل درجة التوازي المكونة. إذا كان عدد استدعاءات RFC إلى SAP أقل من درجة التوازي، فتحقق من أن الجهاز الظاهري ل SHIR يحتوي على ذاكرة كافية وموارد وحدة المعالجة المركزية المتوفرة. اختر جهازا ظاهريا أكبر إذا لزم الأمر. تم تكوين نظام SAP المصدر للحد من عدد الاتصالات المتوازية. لمزيد من المعلومات، راجع قسم التوصيات العامة في هذه المقالة.
عدد الملفات: عند نسخ البيانات إلى مخزن بيانات مستند إلى ملف وتكوين المتلقي المستهدف ليكون مجلدا، يتم إنشاء ملفات متعددة بشكل افتراضي. إذا قمت بتعيين الخاصية
fileName
في المتلقي، تتم كتابة البيانات إلى ملف واحد. يوصى بالكتابة إلى مجلد كملفات متعددة لأنه يحصل على معدل نقل أعلى للكتابة مقارنة بالكتابة إلى ملف واحد.معيار الأداء: نوصي باستخدام تمرين قياس الأداء لاستيعاب كميات كبيرة من البيانات. يختلف هذا الأسلوب المعلمات، مثل التقسيم ودرجة التوازي وعدد الملفات لتحديد الإعداد الأمثل للبنية المحددة وحجم البيانات ونوعها. جمع البيانات من الاختبارات بالتنسيق التالي.
استكشاف الأخطاء وإصلاحها
للاستخراج البطيء أو الفاشل من نظام SAP، استخدم سجلات SAP من SM37 ومطابقتها مع القراءات في Data Factory.
إذا تم تشغيل مهمة دفعية واحدة فقط، فقم بتعيين أقسام مصدر SAP لتحسين الأداء في تدفق بيانات التعيين في Data Factory. لمزيد من المعلومات، راجع الخطوة 6 في خصائص تدفق بيانات الخريطة.
إذا تم تشغيل وظائف دفعية متعددة في نظام SAP وكان هناك فرق كبير بين وقت بدء كل مهمة دفعية، فقم بتغيير حجم وقت تشغيل تكامل Azure. عند زيادة عدد عقد برنامج التشغيل في Azure IR، يزداد توازي وظائف الدفعات في جانب SAP.
ملاحظة
الحد الأقصى لعدد عقد برنامج التشغيل ل Azure IR هو 16. يمكن لكل عقدة برنامج تشغيل تشغيل تشغيل عمليات دفعة واحدة فقط.
تحقق من السجلات في SHIR. لعرض السجلات، انتقل إلى SHIR VM. افتح Event viewer > Applications and service logs > Connectors > Integration runtime.
لإرسال سجلات إلى الدعم، انتقل إلى SHIR VM. افتح Integration Runtime configuration manager > Diagnostic > Send Logs. يرسل هذا الإجراء السجلات من الأيام السبعة الماضية ويوفر لك معرف تقرير. تحتاج إلى معرف التقرير هذا ومعرف RunId للتشغيل الخاص بك. توثيق معرف التقرير للرجوع إليه في المستقبل.
عند استخدام موصل SAP CDC في سيناريو SLT:
تأكد من استيفاء المتطلبات الأساسية. الأدوار مطلوبة لمستخدم SAP Landscape Transformation (SLT)، على سبيل المثال ADFSLTUSER في أنظمة OLTP أو ECC لكي يعمل النسخ المتماثل SLT. لمزيد من المعلومات، راجع ما هي التخويلات والأدوار المطلوبة.
إذا حدثت أخطاء في سيناريو SLT، فراجع التوصيات للتحليل. عزل السيناريو واختباره داخل حل SAP أولا. على سبيل المثال، اختبره خارج Data Factory عن طريق تشغيل برنامج الاختبار الذي توفره SAP
RODPS_REPL_TEST
في SE38. إذا كانت المشكلة على جانب SAP، فستحصل على نفس الخطأ عند استخدام التقرير. يمكنك تحليل استخراج البيانات في SAP باستخدام رمزODQMON
المعاملة .إذا كان النسخ المتماثل يعمل عند استخدام تقرير الاختبار هذا، ولكن ليس مع Data Factory، فاتصل بدعم Azure أو Data Factory.
يوضح المثال التالي تقريرا ل
RODPS_REPL_TEST
في SE38:يوضح المثال التالي رمز
ODQMON
المعاملة :عندما تتصل الخدمة المرتبطة ب Data Factory بنظام SLT، فإنها لا تعرض معرفات نقل الكتلة SLT عند تحديث حقل السياق .
لتشغيل سيناريو النسخ المتماثل ODP/ODQ لخادم النسخ المتماثل SAP LT، قم بتنشيط تنفيذ الوظيفة الإضافية للأعمال التالية (BAdI).
بدي:
BADI_ODQ_QUEUE_MODEL
تنفيذ التحسين:
ODQ_ENH_SLT_REPLICATION
في transaction LTRC، انتقل إلى علامة التبويب Expert Function وحدد Activate / Deactivate BAdI Implementation لتنشيط التنفيذ.
حدد نعم.
في مجلد الدالات المحددة ODQ/ODP ، حدد التحقق مما إذا كان تنفيذ BAdI نشطا.
يعرض مربع الحوار نشاط البرنامج.
إعادة تعيين الاشتراكات. للبدء باستخراج جديد أو إيقاف بيانات النسخ المتماثل، قم بإزالة الاشتراك في ODQMON. يزيل هذا الإجراء أيضا الإدخالات من LTRC. بعد إعادة تعيين الاشتراك، قد يستغرق الأمر بضع دقائق قبل أن ترى التأثير في LTRC. جدولة مهام إدارة المنازل لتوفير البيانات التشغيلية (ODP) للحفاظ على قوائم انتظار دلتا نظيفة، على سبيل المثال
ODQ_CLEANUP_CLIENT_004
CDS_VIEW (معاملة DHCDCMON). اعتبارا من S/4HANA 1909، ينسخ SAP البيانات من طرق عرض CDS التي تستخدم المشغلات المستندة إلى البيانات بدلا من أعمدة التاريخ. المفهوم مشابه ل SLT، ولكن بدلا من استخدام معاملة LTRC لمراقبتها، يمكنك استخدام معاملة DHCDCMON.
استكشاف أخطاء SLT وإصلاحها
يوفر خادم النسخ المتماثل SLT نسخا متماثلا للبيانات في الوقت الحقيقي من مصادر SAP و/أو مصادر غير SAP إلى أهداف SAP و/أو أهداف غير SAP. هناك ثلاثة أنواع من مجموعات الأدوات لمراقبة الاستخراج من SLT إلى Azure.
- ODQMON هي أداة المراقبة الشاملة لاستخراج البيانات. ابدأ التحليل باستخدام ODQMON لتعقب حالات عدم تناسق البيانات وتحليل الأداء الأولي وطلبات الاشتراك والاستخراج المفتوحة.
- LTRC هي العملية التي يجب استخدامها للتحقق من تحليل الأداء. من المفيد إذا كانت لديك مشكلات في النسخ المتماثل للبيانات من النظام المصدر إلى ODP لأنه يمكنك مراقبة تدفق البيانات والعثور على حالات عدم التناسق.
- يوفر SM37 مراقبة مفصلة لكل خطوة استخراج SLT.
يجب إجراء التدبير المنزلي العادي باستخدام ODQMON حيث يمكنك إدارة الاشتراك مباشرة ويجب عدم استخدام LTRC لنفس الشيء.
قد تواجه مشكلات عند استخراج البيانات من SLT، مثل:
لا يتم تشغيل الاستخراج. تحقق مما إذا كان اتصال SAP CDC قد أنشأ اتصالا في ODQMON، وتحقق مما إذا كان الاشتراك موجودا.
عدم تناسق البيانات. تحقق من ODQMON لمشاهدة الطلب الفردي للبيانات وتأكد من أنه يمكنك رؤية البيانات هناك. إذا كان بإمكانك رؤية البيانات في ODQMON ولكن ليس في Azure Synapse أو Data Factory، يجب أن يحدث التحقيق على جانب Azure. إذا لم تتمكن من رؤية البيانات في ODQMON، فقم بإجراء تحليل لإطار عمل SLT باستخدام LTRC.
مشاكل الأداء. استخراج البيانات هو نهج خطوتين. أولا، يقرأ SLT البيانات من النظام المصدر وينقلها إلى ODP. ثانيا، يلتقط موصل SAP CDC البيانات من ODP وينقلها إلى مخزن البيانات المختار. تتيح لك معاملة LTRC تحليل الجزء الأول من عملية الاستخراج. لتحليل استخراج البيانات من ODP إلى Azure، استخدم أدوات مراقبة ODQMON وData Factory أو Synapse.
ملاحظة
للاطلاع على مزيد من المعلومات، راجع هذه الموارد:
أداء SLT
في وضع التحميل الأولي (ODPSLT)، هناك ثلاث خطوات لاستخراج البيانات من SLT إلى ODP:
- إنشاء كائنات الترحيل. تستغرق هذه العملية بضع ثوان فقط.
- الوصول إلى حساب الخطة الذي يقسم الجدول المصدر إلى أجزاء أصغر. تعتمد هذه الخطوة على وضع التحميل الأولي الذي تحدده أثناء تكوين SLT وحجم الجدول. يوصى بالخيار المحسن للموارد.
- ينقل تحميل البيانات البيانات من النظام المصدر إلى ODP.
يتم التحكم في كل خطوة بواسطة وظائف الخلفية. يمكنك استخدام معاملات SM37 وLTRC لمراقبة المدة. إذا كان النظام الخاص بك يستخدم بشكل مفرط، فقد تبدأ مهام الخلفية لاحقا لأنه لا توجد عمليات عمل دفعية مجانية كافية. عندما تكون المهام الخامة، يعاني الأداء.
إذا استغرق حساب خطة الوصول وقتا طويلا وتم تعيين وضع التحميل الأولي إلى "تحسين الأداء"، فقم بتغييره إلى "محسن للموارد" وأعد تشغيل الاستخراج. إذا استغرق تحميل البيانات وقتا طويلا، فقم بزيادة عدد مؤشرات الترابط المتوازية في التكوين.
إذا كنت تستخدم بنية مستقلة للنسخ المتماثل SLT (خادم النسخ المتماثل SLT المخصص)، فقد يؤثر معدل نقل الشبكة بين النظام المصدر وخادم النسخ المتماثل على أداء الاستخراج.
للنسخ المتماثل:
- تأكد من أن لديك مهام نقل بيانات كافية غير محجوزة للتحميل الأولي.
- تحقق من عدم وجود سجل جدول تسجيل غير معالج في إحصائيات التحميل.
- تأكد من تعيين خيار النسخ المتماثل إلى الوقت الحقيقي.
تتوفر إعدادات النسخ المتماثل المتقدمة في LTRS. لمزيد من المعلومات، راجع دليل استكشاف الأخطاء وإصلاحها في SLT.
تحتوي إصدارات SAP المختلفة على واجهات مستخدم LTRC مختلفة. تظهر لقطات الشاشة التالية نفس الصفحة لإصدارين مختلفين.
SAP S/4HANA:
SAP ECC:
Monitor
للحصول على معلومات حول مراقبة استخراج بيانات SAP، راجع هذه الموارد: