تشخيص حالات توقف تام في SQL Server 2005

Question

نحن نرى الخبيث ، ولكن نادر الجمود الأوضاع في تجاوز سعة مكدس قاعدة بيانات SQL Server 2005.

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

UPDATE [dbo].[Posts]
SET [AnswerCount] = @p1, [LastActivityDate] = @p2, [LastActivityUserId] = @p3
WHERE [Id] = @p0

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

SELECT
[t0].[Id], [t0].[PostTypeId], [t0].[Score], [t0].[Views], [t0].[AnswerCount], 
[t0].[AcceptedAnswerId], [t0].[IsLocked], [t0].[IsLockedEdit], [t0].[ParentId], 
[t0].[CurrentRevisionId], [t0].[FirstRevisionId], [t0].[LockedReason],
[t0].[LastActivityDate], [t0].[LastActivityUserId]
FROM [dbo].[Posts] AS [t0]
WHERE [t0].[ParentId] = @p0

أن تكون واضحة تماما, نحن لا نرى يكتب / تكتب المآزق ، ولكن القراءة / الكتابة.

لدينا خليط من LINQ و معلمات استعلامات SQL في هذه اللحظة.واضاف لدينا with (nolock) إلى جميع استعلامات SQL.وقد ساعدت بعض.كان لدينا أيضا واحدة (جدا) سيئة مكتوبة شارة استعلام أنا ثابت أمس ، الذي كان يأخذ ما يزيد عن 20 ثانية لتشغيل كل مرة ، كان يركض في كل دقيقة على أعلى من ذلك.كنت أتمنى هذا كان مصدر بعض مشكلات تأمين!

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

حقا شيء غريب هو أن تأمين كتابة SQL تراه أعلاه هو جزء من كود معين المسار.انها فقط أعدم عندما إجابة جديدة تضاف إلى السؤال-فإنه التحديثات الوالد السؤال مع الإجابة على عدد آخر موعد/المستخدم.هذا هو, بوضوح, لا أن القاسم المشترك بالنسبة إلى عدد هائل من يقرأ نقوم به!بقدر ما أستطيع أن أقول, نحن لا نفعل أعداد هائلة من يكتب في أي مكان في التطبيق.

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

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

نحن يمزح مع فكرة استخدام

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

على قاعدة سياق قاعدة البيانات التي استعلامات LINQ هذه المجموعة.دون أن علينا التفاف كل LINQ دعوة نجعل (حسنا, بسيطة القراءة منها ، وهي الغالبية العظمى منهم) في 3-4 خط الصفقة كتلة التعليمات البرمجية الذي هو قبيح.

أعتقد أنا محبط قليلا أن تافهة يقرأ في SQL server 2005 يمكن أن الجمود على يكتب.كنت أرى يكتب/تكتب المآزق كونها مشكلة كبيرة ، ولكن يقرأ ؟ نحن لا يعمل المصرفية الموقع هنا لا نحتاج إلى دقة مثالية في كل مرة.

أفكار ؟ الأفكار ؟

---

هل إنشاء مثيل جديد LINQ to SQL DataContext وجوه كل عملية أو ربما أنت تقاسم نفس ثابت السياق لجميع المكالمات الخاصة بك ؟

جيرمي, نحن تقاسم ثابت واحد datacontext في قاعدة تحكم معظمها:

private DBContext _db;
/// <summary>
/// Gets the DataContext to be used by a Request's controllers.
/// </summary>
public DBContext DB
{
    get
    {
        if (_db == null)
        {
            _db = new DBContext() { SessionName = GetType().Name };
            //_db.ExecuteCommand("SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED");
        }
        return _db;
    }
}

هل توصي نحن خلق سياق جديد لكل وحدة تحكم أو في الصفحة ، أو ..في كثير من الأحيان ؟

Answer 1

وفقا MSDN:

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

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

قصيرة-تشغيل المعاملات ، النسخة من تعديل الصف قد تحصل على مؤقتا في تجمع المخزن المؤقت دون الحصول على كتب في ملفات القرص قاعدة بيانات tempdp.إذا الحاجة تعيين إصدار الصف قصيرة الأجل ، ببساطة سوف تحصل انخفض من تجمع المخزن المؤقت و قد لا بالضرورة تكبد I/O النفقات العامة.

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

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

ALTER Database [StackOverflow.Beta] SET READ_COMMITTED_SNAPSHOT ON

Answer 2

NOLOCK و القراءة غير ملتزم بها هي منحدر زلق.يجب أن لا تستخدمها إلا إذا كنت أفهم لماذا الجمود يحدث أولا.سوف تقلق لي أن أقول لكم, "واضاف لدينا مع (nolock) إلى جميع استعلامات SQL".تحتاج إلى إضافة مع NOLOCK في كل مكان هو علامة على يقين من أن لديك مشاكل في طبقة البيانات.

