بشكل افتراضي، تتضمن حزمة الخدمة 1 ل SQL Server 2014 وحزمة الخدمة 3 ل SQL Server 2012 هذا الإصلاح، ولا تحتاج إلى إضافة أي علامات تتبع لتمكين الإصلاح. لتمكين الإصلاح بعد تثبيت أحد التحديثات التراكمية في قسم الحل، يجب بدء تشغيل Microsoft SQL Server بإضافة علامة التتبع 1236 إلى معلمات بدء التشغيل.
الأعراض
لنفترض أنك قمت بتشغيل مثيل Microsoft SQL Server 2014 أو SQL Server 2012 أو SQL Server 2008 أو SQL Server 2008 R2 على كمبيوتر يحتوي على العديد من المعالجات. عندما يتجاوز عدد عمليات التأمين (نوع المورد = DATABASE) لقاعدة بيانات معينة عتبة معينة، تواجه مشاكل الأداء التالية:
تحدث القيم المرتفعة لعدد LOCK_HASH مؤشر المغزل.
ملاحظة، راجع قسم "مزيد من المعلومات" للحصول على معلومات حول كيفية مراقبة شاشة العرض هذه.
تستغرق الاستعلامات أو العمليات التي تتطلب تأمين قاعدة البيانات وقتا طويلا حتى تكتمل. على سبيل المثال، قد تلاحظ التأخيرات في الأداء التالية:
- عمليات تسجيل الدخول في SQL Server
- استعلامات الخادم المرتبط
- sp_reset_connection
- العملية
ملاحظة لتحديد موقع قائمة التأمين (نوع المورد = DATABASE) في قاعدة بيانات معينة، راجع المقطع "مزيد من المعلومات". تختلف قيمة العتبة باختلاف البيئة.
الدقة
معلومات التحديث التراكمي
تم إصلاح المشكلة لأول مرة في التحديث التراكمي التالي ل SQL Server.
التحديث التراكمي 13 ل SQL Server 2008 R2 SP2 /en-us/help/2967540
التحديث التراكمي 17 ل SQL Server 2008 SP3 /en-us/help/2958696
التحديث التراكمي 1 ل SQL Server 2014 /en-us/help/2931693
التحديث التراكمي 9 ل SQL Server 2012 SP1 /en-us/help/2931078
حول التحديثات التراكمية ل SQL Server
يحتوي كل تحديث تراكمي جديد ل SQL Server على جميع الإصلاحات العاجلة وجميع إصلاحات الأمان التي كانت مضمنة في التحديث التراكمي السابق. تحقق من آخر التحديثات التراكمية ل SQL Server:
- التحديث التراكمي الأخير ل SQL Server 2008 R2 SP2
- آخر تحديث تراكمي ل SQL Server 2008 SP3
- التحديث التراكمي الأخير ل SQL Server 2014
- التحديث التراكمي الأخير ل SQL Server 2012 SP1
معلومات الإصلاح العاجل
يتوفر إصلاح عاجل مدعوم من Microsoft. ومع ذلك، فإن غرض هذا الإصلاح العاجل هو تصحيح المشكلة الموضحة في هذه المقالة فقط. قم بتطبيق هذا الإصلاح العاجل فقط على الأنظمة التي تواجه هذه المشكلة المحددة.
إذا كان الإصلاح العاجل متوفرا للتنزيل، فهناك قسم "تنزيل الإصلاح العاجل متوفر" في أعلى مقالة قاعدة المعارف هذه. إذا لم يظهر هذا القسم، فأرسل طلبا إلى خدمة عملاء ودعم Microsoft للحصول على الإصلاح العاجل.
ملاحظة إذا حدثت مشاكل إضافية أو إذا كان هناك أي استكشاف الأخطاء وإصلاحها مطلوبا، فقد يتعين عليك إنشاء طلب خدمة منفصل. سيتم تطبيق تكاليف الدعم المعتادة على أسئلة الدعم الإضافية والمشكلات غير المؤهلة لهذا الإصلاح العاجل المحدد. للحصول على قائمة كاملة بأرقام هواتف خدمة العملاء والدعم من Microsoft أو لإنشاء طلب خدمة منفصل، تفضل بزيارة موقع Microsoft التالي على الويب:
/contactus/?ws=support ملاحظة: يعرض نموذج "تنزيل الإصلاح العاجل متوفر" اللغات التي يتوفر لها الإصلاح العاجل. إذا كنت لا تجد اللغة الخاصة بك، فهذا لأن الإصلاح الجديد غير متوفر لتلك اللغة.
الحالة
لقد أكدت Microsoft على أن هذه مشكلة في منتجات Microsoft المُدرجة في القسم "ينطبق على".
المزيد من المعلومات
عندما يقوم تطبيق بإجراء اتصال ب SQL Server، فإنه ينشئ أولا سياق قاعدة بيانات. بشكل افتراضي، سيحاول الاتصال الحصول على قفل قاعدة بيانات في وضع SH. سيتم تحرير قفل SH-DATABASE عند إيقاف الاتصال أو تغيير سياق قاعدة البيانات خلال فترة عمل الاتصال. إذا كان لديك العديد من الاتصالات النشطة التي تستخدم سياق قاعدة البيانات نفسه، فقد يكون لديك العديد من عمليات تأمين نوع مورد DATABASE لقاعدة البيانات المحددة هذه.
على الكمبيوتر الذي يحتوي على 16 وحدة معالجة مركزية أو أكثر، تستخدم كائنات الجدول فقط نظام تأمين مقسم. ومع ذلك، لا يتم تقسيم تأمين قاعدة البيانات. لذلك، كلما زاد عدد أقفال قاعدة البيانات، كلما استغرق SQL Server وقتا أطول للحصول على تأمين قاعدة البيانات. لا تواجه معظم التطبيقات أي مشاكل سببها هذا التصميم. ولكن بمجرد أن يتجاوز الرقم عتبة معينة ، يلزم العمل والوقت الإضافيين للحصول على القفل. على الرغم من أن التكلفة هي ثوان صغيرة فقط لكل قفل إضافي ، إلا أن الوقت الإجمالي يمكن أن يزيد بسرعة لأن مستودعات تجزئة القفل محمية باستخدام قفل مغزلي. يؤدي ذلك إلى دورات إضافية لوحدة المعالجة المركزية وانتظار عاملين إضافيين للحصول على التأمين.
يقدم هذا الإصلاح الجديد "تقسيم تأمين قاعدة البيانات" عند تمكين علامة التتبع T1236 عند بدء التشغيل. يؤدي تقسيم قفل قاعدة البيانات إلى إبقاء عمق قائمة التأمين قابلا للإدارة في كل قسم محلي. يؤدي ذلك إلى تحسين مسار الوصول المستخدم للحصول على تأمين قاعدة البيانات إلى حد كبير.
لمراقبة LOCK_HASH spinlock، يمكنك استخدام الاستعلام التالي. تعيين NOCOUNT في
CREATE TABLE #spinlock_stats([CaptureTime] datetime,[name] nvarchar(512),[collisions] bigint,
[يدور] عدد صحيح،[spins_per_collision] حقيقي،[sleep_time] عدد صحيح،[تراجع] int)
DECLARE @counter int = 1
بينما @counter< 100
BEGIN
INSERT INTO #spinlock_stats SELECT GETDATE() ك "CaptureTime" , * FROM sys.dm_os_spinlock_stats WHERE [name] = 'LOCK_HASH'
انتظار التأخير '00:00:05'
تعيين @counter +=1
مفتاح النهاية END
تحديد * من #spinlock_stats ترتيب حسب [CaptureTime]
إسقاط جدول #spinlock_stats لمزيد من المعلومات حول تشخيص تنازع مؤشر الشاشة على SQL Server وحله، انتقل إلى المستند التالي:
تشخيص وحل نزاع Spinlock على SQL Server ملاحظة على الرغم من أن هذا المستند مكتوب من أجل SQL Server 2008 R2 ، إلا أن المعلومات لا تزال قابلة للتطبيق على SQL Server 2012.
المراجع
لمزيد من المعلومات حول علامات التتبع في SQL Server 2012، انتقل إلى موقع TechNet التالي على الويب:
معلومات حول تتبع العلامات في SQL Server 2012
لمزيد من المعلومات حول كيفية العثور على عدد عمليات تأمين قاعدة البيانات في المستخدم لكل قاعدة بيانات، استخدم الاستعلام التالي لحساب هذه القيمة:حدد Resource_database_id، resource_type، request_mode، request_status،
count (*) 'LockCount' من sys.dm_tran_locks
التجميع حسب Resource_database_id، resource_type، request_mode، request_status