چرا VPN سریع همچنان تثبیت همگام SQL را کند می‌کند
تثبیت با یک نسخهٔ همگام از ساختمان خارج می‌شود. از نوع انتظار تا صف‌های ارسال و redo را دنبال کنید و سپس تصمیم بگیرید که آیا حالت ناهمگام معاملهٔ درستی است.
یک نشست پرس‌وجو روی سرور اصلی باز کنید و ببینید یک نوشتن ساده منتظر چه چیزی است. اگر پایگاه داده عضو یک گروه دسترس‌پذیری با تثبیت همگام باشد و نسخهٔ ثانویه متصل باشد، بخشی از این انتظار از ساختمان خارج می‌شود: رکوردهای گزارش به نسخه سفر می‌کنند، آنجا سخت‌سازی می‌شوند، و خبر این سخت‌سازی پیش از پایان تثبیت بازمی‌گردد. پهنای باند این رفت‌وبرگشت را کوتاه نمی‌کند. مسیر زیر تأیید را از صفحه تا دیسک راه‌دور و بازگشت دنبال می‌کند.
از نوع انتظار روی سرور اصلی شروع کنید
نوشتنی که روی نسخهٔ راه‌دور منتظر است به‌صورت انتظاری مرتبط با گزارش دیده می‌شود، نه انتظار پردازنده یا قفل، و مدت تراکنش رفت‌وبرگشت را دنبال می‌کند نه تعداد سطرها. تثبیت‌های کوچک فراوان این را آشکار می‌کنند، چون هر یک مسیر را جداگانه می‌پردازد. یک عملیات انبوه یگانه همان هزینه را درون یک تأیید طولانی‌تر پنهان می‌کند.
پیش از هر نتیجه‌گیری دربارهٔ پیوند، بار کاری خود را بر اساس بسامد تثبیت مرتب کنید.
پیش از خواندن شبکه، وضعیت نسخه را بخوانید. شمارنده‌های مهم صف ارسال، صف redo و وضعیت همگام‌سازی هستند و با هم نشان می‌دهند آیا ثانویه همگام می‌ماند یا عقب می‌افتد. صف ارسال روبه‌رشد به انتقال اشاره دارد، در حالی که صف redo روبه‌رشد به کار یا ذخیره‌سازی خود ثانویه اشاره می‌کند. این‌ها تعمیرهای متفاوتی هستند و هیچ‌کدام با افزودن پهنای باند بهتر نمی‌شود.
تأیید را تا ثانویه دنبال کنید
در تثبیت همگام، سرور اصلی پیش از اعلام پایان تثبیت منتظر تأییدی است که گزارش مربوطه روی ثانویه سخت‌سازی شده است. سخت‌سازی یعنی پایدار در گزارش، نه بازپخش‌شده در صفحه‌های داده. همین تمایز توضیح می‌دهد چرا یک ثانویهٔ همگام می‌تواند در redo عقب باشد و در همان حال سخت‌سازی را تأیید کند.
مسیر را به ترتیب طی کنید و هر مرحله را جداگانه زمان بگیرید، نه کل را. رکوردهای گزارش از انتقال عبور می‌کنند، ثانویه آن‌ها را می‌نویسد و تخلیه می‌کند، و تأیید از همان مسیر بازمی‌گردد. تأخیر انتقال، زمان‌بندی ثانویه و تأخیر دیسک گزارش ثانویه همه در مجموع می‌نشینند و تنها اولی به مالک شبکه تعلق دارد. ثانویه‌ای که حجم گزارشش با چیز دیگری اشباع شده می‌تواند هر تثبیت را کشیده کند، در حالی که پیوند بیکار است.
SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
drs.log_send_queue_size, drs.redo_queue_size
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;آن عکس فوری را پیش و پس از یک نوشتن نمونه بگیرید، نه یک بار در یک بعدازظهر آرام. تفاوت همان چیزی است که می‌گوید کدام صف در حین انتظار تثبیت جابه‌جا شد.
مسیر را بسنجید، نه پیوند را
یک آزمون توان‌دهی ظرفیت میان دو نقطه را می‌سنجد که نسخه‌های شما نیستند، زیر باری که بار کاری شما نیست. از مالک شبکه تأخیر و افت را در طول مسیر واقعی نسخه، در حالی که ترافیک واقعی جریان دارد، در هر دو جهت بخواهید. افت اینجا از ظرفیت مهم‌تر است، چون یک قطعهٔ گم‌شده هزینهٔ ارسال دوباره دارد و هر تثبیت منتظر یک تأیید است. پیوندی که در آزمون دانلود عالی به نظر می‌رسد می‌تواند برای الگوی پرسروصدای تثبیت نامناسب باشد.
امنیت انتقال پایگاه داده و کنترل‌های دسترسی را هنگام سنجش دست‌نخورده نگه دارید. سنجش یک مسیر هرگز دلیلی برای دور زدن آن‌ها نیست.
زمان‌ها را با شمارنده‌ها همبسته کنید، نه با شهود. اگر صف ارسال خالی بماند و تثبیت همچنان منتظر باشد، تأخیر در تأیید یا در تخلیهٔ ثانویه است. اگر صف ارسال پیوسته رشد کند، انتقال یا ظرفیت محدودیت است. ثبت کنید کدام مشاهده نتیجه را پشتیبانی کرد تا نفر بعدی سنجش را تکرار کند نه بحث را.
حالت ناهمگام واقعاً چه چیزی را تغییر می‌دهد
تثبیت ناهمگام انتظار برای تأیید سخت‌سازی ثانویه را برمی‌دارد، و به همین دلیل نوشتن‌ها سریع‌تر می‌شوند و به همین دلیل جایگاه پایداری شما تغییر می‌کند. سرور اصلی تراکنش را بدون آن تأیید راه‌دور تأیید می‌کند. سپس به ثانویه اجازه داده می‌شود عقب بماند، و همین عقب‌ماندگی همان در معرض بودن است.
اگر سرور اصلی پیش از رسیدن گزارش به یک هدف انتقال خطای قابل استفاده از دست برود، تحمیل سرویس روی آن نسخه تراکنش‌هایی را دور می‌ریزد که برنامه پیش‌تر به آن‌ها گفته شده بود تثبیت شده‌اند.
این تصمیمی دربارهٔ نقطهٔ بازیابی است و به مالک پایگاه داده تعلق دارد، نه به بازبینی کارایی. نخست پنجرهٔ تحمل‌شدهٔ از دست رفتن داده را تعیین کنید، حالتی را که آن را برآورده می‌کند برگزینید، و سپس درون همان مرز بهینه‌سازی کنید. گزینه‌هایی که حفاظت همگام را نگه می‌دارند شامل حذف رفت‌وبرگشت‌های اجتناب‌پذیر تثبیت در جایی که برنامه اجازه می‌دهد، رفع یک گلوگاه سنجیده‌شده در انتقال یا ذخیره‌سازی، و جابه‌جایی نسخه تا تأیید مسافت کمتری طی کند است. آن‌ها را با نیاز پایداری که با آن آغاز کردید و تغییر نکرده است بسنجید.