הודעות שגיאה

במסמך הזה מתוארות הודעות שגיאה שאפשר להיתקל בהן במהלך העבודה ב-BigQuery, כולל קודי שגיאות HTTP והצעות לפתרון בעיות.

מידע נוסף על שגיאות בשאילתות זמין במאמר פתרון בעיות בשאילתות.

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

טבלת שגיאות

תגובות מ-BigQuery API כוללות קוד שגיאה של HTTP ואובייקט שגיאה בגוף התגובה. אובייקט שגיאה הוא בדרך כלל אחד מהבאים:

העמודה הודעת שגיאה בטבלה הבאה ממופה למאפיין reason באובייקט ErrorProto.

הטבלה לא כוללת את כל שגיאות ה-HTTP האפשריות או שגיאות אחרות שקשורות לרשת. לכן, אל תניחו שאובייקט שגיאה קיים בכל תגובת שגיאה מ-BigQuery. בנוסף, יכול להיות שתקבלו שגיאות שונות או אובייקטים של שגיאות אם תשתמשו בספריות הלקוח של Cloud עבור BigQuery API. למידע נוסף, ראו BigQuery API Client Libraries.

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

אם משתמשים בכלי שורת הפקודה של BigQuery כדי לבדוק את סטטוס העבודה, אובייקט השגיאה לא מוחזר כברירת מחדל. כדי לראות את אובייקט השגיאה ואת המאפיין reason התואם שממופה לטבלה הבאה, משתמשים בדגל --format=prettyjson. לדוגמה, bq --format=prettyjson show -j **. כדי להציג רישום מפורט ביומן של כלי bq, משתמשים באפשרות --apilog=stdout. מידע נוסף על פתרון בעיות בכלי bq זמין במאמר בנושא ניפוי באגים.

הודעת השגיאה קוד HTTP תיאור פתרון בעיות
accessDenied 403

השגיאה הזו מוחזרת כשמנסים לגשת למשאב כמו dataset,‏ table,‏ view או job שאין לכם גישה אליו. השגיאה הזו מוחזרת גם כשמנסים לשנות אובייקט לקריאה בלבד.

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

attributeError 400

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

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

backendError ‫500, 502, 503 או 504

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

  • עלייה פתאומית בביקוש לשירות: עליות פתאומיות בביקוש, כמו בזמני שימוש בשיא, עלולות לגרום להפחתת עומס כדי לשמור על איכות השירות לכל משתמשי BigQuery. כדי למנוע עומס יתר על המערכת, BigQuery יכול להחזיר שגיאות 500 או 503 עבור חלק קטן מהבקשות.
  • בעיות ברשת: האופי המבוזר של BigQuery גורם לכך שהנתונים מועברים לעיתים קרובות בין רכיבים או מכונות שונים במערכת. בעיות שונות בקישוריות לרשת שמתרחשות לסירוגין יכולות לגרום ל-BigQuery להחזיר שגיאת 5xx, כולל כשלים ב-SSL handshake או בעיות אחרות בתשתית הרשת בין המשתמש לביןGoogle Cloud.
  • מיצוי משאבים: ב-BigQuery יש מגבלות שונות על משאבים פנימיים כדי להגן על הביצועים הכוללים של השירות מפני משתמש יחיד או עבודה יחידה שצורכים יותר מדי משאבים. ב-BigQuery מיושם מנגנון להפחתת עומס כדי לטפל במצב של מיצוי משאבים.
  • שגיאות בקצה העורפי: במקרים נדירים, בעיה פנימית באחד מרכיבי BigQuery עלולה לגרום לשגיאה 500 או 503 שמוחזרת ללקוח.

שגיאות 5xx הן בעיות בצד השרת, וללקוח אין דרך לתקן אותן או לשלוט בהן. כדי לצמצם את ההשפעה של שגיאות 5xx בצד הלקוח, צריך לנסות שוב את הבקשות באמצעות השהיה מעריכית קטועה לפני ניסיון חוזר. מידע נוסף על השהיה מעריכית לפני ניסיון חוזר (exponential backoff) זמין במאמר השהיה מעריכית לפני ניסיון חוזר. עם זאת, יש שני מקרים מיוחדים לפתרון הבעיה הזו: שיחות jobs.get ושיחות jobs.insert.

jobs.get שיחות

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

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

