نحوه تعیین استفاده از ورود به سیستم پایگاه داده سرور SQL

یکی از جنبه های مهم همه بانکهای اطلاعاتی ، گزارش معامله است. از گزارش معامله برای نوشتن کلیه معاملات قبل از انجام داده ها به پرونده داده استفاده می شود. در برخی شرایط ، سیاهههای مربوط به معامله می توانند بسیار بزرگ شوند و نمی دانند چه چیزی در گزارش معامله وجود دارد یا اینکه چقدر فضای استفاده می شود می تواند به یک مشکل تبدیل شود. بنابراین چگونه می توانید تعیین کنید که چه مقدار از گزارش معامله استفاده می شود و از چه بخش هایی استفاده می شود؟

راه حل

در اکثر بانکهای اطلاعاتی ، ورود به سیستم معاملات به طور کلی فقط یک پرونده (LDF) است ، اما در داخل گزارش کلی معامله یک سری پرونده های ورود به سیستم مجازی است که در زیر به تصویر کشیده شده است.

منبع (کتابهای سرور SQL آنلاین)

نحوه استفاده از گزارش معامله این است که هر پرونده ورود به سیستم مجازی برای آن نوشته شده است و هنگامی که داده ها انجام می شود و یک بازرسی رخ می دهد ، دوباره فضا قابل استفاده می شود. اگرچه این به مدل بازیابی پایگاه داده شما بستگی دارد ، خواه از تکرار و پردازش پشتیبان خود استفاده کنید. در صورت عدم وجود سیاهههای مجازی اضافی ، SQL Server براساس تنظیمات پایگاه داده شما ، ورود به سیستم معامله را رشد می دهد تا فضای اضافی مورد نیاز را در خود جای دهد.

منبع (کتابهای سرور SQL آنلاین)

استفاده از پرونده و سیاهههای مجازی همه بستگی به نحوه استفاده از پایگاه داده و سایر تنظیمات شما در پایگاه داده خود دارد. اگر در حال انتشار داده های این پایگاه داده هستید یا اینکه پایگاه داده روی حالت بازیابی کامل یا فله تنظیم شده است ، این امر همچنین تأثیر می گذارد که آیا فرآیند حلقه به ابتدای پرونده باز می گردد ، در صورت استفاده از ورود به سیستم مجازی بعدی موجود یا ITدر صورت نیاز به رشد گزارش معامله و ایجاد سیاهههای مجازی اضافی.

فضای استفاده شده توسط سیاهههای مربوط به معامله را با استفاده از DBCC SQLPERF (Logspace) دریافت کنید

یک دستور که در درک میزان استفاده از گزارش معامله بسیار مفید است DBCC SQLPERF (Logspace) است. این یک دستور در مورد اندازه فعلی کلیه سیاهههای مربوط به معاملات پایگاه داده و همچنین درصد در حال حاضر استفاده می کند. اجرای این دستور به صورت دوره ای ایده خوبی را در مورد نحوه استفاده از سیاهههای مربوط به معامله به شما می دهد و همچنین به شما ایده می دهد که واقعاً باید چقدر بزرگ باشند. این سوالی است که اغلب توسط بسیاری از افراد که از سرور SQL استفاده می کنند سؤال می شود و با اجرای این کار ، می فهمید که هیچ پاسخ کاملی وجود ندارد ، همه اینها به معیارهای زیادی مانند:

• مدل بازیابی
• اندازه معاملات
• جداول شما چقدر بزرگ است و بنابراین برای نگهداری شاخص چقدر فضای لازم است
• چند بار پشتیبان‌گیری از گزارش تراکنش‌ها را اجرا می‌کنید
• آیا پایگاه داده منتشر شده است یا نه
• و غیره.

برای اجرای این دستور در یک پنجره پرس و جو موارد زیر را صادر کنید:

این نمونه خروجی است:

از اینجا می‌توانیم اندازه گزارش‌های تراکنش و همچنین میزان فضای استفاده شده را ببینیم. فضای گزارش فعلی استفاده شده به شما می گوید که چه مقدار از گزارش تراکنش استفاده می شود. اگر این درصد زیاد است و اندازه لاگ بسیار بزرگ است، احتمالاً به دلیل یکی از موارد ذکر شده در بالا است.

دریافت اطلاعات در مورد گزارش های مجازی SQL Server با استفاده از DBCC LOGINFO

دستور بعدی که باید به آن نگاه کرد، DBCC LOGINFO است. این به شما اطلاعاتی در مورد لاگ های مجازی شما در لاگ تراکنش های شما می دهد. اولین چیزی که در اینجا باید به آن نگاه کرد ستون وضعیت است. از آنجایی که این فایل به صورت متوالی نوشته می شود و سپس به ابتدا باز می گردد، می خواهید به جایی که مقدار "2" در خروجی است نگاه کنید. این به شما می‌گوید که چه بخش‌هایی از گزارش استفاده می‌شود و کدام بخش استفاده نمی‌شود. وضعیت = 0. مورد دیگری که باید به آن توجه داشت، ستون FSeqNo است. این شماره توالی لاگ مجازی است و آخرین آن آخرین گزارش است. اگر در حین صدور تراکنش، این دستور را اجرا کنید، خواهید دید که این اعداد همچنان تغییر می کنند.

برای اجرای این دستور در یک پنجره پرس و جو موارد زیر را صادر کنید:

این نمونه خروجی است:

اگر اکنون یک نسخه پشتیبان از گزارش تراکنش مانند موارد زیر را اجرا کنیم:

و سپس دستور را مجددا اجرا کنید و خواهید دید که چگونه Status=2 در فایل تغییر کرده است. آخرین ورودی همچنان به عنوان در حال استفاده علامت گذاری شده است، اما ورودی های قبلی به 0 بازنشانی شده اند.

یافتن تراکنش های باز SQL با استفاده از DBCC OPENTRAN

دستور دیگری که باید به آن نگاه کرد، DBCC OPENTRAN است. این به شما نشان می دهد که آیا تراکنش های باز در گزارش تراکنش خود دارید که تکمیل نشده یا انجام نشده است. اینها ممکن است تراکنش های فعال یا تراکنش هایی باشند که به دلایلی هرگز تکمیل نشده اند. این می تواند اطلاعات بیشتری در مورد اینکه چرا گزارش تراکنش شما بسیار بزرگ است یا اینکه چرا ممکن است نتوانید فایل گزارش تراکنش را کوچک کنید، ارائه دهد. در صورت انتشار پایگاه داده، این کار هم تراکنش های باز و هم هرگونه تراکنش تکرار نشده را به شما نشان می دهد.

برای اجرای این دستور در یک پنجره پرس و جو موارد زیر را صادر کنید:

این نمونه خروجی است:

اکنون که شما ایده ای دارید که چه مقدار از گزارش معامله شما استفاده می شود و از چه مواردی استفاده می شود ، می توانید تصمیماتی را در مورد میزان ورود به معامله شروع کنید. یک کاری که باید انجام دهید این است که پیدا کنید که اندازه مطلوب به منظور از بین بردن نیاز به کوچک شدن و رشد ورود به سیستم به طور مداوم است. مانند همه فعالیت های بانک اطلاعاتی و سرور ، بهتر است تا حد امکان سربار را به حداقل برسانید و این یکی از مناطقی است که می توانید با ایجاد و حفظ اندازه بهینه معاملات معامله ، تا حدودی مدیریت کنید.

مراحل بعدی

• اطمینان حاصل کنید که بر اساس مدل بازیابی خود از استراتژی صحیح پشتیبان استفاده می کنید
• اگر نیاز به کوچک کردن پرونده ورود به سیستم معامله خود دارید ، به DBCC Shrinkfile نگاهی بیندازید.
• در اینجا چند نکته دیگر در مورد فضای ورود به سیستم معامله آورده شده است.
  • نظارت بر فضای ورود به سیستم معامله

  مقالات مرتبط

  مقالات محبوب

  

  

  درباره نویسنده

  گرگ رابیدوکس رئیس جمهور Edgewood Solutions و بنیانگذار MSSQLTIPS.com است.

  مقاله آخرین به روز شده: 2020-10-23

  نظرات برای این مقاله

   

  دوشنبه ، 19 دسامبر 2022 - 2:59:43 صبح - لانسیو	بازگشت به بالا(90764)
  سلام ، من تعجب کردم که چرا Stapoffset و Fseqno همان ترتیب را ندارند. این اختلال هنگام ایجاد Autogrow به نظر می رسد. آیا اطلاعاتی در مورد آن دارید؟آیا امکان تنظیم مجدد startoffset و fseqno وجود دارد تا پرونده ورود به سیستم پی در پی تر شود؟با احترام

  چهارشنبه ، 8 دسامبر 2021 - 10:10:48 صبح - گرگ رابیدوکس

  بازگشت به بالا(89548)

  سلام وگگن ،   اگر پایگاه داده در مدل بازیابی ساده است ، نیازی به انجام پشتیبان گیری از ورود به سیستم نیست. می توانید به فرکانس بازرسی های پایگاه داده نگاه کنید ، به این مقاله https://www.mssqltips.com/sqlservertip/6319/sql-server-checkpoint-monitoring-with-extended-events/ مراجعه کنید. آیا معاملات بزرگی دارید که در حال اجرا هستند یا همه آنها معاملات بسیار کمی هستند؟ همچنین ، شما ذکر می کنید که گزارش معامله چندین گیگابایت است. در مقایسه با پرونده های داده چقدر بزرگ است؟ انجام پشتیبان گیری AV از ورود به معامله ، وضعیت = 2 (در حال استفاده) را در سیاهههای مجازی تغییر می دهد ، به وضعیت = 0 فقط ورود به سیستم مجازی که دارای آخرین/بزرگترین دنباله NR است ، هنوز وضعیت = 2 خواهد داشت.(در حال استفاده). در یک سیستم از مدل بازیابی ساده استفاده می کنیم. من مطمئن نیستم که موارد فوق در مورد وضعیت فقط برای مدل بازیابی کامل اعمال می شود یا هنوز هم برای مدل ساده مرتبط است. مشکل: چند بار مشاهده می کنیم که logfiles واقعاً بزرگ می شود ، حتی اگر پایگاه داده برنامه ریزی شده روزانه و تهیه نسخه پشتیبان از logfile انجام شود. آیا کسی می تواند سعی کند توضیح دهد که چگونه Logfiles می تواند هنگام استفاده از یک مدل بازیابی ساده ، این بزرگ (چند گیگابایت) را رشد دهد؟ 1. آیا این معامله بیش از حد در مدت زمان کوتاهی علیه بانک اطلاعاتی اخراج می شود و باعث می شود LDF سریعتر از معاملات متعهد به DataFile پر شود؟من تلاش می کنم تا درک کنم چنین بار ممکن است برای واقعی اتفاق بیفتد. یا می تواند یک واحد - به دلایلی معامله "گیر" باعث این امر شود؟ آیا پشتیبان گیری مکرر از گزارش معامله (4 بار در روز) کمک می کند ، فضای ورود به سیستم موجود را آزاد می کند؟(مطمئن نیستید که آیا این برای مدل بازیابی ساده اعمال می شود) من می خواهم نوعی SQL-query ایجاد کنم که می تواند یک هشدار ایجاد کند یا نشان دهد چیزی در حال حاضر اشتباه است. مزیت و ضرر برای تعیین استفاده از ورود به سیستم معاملات SQL Server Server چیست؟ مقاله عالی. سوال: وقتی DBCC Loginfo را اجرا می کنم ، این خط را دریافت می کنم واحد بازیابی = 0 چگونه می توانم فرایندی را پیدا کنم که این ورود به سیستم را در MSSQL انجام دهد؟ از قبل ، از کمک شما در این زمینه متشکرم من همین مسئله را دارم اما حل نشده است. اگر ورود به معامله بزرگتر شود ، 1. شاخص بازسازی روزانه از برنامه حفظ. 2. گرفتن پشتیبان (. bak) و TransactionLog (. t) هر دو از یک برنامه حفظ مشابه. اکنون من برنامه های نگهداری خود را تغییر داده ام ، دو برنامه حفظ ، یکی برای پشتیبان گیری (. bak) و دیگری برای TransactionLog (. t) ایجاد کرده ام. مسئله من را حل کرد .. با تشکر. بسیار توضیحی این به یک سؤال مهم پاسخ نمی دهد: "کدام معامله باعث استفاده زیاد از ورود به سیستم شده است؟". DBCC OpenTran پاسخی ندارد ، زیرا طولانی ترین معامله در حال اجرا ممکن است کسی نباشد که از بیشترین فضای ورود به سیستم استفاده می کند. آیا راهی برای تعیین مسئولیت معامله وجود دارد؟TX سلام ، من می فهمم که چگونه DB Engine از Tran Log استفاده می کند ، اما من نمی فهمم که چگونه افزایش تعداد VLF می تواند بر پشتیبان گیری از ورود به معاملات یا عملکرد بازیابی تأثیر بگذارد؟ SARA - گفتن آن دشوار است زیرا بستگی به این دارد که ردیف های بزرگ درج شده چقدر بزرگ هستند ، بنابراین حتی اگر فقط یک جدول داشته باشید ممکن است به فضای زیادی نیاز داشته باشد. یک قانون کلی این است که معامله را در حدود 20-25 ٪ از پرونده داده وارد کنید ، اما باز هم این همه به پایگاه داده بستگی دارد و بزرگترین جدول که در پایگاه داده خود وجود دارد چقدر بزرگ است. دستور DBCC SQLPERF (LogSpace) را اجرا کنید تا ببینید که در واقع چقدر از فضای استفاده می شود و همچنین این را با اندازه کلی پایگاه داده خود مقایسه کنید. همچنین باید مدل بازیابی پایگاه داده را بررسی کنید. این coudl در بهبودی کامل خواهد بود و اگر شما در حال انجام پشتیبان گیری از ورود به سیستم نیستید ، این فقط رشد خواهد کرد. برای اطلاعات بیشتر به این موضوع مراجعه کنید: http://www.mssqltips.com/sqlservertoritorial/2/sql-server-recovery-models/ اندازه ورود به سیستم 1008. 242mb برای یک جادوگر DB دارای یک جدول واحد با تقریباً 30 درج فردی منطقی است؟ دلیل کامل شدن پایگاه داده مدل چیست؟ مسئله با سرعت اجرای پرس و جو! آیا این باعث می شود که اجرای پایگاه داده کند شود؟ وقتی "DBCC Loginfo" را برای پایگاه داده خود اجرا می کنم ، 307 ردیف دارم! آیا این بدان معنی است که چیزی اشتباه است؟و باعث کاهش سرعت اعدام می شود؟ chiranjib saha roy - بر اساس سناریوی شما اگر سیاهههای مربوط به معامله از دست رفته بودند و شما فقط از نسخه پشتیبان تهیه شده و نسخه پشتیبان تهیه شده از معاملات کامل استفاده کرده اید بهترین کاری که می توانید انجام دهید این است که پشتیبان گیری کامل خود را بازیابی کنید و تمام گزارش های معامله ای که در آنجا ایجاد کرده اید ایجاد شده استدر دنباله. بنابراین اگر 12 نسخه پشتیبان از ورود به سیستم معامله دارید و #6،7،8 بهترین کار را از دست نمی دهید ، بازگرداندن #1،2،3،4،5 و فقط داده ها را تا آن نقطه بازیابی کنید. امیدوارم این به سوال شما پاسخ دهد. مسئله با ترمیم فرض کنید پایگاه داده من با مدل بازیابی کامل پیکربندی شده است. نسخه پشتیبان تهیه شده کامل @ 1 صبح هر شب و بعد از هر بار تهیه نسخه پشتیبان تهیه Tranaction 30 دقیقه سناریو:- پایگاه داده در ساعت 10:01 صبح خراب شده است. DBA دید که آخرین نسخه پشتیبان از ورود به سیستم قبل از این که 7 گزارش معامله وجود داشته باشد وجود دارد. چگونه DBA پایگاه داده را بدون از دست دادن داده بازیابی می کند. هرگونه توضیح لازم ، لطفاً با تماس تماس بگیرید با تشکر! چگونه می توانم بررسی کنم که معاملات فردی چقدر فضای ورود به سیستم را انجام می دهد؟