ה-Sequence נודד ל-SQL Server 2011

ה-Sequence הוא פיצ'ר מוכר לכל איש אורקל. ב-SQL Server הוא לא היה קיים ושם כשאנו מתבקשים ליצור Sequencing, אנחנו בונים עמודה עם הגדרת identity (לרוב זו הייתה עמודת המפתח הראשי של הטבלה).

שמחתי לשמוע שבגרסה הקרובה של SQL Server (גרסת 2011) יהיו גם Sequences, כי יש להם יתרונות רבים שמכיר כל אחד שבא מאורקל. חבריי שעובדים רק על SQL Server ולא עבדו על אורקל מעולם, לא מבינים בכלל למה זה טוב.

בשביל אותם חבר’ה, ערכתי טבלת השוואה בין Sequence לבין Identity column שתסביר למה זה דבר טוב:

Sequence

Identity

בלתי תלוי בטבלה כזו או אחרת

תלוי בטבלה אחת מסויימת.

אפשר לשנות בקלות את תכונות ה-sequence  (כמו לאפס אותו או להחזיר אותו לערך מסויים)

לא ניתן להוסיף או להוריד מהטבלה את הגדרת-identity מעמודה קיימת.

אפשר לשלוף בקלות את הערך הבא של ה-sequence גם במהלך פעולת update

אי אפשר לשלוף בקלות את הערך הבא של ה-identity ללא ביצוע של insert.

אפשר להגדיר ערך מינימום וערך מקסימום ואפילו להגדיר אותו כ-sequence ציקלי.

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

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

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

 

הואיל וה-sequece אינו תלוי בטבלה והואיל ולרוב יש לו קשר לוגי לטבלה מסויימת, רצוי לתת שם ל-sequence שיעיד על הקשר הלוגי שלו. לדוגמה: אם הוא מנהל sequence לטבלה בשם MyTable אז אפשר לקרוא לו MyTable_Seq.

 

מה צריך לשאול לפני תהליך מייגע של tuning ל-DB ולמשפטי SQL?

יש בעיות ביצועים עם database. מה עושים?

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

ובכל זאת – לפני שמתחילים לעשות Tuning או (כיוונון בעברית) למערכת צריך לשאול את השאלות הבאות:

  1. האם יש עוד אפליקציה שרצה על שרת ה-DB וזוללת משאבים?
  2. האם החומרה בכלל חזקה מספיק בשביל לסחוב מערכת עם X משתמשים שעושים Y טרנזקציות בדקה בזמן שיא ו-Z שאילתות קטלניות?
  3. האם נבדקה מהירות התקשורת בין שרת ה-DB ושרת האפליקציה או ה-clients?
  4. האם מישהו מקצועי קינפג את הפרמטרים והאופציות של ה-DB? מישהו בכלל עבר על ההגדרות ובדק את התאמתן?
  5. האם ה-DB מתוכנן נכון ליעוד שלו: OLTP או DWH?
  6. האם ישנם תהליכים מסויימים שכשהם רצים מורגשת בעיית הביצועים?
  7. האם מתכנני האפליקציה ומפתחיה לקחו בחשבון שאנשים רבים עובדים במקביל על המערכת (מה שנקרא concurrency) ועשויים לנעול איש את רעהו?

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

לא לשכוח להתקין TELNET על Windows

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

הדרך הקלה ביותר לבדוק את זה הוא באמצעות תוכנית השירות TELNET המגיעה בכל מערכת UNIX אבל משום מה היא אופציונלית על Windows. למרבה הצער – יש נטיה לשכוח להוסיף את TELNET להתקנה למרות שמישקלו הוא כמשקל אמבה תת ימית.

נו טוב… נצטרך עכשיו להתחיל לפשפש ב-ACL של ה-Firewall.

Firewall הוא כמו אישה – אי אפשר איתו ואי אפשר בלעדיו….

איך לבנות Data Access Layer כמו שצריך

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

בחברה אחת שכזו נעשית חשיבה כיצד נכון בשבילם לכתוב את ה-DAL.

האפשרויות הן:

  1. כתיבת משפטי SQL בתוך הקוד. לרוב נבנה הטקסט של המשפט והוא נשלח לביצוע ל-DB.
  2. קריאה ל- Stored Procedures מתוך הקוד והעברת פרמטרים אליהם ומהם.
  3. שימוש ב-ORM או Object Relational Mapping כמו Hibernate או Entity Framework.

