به دلیل LOG_BACKUP، گزارش تراکنش های SQL Server را برطرف کنید

“گزارش تراکنش به دلیل LOG_BACKUP پر است” به چه معناست؟

گزارش تراکنش SQL Server به دلیل پر می شود LOG_BACKUP زمانی که SQL Server نمی تواند از فضای گزارش غیرفعال استفاده مجدد کند زیرا پایگاه داده به پشتیبان گیری از گزارش تراکنش نیاز دارد. این شرایط معمولاً بر پایگاه‌های داده‌ای که تحت آن اجرا می‌شوند تأثیر می‌گذارد کامل یا BULK_LOGGED مدل بازیابی

خطا نشان دهنده مشکل ظرفیت گزارش تراکنش پایگاه داده است، نه یک وب سایت معمولی، IIS یا خرابی JDBC. وقتی فایل گزارش به حد مجاز خود برسد، ممکن است SQL Server پذیرش به‌روزرسانی‌ها را متوقف کند، حتی اگر پایگاه داده و Windows Server آنلاین باشند. مایکروسافت این شرایط را به عنوان SQL Server Error 9002 شناسایی می کند.

چگونه SQL Server از گزارش تراکنش استفاده می کند؟

هر پایگاه داده SQL Server یک گزارش تراکنش دارد که تغییرات پایگاه داده را ثبت می کند و از بازیابی از خرابی ها پشتیبانی می کند. SQL Server از این فایل log برای برگرداندن تراکنش های ناتمام به حالت ثابت پس از خرابی یا راه اندازی مجدد استفاده می کند.

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

چرا LOG_BACKUP از استفاده مجدد از گزارش تراکنش جلوگیری می کند؟

LOG_BACKUP این بدان معناست که SQL Server قبل از اینکه بتواند از فضای بیکار استفاده مجدد کند منتظر یک نسخه پشتیبان از گزارش تراکنش است. این شرایط معمولاً زمانی اتفاق می‌افتد که پایگاه داده از مدل بازیابی FULL یا BULK_LOGGED بدون برنامه‌ریزی پشتیبان گزارش عملکردی استفاده می‌کند.

در مدل بازیابی FULL، SQL Server به ثبت تراکنش‌ها ادامه می‌دهد، اما پشتیبان‌گیری‌های معمول اجازه می‌دهند تا قسمت‌های غیرفعال قدیمی‌تر گزارش تراکنش دوباره مورد استفاده قرار گیرند. بدون این پشتیبان‌گیری‌ها، فایل لاگ فیزیکی می‌تواند به رشد خود ادامه دهد تا زمانی که به محدودیت پیکربندی‌شده خود برسد یا فضای دیسک اولیه تمام شود.

چرا خطای SQL Server 9002 رخ می دهد؟

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

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

چگونه می توانید تأیید کنید که LOG_BACKUP علت واقعی است؟

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

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

چگونه باید مدل بازیابی پایگاه داده را بررسی کنید؟

مدل بازیابی پایگاه داده تعیین می کند که آیا SQL Server به پشتیبان گیری از گزارش تراکنش نیاز دارد یا خیر و اینکه پایگاه داده چه قابلیت های بازیابی را ارائه می دهد. SQL Server از مدل های بازیابی SIMPLE، FULL و BULK_LOGGED پشتیبانی می کند.

پایگاه داده ای که از بازیابی FULL یا BULK_LOGGED استفاده می کند، نیاز به پشتیبان گیری منظم از گزارش تراکنش دارد. پایگاه داده ای که از بازیابی SIMPLE استفاده می کند، پشتیبان گیری از گزارش تراکنش ها را حفظ نمی کند و به طور خودکار فضای قابل استفاده مجدد را به عنوان بخشی از رفتار بازیابی عادی خود بازیابی می کند.

مدیران هرگز نباید یک پایگاه داده تولید را از FULL به SIMPLE تغییر دهند تا فقط لاگ های تراکنش کامل ناپدید شوند. این تغییر در برخی مواقع بر قابلیت های بازیابی تأثیر می گذارد و می تواند استراتژی بازیابی سازمان را مختل کند.

چگونه می توانید گزارش تراکنش SQL Server را به دلیل LOG_BACKUP رفع کنید؟