التحديث البيان نفسه تبدو إشكالية قليلا.هل تحديد عد في وقت سابق من المعاملات ، أو مجرد سحب من كائن ؟ AnswerCount = AnswerCount+1 عند سؤال يضاف هو على الارجح أفضل طريقة للتعامل مع هذا.ثم أنت لا تحتاج إلى معاملة للحصول على العد الصحيح و كنت لا داعي للقلق حول التزامن المشكلة التي يحتمل أن تعريض نفسك.

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

Answer 3

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

وربما هذا هو فهرس ذات الصلة.على سبيل المثال, دعونا نقول المشاركات الجدول يحتوي على فهرس غير متفاوت X الذي يحتوي على ParentID واحد (أو أكثر) من الميدان(s) تحديث (AnswerCount, LastActivityDate, LastActivityUserId).

حالة توقف تام قد تحدث إذا حدد cmd هل مشتركة-قراءة قفل على مؤشر X إلى البحث عن طريق ParentId ثم يحتاج إلى القيام مشترك-قراءة قفل على فهرس متفاوت المسافات للحصول على ما تبقى من أعمدة بينما التحديث cmd هل الكتابة الحصري قفل على فهرس متفاوت المسافات تحتاج إلى الحصول على كتابة حصرية قفل على مؤشر X لتحديثه.

لديك الآن الحالة التي يكون فيها مؤمن X و هو يحاول Y بينما ب مقفلة Y و هو يحاول الحصول على X.

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

Answer 4

أنا غير مريحة جدا حول هذا السؤال وما يصاحب ذلك من الأجوبة.هناك الكثير من "جرب هذا الغبار السحري!لا أن السحر الغبار!"

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

كل ما كنت قد أشارت إلى أن بعض الأقفال تحدث-لا ما هو أصاب بالجمود.

في SQL server 2005 يمكنك الحصول على مزيد من المعلومات حول ما الأقفال التي يجري اتخاذها من قبل باستخدام:

DBCC TRACEON (1222, -1)

بحيث عند حدوث حالة توقف تام يجب تشخيص أفضل.

Answer 5

هل إنشاء مثيل جديد LINQ to SQL DataContext وجوه كل عملية أو ربما أنت تقاسم نفس ثابت السياق لجميع المكالمات الخاصة بك ؟ أنا أصلا حاولت النهج الأخير ، و من ما أتذكر تسببت غير المرغوب فيها تأمين في ديسيبل.أنا الآن في خلق سياق جديد لكل عملية الذرية.

Answer 6

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

تذكر أن المأزق يتطلب (على الأقل) 2 الأقفال.اتصال 1 قفل يريد قفل ب - والعكس بالعكس بالنسبة اتصال 2.هذا غير قابلة للحل الحالة ، يجب أن يقدم أحدهم.

ما أظهرته حتى الآن هو حل بسيط تأمين Sql Server سعيد أن تفعل طوال اليوم.

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

أتوقع أن هناك على الأقل 4 بيانات إكمال هذا اللغز (أو بيان أن يأخذ أقفال متعددة - ربما هناك الزناد عن المشاركات الجدول؟).

Answer 7

سوف تهتم إذا كان ملف تعريف المستخدم الخاص بك هو بضع ثوان من التاريخ ؟

لا - هذا مقبول تماما.إعداد قاعدة مستوى عزل المعاملة هو على الارجح أفضل/أنظف وسيلة للذهاب.

Answer 8

نموذجية قراءة/كتابة المأزق يأتي من مؤشر أجل الوصول.قراءة (T1) يحدد الصف على المؤشر ومن ثم يبحث المتوقع عمود على مؤشر ب (عادة متفاوت المسافات).كتابة (T2) التغييرات مؤشر ب (المجموعة) ثم تحديث مؤشر A.T1 S-Lck على, يريد S-Lck على ب ، T2 X-Lck على ب ، يريد U-Lck على A.الجمود ، نفخة.T1 هو قتل.هذا هو السائد في البيئات الثقيلة OLTP المرور و مجرد صبي الكثير من الفهارس :).الحل هو جعل إما قراءة يكن لديك للقفز من ألف إلى باء (ie.إدراج عمود في أو إزالة العمود من المتوقع قائمة) أو T2 يكن لديك للقفز من B إلى A (لا تحديث عمود مفهرس).للأسف, linq ليس صديقك هنا...

Answer 9

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

أنا فقط استخدام العالمية ثابت مساعد مثل هذا:

