ארכיון

Archive for the ‘SQL Server’ Category

טבלאות זמניות לפעמים יכולות להיות מתכון לבעיות (ויצא לי חרוז)

טבלאות זמניות זה דבר נהדר. SQL Server מאפשר לבנות טבלאות זמניות לוקליות (בניגוד לאורקל שתומך רק טבלאות זמניות גלובליות- לפחות בגרסה 11g). אבל ה-scope של הטבלאות הזמניות יכול להיות מבלבל ולכן יש תמיד לתת לטבלאות זמניות שמות משמעותיים ולא משהו שרירותי כמו a#.

להלן דוגמה:

CREATE PROCEDURE a AS

CREATE TABLE #a (x INT);

      INSERT INTO #a VALUES (1);

      EXEC b;

      SELECT * FROM #a;

GO

CREATE PROCEDURE b AS

      CREATE TABLE #a (x INT);

      INSERT INTO #a VALUES (2);

      SELECT * FROM #a;

GO

בדוגמה הפרוצדורה b יוצרת טבלה זמנית שנקראת a# וזאת למרות שנוצרה כבר טבלה בשם a# בפרוצדורה שקוראת לה. אבל הטבלה a# בפרוצדורה b היא טבלה אחרת מאשר הטבלה a# שנוצרה לפני כן בפרוצדורה a.

לעומת זאת, מה יקרה אם נכניס להערה את יצירת הטבלה בפרוצדורה b? הנה כך:

ALTER PROCEDURE b AS

      –CREATE TABLE #a (x INT);

      INSERT INTO #a VALUES (2);

      SELECT * FROM #a;

GO

במקרה הזה פעולת ה-insert לטבלה a# שבפרוצדורה b היא לטבלה שנוצרה בפרוצדורה a. כלומר, הטבלה a# היא סוג של "משתנה גלובלי" ומוכרת גם בפרוצדורה היוצרת וגם בפרוצדורות שתחתיה (שנקראות ע"י הפרוצדורה היוצרת).

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

איך לדפדף עם SQL Server 2011

ב- SQL Server 2011 ישנה אופציה חביבה המפשטת מאד את פעולת ההבאה של קבוצת נתונים (או דף) מתוך כלל תוצאותיה של שאילתא. מדובר בביטוי חדש בשם OFFSET הבא כתוספת לאחר ביטוי Order by והמבנה שלו הוא זה:

 

<offset_fetch> ::=

{

OFFSET { integer_constant | offset_row_count_expression } { ROW | ROWS }

[

FETCH { FIRST | NEXT } {integer_constant | fetch_row_count_expression }

{ ROW | ROWS } ONLY

]

}

לדוגמה: נניח שאנו מחלקים את תוצאות השאילתה לדפים בגודל 10 שורות כ"א. אם נרצה לשלוף את הדף השני נבצע משהו כזה:

select *

from Production.Product

order by name asc

offset 10 rows

fetch first 10 rows only

 בדוגמה שלפנו מטבלת המוצרים את 10 המוצרים שבדף השני (מיון לפי שם המוצר), כלומר המוצרים במיקום 11 עד 20 ע"פ המיון שנבחר.

אין ספק שזה נוח להפליא. השאלה היא: האם SQL Server חכם מספיק כדי לשלוף את הדף הרצוי בצורה המהירה ביותר?

התשובה: שיחקתי עם זה קצת ובחנתי את ה-execution plans, ואכן ה-SQL Server יודע לשנות את ה-plan לפי ה-offset ולפי כמות הנתונים המבוקשת:

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

 

הפיצ'ר הזה לדעתי הוא פיצ'ר שישפר את הביצועים באופן אמיתי כשמדובר בשליפת "דפים" כשמשווים אותו לכל צורת דפדוף אחרת (לרוב בשימוש עם row_number() ועם שאילתא בתוך שאילתא).

