סביבות עבודה של המרות

סביבות עבודה להמרת מסדי נתונים עוזרות להמיר את הסכימה והאובייקטים ממסד הנתונים של המקור לתחביר SQL שתואם למסד הנתונים של היעד. בדף הזה מופיעה סקירה כללית על סביבות עבודה להמרת מסדי נתונים ב-Database Migration Service:

יש סוגי נתונים מסוימים שלא נתמכים בהעברות מ-Oracle. מידע נוסף זמין במאמר מגבלות ידועות של סוגי נתונים.

אפשרויות אתחול של סכמת המקור

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

  • חיבור ישיר למסד נתונים: השירות Database Migration Service מתחבר ישירות למסד הנתונים הפעיל במקור באמצעות פרופיל חיבור, ומאחזר את הסכימה דרך חיבור לרשת.
  • קובצי סכימה ב-Cloud Storage: אתם יכולים לחלץ את המטא-נתונים של הסכימה באופן מקומי באמצעות סקריפטים לחילוץ ש-Google מספקת, להעלות את הקבצים שנוצרו לקטגוריה של Cloud Storage ולהכין את סביבת העבודה בלי להתחבר למסד הנתונים של המקור.

במאמר יצירת סביבת עבודה להמרת מסדי נתונים מוסבר איך ליצור את סביבת העבודה להמרת מסדי נתונים באמצעות חיבור ישיר למסד נתונים או באמצעות קובצי סכימה ב-Cloud Storage.

סקירות כלליות של התקדמות ההמרה

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

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

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

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

איך משתמשים בסביבות עבודה להמרת מסדי נתונים

המרת קוד וסכימה דטרמיניסטית

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

המרת קוד דטרמיניסטית תומכת באובייקטים הבאים של מסד נתונים של Oracle:

רכיבי סכימה נתמכים של Oracle

  • מגבלות
  • אינדקסים (רק אינדקסים שנוצרו באותה סכימה כמו הטבלה שלהם)
  • תצוגות מהותיות
  • סוגי אובייקטים (תמיכה חלקית)
  • רצפים
  • מילים נרדפות
  • Tables
  • תצוגות

רכיבי קוד נתמכים של Oracle

  • טריגרים (ברמת הטבלה בלבד)
  • חבילות
  • פונקציות
  • נהלים מאוחסנים

עורך SQL אינטראקטיבי

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

אובייקטים של Oracle שאפשר לערוך

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

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

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

אובייקטים שלא נתמכים לעריכה:

  • סוגי אובייקטים שמוגדרים על ידי המשתמש
  • Tables
  • סכימות

המרת קוד וסכימה מהר יותר בעזרת Gemini

‫Database Migration Service משלב את Gemini ב- Google Cloud בסביבות עבודה להמרת מסדי נתונים, כדי לעזור לכם לזרז ולשפר את תהליך ההמרה בתחומים הבאים:

  • כדי לשפר את התוצאות של ההמרה הדטרמיניסטית, אתם יכולים להשתמש בהמרה אוטומטית מבוססת-Gemini. כך תוכלו להשתמש ביכולות של ה-AI כדי לצמצם משמעותית את מספר ההתאמות הידניות שצריך לבצע בקוד PostgreSQL.

  • הערכות איכות שמבוססות על Gemini מאפשרות לוודא שהקוד שהומר הוא איכותי ופועל כמו שצריך. ההערכות האלה מנתחות את הקוד שהומר, ומספקות משוב על התקינות והפונקציונליות שלו בהשוואה לקוד המקור.

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

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

מידע נוסף על המרה באמצעות Gemini זמין בדפים הבאים:

קובצי מיפוי המרות

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

הוראות המרה נתמכות

‫Database Migration Service תומך בהוראות ההמרה הבאות לקובצי מיפוי המרות:

EXPORT_SCHEMA

EXPORT_SCHEMA היא הנחיה חובה בכל קובצי מיפוי ההמרות. ההוראה הזו נדרשת ב-Database Migration Service כדי לוודא שהסכימות של המקור מומרות לסכימות הנכונות של היעד. חשוב לוודא שקובצי מיפוי ההמרות כוללים את השורה הזו: 

EXPORT_SCHEMA 1

SCHEMA

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

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

צריך להשתמש בפורמט הבא:

SCHEMA SCHEMA_NAME

כאשר SCHEMA_NAME הוא שם הסכימה במסד הנתונים של המקור.

