זיהוי גרסת SQL Server בחיבור מרוחק

לעיתים קרובות מאוד (אולי מדי) אני מתחבר לבסיסי נתונים מרוחקים של לקוחות או על מכונות אחרות באותה רשת שעליה אני עובד כרגע.

אני באופן אישי מבצע את החיבור דרך Sql Server Management Studio 2008 אבל כמובן שאני יכול להתחבר לכול גרסה של בסיס נתונים קודמת מה שיכול להיות מאוד מבלבל.

כמו כן, על מכונת הפיתוח שלי אני מריץ שתי גרסאות של core, גם 2005 וגם 2008, כדי שאוכל לייצא את הנתונים בצורה תקינה לשרתי הproduction או הtest.

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

9-12-2010 12-06-29 PM

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

לכן, יש סקריפט t-Sql מאוד נחמד שנותן פרטים רבים (את כול מה שצריך בעצם) על בסיס הנתונים שאליו אתם מחוברים כעת דרך הAPI של Sql server לנושא ולא דרך מעקפים שונים ומשונים ובטח לא על ידי טלפונים ומיילים לחברת ההוסטינג לשאול אותם :-)

הנה הסקריפט

CREATE TABLE #SqlServerInformation(
editionText char(30),
versionText char(250),
productVersionText char(20),
levelText char(20))

INSERT INTO #SqlServerInformation (editionText, versionText, productVersionText, levelText)
VALUES (
CONVERT(char(30), SERVERPROPERTY('Edition')),
CONVERT(char(250), @@version),
CONVERT(char(20), SERVERPROPERTY('ProductVersion')),
CONVERT(char(20),SERVERPROPERTY('ProductLevel'))
)

SELECT * FROM #SqlServerInformation

drop table #SqlServerInformation

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

אשמח לתגובות

כיווץ בסיסי נתונים Sql Server

שלום לכולם,

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

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

לאותו לקוח היו לו המון בסיסי נתונים ולא רציתי לעבור אחד אחד, לכן כתבתי סקריפט לכיווץ בסיסי הנתונים (כולם).

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

סקיילינג – או איך לא תענשו בחומרה – פתרון אמיתי

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

במה הפוסט יעסוק?

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

יהיו כאן שיקולי תקציב, שיקולי מיקום, חומרה מומלצת ועוד.

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

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

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

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

לחברת בניית האתרים VVV יש כ150 לקוחות, חלק מהלקוחות הינם לקוחות עם חנות וירטואלית אתרי תדמית ומערכות אחרות, חלק בנויות בAsp.Net וחלק בClassic ASP.

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

המטרה: להגיע ל7 שניות ללא שיפורי קוד ומשם לשפר את הקוד עד ל1-3 שניות.

טוב, יאללה לעבודה.

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

סליחה עם ניפצתי למישהו איזה בועה

עכשיו באמת אפשר להתחיל

שלבי העבודה:

קוד

  • 1. בדיקת איכות הקוד
  • 2. בדיקת טיוב שאילתות בסיס נתונים
  • 3. בדיקת גישות לבסיס נתונים מרמת האפליקציה
  • 4. בדיקה גישות לדיסק דרך הקוד (כתיבת וקריאת קבצים)

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

בדיקת איכות הקוד

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

בדיקת איכות הקוד הראשונית אומרת לבדוק את שיטת העבודה, במידה ומדובר בAsp.Net לבדוק שימוש יתר בViewState, שמירה של אובייקטים גדולים מדי בזיכרון או שמירה של אובייקטים לא מתאימים.

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

עוד…

האם ישנם טיימרים בJavascript שניגשים לשרת ומכבידים עליו מאוד, כלומר אם מישהו השאיר את הדפדפן פועל, האם השרת יקבל עשרות או מאות בקשות בשביל לקוח יחיד?

רגע זה לא Refactoring???

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

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

בדיקת טיוב שאילתות בסיס נתונים

בסיס הנתונים הוא הלב הפועם של האפליקציה שלכם, של השירות, של השרת של הכול בעצם.

הכול מנותב דרכו, יש לוגיקות שהוא מנהל ויש מקרים שהוא סתם Data Storage Center, עכשיו מה זה אומר טיוב…?

אני אגיד מה זה לא אומר… זה לא אומר לבדוק 2 שניות או 1.5 שניות, זה אומר לבדוק מקרים שבהם יש TimeOut.