public static class AppData
{
    /// <summary>
    /// Gets a new database context
    /// </summary>
    public static CoreDataContext DB
    {
        get
        {
            var dataContext = new CoreDataContext
            {
                DeferredLoadingEnabled = true
            };
            return dataContext;
        }
    }
}

ثم أفعل شيئا من هذا القبيل:

var db = AppData.DB;

var results = from p in db.Posts where p.ID = id select p;

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

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

تحكم تعيش إلا طلب واحد - حتى في نهاية تجهيز الطلب يتم تجميع البيانات المهملة (وهو ما يعني DataContext يتم جمعها)...

على أي حال, هذا قد لا يكون ذلك ، ولكن مرة أخرى أنها ربما يستحق المحاولة ، وربما بالتزامن مع بعض اختبار الحمل.

Answer 10

س.لماذا تخزين AnswerCount في Posts الجدول في المقام الأول ؟

نهج بديل هو القضاء على "الكتابة مرة أخرى" إلى Posts الجدول من خلال عدم تخزين AnswerCount في الجدول ولكن بشكل حيوي حساب عدد الإجابات على البريد كما هو مطلوب.

نعم, هذا يعني أنك تشغيل إضافية الاستعلام:

SELECT COUNT(*) FROM Answers WHERE post_id = @id

أو أكثر عادة (إذا كنت عرض هذا على الصفحة الرئيسية):

SELECT p.post_id, 
     p.<additional post fields>,
     a.AnswerCount
FROM Posts p
    INNER JOIN AnswersCount_view a
    ON <join criteria>
WHERE <home page criteria>

ولكن هذا عادة النتائج في INDEX SCAN و قد تكون أكثر كفاءة في استخدام الموارد من استخدام READ ISOLATION.

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

Answer 11

تريد بالتأكيد READ_COMMITTED_SNAPSHOT ، والتي ليست بشكل افتراضي.يعطيك MVCC دلالات.انها نفس الشيء أوراكل يستخدم بشكل افتراضي.وجود MVCC قاعدة البيانات هو مفيدة بشكل لا يصدق, لا تستخدم واحد هو مجنون.هذا يسمح لك بتشغيل التالية داخل الصفقة:

التحديث للمستخدمين تعيين FirstName = 'س';//تقرر أن النوم لمدة عام.

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

Answer 12

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

هنا هو ما يجب عليك القيام به:استخدام المحاولة-catch (في T-SQL) إلى الكشف عن حالة توقف تام.عندما يحدث فقط إعادة تشغيل الاستعلام.هذا هو المعيار برمجة قواعد البيانات الممارسة.

هناك أمثلة جيدة من هذه التقنية في بول نيلسون Sql Server 2005 المقدس.

هنا هو قالب السريع التي تستخدم:

-- Deadlock retry template

declare @lastError int;
declare @numErrors int;

set @numErrors = 0;

LockTimeoutRetry:

begin try;

-- The query goes here

return; -- this is the normal end of the procedure

end try begin catch
    set @lastError=@@error
    if @lastError = 1222 or @lastError = 1205 -- Lock timeout or deadlock
    begin;
        if @numErrors >= 3 -- We hit the retry limit
        begin;
            raiserror('Could not get a lock after 3 attempts', 16, 1);
            return -100;
        end;

        -- Wait and then try the transaction again
        waitfor delay '00:00:00.25';
        set @numErrors = @numErrors + 1;
        goto LockTimeoutRetry;

    end;

    -- Some other error occurred
    declare @errorMessage nvarchar(4000), @errorSeverity int
    select    @errorMessage = error_message(),
            @errorSeverity = error_severity()

    raiserror(@errorMessage, @errorSeverity, 1)

    return -100
end catch;    

Answer 13

شيء واحد التي عملت بالنسبة لي في الماضي هو التأكد من كافة الاستعلامات والتحديثات الوصول إلى الموارد (الجداول) في نفس الترتيب.

فإذا أحد الاستعلام التحديثات في جدول1, Table2 مختلفة الاستعلام التحديثات في ترتيب Table2, جدول1 ثم قد ترى المآزق.

ليس متأكدا مما إذا كان من الممكن بالنسبة لك لتغيير النظام من التحديثات منذ كنت باستخدام LINQ.ولكن هذا شيء أن ننظر إلى.

Answer 14

سوف تهتم إذا كان ملف تعريف المستخدم الخاص بك هو بضع ثوان من التاريخ ؟

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

Answer 15

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

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

بمجرد لقد غيرت بلدي استراتيجية لاستخدام البيانات المختلفة السياق في LINQ مستوى في الاستعلام على ثقة من أن SQL server يمكن عمل اتصال تجميع السحر, أقفال يبدو أن تختفي.