CASE_HANDLING

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

  • ההוראה הזו לא מושפעת מההוראה SCHEMA. הוא פועל באופן גלובלי ומשפיע על כל האובייקטים בסביבת העבודה להמרת מסדי נתונים.
  • ההוראות RENAME_*,‏ MOVE_* ו-REPLACE_* מקבלות עדיפות על פני ההוראה CASE_HANDLING, ומשנות את שמות האובייקטים בדיוק, בלי קשר למאפיין CASE_HANDLING.
  • אם ההוראה הזו קיימת בכמה קובצי תצורה עם ערכים סותרים, Database Migration Service יציג שגיאה במהלך ייבוא הסכימה.

צריך להשתמש בפורמט הבא:

CASE_HANDLING OPTION

כאשר OPTION יכול להיות אחד מהערכים הבאים:

  • ‫UPPERCASE: המרת כל שמות האובייקטים לאותיות רישיות.
  • ‫LOWERCASE: המרת כל שמות האובייקטים לאותיות קטנות (פעולת ברירת המחדל).
  • ‫PRESERVE_ORIGINAL: שמירה על האותיות הרישיות המקוריות מסכימת המקור. האפשרות הזו שימושית אם האפליקציות שלכם משתמשות במזהים תלויי אותיות רישיות.

דוגמה:

CASE_HANDLING PRESERVE_ORIGINAL

GENERATE_MISSING_PK

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

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

דוגמה:

GENERATE_MISSING_PK 0

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

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

יצירת מפתחות ראשיים באמצעות עמודות קיימות

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

ALTER TABLE TABLE_NAME
ADD PRIMARY KEY (COLUMN_NAME);

יצירת מפתח ראשי באמצעות כל העמודות

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

ALTER TABLE TABLE_NAME
ADD PRIMARY KEY (COLUMN_NAME_1, COLUMN_NAME_2, COLUMN_NAME_3, ...);

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

יצירת אילוץ ייחודי באמצעות העמודה המדומה ROWID

מסדי נתונים של Oracle משתמשים בעמודה המדומה ROWID כדי לאחסן את המיקום של כל שורה בטבלה. כדי להעביר טבלאות Oracle שאין להן מפתחות ראשיים, אפשר להוסיף עמודת ROWID במסד הנתונים של PostgreSQL ביעד. ‫Database Migration Service מאכלס את העמודה בערכים המספריים התואמים מהעמודה המדומה ROWID של Oracle במקור.

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

ALTER TABLE TABLE_NAME ADD COLUMN rowid numeric(33,0) NOT NULL;
CREATE SEQUENCE TABLE_NAME_rowid_seq INCREMENT BY -1 START WITH -1 OWNED BY TABLE_NAME.rowid;
ALTER TABLE TABLE_NAME ALTER COLUMN rowid SET DEFAULT nextval('TABLE_NAME_rowid_seq');
ALTER TABLE TABLE_NAME ADD CONSTRAINT CONSTRAINT_DISPLAY_NAME PRIMARY KEY (rowid);

שינוי שם של אובייקטים (RENAME_*)

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

תחביר כללי

RENAME_OBJECT_TYPE SOURCE_NAME1:DESTINATION_NAME1 SOURCE_NAME2:DESTINATION_NAME2 ...

שיקולים חשובים

  • ההוראות של RENAME_* תלויות אותיות רישיות בשם של אובייקט היעד, והן מקבלות עדיפות על פני ההוראה CASE_HANDLING. לדוגמה, אם משתמשים בשתי ההוראות: 

    SCHEMA MySchema
CASE_HANDLING PRESERVE_ORIGINAL
# Destination objects are renamed exactly
# to 'SoMe_tAbLe' and 'RenamedView', respecting the case
# despite the CASE_HANDLING directive
RENAME_TABLES some_table:SoMe_tAbLe
RENAME_VIEWS MyView:RenamedView

  • ב-SOURCE_NAME, תמיד צריך להתייחס לשם האובייקט המקורי, גם אם משתמשים בהוראות אחרות כמו MOVE_*. לדוגמה, אם רוצים לשנות את השם של אחד מאובייקטי התצוגה ולהעביר אותו לסכימה חדשה, צריך להתייחס לשם התצוגה המקורי בשתי ההוראות: 

    RENAME_VIEWS MyView:MyRenamedView