אופציה מספר 1 (SQL בתוך הקוד) היא הגרועה שבהם וזאת מכמה סיבות ואלו העיקריות שבהן:

  1. משפטי ה-SQL שבקוד אינם נבדקים בזמן קומפילציה ועלולים "להתעופף" בזמן ריצה אם התחביר שגוי.
  2. שינויים בסכימה (הוספת/ביטול עמודות, שינוי טיפוס נתונים, שינוי בשמות טבלאות וכו') גוררים שינויים בקוד. קשה למצוא את כל המקומות שיש לשנותם. ה-deploy בסביבת היצור חייב יהיה לשנות את הקוד שמעל ה-DB.
  3. השאילתות שנוצרות בקוד הן לרוב – שאילתות דינאמיות עם כל המשמעויות המתבקשות של בעיות ביצועים.

לאופציה מספר 2 (Stored procedures)  יש גם כן מגרעות (אבל פחות מאשר לאופציה מס' 1):

  1. קריאה לפרוצדורות היא סוג של יציאה מעולם האובייקטים לעולם רלציוני – מה ששובר את עקרונות עיצוב מונחה עצמים.
  2. במערכת בינונית ומעלה אפשר למצוא מאות ואפילו אלפי פרוצדורות. אי אפשר למצוא את הידיים ואת הרגליים בהם והרבה פעמים קורה שמפתח כתב stored procedure ולא ידע שמישהו אחר כתב את אותה פרוצדורה לפניו – רק עם שם אחר.
  3. הרבה פעמים הלוגיקה העסקית "מתפזרת" לתוך פרוצדורה ואז היא מצוייה גם בשכבת BLL וגם בשכבת ה-DAL.
  4. לא כל כך נוח לתכנת כל פעולת SQL בשני שלבים – פיתוח קריאה לפרוצדורה בשפה עילית ופיתוח הפרוצדורה בשפת ה-DB (כמו PL/SQL או T-SQL).

לאופציה מספר 3 (ORM) יש גם מגרעות:

  1. קוד ה-SQL שמחולל ע"י ORM עלול להיות לא יעיל בעליל. ככל שרמה הסיבוכיות עולה – הסיכוי שה-SQL שנוצר יהיה איטי גובר.
  2. עבודה עם ORM דורשת לימוד מעמיק של היכולות והמגבלות.
  3. קשה לנסח שאילתות מורכבות בממשק כמו LINQ או HQL. מה שהולך בקלות ב-SQL, הולך קשה ב-LINQ.

מה עושים?

לדעתי – יש לנסות לקחת את הטוב משתי האופציות 2 ו-3. כלומר – כן ליישם ORM – אבל לשלב אותו עם Stored procedure אותם יש לכתוב בשביל משימות שה-ORM מתקשה ליישם בצורה אופטימלית.

עיבוד טרנזקציות? נוח מאד ב-ORM. שאילתות מורכבות? לך על Stored Procedures וחבר אותם ל-ORM.

אשמח לשמוע על רעיונות נוספים.

המצגת והסקריפטים מסמינר SQL Server Service Broker

אפשר להוריד את המצגת ואת הסקריפטים מסמינר SQL Server Service Broker פה:

http://www.f2h.co.il/2902701473795

הזמנה להרצאה שלי – "מבוא ל-Service Broker במערכות SQL Server 2005/2008"

ביום שני 3 במאי 2010 בשעה 17:30 יתקיים מפגש של קבוצת המשתמשים של SQL Server (המכונה ISUG) במיקרוסופט רעננה (ברח' הפנינה). במסגרת המפגש אני אעביר הרצאה על נושא שרבים מאנשי DB לא ממש מכירים – יכולות messaging של בסיס הנתונים. ההרצאה "מבוא ל-Service Broker" תציג את הכלי שמגיע כחלק ממערכת SQL Server 2005 או 2008 ומהווה middleware פשוט, מהיר, יעיל ונוח לתפעול בין רכיבי תוכנה פנימיים (stored procedures) ו/או חיצוניים (תוכנות בשפה עילית).

ההרצאה היא בחינם !!! רק להגיע וללמוד.

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

במסגרת ההרצאה אני אדגים תוכניות ריצה (demos) של רכיבי T-SQL כמו גם רכיבי דוט נט כתובים ב-#C שימחישו כיצד ניתן להשתמש בכלי הזה.

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

כולם מוזמנים !!!

נ.ב. – יש גם בורקסים ושתייה, כמיטב מסורת האירוח של מיקרוסופט.

איך הגעתי בכלל לבסיסי נתונים

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

זה התחיל בשנת 1988 כשהתגייסתי לצה"ל ועשיתי קורס תכנות בממר"ם. באותם הימים שפות הפיתוח הפופולאריות היו C, פסקל  ו-Ada על מערכות VAX/VMS ו- PL/1 וקובול על מיינפריים של IBM. בתום הקורס ביקשתי הצבה בחיל מודיעין ואכן הוצבתי ביח' המחשבים של חמ"ן. מייד לאחר שהגעתי ליחידה, נשלחתי לקורס פיתוח מתקדם ב- VAX/VMS  ולאחריו המערכת הראשונה שבה פיתחתי הייתה מערכת העובדת על אורקל גרסה 6 שרץ על VAX/VMS . זו הייתה הפעם הראשונה שראיתי בסיס נתונים רלציוני ופעם ראשונה שנתקלתי בשפת SQL.

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

בשנת 1997 פגשתי את זיו מנדל, מנכ"ל ג'ון ברייס הדרכה. זיו היה מפקד קורס שלב 9 (או שלב 11, אני כבר לא זוכר) כשהייתי בצבא והוא זכר אותי. זיו הציע לי ל"התגייס" לקבוצת ג'ון ברייס (שאינה קיימת היום) גם כמנהל תחום הדרכת DBA וגם כיועץ אורקל וכך עשיתי. ג'ון ברייס היה בי"ס מעולה בשבילי ולמדתי שם כל מה שאפשר על אורקל וגם על טכנולוגיות אחרות (כמו FW, ג'אווה, שרתי אפליקציות ועוד) בנוסף הסתובבתי בין לקוחות שחיפשו עזרה בעבודה עם אורקל. הימים הם ימי הבועה. קורסי ה-DBA שהייתי מרצה בהם (DBA 1,2,3) היו מפוצצים עד אפס מקום, במיוחד כשיצאה באותם הימים גרסה 8 ואחריה 8i. אורקל הייתה מלכת ה-DB ולמעשה נתנה פתרון בכמה רמות מעל המתחרים (שהיו Informix, DB2, Sybase). היה אז גם מוצר קטן ושולי בשם SQL Server 7 של מיקרוסופט אבל הוא התאים רק למערכות קטנות עם משתמשים מועטים ולא היווה אז גורם משמעותי בתחרות מול אורקל.

במאי 1999 פנו אליי מחברת הסטארט אפ ImageID שגייסה סכומי עתק והציעו לי להצטרף כ-DBA ואיש פיתוח Web. לא היה אז איש תוכנה אחד בישראל שלא חלם על אופציות דשנות ועל המיליונים שהוא עתיד לעשות איתם. כל חודש היה אקזיט של חברה אחרת עם סיפורים על אנשים שסגרו משכנתאות ואפילו פנסיות בזכות האופציות שהיו ברשותם. על הנייר – הייתי יכול לקנות דירה נאה מאופציות שלי. על הנייר… כמובן שבהמשך יכולתי לעשות מהאופציות אוריגמי של בית מנייר….

ב-ImageID לימדתי את כולם לעבוד עם אורקל. אני בעצמי הייתי חצי מהזמן DBA וחצי מהזמן איש פיתוח (בעיקר ב-ASP, VB ו-C++).  בשנת 2003 החלטנו בחברה להיכנס לעולם הדוט נט. אני למעשה הראשון בחברה שלמד דוט נט ו-ASP.NET וכך הפכתי לר"צ WEB בחברה. במקביל המשכתי להיות איש האורקל של החברה. בשנת 2004 בחנתי את SQL Server 2000 ואת MSDE כבסיס נתונים עבור פרוייקט לחברה גרמנית עם סניפים רבים. חיפשנו DB זול יחסית שיעבוד בסניפים ויעביר נתונים ל-DB מרכזי שמריץ אורקל ב- XML באמצעות web services. זו הייתה הפעם הראשונה שנתקלתי ב-SQL Server. האמת – לא ממש התלהבתי ממנו. כאיש אורקל היו חסרים לי המון פיצ'רים במערכת הזו. במיוחד לא אהבתי שלא היה שם row versioning (מה שנקרא snapshot isolation). בשנת 2005 יצאה מיקרוסופט עם SQL Server 2005 וסופסוף היה כאן מוצר שיכול להוות אלטרנטיבה לאורקל. אני התחלתי לעבוד איתו באינטנסיביות כשעזבתי את ImageID והצטרפתי לחברת סטארט אפ אחרת בשם MutualArt ולאחר מכן גם באמדוקס וכיום ב-SRL.

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