אין ספק שזו תוספת נחמדה ומקורית (אני לא מכיר כזה פיצ'ר באורקל).



רקוויאם ל-DTS

עכשיו זה סופי – אין יותר תמיכה ב-DTS בגרסת SQL Server 2011. אי אפשר להריץ אותם יותר והם אפילו לא בתפריט.

זוהי קריאה אחרונה למי שיש לו DTS-ים להמיר אותם ל-SSIS packages.

דרך אגב, מ-SSMS 2011 אי אפשר להריץ DTS גם אם מתחברים ל-instance בגרסה ישנה יותר (2000/2005/2008) – הוא פשוט לא קיים בתפריט.

האם יש למיקרוסופט ב- SQL Server 2011 תשובה ל-Oracle RAC?

האם יש למיקרוסופט ב- SQL Server 2011 תשובה ל-Oracle RAC?

אני אענה כמו נשיאנו שמעון פרס: "כן ולא".

ה-Oracle RAC הוא פתרון ותיק של אורקל שהוצג כבר די מזמן (מימי אורקל 9). ה-RAC החליף את ה- OPS או (Oracle Parallel Server) המיושן שהיה בנוי על הנעילות של מערכת ההפעלה (בניגוד ל-RAC שבו הנעילות מנוהלות ע"י האורקל ללא שימוש בשירותים של מערכת ההפעלה). במשפט אחד, ה-RAC (קיצור ל- Real Application Clustering) הוא פתרון המשלב גם זמינות גבוהה (כאשר שרת נופל, האחרים מגבים אותו) וגם פתרון scalability (יכולת להתמודד עם יותר משתמשים ועם עומס רב יותר ע"י הוספת עוד שרתים למערך שכולם אקטיביים). ה-RAC הוא פתרון נפלא והוא יחודי לאורקל (וגם אחת הסיבות מדוע אורקל היא המובילה העולמית בשוק). אבל מכיל כמה חסרונות כמו העובדה שהוא יקר להחריד וכמו גם המורכבות הרבה שלו הן בהתקנה ובעיקר בתחזוקה הדורשת מומחיות כדי להוציא מה-RAC  את הביצועים האופטימליים.

למיקרוסופט תמיד היו שני יתרונות בולטים מעל אורקל: המחיר (הזול יותר) והפשטות (או קלות/נוחות השימוש). והנה מיקרוסופט מציגה ב-SQL Server 2011 (המכונה Denali) פיצ'ר חדש מהניילונים המכונה AlwaysOn שהוא למעשה שכלול מנגנון ה-mirroring של המערכת שנועד להגדיל את הזמינות שלה.

אחת הבעיות של מנגנון ה-mirroring  הקיים בגרסאות הנוכחיות היא שכל DB מועתק לרפליקה שלו באופן בלתי תלוי ונפרד – וזו בעיה. בסיסי נתונים של SQL Server לרוב מכילים תלויות לוגיות של נתונים . ה- AlwaysOnמציע אפשרות לבנות Availability groups כשכל קבוצה מכילה מספר בסיסי נתונים. בזמן Failover אפשר לבצע Failover לכל הקבוצה ובכך להבטיח שהאפליקציה שמשתמשת במספר בסיסי נתונים תמשיך לעבוד עם ה- mirror.

חידוש נוסף של ה-AlwaysOn הוא היכולת להשתמש ברפליקה שלו – אבל… לקריאה בלבד (שלא כמו ב-Oracle RAC שמאפשר גם כתיבה תוך סנכרון נעילות בין השרתים). ב-SQL 2008 לא ניתן להשתמש ברפליקה כלל, אלא רק כשעושים failover. היכולת להשתמש ברפליקה לקריאה יכול להיות שימושי במיוחד לצורך הפקת דו"חות מנתוני אמת על גבי שרת הרפליקה מבלי להכביד או להשפיע על הביצועים של השרת העיקרי.

עוד חידוש הוא שאפשר לבנות עד 4 העתקים ל-DB (וזה נהדר במיוחד לצורך disaster recovery).

ה-AlwaysOn זקוק ל-Windows clustering שבלעדיו אי אפשר להשתמש בו. לשימחתנו אם פעם cluster  חייב אותנו למנגנון storage משותף ועשה בעיות אם החומרה של השרתים הייתה שונה, הרי שהיום (Windows Server 2008) המנגנון הזה בלתי תלוי ואפשר להחזיק שרת אחד של HP בת"א ושרת אחר של  Dell בניו יורק ואז לבצע mirroring  ביניהם. יש לשים לב לרשיון שמחייב Windows server Enterprise Edition כדי לתמוך ב-Clustering.

לסיכום: האם יש למיקרוסופט ב- SQL Server 2011 תשובה ל-Oracle RAC?

כן – מבחינת הזמינות.

לא – מבחינת ה-scalability.

ה-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) ועשויים לנעול איש את רעהו?

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

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

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

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