أنت غير متصل حاليًا، وفي انتظار الإنترنت الخاص بك ليقوم بإعادة الاتصال

سجل حركة نمت بشكل غير متوقع أو تصبح كاملة في SQL Server

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

اضغط هنا لرابط المقالة باللغة الانجليزية317375
الموجز
إذا تم تعيين الخيار النمو التلقائي في Microsoft SQL Server 2005 وأحدث إصدارات SQL Server 2000 و SQL Server 7.0، توسيع ملفات تسجيل المعاملات تلقائياً إلى ملف السجل إلى أقصى حجم من 2 تيرابايت (ت) في ملف السجل.

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

ومع ذلك، في بعض الحالات قد سجل الحركة أصبحت كبيرة جداً والتشغيل مساحة أو تصبح كاملة. بشكل عام، تتلقى رسالة الخطأ التالية عندما تستخدم مساحة القرص المتوفرة ملف سجل حركة ولا يمكن توسيع بعد:
خطأ: 9002، الخطورة: حالة 17,: 2
ملف السجل لقاعدة البيانات ' %. * ls ممتلئ.
إذا كنت تستخدم SQL Server 2005، تتلقى رسالة خطأ مشابهة لما يلي:
خطأ: 9002، الخطورة: حالة 17,: 2
سجل المعاملات لقاعدة البيانات ' %. * ls ممتلئ. لمعرفة لماذا لا يمكن إعادة استخدام الفضاء في السجل، راجع العمود log_reuse_wait_desc في sys.databases
بالإضافة إلى رسالة الخطأ هذه، SQL Server قد وضع قواعد البيانات كمشتبه فيه بسبب عدم وجود مساحة لتوسيع سجل الحركة. لمزيد من المعلومات حول كيفية استرداد من هذا الموقف، راجع الموضوع "مساحة القرص غير كافية" في "كتب SQL Server عبر إنترنت".

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


ملاحظة في SQL Server 2005 والإصدارات الأحدث، يمكنك مراجعة log_reuse_wait و log_reuse_wait_desc أعمدة عرض كتالوج sys.databases لتحديد لماذا لا يتم استخدامها مساحة السجل الحركة و لماذا لا يتم اقتطاعها في سجل الحركة.


المعاملات غير ملتزم بها
حركات صريحة تظل غير مكتملة إذا لم يصدر أمر صريح بالالتزام أو العودة إلى الحالة السابقة. يحدث هذا الأكثر متكرر عند تطبيق إصدار أمر SQL "إنهاء" دون أمر العودة إلى الحالة السابقة المقابلة أو إلغاء. يحدث إلغاء الحركة، ولكن لا تسترجع مرة أخرى. ولذلك، لا يمكن اقتطاع SQL Server كل المعاملات التي تحدث بعد ذلك لأنه تم إحباط المعاملة لا تزال مفتوحة. يمكنك استخدام مرجع DBCC OPENTRAN SQL للعمليات للتحقق من وجود حركة نشطة في قاعدة بيانات في وقت معين. لمزيد من المعلومات حول هذا السيناريو المحدد، انقر فوق أرقام المقالات التالية لعرضها في "قاعدة المعارف ل Microsoft":
295108 الحركة غير كاملة قد عقد عدد كبير من عمليات التأمين وحظر حالات
171224 فهم كيفية عمل الأمر "إنهاء" SQL للعمليات
بالإضافة إلى ذلك، راجع الموضوع "DBCC OPENTRAN" في "كتب SQL Server عبر إنترنت".

