מגבלות ידועות והמלצות

בדף הזה מתוארות המגבלות הידועות (כולל שיקולים מיוחדים לטיפול בישויות כמו מפתחות ראשיים או מפתחות זרים וטריגרים), וגם שיטות מומלצות להעברות הטרוגניות של Oracle באמצעות Database Migration Service.

מה לא מועבר

  • המשתמשים וההרשאות לא מועברים.
  • שינויים בסכימה שמתרחשים במהלך משימת העברה פעילה לא מועברים באופן אוטומטי. אם אתם משנים את הסכימה במהלך ההעברה, קודם צריך לעדכן את סביבת העבודה להמרת מסדי נתונים בשינויים בסכימה, ואז לרענן את משימות ההעברה הרלוונטיות. מידע נוסף זמין במאמר הוספת סכימה או טבלאות מעודכנות למשימת ההעברה.
  • הצהרות SAVEPOINT לא נתמכות ויכולות לגרום לאי-התאמה בנתונים במקרה של חזרה למצב קודם.
  • שירות Database Migration Service משכפל סוגי נתונים שמוגדרים על ידי המשתמש, אבל מאחסן רק את סוג הנתונים הבסיסי שממנו נגזרים הסוגים שמוגדרים על ידי המשתמש. לדוגמה, אם מגדירים סוג נתונים של USERNAME על סמך סוג הנתונים של VARCHAR2, הנתונים מאוחסנים ביעד בתור VARCHAR.

מסד נתונים, טרנזקציות ועקביות נתונים

  • ההעברה היא במודל עקביות הדרגתי, כי Database Migration Service לא משכפל כל טרנזקציה כשהיא מתרחשת. ההעברה כוללת נתונים מכמה טבלאות. הסדר שבו הנתונים נטענים ביעד עשוי להשתנות, אבל הוא יתיישר מחדש עם המקור אחרי שהכתיבה במקור תיפסק והמאגר הזמני של ההעברה יתרוקן.
  • בהעברות הטרוגניות של Oracle, אפשר להעביר רק מסד נתונים אחד בכל משימת העברה ב-Database Migration Service.
  • ‫Database Migration Service תומך בארכיטקטורה מרובת-דיירים של Oracle‏ (CDB/PDB), אבל אפשר להעביר רק מסד נתונים אחד שניתן לחיבור בכל משימת העברה.
  • ‫Oracle Label Security‏ (OLS) לא משוכפל.
  • יכול להיות שטרנזקציות שבוטלו במסד הנתונים של המקור במהלך תהליך ההעברה יופיעו ביעד באופן זמני (אם הטרנזקציה ארוכה מספיק).
  • ‫Database Migration Service לא תומך בקישוריות ישירה למסדי נתונים באמצעות התכונה Single Client Access Name‏ (SCAN) בסביבות Oracle Real Application Clusters‏ (RAC). במאמר פתרון בעיות שקשורות לשגיאות Oracle SCAN מפורטים פתרונות אפשריים לשימוש בקישוריות של רשימת היתרים של כתובות IP ציבוריות בסביבות כאלה.

קידוד נתונים

  • ‫Database Migration Service תומך רק בקידודים שמוגדרים ב-UTF8 למסד הנתונים של היעד. אין תמיכה בשמות של סכימות וטבלאות שכוללים תווים שלא נכללים בקבוצת הקידוד UTF8.
  • ‫Database Migration Service תומך בקידודים הבאים של מערכות תווים במסדי נתונים של Oracle:
    • AL16UTF16
    • AL32UTF8
    • IN8ISCII
    • IW8ISO8859P8
    • JA16SJIS
    • JA16SJISTILDE
    • KO16MSWIN949
    • US7ASCII
    • UTF8
    • WE8ISO8859P1
    • WE8ISO8859P9
    • WE8ISO8859P15
    • WE8MSWIN1252
    • ZHT16BIG5

