אבחון בעיות בהעברות מ-Oracle ל-Cloud SQL ל-PostgreSQL

בדף הזה מפורטות שגיאות מוכרות ופעולות מומלצות לפתרון בעיות שקשורות ל:

שגיאות בעבודת ההעברה

יכול להיות שיתרחשו שגיאות במהלך זמן הריצה של תהליך העברת המשימות.

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

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

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

תיאור הבעיה סיבות אפשריות פעולות שכדאי לנסות
הודעת שגיאה: Database Migration Service can't set up a tunnel to be connected to the bastion host. ל-Database Migration Service אין גישה ליעד המבוצר (bastion host) או שהיעד המבוצר (bastion host) לא מקבל חיבורים. צריך לבדוק את ההגדרות של מנהרת ה-SSH להעברת נתונים ב פרופיל החיבור למקור וב הגדרות השרת של מנהרת ה-SSH, ולנסות שוב.
הודעת שגיאה: Database Migration Service can't connect to the database או Database Migration Service private connectivity error, cannot connect to the database. Database Migration Service לא הצליח ליצור קישוריות למסד הנתונים של Oracle כמקור.

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

אם יש קוד שגיאה ספציפי של Oracle, למשל ORA-12170: TNS:Connect timeout occurred, אפשר לעיין ב מסמכי Oracle לקבלת מידע נוסף.

הודעת שגיאה: Archiving mode is not ARCHIVELOG. מסד הנתונים של המקור לא פועל במצב ARCHIVELOG. מגדירים את מסד הנתונים של המקור לשימוש במצב ARCHIVELOG. מידע נוסף זמין במאמר בנושא הגדרת מסד נתוני Oracle כמקור.
הודעת שגיאה: Supplemental logging ("ALL COLUMN LOGGING") isn't turned on for the tables listed below. במסד הנתונים של המקור לא מופעלים נתוני יומן משלימים. מפעילים את הנתונים המשלימים ביומן ומגדירים את המצב שלהם ל-ALL. מידע נוסף זמין במאמר בנושא הגדרת מסד נתוני Oracle כמקור.
הודעת שגיאה: No Archive Log Files were found in the source. Database Migration Service קורא רק יומני ארכיון סגורים, ולא נמצאו יומנים במסד הנתונים של המקור.
  1. מריצים את הפקודה הבאה במסד הנתונים של המקור כדי לסגור את קובץ היומן הנוכחי: ALTER SYSTEM SWITCH LOGFILE.
  2. מנסים למצוא את היומנים שוב.

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

הודעת שגיאה: We're missing the necessary permissions to read from the source. לחשבון המשתמש של ההעברה במסד הנתונים של המקור אין את ההרשאות הנדרשות.

Database Migration Service מתחבר למקור בתור חשבון המשתמש שהגדרתם בפרופיל של חיבור המקור. לחשבון הזה צריך להיות סט ספציפי של הרשאות (למשל SELECT ANY TABLE) כדי לקרוא נתונים במסד הנתונים של המקור.

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

הודעת שגיאה: Unable to connect to the destination database. הייתה בעיה בהתחברות למסד הנתונים של היעד. מוודאים שיש לכם גישה למסד נתוני היעד מהפרויקט. בודקים את ההגדרות שקשורות ל שיטת ההגדרה של קישוריות היעד.
הודעת שגיאה: The following tables don't exist in the destination database: {table_names}. הטבלאות שמופיעות ברשימה שניסיתם להעביר לא קיימות במסד הנתונים של היעד. Database Migration Service יוצר את הטבלה וההגדרות הנדרשות כשממירים את סכמת המקור.
הודעת שגיאה: password authentication failed for user {username}. שם המשתמש או הסיסמה של מסד הנתונים של היעד לא הוגדרו בצורה נכונה. מוודאים שפרופיל החיבור של PostgreSQL ליעד מוגדר בצורה נכונה עם שם המשתמש והסיסמה הנכונים.
הודעת שגיאה: The following tables in the destination database don't have primary keys: {table_names}. הטבלאות שמפורטות בהודעת השגיאה קיימות במסד הנתונים של היעד, אבל חסרים בהן מפתחות ראשיים.

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

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

אזהרה: The following tables have foreign keys: {table_names}. הטבלאות שמפורטות בהודעת השגיאה קיימות במסד הנתונים של היעד, אבל יש להן מפתחות זרים.

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

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

הודעת שגיאה: Unable to resume replication as log position is lost. השגיאה הזו עשויה להתרחש אם תהליך השכפול מושהה למשך זמן רב, מה שמוביל לאובדן של מיקום היומן. לא מומלץ להשהות את משימת ההעברה למשך זמן ארוך יותר מתקופת השמירה של היומן (או קרוב לכך). אם מיקום היומן אבד, צריך ליצור מחדש את משימת ההעברה.
הודעת שגיאה: ORA-00942: table or view does not exist. השגיאה הזו עשויה להתרחש כתוצאה משמירת נתונים במטמון בשרת Oracle. כדי לפתור את בעיית השמירה במטמון, צריך ליצור מחדש את משתמש מסד הנתונים.
משימת ההעברה נשארת בשלב של יצירת עותק מלא ולא עוברת לשלב של סימון נתונים שהשתנו (CDC). שירות העברת מסדי נתונים עדיין מבצע גיבוי מלא של חלק מהטבלאות, או שלא ניתן להשלים גיבוי מלא של טבלה אחת או יותר בגלל שגיאות.
  • בודקים את השגיאות במשימת ההעברה ומתקנים את השגיאות שחלות על הטבלאות או מסירים את הטבלאות המשויכות מהמשימה.
  • בודקים את היומנים של שירות העברת מסדי הנתונים כדי לראות אם יש פעילות של גיבוי מלא, ומחכים עד שהיא מסתיימת.