MOVE_VIEWS MyView:MyOtherSchema
  • ההוראה RENAME_TABLES מבטלת את ההוראה REPLACE_TABLES בקובץ יחיד. אם רוצים גם לשנות את השם של הטבלה וגם להעביר אותה, מומלץ להשתמש במקום זאת בהוראה MOVE_*.

  • הפורמט המלא של המשתנה SOURCE_NAME תלוי בשאלה אם משתמשים גם בהוראה SCHEMA:

    • עם ההוראה SCHEMA: משתמשים בשמות לא מוגדרים, לדוגמה MyTable.
    • בלי ההוראה SCHEMA: משתמשים בשמות המלאים, לדוגמה MySchema.MyTable.

הוראות RENAME_* נתמכות

  • ‫RENAME_SCHEMA: שינוי שם של סכימה.
    קובץ תצורה אחד יכול להכיל רק הוראת RENAME_SCHEMA אחת. אם מספקים את ההוראה SCHEMA, RENAME_SCHEMA יכול לשנות את השם רק של הסכימה הספציפית הזו.
  • ‫RENAME_TABLES: שינוי שמות של טבלאות. מבטל את ההגדרה של REPLACE_TABLES באותו קובץ.
  • ‫RENAME_COLUMNS: שינוי שמות של עמודות בטבלאות. מבטלת את ההוראה REPLACE_COLS באותו קובץ. צריך להשתמש בפורמט הבא: 
    RENAME_COLUMNS TABLE1.SRC_COL:DEST_COL TABLE2.SRC_COL:DEST_COL

    אם משתמשים בהוראה SCHEMA, צריך להשתמש בשמות טבלאות לא מוגדרים. אם לא משתמשים בהוראה SCHEMA, צריך לכלול את שמות הטבלאות המלאים, כמו SCHEMA.TABLE1.

  • RENAME_VIEWS
  • RENAME_MATERIALIZED_VIEWS
  • RENAME_SEQUENCES
  • RENAME_FUNCTIONS
  • RENAME_STORED_PROCEDURES
  • RENAME_TRIGGERS

  • ‫RENAME_PACKAGES: ‏Database Migration Service ממיר חבילות של Oracle לסכימות של PostgreSQL. אם הסכימה מכילה חבילות עם שמות זהים, יכול להיות שקוד PostgreSQL ייתקל בהתנגשויות שמות כשהוא ינסה ליצור שתי סכימות עם אותו שם. אפשר להשתמש בהוראה הזו כדי למנוע התנגשויות כאלה.

    ‫לדוגמה, אם יש לכם חבילות כמו SALES.REPORTING_PKG ו-HR.REPORTING_PKG, אתם יכולים לשנות את השמות שלהן לשמות נפרדים: 

    RENAME_PACKAGES SALES.UTILS:SALES_UTILS
RENAME_PACKAGES HR.UTILS:HR_UTILS

  • RENAME_USER_DEFINED_TYPES

    כינוי זמין: RENAME_UDTS.

אובייקטים בתנועה (MOVE_*)

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

תחביר כללי

MOVE_OBJECT_TYPE SOURCE_NAME1:DESTINATION_SCHEMA1 SOURCE_NAME2:DESTINATION_SCHEMA2 ...

שיקולים חשובים

  • ב-SOURCE_NAME, תמיד צריך להתייחס לשם האובייקט המקורי, גם אם משתמשים בהוראות אחרות כמו RENAME_*. לדוגמה, אם רוצים לשנות את השם של אחד מאובייקטי התצוגה ולהעביר אותו לסכימה חדשה, צריך להתייחס לשם התצוגה המקורי בשתי ההוראות: 

    RENAME_VIEWS MyView:MyRenamedView
MOVE_VIEWS MyView:MyOtherSchema
  • ההוראה מצפה רק לשם של DESTINATION_SCHEMA, ולא לשם האובייקט המלא.

  • הפורמט המלא של המשתנה SOURCE_NAME תלוי בשאלה אם משתמשים גם בהוראה SCHEMA:

    • עם ההוראה SCHEMA: משתמשים בשמות לא מוגדרים, לדוגמה MyTable.
    • בלי ההוראה SCHEMA: משתמשים בשמות המלאים, לדוגמה MySchema.MyTable.

