migration to the SAP HANA – הגירה, מעבר, שדרוג ל-HANA

6 במרץ 2017

הגירה אל מערכת סאפ חנה – /Preparation / Migration  SAP HANA

חלק 1

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

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

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

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

פלטפורמת SAP HANA דורשת שרתים עם נפח זיכרון גדול ובכך מבצעת את עיבוד הנתונים במהירות גדולה מאוד. בוא ניקח דוגמא לפני שנמשיך:
כיום ריצה של טרנזקציה FBL5 לוקחת כ-400 שניות, עם HANA זה יקח רק 3 שניות!

הגירה לHANA

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

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

אז לפי שאנחנו זורקים הכל ורצים לאנשי הביסייס וצועקים: שדרגו ל-HANA !!!  רגע רגע… בואו נחשוב מה כדי לעשות ומה צריך לפני שאנשי הבייסיס עטים על הטכנולוגיה החדשה.

לפני הכל – מה צריך?

תחילה אני מאוד מאוד מקווה שאתם

שומרים ונהנים מניתוח ועיבוד של הדוח ST03N. כי דוח זה ישמש אותנו ואת אנשי SAP לתת ניתוח מעמיק לקראת ההגירה של איזה מערכת/מודולים/כוח עיבוד/משתמשים.
באיזה רכיבים ותוכניות משתמשים יותר ובאיזה כוח העיבוד גדול הן של המסד נתונים והן של זיכרון המערכת.

חשוב מאוד לדעת כי החומרה אותה אנו רוכשים מתאימה. על כן יש לנו חברות כגון: יבמ, HP ועוד שמציעות לנו את המערכות שלהם. (בחלק מהחברות מערכת ה-HANA כבר מותקנת על לינוקס) חשוב מאוד, שאנשי הבייסיס בארגון אשר חשים ויודעים את המצב בשטח הם היו שותפים מלאים לתצורת החומרה. כפי שכתבתי מערכת SAP HANA עובדת בשיטה של in-memory (שרת עם הרבה זיכרון RAM) כך שהשרת/ים צריכים לדעת להסתדר עם מה שהארגון דורש מהם.

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

כמה זיכרון צריך? – הרבה !!!  דרישה לכמות הזיכרון תעבור תהליך של SAP אך כדי לעשות לכם קצת סדר בראש הנה נוסחה פשוטה: גודל הבסיס נתונים שלכם לחלק ל-2 בתוספת 25%.  כן… כן…  לא טעיתם…. לא!

תוכלו ג

ם להשתמש באתר: http://service.sap.com/quicksizer
וגם ב: https://www.sap.com/product/technology-platform/hana/implementation/sizing.html

אגב מי שממש רוצה להיות קצת יותר מדוייק יכול להפעיל את התוכנית: / SDF / HANA_BW_SIZING  במערכת ה- BI (אני ממליץ לפי כן לשדרג את רכיב ST-PI)  ומי שרוצה לבדוק במערכת ERP שלו בארגון שיישמם את הנוט/Note:
1872170 – Business Suite on HANA and S/4HANA sizing report

הריצה תפיק עבורכם דוח!

מומלץ לקרוא פוסט של תמכיה בחומרה תוכנה

חשבתם שזהו? אז לא!
כי מה שהסברנו זה רק על שרת עם המסד נתונים. יש לנו שרתי פיתוח ובדיקות. (אפשר להשתמש בורטואליות), אבל עבור מערכת הייצור יש צורך בשרת פיזי.
הזיכרון שדיברנו משמש את המסד נתונים. יש לקחת בחשבון שרתי אפליקציה נוספים.
היי… שכחתי לספר לכם ש-SAP HANA לא תומך ב-JAVA. מה???  כן… לא תומך ב-JAVA אלה רק ב-ABAP. אז מי שיש לו שרת עם ABAP+JAVA יבצע Split ואחר כך יבצע שדרוג/הגירה.
SAP HANA גם לא תומך במערכת שאינה יוניקוד.  וגם לא במערכת שאינה 64Bit.

רגע… יש דרך לבצע הגירה חכמה ומהירה בשלב אחד… זה נקרא DMO – מומלץ לקרוא בפוסט זה. שיטה זו מונעת מאיתנו שדרוג מקדים של בסיס נתונים ושל מערכת הסאפ/NW.

אני לא בטוח אך לדעתי יש צורך לבצע שדרוג מקדים ל-SOLMAN (לדעתי התמיכה כרגע היא 7.1  ו-7.0 עם SP23)

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

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

ביצוע ההגירה – בחלק  2

ממליץ לקרוא הקדמה בפוסט זה ו- בפוסט זה

 שחם לוי – Shacham Levi – ארכיטקט, מיישם ויועץ בכיר בחברת IBM.
Senior SAP Basis consultant.  מומחה בסיסי נתונים: SQL Server, DB2, ORACLE, SAP HANA.  התקנות, שדרוגים, T-SQL, ניטור ושיפור ביצועים. Performance Tuning , Query Optimization (תשתיתי ואפליקטיבי) מתכנת בכיר :  C#, WPF, .NET, ABAP, JAVA, Android . נותן שירות למגוון רחב של ארגונים.

הוסף תגובה
facebook linkedin twitter email