למה VPN מהיר עדיין מאט אישור SQL סינכרוני

פתחו הפעלת שאילתה על הראשי וראו למה ממתינה כתיבה פשוטה. אם מסד הנתונים שייך לקבוצת זמינות עם אישור סינכרוני והמשני מחובר, חלק מההמתנה הזו יוצא מהבניין: רשומות היומן נוסעות לעותק, מוקשחות שם, והידיעה על ההקשחה חוזרת לפני שהאישור מסתיים. רוחב הפס אינו מקצר את הנסיעה הלוך ושוב. המעבר שלהלן עוקב אחר האישור מהמסך לדיסק המרוחק ובחזרה.

התחילו מסוג ההמתנה בראשי

כתיבה שממתינה בעותק המרוחק מופיעה כהמתנה הקשורה ליומן ולא כהמתנה של מעבד או נעילה, ומשך העסקה עוקב אחר הנסיעה הלוך ושוב במקום אחר מספר השורות. אישורים קטנים רבים מבהירים זאת, כי כל אחד משלם את הנסיעה בנפרד. פעולה גורפת אחת מסתירה את אותה עלות בתוך אישור ארוך יותר.

מיין את עומס העבודה לפי תדירות האישורים לפני שתסיק משהו על הקישור.

קרא את מצב העותק לפני שתקרא את הרשת. המונים החשובים הם תור השליחה, תור ה-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;

קחו את התצלום הזה לפני ואחרי כתיבה מייצגת ולא פעם אחת אחר צהריים שקט. ההפרש הוא מה שאומר לכם איזה תור זז בזמן שהאישור המתין.

מדדו את המסלול, לא את הקישור

מבחן תפוקה מודד קיבולת בין שתי נקודות שאינן העותקים שלכם, תחת עומס שאינו העבודה שלכם. בקשו מבעל הרשת השהיה ואובדן לאורך מסלול העותק האמיתי בזמן שתעבורה אמיתית זורמת, בשני הכיוונים. אובדן חשוב כאן יותר מקיבולת, כי קטע שאבד עולה שליחה חוזרת וכל אישור ממתין לאישור אחד. קישור שנראה מצוין במבחן הורדה יכול עדיין להתאים באופן גרוע לתבנית אישורים פטפטנית.

שמרו על אבטחת התעבורה של מסד הנתונים ובקרות הגישה שלמות בזמן המדידה. מדידת מסלול אינה סיבה לעקוף אותן.

תאמו את הזמנים עם המונים ולא עם האינטואיציה. אם תור השליחה נשאר ריק והאישור עדיין ממתין, העיכוב באישור או בריקון של המשני. אם תור השליחה גדל בהתמדה, התעבורה או הקיבולת הם המגבלה. רשמו איזו תצפית תמכה במסקנה כדי שהאדם הבא יוכל לחזור על המדידה ולא על הוויכוח.

מה מצב א-סינכרוני באמת משנה

אישור א-סינכרוני מסיר את ההמתנה לאישור ההקשחה של המשני, ולכן כתיבות נהיות מהירות יותר ולכן עמדת העמידות שלכם משתנה. הראשי מאשר את העסקה בלי האישור המרוחק. אז מותר למשני לפגר, והפיגור הזה הוא החשיפה.

אם הראשי אובד לפני שהיומן מגיע ליעד מעבר כושל שמיש, כפיית השירות על העותק הזה משליכה עסקאות שכבר נמסר ליישום שאושרו.

זו החלטת נקודת שחזור והיא שייכת לבעל מסד הנתונים, לא לסקירת ביצועים. קבעו תחילה את חלון אובדן הנתונים הנסבל, בחרו את המצב שמספק אותו, ואז בצעו אופטימיזציה בתוך הגבול הזה. אפשרויות ששומרות על הגנה סינכרונית כוללות הסרת נסיעות אישור מיותרות היכן שהיישום מאפשר, תיקון צוואר בקבוק מדוד בתעבורה או באחסון, והעברת העותק כך שהאישור יעבור פחות מרחק. שקלו אותן מול דרישת העמידות שאיתה התחלתם, שלא השתנתה.