حساسية حالة الأحرف عند الاستعلام عن SQL Server 2005 من .NET باستخدام OleDB

Question

لدي استعلام أقوم بتنفيذه من تطبيق .NET إلى قاعدة بيانات SQL Server ويبدو أن إكماله يستغرق بعض الوقت (أكثر من 5 دقائق).لقد قمت بإنشاء تطبيق اختباري في C# لمحاولة معرفة ما كان يتحدث لفترة طويلة (يجب أن يعود الاستعلام بسرعة).

بينما كنت أعيد بناء الاستعلام عن طريق إضافة عناصر لمعرفة الجزء الذي كان يستغرق وقتًا طويلاً، انتهى بي الأمر بإعادة بناء الاستعلام حرفيًا عمليًا حيث كان الاختلاف الوحيد هو المسافات في الاستعلام الأصلي وفرق الكتابة بالأحرف الكبيرة.أعاد هذا الاختلاف نتيجة في حوالي 100 مللي ثانية.

هل رأيتم هذا من قبل؟أتساءل عما إذا كانت هناك خدمات معطلة في خادمنا (نظرًا لأن أحد زملائي يعاني من نفس المشكلة) أو على أجهزة الكمبيوتر لدينا.

ويرجع الفضل في ذلك مسبقا لأية مساعدة في هذا الصدد.

نموذج التعليمات البرمجية أدناه (الفرق في السطر الأول من الاستعلام في النهاية (fk_source vs.فك _المصدر):

//Original
    OleDbCommand comm = new OleDbCommand("select min(ctc.serial_no) as MIN_INTERVAL from countstypecode ctc, source s, countstype ct, counts c where ct.value_id=c.value_id and s.c_id=ct.fk_source and " +
      "ct.timeinterval=ctc.typename and ct.timeinterval in ('15min','1h','1day') and c.time_stamp >=  CONVERT(datetime,'01-01-2008',105)  and c.time_stamp < " +
      "CONVERT(datetime,'01-01-2009',105)  and s.c_id = '27038dbb19ed93db011a315297df3b7a'", dbConn);

//Rebuilt
    OleDbCommand comm = new OleDbCommand("select min(ctc.serial_no) as MIN_INTERVAL from countstypecode ctc, source s, countstype ct, counts c where ct.value_id=c.value_id and s.c_id=ct.fk_Source and " +
      "ct.timeinterval=ctc.typename and ct.timeinterval in ('15min','1h','1day') and c.time_stamp >= CONVERT(datetime,'01-01-2008',105) and c.time_stamp < " +
      "CONVERT(datetime,'01-01-2009',105) and s.c_id='27038dbb19ed93db011a315297df3b7a'", dbConn);

Answer 1

أظن أن هذه مشكلة في ذاكرة التخزين المؤقت للإجراء.إحدى فوائد الإجراءات المخزنة هي أن الخطة مخزنة لك، مما يؤدي إلى تسريع الأمور.لسوء الحظ، من الممكن الحصول على خطة سيئة في ذاكرة التخزين المؤقت (حتى عند استخدام الاستعلامات الديناميكية).

من أجل المتعة فقط، قمت بفحص ذاكرة التخزين المؤقت للإجراءات الخاصة بي، وقمت بتشغيل استعلام مخصص، وفحصت مرة أخرى، ثم قمت بتشغيل نفس الاستعلام بأحرف كبيرة مختلفة وفوجئت برؤية عدد الإجراء أعلى.

جرب هذا....

الاتصال بـ SQL Server Management Studio.

DBCC MemoryStatus

Select Columns... From TABLES.... Where....

dbcc MemoryStatus

Select Columns... From tables.... Where....

dbcc MemoryStatus

أعتقد أنك ستجد أن TotalProcs يتغير عندما يتغير البيان (حتى عندما يكون التغيير الوحيد حساسًا لحالة الأحرف).

تحديث الإحصاءات الخاصة بك قد يساعد.هذه عملية تشغيل بطيئة إلى حد ما، لذا قد ترغب في تشغيلها خلال فترة بطيئة.

Answer 2

بما أنك تستخدم SQL Server 2005، هل حاولت استخدام كائن SqlCommand بدلاً من كائن OleDbCommand؟

Answer 3

لا أرى اختلافًا في استفساراتك مما قد يؤثر على الأداء - ماذا عن التخزين المؤقت أو تغيرات الفهرس/الإحصائيات بين عمليات التشغيل؟ربما تغيرت خطة التنفيذ بسبب الإحصائيات أو تغييرات الفهرس.

فيما يتعلق بالقضية:يمكن أن تكون الحالة مهمة إذا تم تعيين قاعدة البيانات لتكون حساسة لحالة الأحرف، ولكن لكي يتم تشغيل كلا الاستعلامين في قاعدة بيانات حساسة لحالة الأحرف، يجب أن تكون هناك أعمدة مسماة في كلا التنسيقين - سيلتزم محلل الاستعلام بالحالة - ولن يفعل ذلك يسبب اختلاف الأداء.

Answer 4

أولاً، هل أنت متأكد بنسبة 100% من أن الاستعلام هو الذي يسير بشكل خاطئ؟تحقق من ملف تعريف التتبع في خادم SQL لمعرفة المدة التي يستغرقها في قاعدة البيانات.

ثانيا، هل تحصل على نفس العدد من النتائج مرة أخرى.لا ينبغي أن تكون الكتابة بالأحرف الكبيرة مهمة بشكل افتراضي في خادم SQL، ولكن كان من الممكن إعدادها بشكل مختلف.

Answer 5

إذا كان لدي استعلام يستغرق "أكثر من 5 دقائق"، فلن أقلق بشأن الـ 100 مللي ثانية التي تستغرقها مطابقة حالة السلسلة.

Answer 6

شكرا لجميع إجاباتك، وسوف أرد على كل واحد على حدة:

1) روس، أوافق على أن SQLConnection سيكون أفضل، لكن لسوء الحظ لا يمكنني تحديد نوع الاتصال.لقد قمت للتو بإنشاء تطبيق صغير لاختبار هذا الاستعلام، ولكن يتم إنشاء الاستعلام ديناميكيًا في تطبيق أكبر بكثير.

2) gbjbaanb، أعتقد أنها ليست مشكلة في الخادم، لأنه يمكنني تشغيل كلا الاستعلامين من استوديو الإدارة في نفس الوقت تقريبًا، ويبدو أن هناك مشكلة فقط عند تشغيلها عبر oledb في .net (1.1 و2.0).لقد قمنا بتشغيل ملف التعريف عليه وأكد ملف التتبع أن الأمر استغرق أكثر من 5 دقائق لإكمال الاستعلام عند استدعائه بهذه الطريقة.

3) جويل كوهورن، متفق عليه، لكن ما أحاول الوصول إليه هنا هو "لماذا" لأننا في الوقت الحالي لا نعرف حجم هذه المشكلة وأين تكمن.

4) Cade Roux، الفرق قابل للتكرار للغاية، لذلك لا أعتقد أن هناك مشكلة تتعلق بتغييرات الفهرس أو التخزين المؤقت لأنني قمت بتشغيل الاختبارات مرة أخرى بنفس النتائج وأنها تستغرق نفس الوقت تقريبًا في SQL Server يجري.

Answer 7

شكرًا لـ G Mastros على الإجابة الأكثر اكتمالًا، على الرغم من أن Cade قد اقترح التحديث في الإحصائيات بأثر رجعي.ومع ذلك، كان حل G Mastos أكثر ملاءمة لمستوى خبرتي في SQL Server.

شكرا لمساعدة الجميع!

سأبحث في السبب الذي يجعل هذا الاختلاف الذي يبدو بريئًا له مثل هذه العواقب الكبيرة