אם הניסיונות החוזרים לא עוזרים והבעיות נמשכות, אפשר לחשב את שיעור הבקשות שנכשלו ולפנות לתמיכה.
בנוסף, אם בקשה ספציפית ל-BigQuery נכשלת באופן עקבי עם שגיאת 5xx, גם כשמנסים שוב באמצעות השהיה מעריכית לפני ניסיון חוזר (exponential backoff) בכמה ניסיונות להפעלה מחדש של זרימת העבודה, צריך להעביר את הבעיה לתמיכה כדי לפתור אותה בצד של BigQuery, ללא קשר לשיעור השגיאות הכולל שחושב. חשוב להסביר בצורה ברורה את ההשפעה על העסק כדי שנוכל לתעדף את הטיפול בבעיה.

badRequest 400

השגיאה 'UPDATE or DELETE statement over table project.dataset.table would affect rows in the streaming buffer, which is not supported' יכולה להתרחש כשחלק מהשורות שהועברו לאחרונה בסטרימינג בטבלה לא זמינות לפעולות DML ‏ (DELETE,‏ UPDATE,‏ MERGE). בדרך כלל זה קורה למשך כמה דקות, אבל במקרים נדירים, עד 90 דקות. מידע נוסף זמין במאמרים בנושא זמינות של נתונים בסטרימינג ומגבלות על DML.

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

אפשרות אחרת היא להשתמש ב-BigQuery Storage Write API (gRPC) כדי להזרים נתונים, כי אין לו את המגבלה הזו.

billingNotEnabled 403

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

מפעילים את החיוב בפרויקט בGoogle Cloud מסוף.

billingTierLimitExceeded 400

השגיאה הזו מוחזרת כשהערך של statistics.query.billingTier עבור משימה לפי דרישה חורג מ-100. זה קורה כשהשאילתות על פי דרישה משתמשות ביותר מדי מעבד (CPU) ביחס לכמות הנתונים שנסרקו. הוראות לבדיקת פרטי המשימה מופיעות במאמר ניהול משימות.

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

נחסם 403

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

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

כפילות 409

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

משנים את השם של המשאב שמנסים ליצור, או משנים את הערך writeDisposition בעבודה. מידע נוסף מופיע במאמר בנושא פתרון בעיות בשגיאה Job already exists.

internalError 500

השגיאה הזו מוחזרת כשמתרחשת שגיאה פנימית ב-BigQuery.

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

לא חוקי 400

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

invalidQuery 400

השגיאה הזו מוחזרת כשמנסים להריץ שאילתה לא תקינה.

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

invalidUser 400

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

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

jobBackendError 400

השגיאה הזו מוחזרת כשהמשימה נוצרה בהצלחה, אבל נכשלה בגלל שגיאה פנימית. יכול להיות שהשגיאה הזו תופיע ב-jobs.query או ב-jobs.getQueryResults.

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

jobInternalError 400

השגיאה הזו מוחזרת כשהמשימה נוצרה בהצלחה, אבל נכשלה בגלל שגיאה פנימית. יכול להיות שהשגיאה הזו תופיע ב-jobs.query או ב-jobs.getQueryResults.

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

jobRateLimitExceeded 400

השגיאה הזו מוחזרת כשהמשימה נוצרה בהצלחה, אבל נכשלה עם השגיאה rateLimitExceeded. יכול להיות שהשגיאה הזו תוצג ב-jobs.query או ב-jobs.getQueryResults.

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

notFound 404

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

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

notImplemented 501

השגיאה הזו מוחזרת כשמנסים לגשת לתכונה שלא הוטמעה.

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

proxyAuthenticationRequired 407

השגיאה הזו מוחזרת בין סביבת הלקוח לבין שרת ה-proxy אם בבקשה חסרים פרטי כניסה תקפים לאימות בשרת ה-proxy. מידע נוסף זמין במאמר בנושא 407 Proxy Authentication Required.

פתרון הבעיות תלוי בסביבה שלכם. אם אתם מקבלים את השגיאה הזו בזמן העבודה ב-Java, ודאו שהגדרתם את המאפיינים jdk.http.auth.tunneling.disabledSchemes= ו-jdk.http.auth.proxying.disabledSchemes= בלי ערך אחרי סימן השוויון.

quotaExceeded 403

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

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

rateLimitExceeded 403, 429

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

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

resourceInUse 400

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

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

resourcesExceeded 400

השגיאה הזו מוחזרת כשהעבודה משתמשת ביותר מדי משאבים.

השגיאה הזו מוחזרת כשהעבודה משתמשת ביותר מדי משאבים. מידע על פתרון בעיות מופיע במאמר פתרון בעיות של חריגה ממגבלות המשאבים.

