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

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

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

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

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

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

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

תיאור הבעיה סיבות אפשריות דברים שכדאי לנסות
הודעת שגיאה: Database Migration Service can't set up a tunnel to be connected to the bastion host. ל-Database Migration Service לא הייתה גישה ליעד המבוצר, או שהיעד המבוצר לא מקבל חיבורים. בודקים את ההגדרות של מנהרת ה-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. כדי לפתור את הבעיה במטמון, צריך ליצור מחדש את משתמש מסד הנתונים.
משימת ההעברה נשארת בשלב ה-dump המלא ולא מתקדמת לשלב סימון הנתונים שהשתנו (CDC). ‫Database Migration Service עדיין מבצע העברה מלאה של חלק מהטבלאות, או שאי אפשר להשלים את ההעברה המלאה של טבלה אחת או יותר בגלל שגיאות.
  • בודקים את השגיאות במשימת ההעברה ומתקנים את השגיאות שרלוונטיות לטבלאות, או מסירים את הטבלאות המשויכות מהמשימה.
  • בודקים ביומנים של Database Migration Service אם יש פעילות מתמשכת של העתקה מלאה, וממתינים עד שהיא תסתיים.

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

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

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

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

סיבה אפשרית: צירוף השירות מוגדר באופן שגוי.

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

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

הזמן הקצוב לחיבור פג, החיבור נדחה

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

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

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

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

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

  • netstat -tunalp | grep PORT

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

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

    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 כדי לאתר את שורש הבעיה. שורש הבעיה יכול להשתנות בהתאם להגדרת המכונה של AlloyDB ל-PostgreSQL.

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

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

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

  • במסוף Google Cloud , נכנסים לדף Private Service Connect.

    כניסה ל-Private Service Connect

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

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

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

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

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

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

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

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

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

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

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

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

  • יוצרים הגדרה של חיבור מבודד באמצעות פתרון של שרת proxy הפוך, כמו HAProxy.