סיפור אמיתי, אני נשבע!

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

שמירה לטבלה הזו לקחה 2 שניות, משיכה ממנה לקחה 7, לעיתים אפילו הSQL קיבל TimeOut.

רגע, אז מה אני עושה במקרה כזה? או… גם המתכנת שאני לקחתי דרך אתר XYZ עשה את זה, מה אני יכול לעשות עכשיו.

אם יש לכם Sql Server 2005 או 2008 ואפילו 2000 (אלוהים יודע למה) עם רישיון מלא אתם יכולים להגדיר Jobs, אצל הלקוח VVV אני הגדרתי JOB שבודק את התאריך (שגם הוא לא היה) של השמירה, היות ונתוני Session נמחקים לאחר 20 דקות בכול מקרה ברמת השרת פשוט וידיתי מחיקה גם מבסיס הנתונים.

100 מוצרים בדף, 20 דפים

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

לא הגיוני נכון?

אז ככה, אני מוכן לעשות התערבות שאם יש לכם אפליקצית Dot NET שמישהו בנה לכם הדפדוף הוא בצורה כזו ב95% מהמקרים מה שאומר שהשרת שלכם מבזבז עשרות אלפי בייטים מבוזבזים של מידע שעולים לכם בNetwork עולים לכם בSystem.IO ועוד.

בדיקת גישות לבסיס הנתונים מרמת האפליקציה

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

בואו נגיד שעד 10 זה בסדר (לא מצוין אבל בסדר)

14-08-2009 15-09-28

מה זה הציור הזה?

ראשית הקרדיט לבלסמיק :-)

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

עכשיו בואו נראה מה קורה בתרשים גישות מאוד ציורי :-)

with_arrows

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

בדיקה גישות לדיסק דרך הקוד (כתיבת וקריאת קבצים)

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

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

יש להשתמש בDisk Caching ולא ליצור את התמונה On Demand במידה וכבר יש אותה.

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

אבל רגע, השרתים עדיין מראים בניטור ניצול מלא כמעט של זיכרון, ניצול מעבר ליכולות הדיסק הקשיה ו20% ניצול CPU (במושגים של שרת זה די אומר שאתם בזבל :-) )

חומרה, אבל לא עונש

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

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

אבל לפני הכול, שיקולים שיש לקחת בחשבון

1. זמן Uptime
2. שרידות מערכת אפליקטיבית
3. קצבים (לא butcher אלא pace :-) )

זמן Uptime

המון חברות אכסון שבהן אני נתקל באינטרנט מתגאים ב99.9% זמן Uptime, זה ברור :-) אבל לא לזה אני מתכוון.
זמן Uptime מבחינתי אומר – כמה שפחות Down time.

המערכת צריכה להיות מתוכננת עד כמה שאפשר ללא Single point of failure ברמת החומרה, בטח שלא ברמה אפליקטיבית.
זמן התגובה לקריסת חומרה (זה קורה, נדיר אבל קורה) צריך להיות סופר מהיר.

שרידות אפליקטיבית

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

קצבים

קצב קריאות אפשרי לבסיס הנתונים, קצב כתיבה לדיסקים, קצב רשת

זול וטוב, או… נחשוב עוד שנתיים שוב

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

14-08-2009 15-35-18

מה יש לנו כאן

יש לנו שרת SQL יחיד שמתבסס על Dell R610

14-08-2009 15-38-04 שני מעבדי Quad Core
8 GB זכרון פנימי 1333MHZ DDR3
6 דיסקים קשיחים 73GB SAS
שני ספקי כוח בRedundancy כלומר פתרון Fail Safe

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

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

שרת נוסף IIS נועד להחזיק את האתרי ASP, אין יותר מדי מה להתעמק בו

שרתי הIIS לא צריכים להיות סופר חזקים כמו שרת הSQL ויכולים להיות מבוססים על R410.

רגע רגע, חסר מלח לא?

חסר כאן משהו נכון?
חסר כאן פתרון גיבוי לשרתים נכון?

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

הסיכוי לכישלון חומרה בין שניהם קטן מהסיכון בחוסר גיבוי ולכן בשלב זה מוותרים (זה הפתרון הזול זוכרים)

שרת הIIS מגבה לSQL וההיפך, הגיבוי הזה קובץ פעם בלילה בין שני שרתי הIIS האחרים.

פתרון גיבוי מלא, לא מיטבי ולא Best Case אבל מלא.

אני הייתי שם בחווה HD חיצוני 2TB של Western Digital שמחובר בUSB או ברשת לאחד השרתים ויחזיק את הגיבויים, אחת לשבוע הייתי עושה גיבוי גם ברמת החווה.

FailSafe – מיידי (בגיבוי)

חסרון הפתרון

אין גיבוי לשרת SQL ברמת החומרה, כלומר אם הוא נופל כול המערכת נופלת.

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

image002
בשביל לעשות סדר, בואו נחלק את הפתרון לשלושה חלקים

with_icons

קצת סדר בבלאגן

1. DATA
שני שרתי SQL עם Active/Passive כלומר רק אחד מהם פועל כול הזמן, השני נכנס לעבודה במקרה של קריסה אפליקטיבית או חומרתית.
מה זה הקטן לידם אתם שואלים? :-)
השרת הקטן לידם הוא זה שאחראי להעביר את המידע בין השניים ואת הקבצים, כך שניהם תמיד "נראים" אותו דבר מבחינת האפליקציה ויכול להיות מצב שגולש ישהה בדף ואפילו לא יבחין בנפילה של בסיס הנתונים.

2. IIS גדול
הפתרון הזה הוא לאתרים הגדולים ודומה מאוד למצב הקודם (בפתרון הקודם) אלא שכאן מדובר על עוד שרת אחד

3. IIS קטן
לאתרים הקטנים יותר שלושה שרתים שפשוט מחלקים בינהם את העומס בצורה מאוד פרימיטיבית, חלק מהאתרים יושבים על X חלק על Y וחלק על Z

גיבוי

כול השרתים מגובים בינם לבין עצמם, כולם מגבים לשרת Sync ואחת לכמה ימים גם ברמת החווה.

שיקולי תקציב

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

הScale הוא רוחבי כלומר ניתן בהחלט ללכת על פתרון אחד ואז לעשות "התנפחות" לפיתרון השני

הפתרון הראשון יוריד כ30% מזמני התגובה של המערכת באופטימום ועוד כמה אחוזים בעומס מכיוון שיש כאן יותר חומרה

הפתרון השני יעשה הבדל של בערך פי 2

כתבו עלי בYnet עכשיו, מה אני עושה

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

זהו.

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

אשמח לשמוע ולקרוא תגובות שלכם

או כמו שאמר @liroz משידורי הניסיון, אני פתוח לכול ביקורת חיובית.

מחיקת כול הטבלאות מבסיס נתונים Sql

שלום לכולם,

לאחרונה נתקלתי בבקשה מוזרה מעט, נתבקשתי למחוק את כול הטבלאות מתוך בסיס נתונים של Sql Server.

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

אז כתבתי קצת קוד שמבצע בדיוק את זה.

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

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

הקוד נבדק על Sql 2005 בלבד

   1: DECLARE @dropSql nvarchar(1000)

   2: DECLARE DropSequence CURSOR LOCAL FAST_FORWARD

   3:

   4: FOR

   5:     SELECT

   6:         N'DROP TABLE ' + QUOTENAME(TABLE_SCHEMA) + N'.' + QUOTENAME(TABLE_NAME)

   7:     FROM

   8:         INFORMATION_SCHEMA.TABLES

   9:     WHERE

  10:         TABLE_TYPE = 'BASE TABLE'

  11:             AND

  12:         OBJECTPROPERTY(OBJECT_ID(QUOTENAME(TABLE_SCHEMA) + N'.' + QUOTENAME(TABLE_NAME)), 'IsMSShipped') = 0

  13:

  14:     OPEN DropSequence

  15:     WHILE 1 = 1

  16:         BEGIN

  17:             FETCH NEXT FROM DropSequence INTO @dropSql

  18:

  19:                 IF @@FETCH_STATUS <> 0 BREAK

  20:                     RAISERROR (@dropSql , 0, 1) WITH NOWAIT

  21:

  22:             --EXEC(@dropSql )

  23:             PRINT @dropSql

  24:         END

  25:

  26: CLOSE DropSequence

  27: DEALLOCATE DropSequence