في سيناريو مستودع البيانات هناك أي عيب لاستخدامه مع (Nolock)

Question

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

انا افهم ال WITH(NOLOCK) يمكن أن تسبب قراءة البيانات غير الملتزم ، ومع ذلك ، لا أرغب أيضًا في إنشاء أي أقفال من شأنها أن تتسبب في فشل عمليات ETL أو حظرها.

في جميع الحالات ، عندما نقرأ من DW ، نقرأ من جداول الحقائق لتاريخ لن يتغير (يتم تقسيم جداول الحقائق حسب التاريخ) وجداول الأبعاد التي لن تتغير سمات للوقائع التي ترتبط بها .

إذن - هل هناك أي عيوب؟ - ربما في خطط التنفيذ أو في تشغيل هذا SELECT-الاستعلامات فقط تعمل بالتوازي قبالة الجداول نفسها.

Answer 1

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

Answer 2

هذا ما تحتاجه على الأرجح:

`alter database AdventureWorks set read_committ_snapshot on ؛

تغيير Database AdventureWorks تعيين left_snapshot_isolation على ؛ `

ثم المضي قدما والاستخدام

SET TRANSACTION ISOLATION LEVEL READ COMMITTED

في استفساراتك. حسب بول:

يعتمد سلوك القراءة الملتزم على إعداد خيار قاعدة بيانات read_committ_snapshot:

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

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

نأمل أن تكون هذه المساعدة. راج

Answer 3

هل فكرت في إنشاء ملف لقطة قاعدة البيانات من DW الخاص بك وتشغيل تقاريرك قبالة ذلك؟

Answer 4

نعم. سيكون SQL الخاص بك أقل قابلية للقراءة. سوف تفوت حتما بعض تلميحات nolock لأن SQL Select Ordersing باستخدام استراتيجية Nolock يجب أن تضعها في كل مكان.

يمكنك الحصول على نفس الشيء عن طريق ضبط مستوى العزلة

تعيين مستوى عزل المعاملة قراءة غير ملتزم

في النهاية ، تحصل على زيادة في الأداء بنسبة 10 ٪ (آسف ، أنا كسول جدًا ، أبحث عن المقال مقابل ذلك ، لكنه موجود هناك)

أود أن أقول إن الربح بنسبة 10 ٪ لا يستحق تقليل قابلية القراءة.

Answer 5

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

ALTER DATABASE adventureworks SET read_only

Answer 6

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