تصحیح صحیح برای LOG_BACKUP این است که یک فرآیند پشتیبان گیری گزارش تراکنش را بازیابی کنید و زمانی که پایگاه داده از بازیابی FULL یا BULK_LOGGED استفاده می کند، یک نسخه پشتیبان از گزارش تراکنش ایجاد کنید. پشتیبان‌گیری موفق گزارش به SQL Server اجازه می‌دهد تا در صورت برآورده شدن شرایط لازم، فضای گزارش غیرفعال را برای استفاده مجدد آزاد کند.

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

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

چگونه باید یک نسخه پشتیبان از تراکنش های SQL Server ایجاد کنید؟

با استفاده از SQL Server Management Studio، Transact-SQL یا PowerShell می توان یک نسخه پشتیبان از گزارش تراکنش ایجاد کرد. مایکروسافت به یک مدل بازیابی مناسب نیاز دارد و خاطرنشان می‌کند که یک نسخه پشتیبان کامل از پایگاه داده باید قبل از ایجاد اولین نسخه پشتیبان گزارش تراکنش وجود داشته باشد.

برای یک محیط تولید، مدیران باید پشتیبان‌گیری از گزارش را در یک برنامه پشتیبان خودکار به جای انجام پشتیبان‌گیری دستی زمانی که ظرفیت پایگاه داده به دست می‌آید، ادغام کنند. فرکانس پشتیبان گیری باید با هدف نقطه بازیابی مورد نیاز و نرخی که بار کاری ورودی های گزارش تراکنش را ایجاد می کند مطابقت داشته باشد.

هر چند وقت یک‌بار باید از گزارش‌های تراکنش SQL Server پشتیبان‌گیری شود؟

فراوانی پشتیبان‌گیری از گزارش تراکنش باید با هدف نقطه بازیابی سازمان و نرخ تولید تراکنش مطابقت داشته باشد، نه یک بازه زمانی یکسان. مایکروسافت پشتیبان‌گیری منظم از گزارش‌ها را برای پایگاه‌های داده FULL و BULK_LOGGED توصیه می‌کند، زیرا هم از اهداف بازیابی محافظت می‌کند و هم از پر شدن غیرضروری گزارش‌های تراکنش جلوگیری می‌کند.

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

چرا فقط گزارش تراکنش SQL Server را کوچک نمی کنید؟

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

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

چه اتفاقی می افتد زمانی که شما به طور مکرر درخت را کوچک و بزرگ می کنید؟

کاهش مکرر و رشد مجدد گزارش می تواند سربار مدیریت ذخیره سازی غیر ضروری ایجاد کند و منجر به پیکربندی گزارش تراکنش ناپایدار شود. گزارش فیزیکی معمولاً باید ظرفیت کافی برای رسیدگی به افزایش حجم کار مورد انتظار بدون عملیات رشد مداوم داشته باشد.

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

چگونه مدل بازیابی بر مدیریت گزارش تراکنش تاثیر می گذارد؟

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

بازیابی BULK_LOGGED همچنین به پشتیبان‌گیری از گزارش تراکنش نیاز دارد، اما ممکن است ثبت گزارش برای برخی عملیات انبوه را کاهش دهد. با این حال، پشتیبان‌گیری‌های فایل لاگ حاوی عملیات حداقل ثبت‌شده همچنان می‌توانند بزرگ شوند، بنابراین مدیران باید ویژگی‌های بار کاری را هنگام طراحی زیرساخت پشتیبان در نظر بگیرند.

چگونه ظرفیت دیسک به ثبت کامل تراکنش های SQL Server کمک می کند؟

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

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

چگونه باید SQL Server autogrowth پیکربندی شود؟

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

افزایش رشد با اندازه ثابت اغلب رفتار قابل پیش بینی بیشتری را نسبت به افزایش درصدی کوچک برای پایگاه های داده سازمانی بزرگ ارائه می دهد، زیرا درصد افزایش می تواند با رشد پایگاه داده بسیار بزرگ شود. مایکروسافت همچنین محدودیت‌های حداکثر ثابت و غیرفعال کردن رشد خودکار را به عنوان عوامل احتمالی در شرایط ثبت کامل شناسایی کرده است.

تراکنش های طولانی مدت چگونه می توانند فایل لاگ SQL Server را پر کنند؟

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