وحدات السيناريو التي قد يؤدي إلى حركات غير ملتزم بها:
  • تطبيق تصميم التي يفترض أن كافة أخطاء كوسيرولباكس.
  • تصميم تطبيق التي لا تماما تعتبر سلوك SQL Server عندما تعيد إلى مسمى أو العمليات المتداخلة خاصة المسماة. إذا كنت تحاول العودة إلى حركة المسمى الداخلي، تتلقى رسالة الخطأ التالية:
    ملقم: Msg 6401، مستوى 16، حالة 1، البند 13 لا استرجاع إينيرتران. تم العثور على نوترانساكشن أو نقطة حفظ هذا الاسم.
    بعد سيرفيرجينيراتيس SQL رسالة الإعلام بالخطأ، فإنه يستمر إلى العبارة التالية. هذا بيديسين. لمزيد من المعلومات، راجع الموضوع "المعاملات متداخلة" أو "داخل SQLServer" في "كتب SQL Server عبر إنترنت".

    نوصي بما يلي عند تصميم التطبيق الخاص بك:
    • وحدة حركة واحدة فقط القلم (تنظر في إمكانية أن عملية أخرى قد تتطلب لك).
    • تحقق من @@TRANCOUNT قبل إصدار التزام، استعادة أو عودة، أو أمر مشابه أو عبارة.
    • كتابة التعليمات البرمجية بافتراض أنه قد "تداخل" yours @@TRANCOUNT آخر وتنوي @@TRANCOUNT الخارجي حالته السابقة عند حدوث خطأ.
    • مراجعة نقطة حفظ ووضع خيارات للحركات. (هذه لا تحرير التأمينات!)
    • إجراء الاختبار الكامل.
  • تطبيق يتيح للمستخدم التفاعل داخل الحركات. يؤدي الحركة تبقى مفتوحة لفترة طويلة، وتسجيل هذه الأسباب حظر وحركة النمو نظراً لتعذر اقتطاع الحركة المفتوحة وحركات جديدة تضاف إلى السجل بعد الحركة المفتوحة.
  • تطبيق التحقق يتم @@TRANCOUNT إلى فيريفيثات هناك أية حركات مفتوحة.
  • الشبكة أو أخطاء أخرى إغلاق أبليكاتيونكونيكشن العميل إلى خادم SQL دون إبلاغ ذلك.
  • تجمع الاتصالات. بعد أن يتم إنشاء مؤشرات ترابط العامل، SQL Server استخدام لها إذا كانت لا تخدم اتصال. عند اتصال مستخدم بدء تشغيل حركة وقطع الاتصال قبل ارتكاب أو تراجع الحركة واتصال بعد أن يعيد استخدام نفس مؤشر الترابط، تظل الحركة السابقة مفتوحة لا يزال. هذا الموقف يؤدي إلى تأمين البقاء مفتوحة من الحركة السابقة ومنع اقتطاع المعاملات التي تم تنفيذها في السجل. وينتج أحجام ملفات السجل كبيرة. لمزيد من المعلومات حول تجمع الاتصالات، انقر فوق رقم المقالة التالي لعرضها في "قاعدة المعارف ل Microsoft":
    164221 كيفية تمكين تجمع الاتصالات في أحد تطبيقات ODBC


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

العمليات: DBCC DBREINDEX وإنشاء فهرس
بسبب التغييرات في نموذج الاسترداد في SQL Server 2000، عند استخدام وضع الاسترداد الكامل وتشغيل DBREINDEX DBCC، سجل الحركة توسيع ملحوظ أكثر مقارنة SQL Server 7.0 في وضع استرداد مكافئة باستخدام SELECT INTO أو نسخ كبيرة ومع "Trunc. تسجيل الدخول chkpt. ".

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

عند استعادة من النسخ الاحتياطية سجل المعاملات
هذا الموضح في مقالة "قاعدة معارف Microsoft" التالية:
232196 استخدام مساحة السجل يظهر النمو بعد استعادة من النسخة الاحتياطية

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

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

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

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

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

ويختلف هذا الموقف على SQL Server 7.0 و SQL Server 2000.

استعلام يمكن أن يؤدي إلى توسيع تلقائياً في حالة امتلاء سجل الحركة. قد يستغرق ذلك وقتاً إضافيا وقد تتوقف استعلام أو قد تتجاوز فترة المهلة الخاصة بها بسبب ذلك. SQL Server 7.0 بإرجاع خطأ 9002 في هذه الحالة. لا تنطبق هذه المشكلة على SQL Server 2000.

في SQL Server 2000، إذا كان لديك خيار تقليص التلقائي قيد التشغيل لقاعدة بيانات، يوجد وقت الصغيرة جداً التي يحاول سجل معاملات توسيع تلقائياً. ومع ذلك، لا يمكن توسيع للدالة التقليص التلقائي قيد التشغيل في نفس الوقت. قد يتسبب هذا أيضا حالات خطأ خطأ 9002.