טבלאות, סכימות ואובייקטים אחרים

  • במהלך ההעברה, אין תמיכה בשינויים של שפת הגדרת נתונים (DDL) בנתונים, בסכימות ובמטא-נתונים. אם מעדכנים את הסכימה במהלך ההעברה, צריך למשוך את השינויים לסביבת העבודה להמרת מסדי נתונים, להמיר את הקוד, לנקות את היעד ולהפעיל שוב את משימת ההעברה.
  • אין תמיכה בשמות של עמודות בטבלה שכוללים תווים שהם לא אלפאנומריים או קו תחתון (_).
  • האורך המקסימלי של שם טבלה או עמודה הוא 30 תווים. ‫Database Migration Service לא יכול לשכפל טבלאות שחורגות מהמגבלה הזו, או טבלאות שמכילות עמודות שהשמות שלהן חורגים מהמגבלה הזו.
  • אין תמיכה בטבלאות מאורגנות לפי אינדקס (IOT).
  • כדי להשתמש בטבלאות זמניות גלובליות, צריך להתקין וליצור את התוסף pgtt ל-PostgreSQL ביעד.
  • בעמודות מסוג BFILE, רק הנתיב לקובץ ישוכפל. תוכן הקובץ לא ישוכפל.
  • ב-Oracle 11g, טבלאות עם עמודות של סוגי הנתונים ANYDATA או UDT לא נתמכות, והטבלה כולה לא תשוכפל.
  • משימות שמתוזמנות באמצעות dbms_job או dbms_scheduler לא מועברות.
  • ההגדרות של התצוגות המהותיות מועברות, אבל הנתונים המהותיים שלהן לא מועברים. אחרי שמסיימים את ההעברה, מרעננים את התצוגות המהותיות כדי לאכלס אותן בנתונים מהטבלאות שהועברו.
  • ערכי הרצף מועברים, אבל הערכים שלהם במסד הנתונים של המקור עשויים להמשיך להתקדם לפני שההעברה תושלם. אחרי השלמת ההעברה, מעדכנים את ערכי הרצף במכונה של היעד כך שיתאימו לאלה שבמסד הנתונים של המקור.
  • משימות ההעברה מוגבלות ל-10,000 טבלאות.
  • גודל השורות מוגבל ל-100MB. שורות שחורגות מהמגבלה של 100MB לא מועברות, ומופיעות כשגיאות במשימת ההעברה.
  • טבלאות שנוצרות אחרי שההעברה מתחילה לא מועברות באופן אוטומטי. קודם צריך לשלוף את הסכימה שלהם בסביבת העבודה להמרת מסדי נתונים, להחיל את ההגדרות שהומרו על היעד ולעדכן את משימת ההעברה.
  • טבלאות מקור שמכילות עמודות בינאריות ואין להן מפתחות ראשיים לא נתמכות בהעברת נתונים בהעברות רציפות.
  • עמודות וירטואליות (GENERATED ALWAYS AS (...) VIRTUAL) לא משוכפלות במהלך העברת הנתונים, כי Oracle לא כותבת ערכים של עמודות וירטואליות ביומני Redo. אם עמודה וירטואלית היא חלק ממפתח ראשי מורכב, רק העמודות הלא וירטואליות משמשות כמפתח הראשי במהלך הרפליקציה.

מגבלות על סוגי הנתונים

סוגי הנתונים הבאים לא נתמכים בהעברות מ-Oracle:

  • ‫ANYDATA (ב-Oracle 11g, טבלאות עם ANYDATA לא נתמכות בכלל ולא משוכפלות).
  • BFILE
  • INTERVAL DAY TO SECOND
  • INTERVAL YEAR TO MONTH
  • LONG/LONG RAW
  • SDO_GEOMETRY
  • UDT
  • UROWID
  • XMLTYPE
  • אפס תאריכים בTIMESTAMP

שיקולים לגבי מפתחות ראשיים

טבלאות בלי מפתחות ראשיים לא מבטיחות רפליקציה עקבית. ‫Database Migration Service מעביר רק טבלאות שיש להן מפתחות ראשיים. אם מסד הנתונים של המקור כולל טבלאות שאין בהן מפתחות ראשיים, סביבות העבודה להמרת מסדי נתונים של Database Migration Service יוצרות באופן אוטומטי את המפתחות הראשיים החסרים בטבלאות היעד כש ממירים את קוד המקור והסכימה. כדי שהתהליך האוטומטי הזה יפעל, טבלאות המקור צריכות:

  • אין להם עדיין מפתחות ראשיים.
  • אל תגדירו אילוץ UNIQUE בלי עמודות שניתנות לאיפוס.
  • אל תשתמשו באינדקס UNIQUE בלי עמודות שניתנות לאיפוס.

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

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

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

שיקולים לגבי מפתחות זרים וטריגרים

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

טריגרים

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

מפתחות זרים

‫Database Migration Service לא משכפל נתונים בצורה טרנזקציונלית, ולכן יכול להיות שהטבלאות יועברו לא לפי הסדר. אם יש מפתחות זרים, וטבלת צאצא שמשתמשת במפתח זר מועברת לפני טבלת ההורה שלה, יכול להיות שיהיו שגיאות בשכפול.

המלצות

  • כש יוצרים את מסד הנתונים של Cloud SQL ביעד, חשוב לוודא שמשתמשים במשאבי מחשוב וזיכרון שמספיקים לצורכי ההעברה. מומלץ להשתמש בסוג מכונה עם מעבד בעל שתי ליבות לפחות.

    לדוגמה, אם שם המכונה הוא db-custom, ויש לה 2 מעבדים ו-RAM בנפח 3,840MB, הפורמט של שם סוג המכונה הוא db-custom-2-3840.

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

מכסות

  • בכל זמן נתון יכולים להיות עד 2,000 פרופילי חיבור ו-1,000 משימות העברה. כדי לפנות מקום, אפשר למחוק משימות העברה (כולל משימות שהושלמו) ופרופילי חיבור.