responseTooLarge 403

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

לפעמים הוספה של סעיף LIMIT יכולה לעזור, או הסרה של סעיף ORDER BY. אם רוצים לוודא שאפשר להחזיר תוצאות גדולות, אפשר להגדיר את המאפיין allowLargeResults לערך true ולציין טבלת יעד. מידע נוסף זמין במאמר בנושא כתיבת תוצאות של שאילתות גדולות.

נעצר 200

קוד הסטטוס הזה מוחזר כשמבטלים משימה.

tableUnavailable 400

יש טבלאות מסוימות ב-BigQuery שמגובות בנתונים שמנוהלים על ידי צוותים של מוצרי Google אחרים. השגיאה הזו מציינת שאחת מהטבלאות האלה לא זמינה.

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

זמן קצוב לתפוגה 400

הזמן הקצוב לעבודה הסתיים.

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

דוגמה לתגובת שגיאה

GET https://bigquery.googleapis.com/bigquery/v2/projects/12345/datasets/foo
Response:
[404]
{
  "error": {
  "errors": [
  {
    "domain": "global",
    "reason": "notFound",
    "message": "Not Found: Dataset myproject:foo"
  }],
  "code": 404,
  "message": "Not Found: Dataset myproject:foo"
  }
}

חישוב קצב הבקשות שנכשלו וזמן הפעולה

אפשר לפתור את רוב השגיאות 500 ו-503 על ידי ניסיון חוזר עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff). אם שגיאות 500 ו-503 עדיין נמשכות, אפשר לחשב את השיעור הכולל של הבקשות שנכשלו ואת זמן הפעולה התקינה התואם, כדי להשוות אותו להסכם רמת השירות (SLA) של BigQuery ולקבוע אם השירות פועל כמצופה.

כדי לחשב את שיעור הבקשות הכולל שנכשלו ב-30 הימים האחרונים, לוקחים את מספר הבקשות שנכשלו עבור קריאה ל-API או מתודה ספציפית מ-30 הימים האחרונים ומחלקים אותו במספר הכולל של הבקשות עבור אותה קריאה ל-API או מתודה מ-30 הימים האחרונים. כדי לקבל את אחוז הבקשות שנכשלו בממוצע ב-30 הימים האחרונים, מכפילים את הערך הזה ב-100.

לדוגמה, אפשר להריץ שאילתה על נתונים של Cloud Logging כדי לקבל את המספר הכולל של בקשות jobs.insert ואת המספר של בקשות jobs.insert שנכשלו, ולבצע את החישוב. אפשר גם לקבל את ערכי שיעור השגיאות מלוח הבקרה של ה-API או באמצעות סייר המדדים ב-Cloud Monitoring. האפשרויות האלה לא כוללות נתונים על בעיות ברשת או בניתוב שנתקלו בהן בין הלקוח ל-BigQuery, ולכן מומלץ גם להשתמש במערכת רישום ודיווח בצד הלקוח כדי לחשב את שיעור הכשל בצורה מדויקת יותר.

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

כדי לחשב את זמן הפעולה, צריך לדעת את מספר הדקות שמוגדרות כזמן השבתה של השירות. זמן השבתה של השירות הוא תקופה של דקה אחת עם שיעור שגיאות של יותר מ-10%, שמחושב לפי ההגדרות של הסכם רמת השירות (SLA). כדי לחשב את זמן הפעולה, לוקחים את סך הדקות מ-30 הימים האחרונים ומפחיתים את סך הדקות שבהן השירות לא פעל. מחלקים את הזמן שנותר במספר הדקות הכולל מ-30 הימים האחרונים, ומכפילים את הערך הזה ב-100 כדי לקבל את אחוז הזמינות ב-30 הימים האחרונים. מידע נוסף על ההגדרות והחישובים שקשורים להסכם רמת השירות זמין במאמר הסכם רמת השירות (SLA) של BigQuery.

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

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

שגיאות אימות

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

{"error" : "_description_string_"}

השגיאה מלווה בשגיאת HTTP 400 Bad Request או בשגיאת HTTP 401 Unauthorized. ‫_description_string_ הוא אחד מקודי השגיאה שמוגדרים במפרט OAuth2. לדוגמה:

{"error":"invalid_client"}