בעיות קישוריות

בקטע הזה מפורטים שלבים לפתרון בעיות אפשריות בקישוריות לרשת.

אי אפשר להתחבר למסד הנתונים של היעד: EOF

הפעלת בדיקת קישוריות מחזירה את הודעת השגיאה [DATABASE] unable to connect to the destination database: EOF.

סיבה אפשרית: קובץ ה-Service Attachment מוגדר באופן שגוי.

מה אפשר לנסות: מוודאים שהערך של enable_proxy_protocol מוגדר ל-false ב קובץ התצורה של Terraform לצירוף שירות. פרוטוקול Proxy נתמך רק בשרתי HTTP כמו NGINX ו-Apache.

כשמשתמשים ב-gcloud כדי ליצור את ההגדרה של Private Service Connect, פרוטוקול ה-Proxy מושבת כברירת מחדל.

תם הזמן הקצוב לחיבור, החיבור נדחה

הפעלת בדיקת הקישוריות נכשלת או שהזמן הקצוב לתפוגה שלה מסתיים. הסיבה הסבירה ביותר לכך היא ניתוב שהוגדר בצורה שגויה בהגדרת Private Service Connect. יכולות להיות כמה סיבות לבעיה הזו.

סיבה אפשרית: חסר כלל בחומת האש שמאפשר לטווח כתובות ה-CIDR של NAT של Private Service Connect לגשת לתת-הרשת של Private Service Connect שבה ממוקם ה-bastion, ובאופן ספציפי לממשק nic0 של מכונת ה-bastion.

מה אפשר לנסות: מוודאים שמדיניות הארגון לא מגבילה כללים פנימיים של חומת האש, כמו כלל חומת האש psc_sp_in_fw שמוגדר בתסריט לדוגמה של Terraform ל הגדרת קישוריות של כתובות IP פרטיות ליעד במכונות Cloud SQL שלא מופעל בהן PSC.

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

מה אפשר לנסות: אפשר לנסות ליצור חיבור SSH למכונת ה-bastion ולחפש את ה-proxy באמצעות הפקודה הבאה:

  • netstat -tunalp | grep PORT

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

  • אם מקבלים תגובה ריקה, השרת הפרוקסי מושבת. מנסים להריץ את הפקודות הבאות:

    sudo su; cd / ובודקים אם שרת Dante מותקן על ידי הפעלת sudo dpkg -s dante-server:

  • אם ה-proxy פועל ומאזין ביציאה שצוינה, נסו לפתוח אליו חיבור באופן הבא:

    1. מתקינים את לקוח PostgreSQL:

      sudo apt-get install postgresql-client.

    2. מתחברים למסד הנתונים של PostgreSQL:

      psql -h 127.0.0.1 -p PORT -U DBUSERNAME -W (תוצג בקשה להזין את הסיסמה).

      מחליפים את מה שכתוב בשדות הבאים:

      • ‫PORT: מספר היציאה של מסד הנתונים.
      • ‫DBUSERNAME: שם המשתמש שמשמש לחיבור למסד הנתונים של PostgreSQL.

    3. מתקינים את לקוח telnet:

      sudo apt-get install telnet

    4. מתחברים ללקוח telnet:

      telnet 127.0.0.1 PORT

      מחליפים את PORT במספר היציאה של מסד הנתונים.

    בהתאם לתוצאות של הפקודות:

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

    • אם החיבור נפתח באמצעות telnet אבל נתקע בלקוח, סביר להניח שהבעיה היא ניתוב של כתובת ה-IP של ה-bastion. במכונה הווירטואלית, מקלידים ip route בטרמינל. בודקים אם יש כלל ניתוב שמנתב חיבורים לכתובת ה-IP הפרטית של מכונת Cloud SQL באמצעות nic המשני (nic1, כתובת ה-IP של DB_SUBNETWORK_GATEWAY).

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

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

  • במסוף Google Cloud , עוברים אל Private Service Connect.

    כניסה אל Private Service Connect

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

  • אם הבקשה נדחית, מוסיפים את הפרויקט ששלח את הבקשה לפרויקטים ברשימת ההיתרים בחיבור השירות.

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

  • מוחקים את פרופיל הקישור שמשויך לקישוריות של Private Service Connect ויוצרים אותו מחדש.

פתרון בעיות שקשורות ל-Oracle SCAN

בקטע הזה מתוארות בעיות פוטנציאליות שאתם עשויים להיתקל בהן כשאתם מבצעים מיגרציה ממקורות של Oracle Real Application Clusters ‏ (RAC) באמצעות התכונה Single Client Access Name ‏ (SCAN).

אין אפשרות ליצור קישוריות למסד נתונים של Oracle SCAN

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

סיבה אפשרית: יכול להיות שאתם מנסים ליצור קישוריות ישירות למסד הנתונים של מקור Oracle SCAN. שירות העברת מסדי נתונים לא תומך בקישוריות ישירה למסדי נתונים באמצעות התכונה SCAN בסביבות Oracle RAC.

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

  • מתחברים ישירות לאחד מהצמתים.

  • משתמשים ב Oracle Connection Manager.

  • יוצרים הגדרת קישוריות פרטית באמצעות פתרון פרוקסי הפוך כמו HAProxy.