هنگامی که علت استفاده مجدد از گزارش گزارش می شود، مدیران باید تراکنش های طولانی مدت را بررسی کنند ACTIVE_TRANSACTION به جای اینکه فرض کنیم هر گزارش کامل نتیجه از دست دادن پشتیبان است. این تمایز اهمیت دارد زیرا افزایش فرکانس پشتیبان نمی‌تواند تراکنشی را که ساعت‌ها فعال می‌ماند حل کند.

چگونه گروه‌های تکرار یا در دسترس می‌توانند باعث رشد گزارش تراکنش شوند؟

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

این سناریو به یک مسیر اصلاحی متفاوت از LOG_BACKUP. مدیران باید موارد خاص را شناسایی کنند log_reuse_wait_desc قبل از تغییر تنظیمات بازیابی یا حذف فایل های گزارش، عملکرد پایگاه داده مربوطه را ارزش گذاری و بررسی کنید.

چگونه مدیران Windows Server باید گزارش های تراکنش SQL Server را نظارت کنند؟

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

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

چه شاخص هایی نقص قریب الوقوع در گزارش تراکنش SQL Server را نشان می دهد؟

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

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

چگونه باید مانیتورینگ پشتیبان SQL Server خطاهای LOG_BACKUP را شناسایی کند؟

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

SQL Server از تاریخچه بایگانی پشتیبانی می کند msdb پایگاه داده سیستمی که منبع مهمی برای تأیید اینکه پشتیبان‌گیری از گزارش تراکنش‌ها واقعاً انجام می‌شود، فراهم می‌کند.

چرا گزارش کامل تراکنش ها بر برنامه ها و وب سایت ها تأثیر می گذارد؟

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

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

چگونه JDBC یک مشکل را در گزارش تراکنش SQL Server آشکار می کند؟

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

در سناریوی گزارش شده، پیام شناسایی می شود LOG_BACKUP به مدیریت گزارش تراکنش های SQL Server اشاره می کند، نه خرابی اتصال شبکه. بنابراین، یک بررسی مناسب در پایگاه داده SQL Server و لایه پشتیبان شروع می شود.

ارائه دهندگان هاست چگونه باید این خطا را برطرف کنند؟

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

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

وقتی مشتری این خطا را گزارش می کند، یک ارائه دهنده هاست باید چه کاری انجام دهد؟

ارائه دهنده هاست باید درمان کند LOG_BACKUP مانند یک حادثه ظرفیت ثبت تراکنش SQL Server به جای راه اندازی مجدد IIS یا برنامه. مهندس تعمیر و نگهداری باید وضعیت پایگاه داده را تأیید کند، فرآیند پشتیبان گیری گزارش مربوطه را بازیابی کند، تأیید کند که فضای گزارش قابل استفاده مجدد است و سپس مسیر تراکنش برنامه را بررسی کند.

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

چگونه می توان تعمیر و نگهداری سرور مدیریت شده از بروز خطاهای گزارش SQL Server جلوگیری کرد؟

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

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

چگونه شرکت ها باید معماری پشتیبان SQL Server را طراحی کنند؟

یک معماری پشتیبان سازمانی باید حفاظت از داده ها را از مدیریت ظرفیت ثبت تراکنش جدا کند و در عین حال یک استراتژی بازیابی ثابت را حفظ کند. پشتیبان‌گیری کامل از پایگاه داده پایه و اساس را ایجاد می‌کند، در حالی که پشتیبان‌گیری از گزارش تراکنش، زنجیره لاگ مورد نیاز برای بازیابی لحظه به لحظه را در مدل بازیابی FULL حفظ می‌کند.

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

محیط‌های SQL Server که میزبان ابر هستند چگونه باید گزارش‌های تراکنش را مدیریت کنند؟

محیط‌های SQL Server با میزبانی ابری هنوز به مدیریت گزارش تراکنش در سطح پایگاه داده نیاز دارند، حتی زمانی که سرور ویندوز زیربنایی بر روی یک پلت فرم ابری اجرا می‌شود. ظرفیت ذخیره سازی ابری به طور خودکار مشکلات مربوط به مدل بازیابی پایگاه داده یا پشتیبان گیری گزارش را حل نمی کند.