הוראות MOVE_* נתמכות

  • ‫MOVE_TABLES: העברת טבלאות לסכימה אחרת. ההגדרה הזו מקבלת עדיפות על פני REPLACE_TABLES לשינויים בסכימה בקובץ תצורה יחיד.
  • MOVE_VIEWS
  • MOVE_MATERIALIZED_VIEWS
  • MOVE_SEQUENCES
  • MOVE_FUNCTIONS
  • MOVE_STORED_PROCEDURES

  • MOVE_USER_DEFINED_TYPES

    כינוי זמין: MOVE_UDTS.

דוגמה: ארגון מחדש של סכימות

SCHEMA LegacyApp

# Moves the 'LegacyApp.Users' and 'LegacyApp.Orders' tables
# to the 'data' schema.
MOVE_TABLES Users:data Orders:data

# Moves the 'LegacyApp.CreateUser' and 'LegacyApp.ProcessOrder'
# stored procedures to the 'api' schema
MOVE_STORED_PROCEDURES CreateUser:api ProcessOrder:api

# Moves the 'LegacyApp.SalesSummary' views to the 'reporting' schema
MOVE_VIEWS SalesSummary:reporting

DATA_TYPE

אתם יכולים להשתמש בהוראה הזו כדי למפות באופן מפורש כל סוג נתונים נתמך בין התחביר של Oracle לבין התחביר של PostgreSQL. ההוראה הזו מצפה לרשימה של מיפויים שמופרדים בפסיקים. צריך לספק את כל ההגדרה בשורה אחת, אבל אתם כוללים כמה הוראות DATA_TYPE בקובץ התצורה. צריך להשתמש בפורמט הבא: 

DATA_TYPE ORACLE_DATA_TYPE1:PGSQL_DATA_TYPE1
DATA_TYPE ORACLE_DATA_TYPE2:PGSQL_DATA_TYPE2...

כאשר ORACLE_DATA_TYPE ו-PGSQL_DATA_TYPE הם סוגי נתונים שנתמכים בגרסאות Oracle ו-PostgreSQL שבהן אתם משתמשים בהעברה. למידע על הגרסאות הנתמכות, קראו את הסקירה הכללית של התרחיש.

דוגמה:

DATA_TYPE REAL:double precision,SMALLINT:integer

למידע נוסף על סוגי הנתונים של Oracle ו-PostgreSQL, קראו את המאמרים הבאים:

MODIFY_TYPE

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

MODIFY_TYPE SOURCE_TABLE_NAME1:COLUMN_NAME:EXPECTED_END_RESULT_DATA_TYPE
MODIFY_TYPE SOURCE_TABLE_NAME2:COLUMN_NAME:EXPECTED_END_RESULT_DATA_TYPE...

כאשר:

  • ‫SOURCE_TABLE_NAME הוא שם הטבלה שמכילה את העמודה שבה רוצים לשנות את סוג הנתונים.
  • ‫COLUMN_NAME הוא שם העמודה שבה רוצים להתאים אישית את מיפוי ההמרות.
  • ‫EXPECTED_END_RESULT_DATA_TYPE הוא סוג הנתונים של PostgreSQL שרוצים להשתמש בו בעמודה שהומרה.

דוגמה:

MODIFY_TYPE events:dates_and_times:DATETIME,users:pseudonym:TEXT

PG_INTEGER_TYPE

כברירת מחדל,Database Migration Service ממיר את הסוגים של NUMBER(p,s) לסוג DECIMAL(p,s) של PostgreSQL.

אפשר לשנות את ההתנהגות הזו באמצעות ההוראה PG_INTEGER_TYPE. מגדירים את הערך שלו ל-1 ומאלצים את כל סוגי ה-NUMBER עם דיוק וקנה מידה (NUMBER(p,s)) להמיר לסוגי smallint,‏ integer או bigint של PostgreSQL, על סמך מספר הספרות של הדיוק.

צריך לכלול את ההגדרה הבאה בקובץ מיפוי ההמרות: 

PG_INTEGER_TYPE 1

PG_NUMERIC_TYPE

מגדירים את ההוראה הזו לערך 1 אם רוצים להמיר את כל סוגי ה-NUMBER עם דיוק וקנה מידה (NUMBER(p,s)) לסוגי real או float של PostgreSQL (על סמך מספר הספרות של הדיוק).

אם מגדירים את ההוראה הזו לערך 0, הערכים של NUMBER(p,s) נשמרים בדיוק כמו שהם במקור ומשתמשים בסוג הנתונים הפנימי של PostgreSQL.

צריך לכלול את ההגדרה הבאה בקובץ מיפוי ההמרות: 

