ما هو "مع (nolock)" في SQL Server؟

https://stackoverflow.com/questions/686724

22-08-2019
|

سؤال

يمكن للشخص أن يشرح الآثار المترتبة على استخدام with (nolock) في الاستعلامات، متى يجب/لا ينبغي عليك استخدامه؟

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

المحلول

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

نصائح أخرى

السؤال هو ما هو الأسوأ:

طريق مسدود، أو
قيمة خاطئة؟

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

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

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

ومع ذلك، قام SQL Server 2005 بإصلاح معظم الأخطاء التي حدثت NOLOCK ضروري.لذا، إلا إذا كنت تستخدم SQL Server 2000 أو إصدار سابق، فلن تحتاج إليه.

قراءة متعمقة
الإصدار على مستوى الصف

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

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

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

الدفع مقال إيتسيك بن غان.وهنا مقتطف:

"مع تلميح Nolock (أو تعيين مستوى العزل في الجلسة لقراءة غير ملتزم) ، تخبر SQL Server أنك لا تتوقع الاتساق ، لذلك لا توجد ضمانات.ضع في اعتبارك أن "البيانات غير المتسقة" لا تعني فقط أنك قد ترى تغييرات غير ملتزم بها تم ترحيلها لاحقًا ، أو تغييرات البيانات في حالة وسيطة للمعاملة. وهذا يعني أيضًا أنه في استعلام بسيط يقوم بمسح جميع خادم SQL Table/Index قد يفقد موضع المسح ، أو قد ينتهي بك الأمر إلى الحصول على نفس الصف مرتين. "

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

إذا كنت تواجه مشاكل في تأمين وتنفيذ الإصدارات وتنظيف التعليمات البرمجية.

لا قفل ليس فقط بإرجاع قيم خاطئة فإنها ترجع السجلات الوهمية والتكرارات.

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

في الإنصاف، وهنا اثنين من السيناريوهات الخاصة التي قد توفر تلميحا NOLOCK فائدة

1) قاعدة بيانات SQL Server ما قبل عام 2005 التي تحتاج إلى تشغيل الاستعلام طويلة ضد قاعدة بيانات OLTP الحية وهذا قد يكون السبيل الوحيد

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

وNOLOCK ما يعادل READ UNCOMMITTED، ولكن تقول مايكروسوفت يجب عدم استخدامها للبيانات UPDATE أو DELETE:

<اقتباس فقرة>

لتحديث أو حذف البيانات: سيتم إزالة هذه الميزة في إصدار مستقبلي من Microsoft SQL Server. تجنب استخدام هذه الميزة في عمل جديد للتنمية، وخطة لتعديل التطبيقات التي تستخدم حاليا هذه الميزة.

http://msdn.microsoft.com/en-us/library/ ms187373.aspx

وتنطبق هذه المادة إلى SQL Server 2005، وبالتالي فإن دعم NOLOCK موجود إذا كنت تستخدم هذا الإصدار. من أجل قانون مستقبل برهان لك (على افتراض كنت قد قررت استخدام القذرة يقرأ) هل يمكن استخدام هذا في الإجراءات المخزنة:

وSET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

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

ويمكن أن يكون أسرع في عملية القراءة، ولكن لا أستطيع أن أقول حقا كم.

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

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

في الحالة العامة: يمكن استخدامه عندما كنت جدا متأكد من أنه لا بأس أن يقرأ البيانات القديمة. الشيء المهم هو أن نتذكر أن لها <م> من السهل جدا للحصول على هذا الخطأ . على سبيل المثال، حتى لو كان على ما يرام في الوقت الذي كتابة الاستعلام، هل أنت متأكد من شيء لن يتغير في قاعدة البيانات في المستقبل لجعل هذه التحديثات أكثر أهمية؟

وأنا أيضا 2 فكرة أنه ربما <م> لا فكرة جيدة في التطبيق المصرفي. أو التطبيق المخزون. أو في أي مكان كنت تفكر في المعاملات.

والجواب بسيط - كلما SQL الخاص بك لا يغير البيانات، وكان لديك استعلام التي قد تتداخل مع نشاط آخر (عبر تأمين)

وانها تستحق النظر عن أي استفسارات المستخدمة في التقارير، خصوصا إذا كان الاستعلام يأخذ أكثر من، مثلا، 1 ثانية.

وانها مفيدة وخاصة إذا كان لديك تقارير OLAP من نوع كنت تقوم بتشغيل مقابل قاعدة بيانات OLTP.

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

وبلدي 2 سنت - فمن المنطقي لاستخدام WITH (NOLOCK) عند الحاجة إلى توليد التقارير. عند هذه النقطة، فإن البيانات لا يتغير كثيرا وكنت لا تريد لقفل هذه السجلات.

إذا كنت التعامل مع المعاملات المالية فإنك لن ترغب في استخدام nolock. يتم استخدام أفضل nolock لتحديد من جداول كبيرة التي لديها الكثير من التحديثات وكنت لا تهتم إذا كان السجل تحصل يمكن ان يكون قديما.

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

ولقد استعملت لاسترداد "الدفعة التالية" للأشياء للقيام بها. لا يهم في هذه الحالة التي البند المحدد، ولدي الكثير من المستخدمين تشغيل هذا الاستعلام نفسه.

اجابة قصيرة:

لم أستعمل أبدا WITH (NOLOCK).

اجابة طويلة:

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

يمكن أن تحتوي مجموعة النتائج على صفوف لم يتم الالتزام بها بعد، والتي غالبًا ما يتم التراجع عنها لاحقًا.

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

وذلك لأن المعاملات الأخرى تقوم بنقل البيانات في نفس الوقت الذي تقرأه فيه.

تضيف ميزة READ COMMITTED مشكلة إضافية تتمثل في تلف البيانات داخل عمود واحد حيث يقوم عدة مستخدمين بتغيير نفس الخلية في وقت واحد.

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

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

لا تستخدم أبدًا NOLOCK أبدًا.

(أبدًا)

استخدم NOLOCK عندما كنت على ما يرام مع البيانات "القذرة". وهو ما يعني NOLOCK يمكن أيضا قراءة البيانات التي هي في طور تعديل و / أو البيانات غير ملتزم بها.

وانها عموما ليست فكرة جيدة لاستخدامها في بيئة معاملة عالية وهذا هو السبب في أنها ليست الخيار الافتراضي في الاستعلام.

وأنا استخدم مع (NOLOCK) تلميح ولا سيما في سيكلسرفير قواعد البيانات 2000 مع ارتفاع النشاط. أنا لست على يقين من أن هناك حاجة في SQL Server 2005 ولكن. أنا في الآونة الأخيرة وأضاف أن تلميح في SQL خادم 2000 بناء على طلب من DBA العميل، لأنه كان يلاحظ الكثير من الأقفال سجل SPID.

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

وبالمناسبة، قواعد البيانات أتعامل مع تعود ينتهي إلى الشركة أنظمة المطالبات الطبية، لذلك نحن نتحدث عن ملايين من السجلات والجداول 20+ في كثير صلات. أنا عادة إضافة مع (NOLOCK) تلميح لكل جدول في الانضمام (إلا اذا كان جدول مشتقة، وفي هذه الحالة لا يمكنك استخدام هذا تلميح خاص)

وأبسط الجواب هو سؤال بسيط - لا تحتاج النتائج إلى أن تكرار؟ إذا كانت الإجابة بنعم ثم NOLOCKS ليس مناسبا تحت أي ظرف من الظروف

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

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow