לאחר החלת תיקון חם זה, עליך להפוך את דגל המעקב 1800 לזמין כפלמטר אתחול בכל השרתים או העותקים המשוכפלים בעלי גודל סקטור פיזי של 512 בתים ולהפעיל אותם מחדש, כדי לגרום לתיקון חם זה לפעול כראוי.
תופעות
שקול את התרחיש הבא:
-
הפוך את התכונה 'קבוצות זמינות AlwaysOn' או 'יומני רישום' לזמינה ב- Microsoft SQL Server.
-
בדיסקים המאחסנים את קבצי יומן הרישום של העותק המשוכפל הראשי והמשוכפל המשני בקבוצת זמינות AlwaysOn (AG) יש גדלים שונים של סקטור. לחלופין, בסביבות משלוח יומני רישום, הדיסקים שאחסון קבצי יומן הרישום עבור Logshipping primary servers and Logshipping secondary servers have different sector sizes. לדוגמה:
-
קובץ יומן הרישום הראשי של העותק המשוכפל ממוקם בדיסק בעל גודל סקטור של 512 בתים. עם זאת, קובץ יומן הרישום המשני של העותק המשוכפל ממוקם בדיסק בגודל הסקטור של 4 קילו-בתים (KB).
-
קובץ יומן הרישום הראשי של העותק המשוכפל ממוקם במערכת מקומית מקומית בעלת גודל סקטור של 512 בתים. עם זאת, העותק המשוכפל המשני ממוקם בדיסק אחסון של Windows Azure בגודל הסקטור של 4 קילו-בתים (KB).
-
בתרחיש זה, הודעת השגיאה הבאה נרשמת ביומן SQL Server שגיאות. הודעת השגיאה עשויה להימשך זמן מה לאחר ההפעלה מחדש אם היו יומני רישום שלא הוחלו על משניים לפני הפעלה מחדש של השרת.
היו X הודעות IOs לא מיושנות של יומן רישום שידרשו לחזור ל- IO סינכרוני. ה- IO הנוכחי נמצא בקובץ ....
בנוסף, סינכרון משלוחים מסוג AG או Logs פועל לאט מאוד עקב מערכת ההפעלה/I/Os הסינכרוני. אם העותק המשוכפל המשני נמצא באחסון של Windows Azure, נדרש זמן רב מהצפוי כדי לסיים את תהליך הסינכרון.
הערה בעיה זו מתרחשת כאשר אתה משתמש הן בכוננים החדשים בעלי גודל סקטור של 4-KB והן בכוננים הישנים בעלי גודל סקטור של 512 בתים. לקבלת מידע נוסף אודות הכוננים החדשים, ראה SQL Server - כוננים חדשים השתמש בגודל סקטור 4K ובגודל SQL Server-אחסון/VHDx ובגודל סקטור 4K.
פתרון
הבעיה תוקנה תחילה בעדכון המצטבר הבא של SQL Server.
עדכון מצטבר 5 עבור SQL Server 2014 /en-us/help/3011055
עדכון מצטבר 3 עבור SQL Server 2012 SP2 /en-us/help/3002049
עדכון מצטבר 13 עבור SQL Server 2012 SP1 /en-us/help/3002044
לאחר החלת התיקון החם ותאפשר דגל מעקב 1800 כפרמטר אתחול בכל העותקים המשוכפלים של השרתים הפועלים בדיסק בעל גודל סקטור של 512 בתים, אתה מבחין גידול קטן בגודל של הקבצים הבאים:
-
קובץ יומן רישום של טרנזקציות
-
רשום גיבויים
בנוסף, אתה מבחין כי ההודעות הבאות נרשמות ביומן SQL Server שגיאות של השרת הראשי:
זנב יומן הרישום עבור מסד הנתונים '<מסד נתונים> ' מוכתב כדי להתאים לגודל הסקטור החדש של 4096 בתים
זוהי הודעת מידע שניתן להתעלם ממנה בבטחה.
כל עדכון מצטבר חדש עבור SQL Server מכיל את כל התיקונים החמים ואת כל תיקוני האבטחה שנכללו בעדכון המצטבר הקודם. עיין בעדכונים המצטברים האחרונים עבור SQL Server:
פתרון
כדי לעקוף בעיה זו, העבר את קובץ יומן הטרנזקציות ביעד לכונן שבו מוגדרים בתים למגזר הפיזי כ- 512 בתים.
מצב
Microsoft אישרה כי זוהי בעיה במוצרי Microsoft המפורטים בסעיף "חל על".
מידע נוסף
כשם עבודה מומלצת, נסה לוודא שכל הדיסקים בכל העותקים המשוכפלים (לפחות כל הדיסקים שמארחים קבצי יומן רישום) הם בעלי גודל סקטור זהה. בסביבות מעורבות, כאשר למגזר המשני יש מגזר פיזי של 512 בתים, ולמפתח הראשי יש גודל סקטור של 4 KB, יש להשתמש ב- TF 1800 כסגל אתחול בכל השרתים או העותקים המשוכפלים בעלי גודל סקטור פיזי של 512 בתים והפעלה מחדש. פעולה זו מבטיחה שתבנית יצירת יומן הרישום המתמשך משתמשת בגודל סקטור של 4 KB.
לקבלת מידע נוסף על האופן SQL Server עם גדלים גדולים יותר של סקטורים, עיין בפרסום הבא בבלוג התמיכה:
SQL Server–שטחי אחסון/VHDx וגודל סקטור
4K
באפשרותך להשתמש בכלי השירות של שורת הפקודה Fsutil כדי לקבוע את הערך Bytes per Physical Sector. אם פרמטר זה אינו גלוי בפלט, עליך להחיל את התיקון החם שצוין במאמר KB 982018.
כדי לאמת את סוג הכונן שברשותך, בצע את הפעולות הבאות:
-
הפעל את הפקודה הבאה בשורת פקודה עם הרשאות מלאות:
Fsutil fsinfo ntfsinfo x: הערה מציין המיקום x מייצג את הכונן שאתה בודק.
-
השתמש בערכים עבור בתים לכל סקטור והבתים לכל סקטור פיזי כדי לקבוע את סוג הכונן שברשותך. לשם כך, השתמש בטבלה הבאה:
הערך "בתים לכל סקטור"
הערך "בתים למגזר הפיזי"
סוג כונן
4096
4096
4K מקורי
512
4096
תבנית מתקדמת (המכונה גם 512E)
512
512
512 בתים מקוריים
