none
מה צריך לעשות בשרתי SQL כדי להזיז את השעון לשעון חורף ב-27.10? RRS feed

  • שאלה

  • שלום

    מה צריך לעשות בשרתי SQL כדי להכין אותם לשעון חורף ב-27.10?

    איך לוודא שהשרת לא ינזק הזמן שהשעון עובר אחורה?

    האם כדאי להוריד אותו?

    רוני


    Ronnie Godfrey

    יום רביעי 09 אוקטובר 2013 11:08

תשובות

  • הי,

    בשרתי SQL תוודא שישנו גיבוי על של בסיסי הנתונים.

    ה-SQL לוקח את ה-DST'Offset וכו' מתוך מערכת ההפעלה ולכן אתה צריך לוודא שישנו עדכון KB2863058 ולאחר מכן אתחול השרת.

    תוכל להיעזר במאמר הבא, http://beta.blogs.microsoft.co.il/blogs/eshlomo9/archive/2013/08/14/2404008.aspx

    אלי.


    Email:eshlomo9@hotmail.com;Twitter:https://twitter.com/EliShlomo1

    • סומן כתשובה על-ידי R1G2 שבת 12 אוקטובר 2013 19:43
    יום רביעי 09 אוקטובר 2013 11:19
  • בכיף רוני :-)

    אבל יש עוד דיי הרבה נקודות שצריך לקחת בחשבון. למעשה המאמר שם דגש על עבודת ה IT (והוא טוב מאוד בפני עצמו), וכמו כן דן מעט באפליקציות של מייקרוסופט אם כי כאמור לא דן בשרתי מסדי נתונים בכלל. אבל יותר מכך באופן טיבעי הוא לא דן בכלל בכל ההשלכות המישניות. נחמד שמייקרוסופט כיסו את הנושא עם תוכנת ה שרת המייל שלהם לדוגמה, אבל מה אם אתה עובד עם תוכנת שרת מייל שאתה פיתחת (או כל צד שלישי אחר) והתוכנה מושפעת באופן טיבעי מההשלכות של השינוי במערכת ההפעלה? מה לגבי כל אפליקצהי אחרת בפיתוח שלכם או של צד שלישי, האם כיסתם את כל הנקודות החשובות? מייקרוסופט לא יכולים לכסות עבורינו את הנקודות הנ"ל :-)

    צריך להקפיד לבחון תאימות של המערכות שלכם ולצפות לתופעות מוזרות :-)

    הנה עוד דוגמה למקור ענק של בעיות:

    כל עבודה עם טור מסוג time או datetime הוא פוטניאל לבעיה:-)

    * כל ניתוח זמנים שמבוססת על הפרש זמנים הכולל את הזמן החסר (במעבר לקיץ) או הכפול (במעבר לחורף) יוביל לחישובים לא נכונים במערכות שלא בוצע בהם עדכון מתאים. רוב האפליקציות שלנו ועל אחת כמה וכמה כל SP שאנחנו כותבים, כל דוח SSRS וכו, עובדים בניתוק מעדכוני מערכת ההפעלה,  ואין להן בכלל עדכונים שוטפים. לשם הדוגמה, תחשבו על מערכת שכר שמחשבת את זמן העבודה לפי כרטיס נוכחות. כל עובד שנכנס לפני שעה 02:00 ויצא אחרי שעה שעה 02:00 עבד למעשה את השעה הכפולה אבל בחישובים שלנו הוא יפסיד משכורת של שעה אחת, אם המערכת לא הותאמה למעבר לחורף (וירוויח שעה במעבר לקיץ).

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

    * כל נתון שנכנס בין 01:00-02:00 לא נוכל לדעת אם הוא נכנס בשעה לפני החזרת השעון או השעה של אחרי החזרת השעון (אם המערכת לא הותאמה לכך). אחרי הכל השעה 01:00-02:00 מגיעה פעמיים במחזוריות. כל סדר הנתונים בזמן זה נתון לספק! כל שימוש בתלות בסדר הנתונים (למשל כל שאילתה עם order by או row_number או כל פונקציית חלון עם סידור לפי טור מסוג כזה)

    ** כאמור יש עוד נקודות וההשלכות היותר גדולות הן ההשלכות המישניות השונות לחלוטין במערכת אחת ממערכת שנייה ויש להקפיד לבחון את תאימות המערכות שלכם ולצפות לתופעות מוזרות :-)


    [Personal Site] [Blog] [Facebook]signature

    • נערך על-ידי pituachMVP, Editor שבת 12 אוקטובר 2013 16:22
    • סומן כתשובה על-ידי R1G2 שבת 12 אוקטובר 2013 19:42
    שבת 12 אוקטובר 2013 15:47
    מנחה דיון
  • תודה רבה!!!

    זאת נקודה חשובה!


    Ronnie Godfrey

    • סומן כתשובה על-ידי R1G2 שבת 12 אוקטובר 2013 19:43
    יום שישי 11 אוקטובר 2013 10:33

כל התגובות

  • הי,

    בשרתי SQL תוודא שישנו גיבוי על של בסיסי הנתונים.

    ה-SQL לוקח את ה-DST'Offset וכו' מתוך מערכת ההפעלה ולכן אתה צריך לוודא שישנו עדכון KB2863058 ולאחר מכן אתחול השרת.

    תוכל להיעזר במאמר הבא, http://beta.blogs.microsoft.co.il/blogs/eshlomo9/archive/2013/08/14/2404008.aspx

    אלי.


    Email:eshlomo9@hotmail.com;Twitter:https://twitter.com/EliShlomo1

    • סומן כתשובה על-ידי R1G2 שבת 12 אוקטובר 2013 19:43
    יום רביעי 09 אוקטובר 2013 11:19
  • תודה רבה!!!

    Ronnie Godfrey

    • סומן כתשובה על-ידי R1G2 שבת 12 אוקטובר 2013 19:43
    • סימון כתשובה בוטל על-ידי R1G2 שבת 12 אוקטובר 2013 19:43
    יום רביעי 09 אוקטובר 2013 12:38
  • לא הוזכרה נקודה חשובה! הנושא של תזמון JOB-ים במערכת :-)

    הזזת השעון משגעת את תזמון של ה JOB לפעמים. יש תופעה ידועה בקשר להרצת פעולות מתוזמנות (JOB) שקשורה בזמנים של מערכת ההפעלה, ויכולה לגרור הפסקת הפעלת פעולה מסויימת לחלוטין, או הרצה כפולה. ה-SQL Server Agent מחשב בכל פעם את זמן הריצה הבאה של הג'וב ושומר אותו. ברגע שמגיע הזמן, הג'וב מתחיל לרוץ. אם השעון של השרת מתעדכן (באופן ידני או אוטומטי), עלול להיווצר מצב שזמן הריצה הבא לעולם לא יגיע (למשל במעבר לשעון קיץ) או שהזמן יגיע פעמיים (כמו במעבר לשעון חורף). צריך לחשוב על ההשלכות של זה (זה יותר קריטי במעבר לשעון קיץ, שם אם היו פעולות מתוזמנות לזמן שקפצו עליו אז הזמן לא ייע אף פעם ומכיוון שהזמן הבא נקבע בזמן הריצה אז לא יקבע זמן ריצה הבא והתזמון הקבוע עלול להעצר)

    בזמן שיש תקלה או במעבר לשעון החדש כדאי לבדוק מה הערך של זמן ההרצה הבא ב msdb.dbo.sysjobschedules (אמור להתעדכן כל 20 דקות בעקרון) וכן ב msdb.dbo.sysjobactivity (אמור להיות עדכני בכל פעם ש JOB רץ או משתנה). אם אני לא טועה במעבר אל החורף כאמור זה פחות קריטי. אבל כדאי ללכת על בטוח ולחשוב ספציפית על המערכת שלכם והאם יש לכך השלכה.

    select next_scheduled_run_date,* from msdb.dbo.sysjobactivity
    GO
    SELECT * FROM msdb.dbo.sysjobschedules
    GO

    הערה: קשה לי להאמין (גם במאמר לא מזכיר בכלל sql agent) אבל אולי בין כל העדכונים שמתקינים נכלל גם תיקון לנקודה זו. בעבר הנושא לא היה סגור לחלוטין ובהחלט יכולנו להיתקל בבעיות כאלה.


    [Personal Site] [Blog] [Facebook]signature

    יום רביעי 09 אוקטובר 2013 13:23
    מנחה דיון
  • תודה רבה!!!

    זאת נקודה חשובה!


    Ronnie Godfrey

    • סומן כתשובה על-ידי R1G2 שבת 12 אוקטובר 2013 19:43
    יום שישי 11 אוקטובר 2013 10:33
  • בכיף רוני :-)

    אבל יש עוד דיי הרבה נקודות שצריך לקחת בחשבון. למעשה המאמר שם דגש על עבודת ה IT (והוא טוב מאוד בפני עצמו), וכמו כן דן מעט באפליקציות של מייקרוסופט אם כי כאמור לא דן בשרתי מסדי נתונים בכלל. אבל יותר מכך באופן טיבעי הוא לא דן בכלל בכל ההשלכות המישניות. נחמד שמייקרוסופט כיסו את הנושא עם תוכנת ה שרת המייל שלהם לדוגמה, אבל מה אם אתה עובד עם תוכנת שרת מייל שאתה פיתחת (או כל צד שלישי אחר) והתוכנה מושפעת באופן טיבעי מההשלכות של השינוי במערכת ההפעלה? מה לגבי כל אפליקצהי אחרת בפיתוח שלכם או של צד שלישי, האם כיסתם את כל הנקודות החשובות? מייקרוסופט לא יכולים לכסות עבורינו את הנקודות הנ"ל :-)

    צריך להקפיד לבחון תאימות של המערכות שלכם ולצפות לתופעות מוזרות :-)

    הנה עוד דוגמה למקור ענק של בעיות:

    כל עבודה עם טור מסוג time או datetime הוא פוטניאל לבעיה:-)

    * כל ניתוח זמנים שמבוססת על הפרש זמנים הכולל את הזמן החסר (במעבר לקיץ) או הכפול (במעבר לחורף) יוביל לחישובים לא נכונים במערכות שלא בוצע בהם עדכון מתאים. רוב האפליקציות שלנו ועל אחת כמה וכמה כל SP שאנחנו כותבים, כל דוח SSRS וכו, עובדים בניתוק מעדכוני מערכת ההפעלה,  ואין להן בכלל עדכונים שוטפים. לשם הדוגמה, תחשבו על מערכת שכר שמחשבת את זמן העבודה לפי כרטיס נוכחות. כל עובד שנכנס לפני שעה 02:00 ויצא אחרי שעה שעה 02:00 עבד למעשה את השעה הכפולה אבל בחישובים שלנו הוא יפסיד משכורת של שעה אחת, אם המערכת לא הותאמה למעבר לחורף (וירוויח שעה במעבר לקיץ).

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

    * כל נתון שנכנס בין 01:00-02:00 לא נוכל לדעת אם הוא נכנס בשעה לפני החזרת השעון או השעה של אחרי החזרת השעון (אם המערכת לא הותאמה לכך). אחרי הכל השעה 01:00-02:00 מגיעה פעמיים במחזוריות. כל סדר הנתונים בזמן זה נתון לספק! כל שימוש בתלות בסדר הנתונים (למשל כל שאילתה עם order by או row_number או כל פונקציית חלון עם סידור לפי טור מסוג כזה)

    ** כאמור יש עוד נקודות וההשלכות היותר גדולות הן ההשלכות המישניות השונות לחלוטין במערכת אחת ממערכת שנייה ויש להקפיד לבחון את תאימות המערכות שלכם ולצפות לתופעות מוזרות :-)


    [Personal Site] [Blog] [Facebook]signature

    • נערך על-ידי pituachMVP, Editor שבת 12 אוקטובר 2013 16:22
    • סומן כתשובה על-ידי R1G2 שבת 12 אוקטובר 2013 19:42
    שבת 12 אוקטובר 2013 15:47
    מנחה דיון
  • שוב תודה.

    התשובה הזאת מרחיבה את הפרספקטיבה לתקלות אפשריות נוספות, תשתיתיות ואפליקטיביות.


    Ronnie Godfrey

    שבת 12 אוקטובר 2013 19:49
  • הי,

    תודה על שיתוף המידע.

    אלי.


    Email:eshlomo9@hotmail.com;Twitter:https://twitter.com/EliShlomo1

    יום ראשון 13 אוקטובר 2013 12:08
  • מה קורה עם Change Data Capture?

    Ronnie Godfrey

    יום שני 21 אוקטובר 2013 07:38
  • הי רוני,

    למיטב ידיעתי, לא אמורה להיות שום בעיה עם CDC.

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

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

    -----------------------------
    גיא גלנצר
    יועץ ומדריך SQL Server
    Madeira - SQL Server Services
    http://www.madeira.co.il

    יום שני 21 אוקטובר 2013 08:34
    מנחה דיון
  • תודה רבה!!!

    Ronnie Godfrey

    יום שני 21 אוקטובר 2013 09:50