نظارت بر گزارش معاملات و اهمیت آن

نظارت بر اندازه فایل های گزارش تراکنش به دلایل زیر مهم است:

1. فایل گزارش تراکنش ممکن است پر شود و ممکن است خطاهای زیر را ایجاد کند: 1. 1) تراکنش ها ممکن است شکست بخورند و ممکن است شروع به بازگشت کنند. 1. 2) ممکن است مدت زمان زیادی طول بکشد تا تراکنش ها تکمیل شوند 1. 3) مشکلات عملکرد ممکن است رخ دهد 1. 4) مسدود شدن ممکن است رخ دهد
2. فایل گزارش تراکنش ممکن است تمام فضای خالی دیسک شما را مصرف کند و سیستم شما را متوقف کند.
3. گزارش‌های تراکنش بسیار بزرگ اغلب نشان می‌دهند که پشتیبان‌گیری از گزارش تراکنش برای مدت طولانی در پایگاه داده حالت بازیابی کامل انجام نشده است.

اگر شاهد رشد سریع یک فایل گزارش تراکنش هستید، شایع ترین دلایل آن موارد زیر است:

1. تراکنش طولانی در حال اجرا (نگهداری شاخص؟ حذف یا به روز رسانی دسته ای بزرگ؟)
2. پایگاه داده در حالت بازیابی کامل است و شما به اندازه کافی از لاگ پشتیبان تهیه نمی کنید.

سناریوها معمولاً از دو الگو پیروی می کنند:

1.) عدم درک مدل های بازیابی در حالت بازیابی کامل و عدم تهیه نسخه پشتیبان از گزارش - این شایع ترین دلیل است - اکثریت قریب به اتفاق کسانی که این مشکل را تجربه می کنند، هستند. در SQL Server، سه مدل بازیابی وجود دارد - Full، Bulk-Logged و Simple. فعلاً Bulk-Logged را نادیده می گیریم و به نوعی می گوییم که این یک مدل هیبریدی است و اکثر افرادی که در این مدل هستند به دلایلی آنجا هستند و مدل های بازیابی را درک می کنند.

چند نکته مهم که باید در مورد فایل های گزارش تراکنش بدانید عبارتند از:

1. فایل گزارش تراکنش برای بازیابی خرابی/راه‌اندازی مجدد وجود دارد. برای حرکت رو به جلو و برگشت کاری که یا قبل از خرابی یا راه اندازی مجدد انجام شده است (غلتیدن به جلو/دوباره) و کاری که شروع شده است اما پس از خرابی یا شروع مجدد به پایان نرسیده است (بازگرداندن/بازگرداندن). این وظیفه گزارش تراکنش است که ببیند یک تراکنش شروع شده اما هرگز تمام نشده است. در آن شرایط، وظیفه لاگ این است که در حین بهبودی بگوید «هی، این واقعاً تمام نشد، بیایید آن را به عقب برگردانیم». همچنین وظیفه گزارش این است که ببیند چیزی را تمام کرده اید و به برنامه مشتری شما گفته شده که تمام شده است (حتی اگر هنوز در فایل داده شما سخت نشده باشد) و بگویید "هی.. واقعاً این اتفاق افتاده است، بیایید آن را رول کنیم. به جلو، اجازه دهید آن را همانطور که برنامه‌ها فکر می‌کنند پس از راه‌اندازی مجدد. اکنون موارد بیشتری وجود دارد، اما این هدف اصلی است.
2. هدف دیگر یک فایل گزارش تراکنش این است که بتواند به ما توانایی بازیابی در یک نقطه از زمان را به دلیل "اوپس" در پایگاه داده یا تضمین یک نقطه بازیابی در صورت خرابی سخت افزار مربوط به داده ها و تضمین کند./یا فایل های گزارش یک پایگاه داده. اگر این گزارش تراکنش حاوی سوابق تراکنش‌هایی باشد که برای بازیابی شروع و به پایان رسیده‌اند، SQL Server می‌تواند و سپس از این اطلاعات برای رساندن پایگاه داده به جایی که قبل از وقوع مشکل بود استفاده می‌کند، اما همیشه این گزینه در دسترس نیست. مابرای اینکه کار کند، باید پایگاه داده خود را در مدل بازیابی مناسب داشته باشیم، و باید از لاگ پشتیبان تهیه کنیم.

