KB4338890 - FIX: خطأ "غير مردود" ويظهر SQL Server غير مستجيب في SQL Server 2014 و2016 و2017

ينطبق على
SQL Server 2016 Developer - duplicate (do not use) SQL Server 2016 Enterprise - duplicate (do not use) SQL Server 2016 Enterprise Core - duplicate (do not use) SQL Server 2016 Standard - duplicate (do not use) SQL Server 2017 Developer on Windows SQL Server 2017 Enterprise Core on Windows SQL Server 2017 Enterprise on Windows SQL Server 2017 Standard on Windows SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Enterprise Core - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use)

الأعراض

افترض أن لديك Microsoft SQL Server 2014 أو 2016 أو 2017 مثبتا.  قد تواجه مشكلة واحدة أو أكثر من المشكلات التالية:

  • يبدو المثيل SQL Server غير مستجيب ويحدث خطأ "مجدول غير منتج". قد تحتاج إلى إعادة تشغيل الخادم للاسترداد.
  • قد يستغرق التراجع عن العملية وقتا طويلا لإكمالها. في معظم الحالات، ستسمح إعادة تشغيل المثيل لقاعدة البيانات باسترداد أسرع بكثير من التراجع. لاحظ أن هناك العديد من الأسباب التي قد تستغرق العودة إلى الحالة السابقة وقتا طويلا لإكمالها، راجع قسم "مزيد من المعلومات" أدناه للحصول على تفاصيل حول مراقبة التراجع قبل محاولة إعادة التشغيل.
  • قد ترى انتظارات عالية على الدوارات مثل SOS_OBJECT_STORE.

الدقة

تم إصلاح هذه المشكلة في التحديثات التراكمية التالية SQL Server:

التحديث التراكمي 9 SQL Server 2017

التحديث التراكمي 2 SQL Server 2016 SP2

حول التحديثات التراكمية SQL Server:

يحتوي كل تحديث تراكمي جديد SQL Server على جميع الإصلاحات العاجلة وجميع إصلاحات الأمان التي تم تضمينها مع التحديث التراكمي السابق. اطلع على آخر التحديثات التراكمية SQL Server:

آخر تحديث تراكمي SQL Server 2017

آخر تحديث تراكمي SQL Server 2016

آخر تحديث تراكمي SQL Server 2014

معلومات حزمة الخدمة SQL Server

تم إصلاح هذا التحديث في حزمة الخدمة التالية SQL Server:

حزمة الخدمة 3 SQL Server 2014

حول حزم الخدمة SQL Server:

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

كيفية تحديد إصدار SQL Server ومكوناتها وإصدارها وتحديثها

مزيد من المعلومات

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

  • من sys.dm_exec_requests، حدد session_id التي تم تعيين أمرها إلى "KILLED/ROLLBACK" وتأكد من أن الجلسة تتراكم على كل من وقت الإدخال/الإخراج ووحدة المعالجة المركزية الذي يشير إلى التقدم. إذا لم يتغير IO، فقد يكون مؤشرا على أنك تواجه المشكلة الموضحة في هذه المقالة.
  • sys.dm_tran_database_transactions الاستعلام لتحديد الحالة الحالية للتراجع باستخدام استعلام كما يلي:

ملاحظة

  • SELECT getdate() as CurrentTime, database_transaction_next_undo_lsn,database_transaction_begin_lsn,t.transaction_id,database_transaction_begin_time,database_transaction_log_record_count,db_name(t.database_id)
  • FROM sys.dm_tran_database_transactions t
  • JOIN sys.dm_exec_requests s
       ON t.transaction_id=s.transaction_id
  • WHERE t.database_id=db_id('<Database Name') و s.session_id=<Session_id تنفيذ عملية> التراجع

ملاحظة:

في الاستعلام أعلاه،

database_transaction_next_undo_lsn هو LSN للسجل التالي للتراجع. database_transaction_begin_lsn هو LSN لسجل البدء للمعاملة في سجل المعاملات.

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

الهدف هنا هو أخذ بعض اللقطات من الاستعلام السابق ضمن فاصل زمني محدد مسبقا ثم استخدام دلتا LSNs التي تمت معالجتها في database_transaction_next_undo_lsn خلال هذا الفاصل الزمني واستقراء الوقت المستغرق لتقدير الوقت الذي سيستغرقه database_transaction_next_undo_lsn للوصول إلى database_transaction_begin_lsn.

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

راجع المقالات التالية لمزيد من المعلومات حول الاسترداد طويل الأمد:

الحالة

لقد أكدت Microsoft على أن هذه مشكلة في منتجات Microsoft المُدرجة في القسم "ينطبق على".

المراجع

تعرّف على المصطلحات التي تستخدمها Microsoft لوصف تحديثات البرامج.