سازمان ها با استفاده از خدمات مدیریت زیرساخت ابری باید گزارش‌های تراکنش SQL Server را همراه با ذخیره‌سازی ماشین مجازی، عملکرد دیسک ابری، ذخیره‌سازی پشتیبان، اتصال به شبکه و ظرفیت محاسباتی نظارت کند. این معماری به تیم ها اجازه می دهد تا مسائل ظرفیت سطح پایگاه داده را از محدودیت های زیرساخت ابری جدا کنند.

نظارت بر AWS SQL Server باید شامل چه مواردی باشد؟

محیط های Windows SQL Server میزبان AWS باید تله متری زیرساخت ابری را با معیارهای پایگاه داده SQL Server و نظارت بر سیستم عامل ویندوز ترکیب کنند. خدمات مدیریت سرور AWS بنابراین، باید ظرفیت ذخیره سازی، عملکرد دیسک، منابع ویندوز، سلامت سرور SQL، عملیات پشتیبان گیری و در دسترس بودن برنامه را با هم کنترل کند.

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

درس های میدانی: چگونه یک شکست LOG_BACKUP می تواند یک وب سایت را خراب کند

حتی زمانی که استفاده از CPU و حافظه ویندوز کاملاً عادی باشد، ممکن است قطعی SQL Server تولید شود. یک برنامه تجاری با میزبانی ویندوز را در نظر بگیرید که در آن پایگاه داده SQL Server از بازیابی FULL استفاده می کند و معمولاً در طول یک روز کاری تقریباً 8 گیگابایت ورودی گزارش تراکنش ایجاد می کند.

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

در ابتدا، برنامه به ارائه عملیات خواندن ادامه می‌دهد، زیرا SQL Server آنلاین می‌ماند، اما تراکنش‌های نوشتن در نهایت زمانی که فایل log به حد مجاز خود می‌رسد با شکست مواجه می‌شود. سپس برنامه خطای SQL Server را از طریق لایه JDBC خود در معرض دید کاربران قرار می دهد.

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

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

چگونه کسب و کارها می توانند از خطای SQL Server 9002 جلوگیری کنند؟

شرکت‌ها می‌توانند با حفظ نسخه‌های پشتیبان‌گیری منظم از گزارش تراکنش‌ها، اندازه‌گیری فایل‌های گزارش برای افزایش حجم کاری مورد انتظار، نظارت بر ظرفیت دیسک، اعتبارسنجی کارهای پشتیبان‌گیری، و بررسی شرایط وقفه استفاده مجدد از گزارش قبل از رسیدن فایل log به ظرفیت بحرانی، از خطای 9002 جلوگیری کنند. مایکروسافت این کنترل‌ها را به‌عنوان مرکزی برای جلوگیری از حوادث گزارش کامل تراکنش شناسایی می‌کند.

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

تفاوت بین log truncation و log shrinking چیست؟

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

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

ایمن ترین راه حل بلندمدت برای LOG_BACKUP چیست؟

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

تغییر مدل بازیابی ممکن است در معماری های خاص مناسب باشد، اما مدیران باید این تصمیم را بر اساس نیازمندی های بازیابی، به جای استفاده از بازیابی SIMPLE به عنوان راه حل بازگشتی، اتخاذ کنند. FULL RECOVERY زمانی که زنجیره پشتیبان لازم وجود داشته باشد، بازیابی لحظه به لحظه را فراهم می کند.

چگونه ACTSupport می تواند به جلوگیری از حوادث Windows SQL Server کمک کند؟

پشتیبانی ACTS می تواند فراهم کند خدمات مدیریت سرور 24 ساعته شامل نظارت بر زیرساخت، مدیریت ویندوز سرور، تعمیر و نگهداری SQL Server، نظارت بر پشتیبان گیری، عیب یابی عملکرد، مدیریت امنیت، و پاسخ به حوادث.

سازمان هایی که نیاز به پوشش عملیاتی مستمر دارند می توانند استفاده کنند خدمات مدیریت سرور از راه دور تیم داخلی IT خود را با نظارت و عیب یابی فعال تقویت کنند. ACTSupport همچنین می‌تواند از محیط‌های ترکیبی پشتیبانی کند که در آن سرورهای ویندوز، سیستم‌های لینوکس، زیرساخت‌های ابری، پایگاه‌های داده و سرویس‌های کاربردی با هم کار می‌کنند.