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

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

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

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

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

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