PG_NUMERIC_TYPE 1

DEFAULT_NUMERIC

ההמרה שמוגדרת כברירת מחדל לערכי NUMBER בלי דיוק משתנה אם משתמשים גם בהוראה PG_INTEGER_TYPE:

  • אם משתמשים בהוראה PG_INTEGER, ערכי NUMBER ללא דיוק מומרים לערכי DECIMAL.
  • אם לא משתמשים בהוראה PG_INTEGER, ערכי NUMBER ללא דיוק מומרים לערכי BIGINT.

אפשר לשנות את ההתנהגות הזו ולהשתמש בהוראה DEFAULT_NUMERIC כדי לציין באיזה סוג נתונים צריך להשתמש לסוגי NUMBER בלי נקודות דיוק שצוינו. צריך להשתמש בפורמט הבא: 

DEFAULT_NUMERIC POSTGRESQL_NUMERIC_DATA_TYPE

כאשר POSTGRESQL_NUMERIC_DATA_TYPE הוא אחד מהערכים הבאים: integer,‏ smallint,‏ bigint.

דוגמה:

DEFAULT_NUMERIC integer

REPLACE_COLS

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

צריך להשתמש בפורמט הבא: 

REPLACE_COLS SOURCE_TABLE_NAME1(SOURCE1_TABLE1_COLUMN_NAME1:DESTINATION_TABLE1_COLUMN_NAME1,SOURCE_TABLE1_COLUMN_NAME2:DESTINATION_TABLE1_COLUMN_NAME2),SOURCE_TABLE_NAME2(SOURCE_TABLE2_COLUMN_NAME1:DESTINATION_TABLE2_COLUMN_NAME1,SOURCE_TABLE2_COLUMN_NAME2:DESTINATION_TABLE2_COLUMN_NAME2)...

כאשר:

  • ‫SOURCE_TABLE_NAME הוא שם הטבלה שמכילה את העמודה שאת השם שלה רוצים לשנות. אם לא משתמשים בהוראה SCHEMA, צריך להשתמש בשם הטבלה המלא: SCHEMA_NAME.SOURCE_TABLE_NAME
  • ‫SOURCE_COLUMN_NAME הוא שם העמודה במקור שאת השם שלה רוצים לשנות.
  • ‫DESTINATION_COLUMN_NAME הוא השם החדש של העמודה שבה רוצים להשתמש בסכימה שהומרה.

דוגמה:

REPLACE_COLS events(dates_and_times:event_dates),users(pseudonym:nickname)

REPLACE_TABLES

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

אם לא משתמשים בהוראה SCHEMA, צריך להשתמש בשמות המלאים של הטבלאות במירכאות גם למשתני המקור וגם למשתני היעד:

  • "SCHEMA_NAME.SOURCE_TABLE_NAME"
  • "SCHEMA_NAME.DESTINATION_TABLE_NAME"

שינוי שמות של טבלאות

כדי לשנות את השמות של הטבלאות בסכימה שהומרה, משתמשים בפורמט הבא:

REPLACE_TABLES SOURCE_TABLE_NAME1:DESTINATION_TABLE_NAME1 SOURCE_TABLE_NAME2:DESTINATION_TABLE_NAME2

כאשר:

  • ‫SOURCE_TABLE_NAME הוא השם של טבלת המקור שרוצים לשנות בסכימה שהומרה.
  • ‫DESTINATION_TABLE_NAME הוא השם החדש של הטבלה שבה רוצים להשתמש בסכימה שהומרה.

דוגמה:

REPLACE_TABLES "events:login_events" "users:platform_users"

העברת טבלאות בין סכימות

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

REPLACE_TABLES "events:NEW_SCHEMA_NAME.login_events"

כינויים להתאמה אישית של סוגי נתונים

כשמשתמשים בהוראות המרה כדי לשנות את האופן שבו Database Migration Service ממיר סוגי נתונים שונים (לדוגמה, באמצעות ההוראות DATA_TYPE,‏ MODIFY_TYPE או PG_NUMERIC_TYPE), אפשר להשתמש בכינויים במקום בסוגי הנתונים של SQL במקור.

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

כינויים של סוגי נתונים