التوسيع التلقائي من ملفات سجل العمليات تحدث عادة بسرعة. ومع ذلك، في الحالات التالية، قد يستغرق وقتاً أطول من المعتاد:
  • يتم زيادة حجم صغير جداً.
  • الخادم بطيئة لأسباب مختلفة.
  • محركات الأقراص غير كافية.


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

لمزيد من المعلومات حول كيفية استكشاف أخطاء حركات unreplicated، راجع مواضيع "sp_replcounters" و "sp_repldone" في "كتب SQL Server عبر إنترنت".

لمزيد من المعلومات، انقر فوق أرقام المقالات التالية لعرض المقالات في قاعدة معارف Microsoft:
306769 تصحيح: لا يمكن اقتطاع سجل المعاملة من قاعدة البيانات المنشورة في لقطة
240039 تصحيح: DBCC OPENTRAN لا يعلم معلومات النسخ المتماثل
198514 تصحيح: يؤدي استعادة إلى ملقم جديد بالبقاء في سجل المعاملات


إلى 'AVAILABILITY_REPLICA' تطبيق حركة سجلات قاعدة بيانات ثانوي

في SQL Server 2012 مع "مجموعات توفر إلى" تمكين، قد ترى رسالة في سجل أخطاء SQL بعد:

خطأ: 9002، الخطورة: حالة 17,: 9.
سجل المعاملات لقاعدة البيانات '%. * ممتلئ ls سبب' AVAILABILITY_REPLICA '

تشير AVAILABILITY_REPLICA log_reuse_wait إلى نسخة متماثلة "إلى إتاحة مجموعات" ثانوية هي تطبيق حركة سجلات قاعدة البيانات هذه قاعدة البيانات ثانوي المقابل.

هناك سيناريوهان يمكن أن يؤدي إلى تسجيل نمو في قاعدة بيانات توفر و AVAILABILITY_REPLICA ' log_reuse_wait:

السيناريو 1: توفير استتار تسجيل التغييرات الثانوية

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

السيناريو 2: إعادة زمن الوصول

مجرد تصعيب إلى ملف سجل قاعدة البيانات الثانوية تطبيق مؤشر ترابط مخصص إعادة سجلات التسجيل.

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

يمكنك استخدام لوحة المعلومات إلى وإرسال قائمة انتظار sys.dm_hadr_database_replica_states طرق عرض إدارة الحيوي للمساعدة في مراقبة السجل وإعادة قائمة الانتظار. بعض الحقول الأساسية:

الحقلالوصف
log_send_queue_sizeمقدار سجلات لم تصل في النسخة المتماثلة الثانوية
log_send_rateالمعدل الذي سجل يتم إرسال السجلات إلى قواعد البيانات الثانوية
redo_queue_sizeمقدار سجلات التسجيل في ملفات السجل الثانوي النسخة المتماثلة التي قد لا بعد تم إعادتها، بالكيلوبايت (KB)
redo_rateالمعدل الذي يتم يتم إعادتها السجلات على قاعدة ثانوية معينة، بالكيلوبايت (KB)/الثانية
last_redone_lsnرقم التسلسل السجل الحقيقي سجل آخر تم إعادة بنائه على قاعدة ثانوية. last_redone_lsn يكون دوماً أقل من last_hardened_lsn
last_received_lsnتسجيل معرف المنع التعرف على نقطة صلاحية جميع الكتل سجل تم تلقيها بواسطة النسخة المتماثلة الثانوي الذي يستضيف قاعدة بيانات ثانوية هذا. يعكس هوية كتلة سجل مبطن بأصفار. لم يكن رقم تسلسل سجل الفعلي.

ملاحظة لمزيد من المعلومات حول عرض sys.dm_hadr_database_replica_states، راجع موقع TechNet التالي على الويب:

http://technet.microsoft.com/en-us/library/ff877972.aspx



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

لمزيد من المعلومات، راجع الموضوع "هندسة سجل الفعلي على المعاملة" في "كتب SQL Server عبر إنترنت". بالإضافة إلى ذلك، راجع رسم تخطيطي ومناقشه ذلك في الصفحة 190 من "داخل SQL Server 7.0" (Soukup رون. داخل Microsoft SQL Server 7.0 أو Microsoft Press، 1999)، وأيضا على صفحة 182 و 186 "داخل SQL Server 2000" (ديلاني، كالين. داخل Microsoft SQL Server 2000، Microsoft Press، 2000). قواعد بيانات SQL Server 2000 أو SQL Server 7.0 تتوفر الخيارات للنمو التلقائي وأوتوشرينك. يمكنك استخدام هذه الخيارات لمساعدتك في ضغط أو توسيع سجل العمليات.

