اتصال JDBC إلى SQL 2000 مشغول للغاية: SelectMethod = Cursor vs SelectMethod = Direct؟
-
26-09-2019 - |
سؤال
في عملية محاولة مساعدة فريق DEV APP الذي يعاني من مشكلات في الأداء على خادم SQL 2000 (من مجموعة من تطبيقات Java على خوادم التطبيقات المنفصلة) ، قمت بتشغيل أثر SQL واكتشفت أن جميع المكالمات إلى قاعدة البيانات مليئة بـ API عبارات مؤشر الخادم (sp_cursorprepexec ، sp_cursorfetch ، sp_cursorclose).
يبدو أنهم يحددون بعض خصائص سلسلة الاتصال التي تجبر استخدام المؤشرات من جانب الخادم ، واسترداد 128 صفًا فقط من البيانات في وقت واحد: (من http://msdn.microsoft.com/en-us/library/AA172588)
عندما يتم تعيين سمات أو خصائص مؤشر API على أي شيء آخر غير الافتراضيات ، فإن مزود OLE DB لخادم SQL و SQL Server ODBC يستخدم مؤشرات خادم API بدلاً من مجموعات النتائج الافتراضية. كل مكالمة إلى دالة API التي تجلب صفوفًا تقوم بإنشاء مستديرة إلى الخادم لجلب الصفوف من مؤشر خادم API.
تحديث: سلسلة الاتصال في العدد هي معلمة سلسلة اتصال JDBC ، selectMethod=cursor
(الذي يمكّن المؤشرات من جانب الخادم التي ناقشناها أعلاه) مقابل البديل selectMethod=direct
. لقد كانوا يستخدمون selectMethod=cursor
كسلسلة اتصال قياسية من جميع التطبيقات.
من وجهة نظر DBA الخاصة بي ، هذا مزعج (إنه يتجول في التتبع مع خردة غير مجدية) ، و (أود التكهن) يؤدي إلى العديد من رحلات خادم التطبيق إلى SQL ، مما يقلل من الأداء الكلي.
يبدو أنهم اختبروا تغيير (واحد فقط من حوالي 60 اتصالات تطبيقات مختلفة) إلى selectMethod=direct
لكن عانيت من بعض المشكلات (التي ليس لدي أي تفاصيل) وأشعر بالقلق إزاء كسر التطبيق.
لذلك ، أسئلتي هي:
- يمكن استخدام
selectMethod=cursor
انخفاض أداء التطبيق ، كما حاولت أن أجادل؟ (بزيادة عدد الرحلات المستديرة اللازمة على خادم SQL الذي يحتوي بالفعل على استعلامات/ثانية للغاية) - هو
selectMethod=
إعداد تنقل التطبيق على اتصال JDBC؟ هل يمكن أن يكسر هذا تطبيقهم إذا قمنا بتغييره؟ - بشكل عام ، متى يجب أن تستخدم
cursor
ضدdirect
?
ايضا متقاطع إلى SF.
تعديل: تلقي التفاصيل الفنية الفعلية التي تستدعي تحريرًا مهمًا إلى العنوان والسؤال والعلامات.
تعديل: أضيفت مكافأة. تمت إضافة Bounty إلى سؤال SF (يركز هذا السؤال على سلوك التطبيق ، ويركز سؤال SF على أداء SQL.) شكرًا !!
المحلول
موجز،
selectMethod=cursor
- من الناحية النظرية يتطلب المزيد من الموارد من جانب الخادم من
selectMethod=direct
- فقط الأحمال على الأكثر حجم الدفعة السجلات في ذاكرة العميل في وقت واحد ، مما يؤدي إلى بصمة ذاكرة عميل أكثر يمكن التنبؤ بها
- من الناحية النظرية يتطلب المزيد من الموارد من جانب الخادم من
selectMethod=direct
- من الناحية النظرية ، يتطلب موارد أقل من جانب الخادم من
selectMethod=cursor
- سوف تقرأ النتيجة بالكامل التي تم تعيينها في ذاكرة العميل (ما لم يدعم برنامج التشغيل أصلاً استرجاعًا غير متزامن للنتيجة) قبل أن يتكرر تطبيق العميل ؛ هذه يمكن أن تقلل الأداء بطريقتين:
- انخفاض الأداء مع مجموعات نتائج كبيرة إذا تم كتابة تطبيق العميل بطريقة تتوقف عن المعالجة بعد اجتياز جزء صغير فقط من مجموعة النتائج (مع
direct
لقد دفعت بالفعل تكلفة استرداد البيانات التي سيتم التخلص منها بشكل أساسي ؛ معcursor
يقتصر النفايات على الأكثر حجم الدفعة - 1 صفوف - من المحتمل أن يتم إعادة ترميز حالة الإنهاء المبكرة في SQL على أي حال على سبيل المثالSELECT TOP
أو وظائف النافذة) - انخفاض الأداء مع مجموعات النتائج الكبيرة بسبب جمع القمامة المحتملة و/أو المشكلات خارج الذاكرة المرتبطة ببعض البصمة الذاكرة
- انخفاض الأداء مع مجموعات نتائج كبيرة إذا تم كتابة تطبيق العميل بطريقة تتوقف عن المعالجة بعد اجتياز جزء صغير فقط من مجموعة النتائج (مع
- من الناحية النظرية ، يتطلب موارد أقل من جانب الخادم من
في تلخيص،
- يمكن استخدام
selectMethod=cursor
انخفاض أداء التطبيق؟ - يمكن لأي من الطريقة أن يقلل من الأداء ، لأسباب مختلفة. بعد حجم مجموعة نتائج معينة ،cursor
قد لا يزال من الأفضل. انظر أدناه لموعد استخدام واحد أو آخر - هو
selectMethod=
إعداد تنقل التطبيق على اتصال JDBC؟ - إنه شفاف ، ولكن لا يزال بإمكانه كسر تطبيقه إذا كان استخدام الذاكرة ينمو بشكل كبير بما يكفي لخزانة نظام عملائهم (وفي المقابل ، الخادم الخاص بك) أو تعطل العميل تمامًا - بشكل عام ، متى يجب أن تستخدم
cursor
ضدdirect
? - أنا شخصيا استخدامcursor
عند التعامل مع مجموعات نتائج كبيرة أو غير محدودة. ثم يتم إطفاء النفقات العامة المستديرة بالنظر إلى حجم دفعة كبيرة بما يكفي ، ويكون بصمة ذاكرة العميل الخاصة بي يمكن التنبؤ بها. أنا أستعملdirect
عندما يكون حجم مجموعة النتائج التي أتوقع أن يكون أدنى من حجم الدُفعة الذي أستخدمهcursor
, أو ملزمة بطريقة ما ، أو عندما لا تكون الذاكرة مشكلة.
نصائح أخرى
استخدام selectMethod=cursor
يمنع خادم SQL من استخدام معالجة الاستعلام الموازية, ، والتي يمكن أن يكون لها تأثير كبير في الأداء ، على سبيل المثال عندما:
- لديك العديد من نوى وحدة المعالجة المركزية (ومن لا؟)
- لقد قمت بتحسين قاعدة البيانات الخاصة بك عن طريق تقسيم الجداول
- أنت تقوم بتشغيل الكثير من الاستفسارات الكلية (
sum()
,count()
, ، إلخ.)
وأخيرا ، Microsoft تنص على ما يلي:
(
selectMethod=direct
) يوفر أسرع أداء عندما يقوم التطبيق بمعالجة جميع الصفوف.
يجب أن تحاول بالتأكيد معرفة ما إذا كان إعداد SelectMethod = Direct يحدث فرقًا بالنسبة لك.