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

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

מה לא מועבר

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

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

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

קידוד נתונים

  • 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 לא מועברות ומופיעות כשגיאות בעבודת ההעברה.
  • טבלאות שנוצרו אחרי שההעברה התחילה לא יועברו אוטומטית. קודם כול, צריך לשלוף את הסכימה שלהם בסביבת העבודה של ההמרות, להחיל הגדרות שהומרו על היעד ולעדכן את משימת ההעברה.
  • לא ניתן להשתמש בטבלאות מקור שמכילות עמודות בינאריות ואין להן מפתחות ראשיים להעברת נתונים במיגרציות רציפות.

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

סוגי הנתונים הבאים לא נתמכים בהעברות של 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 יוצרות אוטומטית מפתחות ראשיים חסרים בטבלאות היעד כש ממירים את קוד המקור ואת הסכימה. אפשר גם להשבית את היצירה האוטומטית של מפתח ראשי באמצעות הוראת ההמרה GENERATE_MISSING_PK.

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

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

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

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

טריגרים

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

מפתחות זרים

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

המלצות

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

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

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

מכסות

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