لمزيد من المعلومات حول كيف يمكن أن تؤثر هذه الخيارات على الخادم، انقر فوق رقم المقالة التالي لعرضها في "قاعدة المعارف ل Microsoft":
315512 اعتبارات لتكوين أوتوشرينك والنمو التلقائي في SQL Server
اقتطاع ملف سجل الحركة يختلف ضغط ملف سجل المعاملات. عندما يقوم SQL Server باقتطاع ملف سجل المعاملات، وهذا يعني أنه يتم حذف محتويات هذا الملف (على سبيل المثال، الحركات الإلزامية). ومع ذلك، عندما تقوم بعرض حجم الملف من منظور مساحة قرص (على سبيل المثال، في مستكشف Windows أو باستخدام الأمر dir )، لم يتغير الحجم. ومع ذلك، المساحة الموجودة داخل ملف.ldf يمكن الآن استخدامها من قبل حركات جديدة. فقط عندما يكون ملقم SQL تقليص حجم ملف سجل المعاملات فعلياً ترى تغيير الحجم الفعلي لملف السجل.

لمزيد من المعلومات حول كيفية تقليص سجلات الحركة، انقر فوق رقم المقالة التالي لعرضها في "قاعدة المعارف ل Microsoft":
256650 كيفية تقليص سجل المعاملات SQL Server 7.0
272318 تقليص سجل المعاملات في SQL Server 2000 باستخدام DBCC SHRINKFILE
لمزيد من المعلومات حول استخدام سجل المعاملة SQL Server 6.5، انقر فوق رقم المقالة التالي لعرضها في "قاعدة المعارف ل Microsoft":
110139 أسباب ملء سجل المعاملات SQL

كيفية تحديد الاستعلامات التي تستهلك قدرا كبيرا من مساحة السجل في SQL Server 2005 والإصدارات الأحدث

في SQL Server 2005 والإصدارات الأحدث، يمكنك استخدام طريقة عرض إدارة الحيوي sys.dm_tran_database_transactions (DMV) لتحديد الاستعلامات التي تستهلك كميات كبيرة من مساحة السجل. الأعمدة التالية في sys.dm_tran_database_transactions دي أم يمكن أن تكون مفيدة:
  • database_transaction_log_bytes_used
  • database_transaction_log_bytes_used_system
  • database_transaction_log_bytes_reserved
  • database_transaction_log_bytes_reserved_system
  • database_transaction_log_record_count
يمكنك الاستعلام عمود sql_handle sys.dm_exec_requests دي أم الحصول على نص العبارة الفعلية التي تستهلك كميات كبيرة من مساحة السجل. يمكنك القيام بذلك بالانضمام إلى sys.dm_tran_database_transactions DMV و sys.dm_tran_session_transactions دي أم على عمود transaction_id، ثم إضافة إنشاء صلة إضافية مع sys.dm_exec_requests في العمود session_id.

لمزيد من المعلومات حول sys.dm_tran_database_transactions دي أم، انتقل sys.dm_tran_database_transactions (SQL للعمليات) موقع شبكة مطوري Microsoft (MSDN).

لمزيد من المعلومات حول sys.dm_tran_session_transactions دي أم، انتقل sys.dm_tran_session_transactions (SQL للعمليات) موقع MSDN على ويب.

لمزيد من المعلومات حول sys.dm_exec_requests دي أم، انتقل sys.dm_exec_requests (SQL للعمليات) موقع MSDN على ويب.

تحذير: تمت ترجمة هذه المقالة تلقائيًا

خصائص

رقم الموضوع: 317375 - آخر مراجعة: 01/13/2014 17:48:00 - المراجعة: 3.0

Microsoft SQL Server 2012 Standard, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Express, Microsoft SQL Server 2008 R2 Standard, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 R2 Enterprise, Microsoft SQL Server 2008 R2 Express, Microsoft SQL Server 2008 Standard, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 7.0 Standard Edition

  • kbsqlsetup kbinfo kbmt KB317375 KbMtar
تعليقات