ארכיון

Archive for the ‘Oracle’ Category

קבצי ההדגמה מהרצאתי בשבוע אורקל: "Advanced PL/SQL: New features and Tips & Tricks For Better Performance"

קבצי ההדגמה מהרצאתי בשבוע אורקל: "Advanced PL/SQL: New features and Tips & Tricks For Better Performance" אפשר להוריד מהלינק במצורף:

קבצי ההדגמה מההרצאה

מודעות פרסומת

האם יש למיקרוסופט ב- 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.

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

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

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

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

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

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

"עכשיו מעונן" – בסיסי נתונים במחשוב ענן

מחשוב ענן (Cloud computing) הוא buzzword שרץ חזק בשנתיים האחרונות בעולם ה-IT. חברות מובילות כמו מיקרוסופט, אורקל ו-IBM עובדות על כל מיני פתרונות בתחום וכבר נשפכו לא מעט מילים על כך (והרבה מאד דולרים).

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

דמיינו לכם שאתם מפתחים מערכת שה-DB שלה בתוך ענן, אי שם ברשת ה-WAN (או ה-LAN הארגוני). לא צריך שום התקנות, שום ברזלים, וה-DB הזה מנוהל ומתוחזק ע"י מישהו אחר, עובר גיבוי ע"י מישהו אחר, ניתן להעמיס עליו כמות משתמשים ככל שנדרש מבלי לדאוג ל"ברזלים" (מישהו אחר דואג לזה). אתה משלם על השימוש ב-DB בהתאם למשאבים שאתה באמת צורך. אה ! מה עם storage? את מי זה מעניין. מישהו אחר דואג ל-storage. פשוט משלמים על פי מה שצורכים. ועוד משהו: ה-DB הזה זמין 24X7 וכמעט שלעולם לא נופל (כי הוא מתוחזק ע"י טכנולוגיות clustering למיניהן).

נשמע מעניין, נכון?

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

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

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

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

מיקרוסופט הולכת עם פרויקט שאפתני בשם Azure כאשר חלק ממנו הוא ה-SQL Azure שהוא למעשה פתרון לבסיס נתונים במחשוב ענן אשר צפוי להיות זמין לשימוש דרך האינטרנט במהלך השנה הקרובה. לפרטים:  http://www.microsoft.com/windowsazure/sqlazure

אורקל גם היא עובדת חזק על ה"ענן" וחברה לחברת "אמזון" (כן, אלה מהספרים…) ומאפשרת לשים פתרון תוכנה שלם מבוסס אורקל בענן של אמזון. כמו כן ניתן לגבות DB מחוץ לענן אל תוך הענן. לפרטים: http://www.oracle.com/technology/tech/cloud/index.html

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

בשורה התחתונה, אנחנו על סף עידן חדש בתחום בסיסי הנתונים. עידן ה"ענן" עשוי לחדור כבר ב-2010 חזק לתעשייה. האם זה אומר שבסיסי הנתונים "הרגילים" ייעלמו בעתיד? התשובה: לא כל כך מהר! אנחנו צפויים לראות מערכות "ענן" רצות לצד מערכות קונוונציונליות לפחות בשנים הקרובות. ומה בעתיד הרחוק יותר? התשובה תלויה כנראה ב-buzzwords של 2015.

משתמשים ב-XMLType של אורקל? כדאי שתקראו את זה

XMLType הוא טיפוס נתונים ותיק עוד מימי אורקל 8i. לרוב אנחנו צריכים לאנדקס ערכים מתוך ה-XML שיכולים להופיע ב-elements או ב-attributes שבתוך ה-XML. שימוש שכיח לכך הוא ע"י הרכבת אינדקס על פונקציה המבצעת קריאה ל-ExtractValue באופן הבא:

CREATE INDEX emp_id_ix ON employees

  (extractValue(XMLCol, '/Employees/Id'));

 

אבל מה יקרה אם ה-XML מכיל מס' אלמנטים בעלי אותו שם באותה רמה בעץ? לדוגמה:

<Employees>

            <Id> 123</Id>

            <Id> 234</Id>

</Employees>

אם ננסה ליצור את האינדקס על  ה-XML שבדוגמה נקבל שגיאה:

ORA-19025: EXTRACTVALUE returns value of only one node

הסיבה לשגיאה היא ש-ExtractValue לא יכול להחזיר יותר מערך אחד. אז מה עושים?

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

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

דוגמה:

נניח שיש לי טבלה עם עמודה XML שנקראת xmltab:

create table xmltab (xmlid int, xmlcol xmltype );

ניצור "טבלת בת" שתכיל את הערכים שנוציא החוצה מה-XML:

create table xmltab_Vals (id int, xmlid int, val int);

create sequence xmltab_vals_id start with 1;

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

CREATE OR REPLACE
TRIGGER TR_XMLTAB
AFTER INSERT ON XMLTAB
REFERENCING OLD AS oldval NEW AS newval
FOR EACH ROW 
BEGIN
  insert into xmltab_Vals
    SELECT xmltab_vals_id.nextval, :newval.id, extractvalue(value(d),'/id')
      FROM table(xmlsequence(
                 extract(:newval.xmlcol ,'/employees/id'))) d;

END;

ה-select שבטריגר הופך את הערכים של האלמנט Id לטבלה שמכילה קטעי XML עבור כל Id בנפרד. בשלב הבא, נעשה ExtractValue כדי לחלץ את ה-Id. הפעם לא נקבל את השגיאה ORA-19025 והערכים יסתדרו להם יפה בתוך הטבלה xmltab_Vals.

אם נזין את ה-XML שהבאתי כדוגמה, נקבל שתי רשומות בטבלת xmltab_vals עם הערכים 123 ו-234.

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

כמובן שכדאי ליצור fk עם on delete cascade בין הטבלאות הנ"ל ויש לכוון את השאילתות מול טבלת הבת במקום להשתמש ב-extractValue.

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

לאסוף מדדים ממערכת ההפעלה Windows ולתחקר אותם בהמשך

Perfmon הוא כלי נפלא ופשוט המאפשר לראות מדדי מערכת. אבל – לעיתים אנו רוצים לדגום יום שלם או שבוע שלם של מדדים שמייצר שרת Windows ואח"כ לנתח את הנתונים. כמו למשל, מתי היו רגעי שיא של פעולות CPU, רגעי שיא או שפל של תור הפניות ל-I/O  משכי זמן של Peaks וכו'.

ישנן שתי דרכים לעשות זאת:

דרך אחת – להשתמש ב-Utility של Windows הנקראת LOGMAN.

דרך שניה – לבצע "שאילתות" למשאבי השרת באמצעות אובייקטים של WMI או Windows Management Instrumentation. במקרה זה אפשר להשתמש ב-VBScript או לכתוב תוכנית בשפה עילית (DOT NET או Unmanaged code).

במאמר הזה אתמקד בשימוש ב-LOGMAN. שימוש ב-WMI הוא נושא למאמר נפרד ואולי אפילו לכמה מאמרים. נשאיר את זה בצד לעת עתה.

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

ב-Books On Line (או BOL) של מיקרוסופט אפשר למצוא תיעוד של כל שלל האפשרויות לשימוש בתוכנה זו.

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

logman create counter MyTrace -s MyServer -f  sql -si "00:00:05" –v -o DBServer!DBA -cf "c:\counters.config" -u MyUsername MyPassword

בפקודה זו הגדרנו תהליך איסוף מדדים בשם MyTrace שדוגם מדדים משרת בשם MyServer כל 5 שניות ואת התוצאות אנחנו רוצים להזין לטבלה ב-DB רלציוני התומך ODBC. הנתונים יכנסו לשרת DB בשם DBServer  לבסיס נתונים הנקרא DBA (באורקל זאת תהיה סכימה בשם DBA). ה-LOGIN לבסיס הנתונים יהיה עם המשתמש MyUsername ועם הסיסמה MyPassword. המדדים שברצוננו לדגום מפורטים בקובץ בשם counters.config.

כדי העסק יעבוד, יש להגדיר את ה-DB שאליו יש להזין את המדדים ב- ODBC Data Sources (ע"י Control Panel -> Administrative tools -> Data Sources). בלשונית SYSTEM DSN הוסיפו את שרת בסיס הנתונים (יכול להיות SQL Server, אורקל, MySQL או כל בסיס נתונים אחר שתומך ODBC).

LOGMAN יצור באופן אוטומטי טבלה (אם היא לא קיימת) שאליה הוא יזין את המדדים.

את רשימת המדדים אפשר לבנות בקלות ע"י PerfMon. אספו את המדדים שברצונכם לדגום עם LOGMAN באמצעות PerfMon. אח"כ לחצו CTRL-L ויפתח חלון. בלשונית DATA תוכלו לראות את שמות המדדים שבחרתם כפי שיש לציינם בקובץ הקונפיגורציה. אפשר כמובן לציין לא רק מדדים של Windows אלא גם מדדים של SQL Server או אורקל.

לאחר שהגדרנו את תהליך איסוף המדדים, כל שנותר הוא להפעיל אותו ע"י הפקודה:

logman start -s MyServer MyTrace

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

כדי לעצור את התהליך אפשר להריץ:

logman stop -s MyServer MyTrace

התהליך נעצר. ניתן לשוב ולהפעילו ע"י START.

 

הסמינרים הקצרים שלי משבוע אורקל 2009

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