כינוי ההמרה לסוג PostgreSQL
bigint, int8 BIGINT
bool, boolean BOOLEAN
bytea BYTEA
char, character CHAR
character varying, varchar VARCHAR
date DATE
decimal, numeric DECIMAL
double precision, float8 DOUBLE PRECISION
real, float4 REAL
int, integer, int4 INTEGER
int2 SMALLINT
interval INTERVAL
json JSON
smallint SMALLINT
text TEXT
time TIME
timestamp TIMESTAMP
timestamptz TIMESTAMPTZ
timetz TIMETZ
uuid UUID
XML XML

קובץ מיפוי המרות לדוגמה

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

EXPORT_SCHEMA 1
SCHEMA root

# Preserve original casing for all objects
CASE_HANDLING PRESERVE_ORIGINAL

# Data type conversions
PG_NUMERIC_TYPE 0
PG_INTEGER_TYPE 1
DEFAULT_NUMERIC integer
DATA_TYPE NUMBER(4\,0):integer
MODIFY_TYPE events:dates_and_times:TIMESTAMP

# Renaming objects using the RENAME_* directives
# These allow case-sensitive destination names
RENAME_TABLES events:LoginEvents users:PlatformUsers
RENAME_COLUMNS events.dates_and_times:EventDates users.pseudonym:Nickname
RENAME_VIEWS InternalReport:FinInternalReport

# Moving objects to new schemas using the MOVE_* directives
MOVE_TABLES audit_log:archive
MOVE_VIEWS InternalReport:reporting

אלה התוצאות של השימוש בקובץ הזה:

  • ‫EXPORT_SCHEMA 1 היא הוראה חובה.
  • ‫SCHEMA root גורם להנחיות האחרות לחול על אובייקטים בסכימה root, אלא אם משתמשים בשמות מלאים.
  • CASE_HANDLING PRESERVE_ORIGINAL מבטיח שכל שמות האובייקטים מהסכימה root של המקור ישמרו על האותיות הרישיות המקוריות שלהם ביעד (אלא אם הם הוחלפו על ידי הוראת RENAME_*).
  • ‫PG_INTEGER_TYPE 1 גורם ל-Database Migration Service להמיר את כל סוגי הנתונים המספריים של Oracle שנמצאים בטבלאות בסכימה root לסוגים ספציפיים ל-PostgreSQL, במקום לסוגים מספריים ניידים של ANSI.
  • ‫DEFAULT_NUMERIC integer גורם ל-Database Migration Service להמיר ערכי NUMBER שאין להם נקודת דיוק מוגדרת לסוג INTEGER של PostgreSQL.
  • DATA_TYPE NUMBER(4\,0):integer גורם ל-Database Migration Service להמיר ערכי NUMBER(4,0) ספציפיים ל-INTEGER של PostgreSQL.
  • ההוראה MODIFY_TYPE events:dates_and_times:TIMESTAMP גורמת ל-Database Migration Service להמיר את הנתונים בעמודה dates_and_times בטבלת המקור events באופן ספציפי לסוג TIMESTAMP של PostgreSQL.
  • RENAME_TABLES events:LoginEvents users:PlatformUsers משנה את שמות הטבלאות, תוך שמירה על האותיות הרישיות שצוינו:
    • השם של הטבלה events משתנה ל-LoginEvents.
    • השם של הטבלה users משתנה ל-PlatformUsers.
  • RENAME_COLUMNS events.dates_and_times:EventDates user.pseudonym:Nickname משנה את שמות העמודות, תוך שמירה על אותיות רישיות או קטנות ביעד:
    • בטבלה LoginEvents (השם המקורי events), השם של העמודה dates_and_times השתנה ל-EventDates.
    • ב-PlatformUsers (השם המקורי users), השם של העמודה pseudonym השתנה ל-Nickname.
  • ‫RENAME_VIEWS InternalReport:FinInternalReport משנה את השם של התצוגה InternalReport ל-FinInternalReport.
  • הפקודה MOVE_TABLES audit_log:archive מעבירה את הטבלה audit_log מהסכימה root לסכימה archive.
  • ‫MOVE_VIEWS InternalReport:reporting מעביר את התצוגה InternalReport לסכימה reporting. גם השם של התצוגה הזו משתנה ל-FinInternalReport בגלל ההוראה RENAME_VIEWS. ‫Database Migration Service מטפל ביחסי התלות: קודם משנים את שם האובייקט ואז מעבירים אותו.

סביבות עבודה מדור קודם להמרת מסדי נתונים

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

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

המאמרים הבאים

מידע נוסף על השימוש בסביבות עבודה להמרת מסדי נתונים: