מה זה גודל סקטור פיזי, ולמה זה קריטי לעבודה עם Cabinet Vision ו-SQL?

כל הנתונים ב-Cabinet Vision – ספריות, פרויקטים, הגדרות ושרטוטים – נשמרים בבסיס נתונים של Microsoft SQL Server. לכן, אם ה-SQL לא עובד כמו שצריך, גם Cabinet Vision מתחילה לקרטע, לקפוא או לא לטעון פרויקטים. אחת הסיבות השקטות והקריטיות ביותר לכך היא גודל הסקטור הפיזי של הדיסק.

מה זה סקטור פיזי?

הדיסק הוא כמו מחברת ענקית המחולקת לדפים קטנים; כל דף הוא סקטור – היחידה הקטנה ביותר שאפשר לכתוב אליה או לקרוא ממנה. בעבר כל סקטור היה בגודל 512 בייט. היום, במיוחד עם כונני SSD ו-NVMe, יצרנים רבים עברו לסקטורים גדולים יותר – 4K (4096 בייט), ולעיתים אף יותר מכך.

למה זה משנה ל-SQL (ול-Cabinet Vision)?

SQL Server עובד עם עמודי נתונים (Pages) בגודל קבוע של 8KB, וכותב ליחידות מיושרות לסקטור. כשגודל הסקטור אינו תואם למה ש-SQL Server תומך בו, הכתיבה אינה יכולה להתבצע באופן אטומי – ובמקרה של הפסקת חשמל באמצע פעולה, חלק מהמידע עלול להיכתב והשאר ללכת לאיבוד, מה שעלול להוביל לשחיתות בבסיס הנתונים.

הגבול המדויק — מה נתמך ומה לא

• SQL Server תומך בגודלי סקטור פיזי של 512 בייט ושל 4KB (4096 בייט) – כולל כונני 4Kn וכונני 512e.
• הבעיה מתחילה בדיסקים המדווחים על סקטור פיזי גדול מ-4KB (למשל 8K או 16K) – תצורה שאינה נתמכת באף גרסה מתועדת של SQL Server, ועלולה למנוע ממנו לעלות כראוי (שגיאות מתועדות כמו 5178 ו-5179), בעיקר סביב קובץ הלוג ובזמן ההתקנה עצמה.
• כלומר: 512n, 512e ו-4Kn – כולם תקינים. מה שצריך להימנע ממנו הוא דיסק שמדווח על סקטור פיזי מעל 4KB.

איך בודקים בפועל

כדי לבדוק בפועל מהו גודל הסקטור הפיזי של הדיסק ב-Windows, הריצו כמנהל (Administrator) את הפקודה שבתיבה למטה. בפלט יש לבדוק את השדות PhysicalBytesPerSectorForAtomicity ו-PhysicalBytesPerSectorForPerformance – כאשר הם שונים זה מזה, הערך הקובע הוא הגדול מביניהם. ערך של 4096 מציין סקטור פיזי של 4K, שהוא הגבול הנתמך העליון.

fsutil fsinfo sectorinfo C:

למה היצרנים לא מציינים את זה?

רוב יצרני הדיסקים אינם מציינים את גודל הסקטור הפיזי במפרט הרשמי, וגם כלי הניהול הרגילים של Windows לא תמיד חושפים אותו בבירור. כך קורה שמשתמשים רוכשים כונן NVMe חדש ומהיר, ומגלים רק בדיעבד ש-SQL Server – ואיתו Cabinet Vision – לא מסתדרים איתו.

זה עבד ב-Windows 10 — ואז נשבר אחרי השדרוג ל-Windows 11

יש גרסה ספציפית של הבעיה הזו שכדאי להתייחס אליה בנפרד, כי היא נפוצה מספיק שהתיעוד הרשמי לפתרון בעיות של מיקרוסופט מתאר אותה במפורש: מחשב שהריץ את Cabinet Vision ואת SQL Server בלי שום בעיה על Windows 10, ואז התחיל להיכשל בהעלאת SQL Server – בלי שום שינוי בחומרה – מיד לאחר שדרוג מערכת ההפעלה ל-Windows 11. יומן השגיאות של SQL Server במחשבים כאלה מציג בדרך כלל שורות כמו "There have been 256 misaligned log IOs which required falling back to synchronous IO", או תקלת יישום (application fault) בקובץ ntdll.dll בזמן ההפעלה. בפועל, הסימן הראשון שרוב המשתמשים בכלל רואים הוא לא שורה ביומן ה-SQL, אלא הודעת שגיאה גנרית של Windows עצמו: שגיאה 1067 – "התהליך הסתיים באופן בלתי צפוי" – בזמן ניסיון להפעיל את השירות (בין אם דרך services.msc ובין אם עם הפקודה net start), כולל על מופעים בעלי שם (named instances) כמו אלה שמתקין Cabinet Vision. שגיאה 1067 היא הודעה גנרית של Service Control Manager של Windows, וכשלעצמה היא לא מסבירה דבר – הסיבה האמיתית נמצאת דווקא בשורות שצוינו למעלה, ביומן השגיאות של SQL Server עצמו.

הסיבה אינה דיסק שונה או פחות טוב – אלא שינוי באופן שבו Windows 11 מדווח עליו. תחת Windows 10, מנהל ההתקן של NVMe העביר לתוכנות ערך מדומה, "תואם", של גודל סקטור פיזי – לרוב 4096 בייט, ולעיתים אף 512 – גם כאשר הבקר של הכונן עצמו עבד באופן טבעי בגודל גדול יותר מתחת לפני השטח. מנהל ההתקן המעודכן של Windows 11 מדווח במקום זאת על גודל הסקטור שהוא קורא ישירות מההתקן. שום דבר בכונן לא משתנה בשדרוג הזה – רק האופן שבו Windows מתאר אותו. הריצו את אותה בדיקת fsutil fsinfo sectorinfo שתוארה למעלה והשוו: בדוגמה המתועדת של מיקרוסופט עצמה הערך קופץ מ-4096 ב-Windows 10 ל-16384 ב-Windows 11 עבור אותו כונן בדיוק, וראינו בשטח גם ערכים גבוהים כמו 65536 (64K) על חומרה אחרת – ראו את המקרה המאומת בהמשך. אם המספר השתנה רק אחרי השדרוג ל-Windows 11 והדיסק עצמו לא הוחלף, זהו סימן חזק לכך שמדובר בשינוי דיווח ולא בדיסק שבאמת לא תואם – ובמקרים כאלה בדרך כלל אפשר לתקן את זה.

האם אפשר לשנות?

גודל הסקטור הפיזי נקבע ברמת הבקר או הקושחה של הדיסק, ואינו הגדרה שמשנים בקלות דרך תוכנה. עם זאת, בדיוק עבור סוג כזה של פער בדיווח, מיקרוסופט מתעדת פתרון אמיתי ונתמך: ערך רישום בשם ForcedPhysicalSectorSizeInBytes, שמתווסף תחת המפתח של מנהל ההתקן של האחסון עצמו, ומאלץ את Windows לדווח לתוכנה על סקטור של 4K במקום הערך הגדול יותר שמנהל ההתקן קרא מההתקן. הפעולה הזו לא מפרמטת מחדש את הכונן, לא מחלקת אותו מחדש למחיצות ולא נוגעת בשום קובץ בסיס נתונים – השינוי כולו נמצא באופן שבו מנהל ההתקן מדווח על עצמו לתוכנה, ומשחזר בדיוק את ההתנהגות שהייתה קיימת תחת Windows 10 עבור אותה חומרה. הפקודה המדויקת מופיעה למטה. בחלק מכונני ה-NVMe קיימת גם אפשרות לפרמט מחדש את ה-namespace לפורמט LBA אחר בעזרת כלי היצרן – פעולה הרסנית שמוחקת את כל הנתונים בכונן. כלומר: לא מדובר במתג תוכנה יומיומי, אבל יש פתרונות אמיתיים ומתועדים.

REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device" /v "ForcedPhysicalSectorSizeInBytes" /t REG_MULTI_SZ /d "* 4095" /f

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

REG QUERY "HKLM\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device" /v "ForcedPhysicalSectorSizeInBytes"

shutdown /r /t 0

לאחר שהמחשב חזר לפעול, אל תסתפקו בהנחה – הריצו שוב את אותה בדיקת סקטור שתוארה למעלה, וודאו ששני הערכים כעת עומדים על 4096 או פחות. רק אז יש להפעיל את שירות ה-SQL Server. התקנות של Cabinet Vision בדרך כלל רצות על מופע בעל שם (named instance), ומופעים כאלה מופעלים עם הקידומת MSSQL$ ולאחריה שם המופע – יש להחליף את INSTANCENAME למטה בשם המופע בהתקנה שלכם.

fsutil fsinfo sectorinfo C:

net start MSSQL$INSTANCENAME

מקרה אמיתי מהשטח, שאומת

כך נראה כל זה בפועל, במקרה אחד שנפתר: כונן WD Green SN3000 בנפח 1TB, שדיווח על גודל סקטור לוגי (Logical Sector Size) של 512 בייט אך גודל סקטור פיזי (Physical Sector Size) של 65536 בייט (64K) תחת Windows 11 – פי שש-עשרה מהגבול הנתמך על ידי SQL Server. שירות ה-SQL Server של מופע בעל שם של Cabinet Vision 2025, MSSQL$CV25, סירב לעלות וקרס עם שגיאת Windows הגנרית 1067, "התהליך הסתיים באופן בלתי צפוי". אותו מופע, על אותו מחשב פיזי בדיוק, רץ בלי שום בעיה תחת Windows 10 – שום דבר בחומרה לא השתנה. לאחר אימות הפער בעזרת fsutil fsinfo sectorinfo, החלת תיקון הרישום ForcedPhysicalSectorSizeInBytes שתואר למעלה, והפעלה מחדש – השירות עלה בצורה נקייה והמופע חזר לפעול. זה לא תיקון תיאורטי – זהו תיקון שאומת בשטח.

כלי חינמי לאבחון ותיקון

מעדיפים לא להריץ את כל הבדיקות והפקודות האלה ידנית? ארזנו את אותה לוגיקת אבחון ותיקון שתוארה למעלה לתוך כלי קטן ל-Windows: כלי PowerShell שמתעלה להרשאות מנהל (Administrator) באופן אוטומטי, פועל על Windows 10 ו-11, ובנוי מארבע לשוניות. הלשונית Disks מציגה את כל הכוננים במחשב עם גודל הסקטור הלוגי והפיזי שלהם, סוג הבאס (bus type) והמצב הבריאותי, ומסמנת כל ערך מעל 4096 בייט כלא-נתמך עבור SQL. הלשונית SQL Services מציגה את MSSQLSERVER ואת כל המופעים בעלי שם (MSSQL$) עם מצבם, מצב ההפעלה והחשבון שלהם, ומאפשרת להפעיל או לעצור את המופע הנבחר. הלשונית Registry Fix מציגה את הערך הנוכחי של ForcedPhysicalSectorSizeInBytes, מאפשרת להחיל או להסיר אותו, ואף להפעיל מחדש את Windows ישירות מהכלי. הלשונית SQL Error Logs מאתרת את קובץ ה-ERRORLOG הרלוונטי ומציגה את סופו. באנר סטטוס צבעוני מסכם את המצב במבט אחד, וכל הרצה נרשמת ביומן תחת C:\ProgramData\SQLSectorFixTool.

איך לבחור דיסק שמתאים

• העדיפו כונן שמדווח על סקטור פיזי של 512e או 4Kn.
• בדקו את גודל הסקטור הפיזי לפני רכישה או פריסה, במיוחד בכונני NVMe חדשים ומהירים.
• בשרת שמריץ Cabinet Vision, אל תניחו שכונן מהיר יותר הוא בהכרח תואם – בדקו.

לסיכום

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