it-swarm.asia

لماذا يكون استعلامي أبطأ فجأة مما كان عليه بالأمس؟

[تحيات]

(اختر واحد)

[ ] Well trained professional, [ ] Casual reader, [ ] Hapless wanderer,

لدي (ضع علامة على كل ما ينطبق)

[ ] query [ ] stored procedure [ ] database thing maybe  

التي كانت تعمل بشكل جيد (إن وجد)

[ ] yesterday [ ] in recent memory [ ] at some point 

لكنه أصبح أبطأ فجأة الآن.

لقد تحققت بالفعل للتأكد من عدم حظره ، وأنه ليس ضحية بعض مهام الصيانة أو التقارير أو عمليات أخرى خارج النطاق.

ما هي المشكلة ، وماذا أفعل ، وما هي المعلومات التي يمكنني تقديمها للحصول على بعض المساعدة؟

[*Insert appropriate closing remarks*]
77
Erik Darling

عزيزي [اسمك هنا]!

أوه لا ، أنا آسف لسماع ذلك! لنبدأ ببعض الأساسيات لإصلاحك في لمح البصر.

الشيء الذي تقابله يسمى Parameter Sniffing

إنها طريقة للخروج من مشكلة غريبة باروكة. الاسم يتدحرج من اللسان. مثل الكلمة الألمانية للسناجب.

وعادة ما يكون صديقك.

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

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

فمثلا:

  • الأشخاص الذين يرتدون قمصان كروس فيت غير المصابين: صفر

  • الأشخاص الذين يرتدون قمصان كروس فيت الذين يتجشمون عندما يفسدون: الكل

من الواضح أن تنفيذ هذا الكود يجب أن يقوم بعمل أكثر بكثير من تنفيذ آخر ، وخطط الاستعلام التي تريد القيام بها بكميات مختلفة تمامًا من العمل ستبدو مختلفة تمامًا.

ما أنا ضد؟

هذه مشكلة يصعب العثور عليها واختبارها وإصلاحها.

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

اصلاح سريع

في بعض الأحيان ، كل ما تحتاجه هو القليل من الوضوح. أو بالأحرى ، ذاكرة التخزين المؤقت لخطتك.

إذا كان إجراء مخزن

حاول الجري EXEC sys.sp_recompile @objname = N'schema.procname'. سيؤدي هذا الإجراء إلى إعادة تجميع خطة جديدة في المرة التالية التي يتم تشغيلها.

ما لن يصلحه هذا:

  • العمليات قيد التشغيل حاليًا.

ما لا يضمنه هذا:

  • ستستخدم العملية التالية التي يتم تشغيلها بعد إعادة التحويل البرمجي معلمة تمنحك خطة جيدة.

يمكنك أيضًا الإشارة إلى sp_recompile على طاولة أو عرض ، ولكن يجب تحذيرك من أن جميع التعليمات البرمجية التي تمس ذلك الجدول أو طريقة العرض سيتم إعادة تجميعها. وهذا يمكن أن يجعل المشكلة أصعب بكثير.

إذا كان استعلامًا ذا معلمات

عملك أكثر صعوبة. ستحتاج إلى تعقب مقبض SQL. لا تريد تحرير ذاكرة التخزين المؤقت للخطة بالكامل - تمامًا مثل استخدام sp_recompile مقابل جدول أو عرض ، يمكنك تشغيل (ها ها ها) مجموعة كاملة من العواقب غير المقصودة.

أسهل طريقة لمعرفة هذا الأمر هي تشغيل sp_BlitzWho *! هناك عمود يسمى "تحديد معلمة الإصلاح" يحتوي على أمر لإزالة خطة واحدة من ذاكرة التخزين المؤقت. هذا له نفس العوائق التي تعيد تجميعها ، على الرغم من ذلك.

ما لن يصلحه هذا:

  • العمليات قيد التشغيل حاليًا.

ما لا يضمنه هذا:

  • ستستخدم العملية التالية التي يتم تشغيلها بعد إعادة التحويل البرمجي معلمة تمنحك خطة جيدة.

ما زلت بحاجة إلى المساعدة!

سنحتاج إلى الأشياء التالية:

  • خطة الاستعلام الجيدة ، إن أمكن
  • خطة الاستعلام السيئة
  • المعلمات المستخدمة
  • الاستعلام المعني
  • تعريفات الجدول والفهرس

الحصول على خطط الاستعلام والاستعلام

إذا كان الاستعلام قيد التشغيل ، فيمكنك استخدام sp_BlitzWho * أو sp_WhoIsActive لالتقاط الاستعلامات المنفذة حاليًا.

EXEC sp_BlitzWho;

EXEC sp_WhoIsActive @get_plans = 1;

NUTS

إذا لم يكن الاستعلام قيد التنفيذ حاليًا ، فيمكنك التحقق منه في ذاكرة التخزين المؤقت للخطة ، باستخدام sp_BlitzCache *.

إذا كنت تستخدم SQL Server 2016+ وقمت بتشغيل Query Store ، فيمكنك استخدام sp_BlitzQueryStore *.

EXEC dbo.sp_BlitzCache @StoredProcName = 'Your Mom';

EXEC dbo.sp_BlitzQueryStore @StoredProcName = 'Your Mom';

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

EXEC dbo.sp_BlitzCache @QueryFilter = 'statement';

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

NUTS

أسهل طريقة لمشاركة الخطط هي استخدام Paste The Plan * ، أو تفريغ XML في Pastebin. للحصول على ذلك ، انقر فوق أحد الأعمدة الداعية للنقر الأزرق. يجب أن تظهر خطة الاستعلام الخاصة بك في علامة تبويب SSMS جديدة.

NUTS

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

كل هذه الأدوات التي تحدثنا عنها يجب أن تُرجع نص الاستعلام. لا تحتاج إلى القيام بأي شيء آخر هنا.

الحصول على المعلمة (المعلمات) أكثر صعوبة. إذا كنت تستخدم Plan Explorer ، فهناك علامة تبويب في الأسفل تسردها جميعًا لك.

NUTS

إذا كنت تستخدم sp_BlitzCache * ، فهناك عمود قابل للنقر يمنحك بيان التنفيذ للإجراءات المخزنة.

NUTS

الحصول على تعريفات الجدول والفهرس

يمكنك بسهولة النقر بزر الماوس الأيمن في SSMS لبرمجة الأشياء.

NUTS

إذا كنت ترغب في الحصول على كل شيء في لقطة واحدة ، فيمكن sp_BlitzIndex * مساعدتك إذا أشرت إليه مباشرةً على طاولة.

EXEC dbo.sp_BlitzIndex @DatabaseName = 'StackOverflow2010',
                       @SchemaName = 'dbo',
                       @TableName = 'Users';

سيعطيك هذا تعريف الجدول (وإن لم يكن بمثابة عبارة إنشاء) ، وإنشاء عبارات لجميع الفهارس الخاصة بك.

يجب أن يؤدي جمع هذه المعلومات وإضافتها إلى سؤالك إلى الحصول على معلومات كافية من الأشخاص للمساعدة ، أو توجيهك في الاتجاه الصحيح.

أريد أن أفعل ذلك بنفسي!

حسنًا ، رائع. انا سعيد لأجلك. أنت شخص مجنون.

هناك الكثير من الطرق التي يعتقد الناس أنها تعمل على "إصلاح" التعرف على معلمة:

ولكن هذه بالفعل تعطل استنشاق المعلمات بطرق مختلفة. هذا لا يعني أنهم لا يستطيعون حل المشكلة ، فهم لا يصلون بالفعل إلى السبب الجذري.

ذلك لأن الوصول إلى السبب الجذري عادة ما يكون نوعًا من الصعوبة. عليك أن تبحث عن تلك "مشاكل جودة الخطة" المزعجة.

بدءًا من الخطط السريعة مقابل البطيئة ، ابحث عن الاختلافات مثل:

  • الفهارس المستخدمة
  • انضمام النظام
  • المسلسل مقابل الموازي

ابحث أيضًا عن عوامل تشغيل مختلفة تجعل شفرتك حساسة تجاه التعرف على المعلمات:

  • عمليات البحث
  • أنواع
  • نوع الانضمام
  • منح الذاكرة (وبالامتداد ، الانسكابات)
  • مكبات

لا تنغمس كثيرًا في البحث عن المسح الضوئي أو تجزئة الفهرس أو أي من الأشياء التي يقوم الناس بتقليدها والتخلص منها.

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

إذا كنت تريد معرفة المزيد عن استنشاق المعلمات:

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


89
Erik Darling

لا يعتبر استنشاق المعلمات السبب الوحيد المحتمل لأداء الاستعلام المتغير. قد تظهر أي من الأسباب الشائعة التالية نفس الأعراض:

  1. تم تغيير توزيع/حجم البيانات ، مع تجاوز نقطة تحول في قرار شجرة بحث محسن
  2. تم تجزئة الفهارس/الملفات
  3. تم تحديث/إضافة/إسقاط الإحصاءات أو أصبحت قديمة ومضللة بسبب تغييرات البيانات
  4. تغير استخدام ذاكرة Windows
  5. سجلات المعاملات ممتلئة وليست مبتورة ، مما يتسبب في توسيع الملف الفعلي المتكرر
  6. تم تغيير المخطط - تمت إضافة عرض/عمود/قيد مقيد/مفهرس ، تم تعديله أو إسقاطه ، تغير نوع البيانات ، إلخ.
  7. تم تغيير إعدادات إشارة التتبع
  8. تم تطبيق تحديث Windows
  9. تم تغيير إعداد قاعدة البيانات أو الخادم
  10. تم تغيير مستوى وحدة خدمة الخادم
  11. تم تغيير إعدادات جلسة تطبيق العميل

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

27
SQLRaptor

فقط للإضافة إلى الإجابات الموجودة في حال لم تساعد ، عندما تتصرف استفساراتك "فجأة" بشكل مختلف في اليوم التالي ، تحقق:

  • هل تغير مخطط الجداول المستخدمة منذ آخر مرة؟ في حالة SSMS ، يمكنك النقر بزر الماوس الأيمن على الخادم في Object Explorer واختيار Reports → Standard Reports → Schema Changes History.
  • هل زاد عدد العناصر بشكل كبير؟ ربما يكون استعلامك أبطأ بكثير عندما يكون هناك الكثير من البيانات في الجداول المستخدمة.
  • هل هناك شخص آخر يستخدم قاعدة البيانات في نفس الوقت الذي تستخدمه؟ ربما اختر فترات زمنية لا تتدخل فيها في عمل بعضكما البعض.
  • كيف تبدو إحصاءات النظام؟ ربما الخادم يعمل بسرعة ويختنق وحدة المعالجة المركزية أو محركات الأقراص الصلبة تنفد من المساحة أو المبادلة. ربما هناك مشكلة أخرى في الأجهزة مثل حريق أو فيضان في غرفة الخادم.
9
user1306322

الاحتمال الآخر هو أن فريق البنية التحتية الخاص بك يستخدم أدوات مثل vMotion على VMware و VM الذي يتم نقله إلى مثيل SQL الخاص بك بسلاسة من Host إلى Host دون علم DBA بذلك.

هذه مشكلة حقيقية عندما تكون البنية التحتية الخاصة بك من مصادر خارجية ... لدي كابوس حقيقي معها.

7
pacreely