چرخهٔ عمر یک خطا: از گزارش کاربر تا رفع در اسپرینت
یک خطای واقعی را از مرورگر کاربر تا لاگ بکاند، دیتابیس، سرور و تابلوی تیم دنبال میکنیم و میبینیم در هر لایه کجا را باید نگاه کرد.
لایهٔ پایگاه داده · DBMug
هر دقیقه SQL Server را میخواند — لاگ پرشده، دیسک در حال تمام شدن، کوئری کند، بکاپ عقبافتاده — و به جای صد نمودار یک جمله پیامک میکند. بکاپها را هم میگیرد و با بازگرداندن واقعی میآزماید.
بسیاری از خطاهایی که در لاگ بکاند دیده میشوند، ریشه در پایگاه داده دارند: کوئریای که کند شده، لاگ ترنزکشنی که پر شده یا دیسکی که دارد تمام میشود. دیبیماگ برای تیمهایی ساخته شده که DBA تماموقت ندارند و باید پیش از کاربر خبردار شوند.
روی دیتابیس شما هیچ چیزی نصب نمیشود — نه اسمبلی، نه تریگر، نه جاب. حساب پایش sysadmin نیست، به xp_cmdshell نیاز ندارد و فقط میخواند.
CPU، حافظه، طول عمر صفحهها، انتظارها، تراکنشها و اتصالها، همه با تاریخچه.
هر مشکل شناسهٔ یکتا دارد؛ دورهٔ سکوت، نردبان اطلاعرسانی و سقف روزانه.
فول، دیفرنشیال و لاگ در پنجرهٔ کمباری با فشردهسازی و سیاست نگهداری.
بکاپ دورهای در دیتابیس موقت برگردانده و CHECKDB میشود. بکاپی که آزموده نشده، بکاپ نیست.
کوئری کند، ایندکس گمشده یا بیاستفاده و آمار قدیمی — با شاهد و اسکریپت آماده.
از روند رشد فایلها، روزِ پر شدن دیسک تخمین زده میشود.
در خانوادهٔ ماگ
وقتی ریشهٔ خطای بکاند یک timeout یا کوئری کند است، دیبیماگ میگوید در همان دقیقه در SQL Server چه میگذشت: انتظارها، لاگ ترنزکشن، ایندکس گمشده.
دیسکی که پر میشود یا سرویسی که بیصدا متوقف شده، از لایهٔ دیتابیس به لایهٔ ماشین میرسد؛ سرورماگ سلامت و امنیت خود سرور را نگه میدارد.
روی سرور ما با یک هفتهٔ رایگان، یا نصب اختصاصی روی سرور خودتان با پروانهٔ آفلاین.
بر اساس تعداد نمونهٔ SQL Server، مدل استقرار و دامنهٔ کار؛ هفتهٔ اول رایگان و کامل. پرداخت ریالی.
جزئیات در سایت دیبیماگهیچ چیز. دیبیماگ با یک حساب SQL با کمترین دسترسی وصل میشود و فقط از DMVها میخواند.
SQL Server 2016 به بالا، از Express تا Enterprise. سازگاری پیش از ثبت هر سرور بررسی میشود.
کافی است پورت SQL فقط برای آدرس IP دیبیماگ باز شود؛ اگر این هم ممکن نیست، نصب اختصاصی بی هیچ پورت بازی همان کار را میکند.
از بلاگ
یک خطای واقعی را از مرورگر کاربر تا لاگ بکاند، دیتابیس، سرور و تابلوی تیم دنبال میکنیم و میبینیم در هر لایه کجا را باید نگاه کرد.
خطای ۹۰۰۲ یعنی لاگ ترنزکشن جا ندارد. پیش از shrink کردن، باید فهمید چه چیزی جلوی استفادهٔ دوباره از لاگ را گرفته است.
بکاپ گرفتن نیمی از کار است. اینکه فایل بکاپ واقعاً برمیگردد و دیتابیس سالم بالا میآید را فقط با بازگرداندن واقعی و DBCC CHECKDB میشود فهمید.
در جلسهٔ دمو، روی سامانهٔ خودتان نشانش میدهیم و قیمت دقیق را میگوییم.