רוצים לשדרג תחנות עבודה בארגון ל Windows 7? לא יודעים איך להתחיל?

שלב ראשון – סקירת מצב קיים

1. מידע לאיסוף:

- מידע כללי (מערכות הפעלה בשימוש בתחנות עבודה, רשימת שפות לתמיכה, מערכת שו"ב ארגונית ועוד)

- אפליקציות (כמויות, שיטות הפצה, פיתוח פנימי ועוד)

- תהליך Imaging

- תשתיות (כללי, תקשורת, הבטחת מידע ועוד)

2. סקר מצב חומרה

- כדי לבדוק תאימות חומרה ל Windows 7, ניתן להריץ כלי חינמי בשם Microsoft Assessment and Planning (MAP) Toolkit. מידע נוסף: http://technet.microsoft.com/en-us/solutionaccelerators/dd627342.aspx

3. סקר מצב תוכנה

- כדי לקבל רשימת אפליקציות בשימוש ותאימות שלהן ל Windows 7, ניתן להריץ כלי חינמי נוסף בשם Application Compatibility Toolkit (ACT). מידע נוסף:

http://technet.microsoft.com/en-us/windows/aa905066.aspx

מה שלבים הבאים? איך בונים Image יחיד - כלל ארגוני? איך מפיצים אותו?

צרו אתנו קשר ונשמח לעזור.

אלכסיי

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

אבל, בכתיבה של SQL  זה לא תמיד כדאי.

אז הנה דוגמא מהחיים (הדוגמאות רצות על AdventureWorks):

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

השיטה בעזרת פונקציות:

לעבור על טבלת הספקים, ההזמנות ושורות ההזמנה

קוד בעזרת פונקציות (הגדרות הפונקציות בנספח):

SELECT PV.VendorID, Purchasing.fn_SumQty(PV.VendorID) SumQty, Purchasing.fn_SumValue(PV.VendorID) SumValue ,

      Purchasing.fn_SumFreight(PV.VendorID) SumFreight,

      Purchasing.fn_SumValue(PV.VendorID) / Purchasing.fn_SumQty(PV.VendorID) AvgQty,

      Purchasing.fn_SumFreight(PV.VendorID) / Purchasing.fn_SumQty(PV.VendorID) AvgFreight

FROM Purchasing.ProductVendor PV

הביצועים - ברצפה (11 שניות, 200K Reads)

נעבור לשיטה חלופית (הסבר יבוא):

SELECT PV.VendorID, SumQty, SumValue, SumFreight, SumValue/SumQty AvgQty, SumFreight/SumQty AvgFreight

FROM Purchasing.ProductVendor PV

LEFT OUTER JOIN

(select VendorID,sum(Freight) SumFreight, sum(LineTotal) SumValue, sum(cast(OrderQty as int)) SumQty

from Purchasing.PurchaseOrderHeader H

inner join Purchasing.PurchaseOrderDetail D

on H.PurchaseOrderID = D.PurchaseOrderID

GROUP BY VendorID) HelpSumOrders

on PV.VendorID = HelpSumOrders.VendorID

הביצועים - מצויינים (0.2 שניות, Reads 112) - פי 55 יותר מהר, פחות מאלפית פעולות IO

אז מה הקסם:

• פעולת ה JOIN הישירה מאפשרת לאופטימייזר לקרוא את הטבלאת פעם אחת ולא פעם לכל שורה
• בנוסף, במימוש המקורי יש 5 קריאות לפונקציה לכל שורה!!

מסקנה:

אל תשמשו בפונקציות העושות פניות נוספות ל Database אלא אם מספר השורות נמוך!!

נספח פונקציות:

CREATE FUNCTION Purchasing.fn_SumFreight (@VendorID int) RETURNS money

AS

BEGIN

DECLARE @SumFreight MONEY

select @SumFreight= sum(Freight) from Purchasing.PurchaseOrderHeader

WHERE VendorID = @VendorID

RETURN (@SumFreight)

END

go

CREATE FUNCTION Purchasing.fn_SumValue (@VendorID int) RETURNS money

AS

BEGIN

DECLARE @SumLineTotal MONEY

select @SumLineTotal= sum(LineTotal) from Purchasing.PurchaseOrderDetail D

INNER JOIN Purchasing.PurchaseOrderHeader H ON H.PurchaseOrderID = D.PurchaseOrderID

WHERE VendorID = @VendorID

RETURN (@SumLineTotal)

END

GO

ALTER FUNCTION Purchasing.fn_SumQty (@VendorID int) RETURNS INT

AS

BEGIN

DECLARE @SumQty INT

select @SumQty= sum(cast(OrderQty as int)) from Purchasing.PurchaseOrderDetail D

INNER JOIN Purchasing.PurchaseOrderHeader H ON H.PurchaseOrderID = D.PurchaseOrderID

WHERE VendorID = @VendorID

RETURN (@SumQty)

END

 היי , אני קורא לזה... תהליכים ל "מידות גדולות..."

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

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

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

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

DBA, מפתחי BI, מנהלי תחום מחסן הנתונים כל הזמן עסוקים במתן אחריות לנושא זה   J

האם ה DBA  אמון לתהליך שיפור הביצועים או האם מפתח ה BI נדרש לפתח תהליך מיטבי?

האם ה ERD  ואפיון הפיסי תואם את הדרישות?

האם ה DBA שותף לתכנון הפיסי או לתהליכי ה Source To Target ?

טוב, ישנן עשרות שאלות תהליכיות ולצערי גם טריטוריות ולכן לא אעסוק בהן כאן!

אחד המאמרים המצויינים שנכתב ע"י קבוצת SQLCAT הסוקר בהרחבה את כל סוגיות והשיטות הקיימות לניהול מערכי מידע גדולים מאוד , אחד הנושאים האהובים עליי הוא המאפיין ה-א-ג-ד-י Trace Flag 610 (תגלו לבד!).

קישור למאמר

The Data Loading Performance Guide

בהצלחה , תהנו.

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

1. סוג רכיבי המידע איתם אעבוד באפליקציה
קיימים סוגים שונים של רכיבי מידע (Xml, Dataset, POCO....) - מה היתרונות/חסרונות בהיבטי ביצועים?

XML

מתי?
· כאשר קיים צורך בצימוד נמוך וה caller צריך לקבל/לדעת רק את ה value וה schema
· כאשר קיים צורך לתמוך גם בצרכנים שאינם כתובים ב- dotnet.
· כאשר יש צורך בתמיכה built in ל serialization

בעיות?
· בדרך כלל צורך CPU מכיוון ששליפת נתונים ועדכון מבצעים חיפוש ב – DOM.
· מבנים גדולים צורכים זכרון וכל עיבוד איטי משמעותית.
· דורש casting

Dataset/Typed Dataset

מתי?
· כאשר קיים צורך בתמיכה של מבנה ישויות מורכב
· כאשר קיים צורך בתמיכה של relations מורכבים
· כאשר יש צורך במעקב אחר שינויים על המידע (self-tracking)
· כאשר קיים צורך בתמיכה built in ל serialization

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

POCO

מתי?
· כאשר קיים צורך בתמיכה של מבנה ישויות מורכב
· כאשר שני הצדדים (caller, callee) מכירים את מבנה הישויות
· כאשר יש צורך ב binary serialization עבור ביצועים

2. תקשורת בין שכבות
כאשר אני מפתח מערכת C\S וה – client שלי הוא win application, בדרך כלל, רכיב השרת שלי יכיל שכבת שירותים שתחשוף WCF Services.
אך מה כאשר המערכת שלי היא מערכת אינטרנט ובא שכבת ה – UI שלי וגם רכיבי השרת שלי נמצאים על אותו שרת? האם גם אז התקשורת בין שכבת ה- UI לשכבת השירותים תהיה מבוססת WCF?

יתרונות של תקשורת מבוססת WCF:
- במקרה שנרצה להפריד את השכבה העסקית לשרת נפרד, לא יהיה צורך בשינוי קוד.
חסרונות:
- ביצועים. Reference ישיר מאפשר לי תקשורת ישירה בין רכיבים (in-proc).
[אני בעד הפשטה (אבסטרקציה) שתאפשר לי לבצע מעבר בין 2 האפשרויות, בשינוי קוד מינימלי].

3. Caching
נושא ה- caching נתפס כמשהו שבמהותו הוא משפר ביצועים. אך לא תמיד כך הוא הדבר. תכנון לא נכון של cache יכול לפגוע בביצועים באופן ניכר.
למה להשתמש ב – cache?
- להקטין את מספר הפניות למקור מידע.
- להקטין כמות עיבודים (ע"י כך שנחזיק ב – cache רכיבים "מעובדים").

מה הסיכונים ב- cache?
- ניצול יתר של הזכרון.
- עבודה עם מידע לא מעודכן (במקרה שהמידע במקור המידע השתנה).

אני לא אכנס כאן לדיון מעמיק על מתי נתון נכנס/יוצא מ- cahce, סוגי cache וכו', רק אציין 2 שיקולים מרכזיים המשפיעים על אלו נתונים יוחזקו ב- cache:
- תדירות שינוי הנתונים (נתונים המשתנים בתדירות גבוהה, אולי לא כדאי להחזיק ב- cache).
- תדירות צריכת הנתונים (אעדיף להחזיק ב- cache נתונים שנצרכים יותר).

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

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

עד אז, בהצלחה.

טל

לאחרונה הושק Visual Studio 2010 ואיתו כמובן גם TFS2010. בכדי לסייע לכם לקפוץ ישר למים, קבוצת ה- Visual Studio ALM Rangers פרסמה את ה- Visual Studio 2010 Quick Reference Guidance . שם ניתן למצוא הסברים פשוטים וממוקדים על היכולות החדשות של VS2010, קצת ALM ו- TFS Deployment.

תהנו...