בדיקת השגיאות

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

  • חיפוש משימות שנכשלו בגלל בעיות בהרשאות ביומני הביקורת Policy Denied:

    resource.type="bigquery_resource"
    protoPayload.status.message=~"Access Denied"
    logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access"
    

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

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

    resource.type="bigquery_resource"
    protoPayload.authenticationInfo.principalEmail="EMAIL"
    

    מחליפים את EMAIL בכתובת האימייל של המשתמש או של חשבון השירות.

  • חיפוש שינויים במדיניות של ניהול זהויות והרשאות גישה (IAM) ביומני הביקורת Admin Activity:

    protoPayload.methodName=~"SetIamPolicy"
    logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity"
    
  • חיפוש שינויים במערך נתונים ספציפי ב-BigQuery ביומני הביקורת של גישה לנתונים:

    resource.type="bigquery_resource"
    protoPayload.resourceName="projects/PROJECT_ID/datasets/DATASET_ID"
    logName=projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access
    

    מחליפים את DATASET_ID במזהה של קבוצת הנתונים שמכילה את המשאב.

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

בטבלה הבאה מפורטות הודעות שגיאה שעשויות להופיע בגלל בעיות קישוריות לסירוגין כשמשתמשים בספריות הלקוח או כשקוראים ל-BigQuery API מהקוד:

הודעת השגיאה ספריית לקוח או API פתרון בעיות
com.google.cloud.bigquery.BigQueryException: Read timed out Java מגדירים ערך זמן קצוב לתפוגה ארוך יותר.
החיבור נסגר: javax.net.ssl.SSLException: java.net.SocketException: Connection reset at com.google.cloud.bigquery.spi.v2.HttpBigQueryRpc.translate(HttpBigQueryRpc.java:115) Java מטמיעים מנגנון ניסיון חוזר ומגדירים ערך פסק זמן גדול יותר.
‫javax.net.ssl.SSLHandshakeException: המארח המרוחק סיים את לחיצת היד Java כדאי להטמיע מנגנון ניסיון חוזר ולהגדיר ערך זמן קצוב לתפוגה גדול יותר.
‫BrokenPipeError: [Errno 32] צינור שבור Python הטמעת מנגנון לניסיון חוזר. מידע נוסף על השגיאה הזו זמין במאמר בנושא BrokenPipeError.
החיבור בוטל. RemoteDisconnected('Remote end closed connection without response' Python מגדירים ערך זמן קצוב לתפוגה ארוך יותר.
‫SSLEOFError (התרחשה שגיאת EOF בהפרה של הפרוטוקול) Python השגיאה הזו מוחזרת במקום שגיאת HTTP 413 (ENTITY_TOO_LARGE). צריך להקטין את גודל הבקשה.
TaskCanceledException: המשימה בוטלה ספריית ‎.NET מגדילים את ערך הזמן הקצוב לתפוגה בצד הלקוח.
‪google.api_core.exceptions.PreconditionFailed: 412 PATCH Python השגיאה הזו מוחזרת כשמנסים לעדכן משאב של טבלה באמצעות בקשת HTTP. צריך לוודא שערך ה-ETag בכותרת ה-HTTP לא עדכני. לפעולות ברמת הטבלה או מערך הנתונים, מוודאים שהמשאב לא השתנה מאז הפעם האחרונה שהוא הופעל, ויוצרים מחדש את האובייקט אם צריך.
יצירת חיבור חדש נכשלה: [Errno 110] פג הזמן שהוקצב לחיבור ספריות לקוח השגיאה הזו מוחזרת כשהבקשה הזו הגיעה לסוף הקובץ (EOF) במהלך סטרימינג או קריאה של נתונים מ-BigQuery. מטמיעים מנגנון ניסיון חוזר ומגדירים ערך זמן קצוב לתפוגה גדול יותר.
socks.ProxyConnectionError: Error connecting to HTTP proxy :8080: [Errno 110] Connection timed out ספריות לקוח פתרון בעיות שקשורות לסטטוס ולהגדרות של שרת proxy. מטמיעים מנגנון ניסיון חוזר ומגדירים ערך זמן קצוב לתפוגה גדול יותר.
התקבל EOF לא צפוי או 0 בייטים מזרם התעבורה ספריות לקוח מטמיעים מנגנון ניסיון חוזר ומגדירים ערך זמן קצוב לתפוגה גדול יותר.

Google Cloud הודעות שגיאה במסוף

בטבלה הבאה מפורטות הודעות שגיאה שעשויות להופיע במהלך העבודה במסוףGoogle Cloud .

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