הודעות שגיאה

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

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

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

טבלת שגיאות

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

• אובייקט errors, שמכיל מערך של אובייקטים ErrorProto.
• אובייקט errorResults, שמכיל אובייקט ErrorProto אחד.

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

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

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

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

הודעת השגיאה	קוד HTTP	תיאור	פתרון בעיות
accessDenied	403	השגיאה הזו מוחזרת כשמנסים לגשת למשאב כמו מערך נתונים, טבלה, תצוגה או עבודה שאין לכם גישה אליהם. השגיאה הזו מוחזרת גם כשמנסים לשנות אובייקט לקריאה בלבד.	צריך לפנות לבעלים של המשאב ולבקש גישה למשאב עבור המשתמש שמזוהה לפי הערך principalEmail ביומן הביקורת של השגיאה.
attributeError	400	השגיאה הזו מוחזרת כשיש בעיה בקוד המשתמש, שבה מתבצעת קריאה למאפיין מסוים של אובייקט שלא קיים.	מוודאים שלאובייקט שעובדים איתו יש את המאפיין שמנסים לגשת אליו. מידע נוסף על השגיאה הזו זמין במאמר בנושא AttributeError.
backendError	‫500, 502, 503 או 504	השגיאה הזו מציינת שהשירות לא זמין כרגע. יכולות להיות לכך כמה סיבות זמניות, כולל: עלייה פתאומית בביקוש לשירות: עליות פתאומיות בביקוש, כמו בשעות השימוש העמוסות, עלולות לגרום להפחתת עומס כדי להגן על איכות השירות לכל משתמשי BigQuery. כדי למנוע עומס יתר על המערכת, BigQuery יכול להחזיר שגיאות 500 או 503 עבור חלק קטן מהבקשות. בעיות ברשת: האופי המבוזר של BigQuery גורם לכך שהנתונים מועברים לעיתים קרובות בין רכיבים או מכונות שונים במערכת. בעיות שונות בקישוריות לרשת לסירוגין עלולות לגרום ל-BigQuery להחזיר שגיאת 5xx, כולל כשלי לחיצת יד של SSL או בעיות אחרות בתשתית הרשת בין המשתמש לבין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 כדי להזרים נתונים, כי אין לו מגבלה כזו.
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.	כדי להקטין את קצב הבקשות, צריך להשתמש בהשהיה מעריכית לפני ניסיון חוזר (exponential backoff), ואז לנסות שוב להריץ את העבודה עם 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	השגיאה הזו מוחזרת אם הפרויקט חורג ממגבלת קצב לטווח קצר, כי נשלחו יותר מדי בקשות מהר מדי. לדוגמה, אפשר לעיין במגבלות הקצב של עבודות שאילתה ובמגבלות הקצב של בקשות 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) זמין במאמר הסכם רמת השירות (SLA) של BigQuery.

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

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

שגיאות אימות

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

{"error" : "_description_string_"}

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

{"error":"invalid_client"}

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

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

• מחפשים ביומני הביקורת 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] Broken pipe	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	עוברים למצב פרטי או למצב גלישה פרטית בדפדפן וחוזרים על הפעולה שגרמה לשגיאה. אם לא מופיעה שגיאה במצב פרטי, יכול להיות שהשגיאה נובעת מתוסף לדפדפן, כמו חוסם מודעות. משביתים את תוספי הדפדפן כשלא נמצאים במצב פרטי, ובודקים אם הבעיה נפתרה.