بالطبع كنت تحت ضغط الوقت ، لذلك يحاول عدد من الأشياء في جميع أنحاء نفس الوقت, لذلك أنا لا يمكن أن تكون 100 ٪ على يقين من أن ما هو ثابت ، ولكن لدي مستوى عال من الثقة دعونا نضع الامر بهذه الطريقة.

Answer 16

يجب تنفيذ القذرة يقرأ.

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

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

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

نحن لا يعمل المصرفية الموقع هنا لا نحتاج إلى دقة مثالية في كل مرة

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

دون أن علينا التفاف كل LINQ دعوة نجعل (حسنا, بسيطة القراءة منها ، وهي الغالبية العظمى منهم) في 3-4 خط الصفقة كتلة التعليمات البرمجية الذي هو قبيح

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

Answer 17

فما هي المشكلة مع تنفيذ المحاولة الآلية ؟ سوف يكون هناك دائما إمكانية الجمود ocurring لذلك لماذا لا يكون بعض المنطق للتعرف عليه فقط حاول مرة أخرى ؟

لن الأقل بعض من الخيارات الأخرى تقديم الأداء العقوبات التي تتخذ في كل مرة عند إعادة المحاولة النظام سوف ركلة نادرا ما?

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

Answer 18

الآن أرى جيريمي الجواب أعتقد أنني سمعت هذا أفضل الممارسات لاستخدام جديد DataContext لكل البيانات العملية.روب Conery كتب العديد من المشاركات حول DataContext و كان دائما الأخبار لهم بدلا من استخدام المفرد.

• http://blog.wekeroad.com/2007/08/17/linqtosql-ranch-dressing-for-your-database-pizza/
• http://blog.wekeroad.com/mvc-storefront/mvcstore-part-9/ (انظر التعليقات)

هنا هو نمط كنا الفيديو.عرض (رابط "عرض المصدر" في CodePlex):

using System.Configuration;
namespace VideoShow.Data
{
  public class DataContextFactory
  {
    public static VideoShowDataContext DataContext()
    {
        return new VideoShowDataContext(ConfigurationManager.ConnectionStrings["VideoShowConnectionString"].ConnectionString);
    }
    public static VideoShowDataContext DataContext(string connectionString)
    {
        return new VideoShowDataContext(connectionString);
    }
  }
}

ثم في مستوى الخدمة (أو حتى أكثر دقة ، على التحديثات):

private VideoShowDataContext dataContext = DataContextFactory.DataContext();

public VideoSearchResult GetVideos(int pageSize, int pageNumber, string sortType)
{
  var videos =
  from video in DataContext.Videos
  where video.StatusId == (int)VideoServices.VideoStatus.Complete
  orderby video.DatePublished descending
  select video;
  return GetSearchResult(videos, pageSize, pageNumber);
}

Answer 19

وأود أن نتفق مع جريج طالما تعيين مستوى عزل القراءة غير ملتزم بها لا يكون لها أي آثار سيئة على استفسارات أخرى.

سأكون مهتما لمعرفة, جيف, كيف يحدد ذلك على مستوى قاعدة البيانات سوف تؤثر على الاستعلام كما يلي:

Begin Tran
Insert into Table (Columns) Values (Values)
Select Max(ID) From Table
Commit Tran

Answer 20

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

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

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

Answer 21

وأود أن الاستمرار في ضبط كل شيء ؛ كيف هو النظام الفرعي القرص في الأداء ؟ ما هو متوسط طول قائمة انتظار القرص?إذا I/O هي النسخ الاحتياطي, المشكلة الحقيقية قد لا تكون هذه اثنين من الاستفسارات التي أصاب بالجمود ، قد يكون آخر استعلام الاختناقات النظام ؛ ذكرت استعلام أخذ 20 ثانية التي تم ضبطها ، هل هناك غيرها ؟

التركيز على تقصير استعلامات التشغيل الطويل ، أراهن الجمود المشاكل سوف تختفي.

Answer 22

كان لدي نفس المشكلة و لا يمكن استخدام "IsolationLevel = IsolationLevel.ReadUncommitted" على TransactionScope لأن الخادم لا يكون DTS تمكين (!).

هذا ما فعلته مع امتداد الطريقة:

public static void SetNoLock(this MyDataContext myDS)
{
    myDS.ExecuteCommand("SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED");
}

لذلك ، يختار من استخدام الحرجة التزامن الجداول ، ونحن تمكين "nolock" مثل هذا:

using (MyDataContext myDS = new MyDataContext())
{
   myDS.SetNoLock();

   //  var query = from ...my dirty querys here...
}

Sugestions هي موضع ترحيب!