در صورتی که پایگاه داده شما در حالت بازیابی کامل است، در اینجا نیز می توانید با عدم تهیه نسخه پشتیبان از گزارش به اندازه کافی، خود را دچار مشکل کنید.– گرفتن یک نسخه پشتیبان از لاگ در روز ممکن است خوب به نظر برسد، این امر باعث می‌شود که بازیابی به دستورات بازیابی کمتری نیاز داشته باشد، اما با در نظر گرفتن بحث بالا، این فایل لاگ تا زمانی که از لاگ پشتیبان تهیه کنید به رشد و رشد خود ادامه خواهد داد. شما باید فرکانس بک آپ لاگ خود را با در نظر گرفتن دو چیز در نظر بگیرید:

1. نیازهای بازیابی – در صورتی که درایو حاوی گزارش تراکنش شما خراب شود یا دچار فساد شدیدی شوید که بر پشتیبان‌گیری گزارش شما تأثیر می‌گذارد، چه مقدار داده می‌تواند از بین برود؟اگر این تعداد بیشتر از 10-15 دقیقه نیست، پس باید هر 10-15 دقیقه یک بار از گزارش پشتیبان تهیه کنید، پایان بحث.
2. رشد گزارش - اگر سازمان شما به دلیل توانایی بازآفرینی آسان آن روز، نمی‌تواند داده‌های بیشتری را از دست بدهد، ممکن است برای داشتن یک نسخه پشتیبان از گزارش با دفعات کمتر از 15 دقیقه خوب باشد. شاید سازمان شما با هر 4 ساعت خوب باشد. اما باید ببینید در 4 ساعت چند تراکنش ایجاد می کنید. آیا اجازه دادن به گزارش برای ادامه رشد در آن چهار ساعت باعث می‌شود که یک فایل گزارش بیش از حد بزرگ شود؟آیا این بدان معنی است که پشتیبان گیری از لاگ شما بیش از حد طول می کشد؟شما باید آن را در نظر بگیرید.

2.) تراکنش های طولانی مدت این نیز می تواند دلیل رشد کنترل نشده و بی بند و بار باشد. بدون توجه به مدل بازیابی، اما اغلب به صورت "اما من در مدل بازیابی ساده هستم - چرا گزارش من هنوز در حال رشد است!"دلیل اینجا ساده است، اگر SQL همانطور که در بالا توضیح دادم از این گزارش تراکنش برای اهداف بازیابی استفاده می کند، باید به شروع تراکنش برگردد. اگر تراکنشی دارید که زمان زیادی طول می‌کشد یا تغییرات زیادی انجام می‌دهد، گزارش نمی‌تواند برای هیچ یک از تغییراتی که هنوز در تراکنش‌های باز هستند یا از زمان شروع آن تراکنش شروع شده‌اند، در نقطه بازرسی کوتاه شود. این به این معنی است که حذف بزرگ، حذف میلیون‌ها ردیف در یک دستور حذف، یک تراکنش است و تا زمانی که کل حذف انجام نشود، لاگ نمی‌تواند هیچ گونه کوتاهی انجام دهد. در مدل بازیابی کامل، این حذف ثبت می‌شود و می‌تواند بسیاری از رکوردهای گزارش باشد. کار بهینه‌سازی Index در طول پنجره‌های تعمیر و نگهداری یکسان است. همچنین به این معنی است که مدیریت ضعیف تراکنش ها و عدم مشاهده و بستن تراکنش های باز می تواند واقعاً به شما و فایل لاگ شما آسیب برساند. به این ترتیب می توانید اندازه فایل های گزارش تراکنش خود را تشخیص دهید:

SELECT (اندازه * 8. 0)/1024. 0 AS size_in_mb , CASE WHEN max_size = -1 THEN 9999999 -- رشد نامحدود ELSE (max_size * 8. 0)/1024. 0 END AS max_size_in_mb FROM dataspace.

نظارت بر گزارش تراکنش ها و تنظیم یک خط مشی پشتیبان گیری مناسب برای پایگاه های داده شما، کلید دوام سیستم شما است.