יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

הודעות שגיאה

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

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

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

טבלת שגיאות

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

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

העמודה הודעת שגיאה בטבלה הבאה ממופה למאפיין 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 *<job id>*. כדי להציג רישום מפורט ביומן של כלי bq, משתמשים בפקודה --apilog=stdout. מידע נוסף על פתרון בעיות בכלי bq זמין במאמר בנושא ניפוי באגים.

הודעת השגיאה	קוד HTTP	תיאור	פתרון בעיות
accessDenied	403	השגיאה הזו מוחזרת כשמנסים לגשת למשאב כמו dataset,‏ table,‏ view או job שאין לכם גישה אליו. השגיאה הזו מוחזרת גם כשמנסים לשנות אובייקט לקריאה בלבד.	צריך לפנות לבעלים של המשאב ולבקש גישה למשאב עבור המשתמש שמזוהה לפי הערך `principalEmail` ביומן הביקורת של השגיאה.
attributeError	400	השגיאה הזו מוחזרת כשיש בעיה בקוד המשתמש, שבה מתבצעת קריאה למאפיין מסוים של אובייקט שלא קיים.	מוודאים שלאובייקט שאתם עובדים איתו יש את המאפיין שאתם מנסים לגשת אליו. מידע נוסף על השגיאה הזו זמין במאמר בנושא AttributeError.
backendError	‫500, 503 או 504	השגיאה הזו מציינת שהשירות לא זמין כרגע. יכולות להיות לכך כמה סיבות זמניות, כולל: עלייה פתאומית בביקוש לשירות: עליות פתאומיות בביקוש, כמו בשעות השימוש העמוסות, עלולות לגרום להפחתת עומס כדי להגן על איכות השירות לכל משתמשי BigQuery. כדי למנוע עומס יתר על המערכת, BigQuery יכול להחזיר שגיאות 500 או 503 עבור חלק קטן מהבקשות. בעיות ברשת: האופי המבוזר של BigQuery גורם לכך שהנתונים מועברים לעיתים קרובות בין רכיבים או מכונות שונים במערכת. בעיות שונות בקישוריות לרשת לסירוגין עלולות לגרום ל-BigQuery להחזיר שגיאת 5xx, כולל כשלי לחיצת יד של SSL או בעיות אחרות בתשתית הרשת בין המשתמש לביןCloud de Confiance by S3NS. מיצוי משאבים: ב-BigQuery יש מגבלות שונות על משאבים פנימיים כדי להגן על הביצועים הכוללים של השירות מפני משתמש יחיד או עבודה יחידה שצורכים יותר מדי משאבים. ב-BigQuery מיושם מנגנון להפחתת עומס כדי לטפל במצב של מיצוי משאבים. שגיאות בשרת העורפי: במקרים נדירים, בעיה פנימית באחד מרכיבי BigQuery עלולה לגרום לשגיאה 500 או 503 שמוחזרת ללקוח.	שגיאות 5xx הן בעיות בצד השרת, וללקוח אין אפשרות לתקן אותן או לשלוט בהן. כדי לצמצם את ההשפעה של שגיאות 5xx בצד הלקוח, צריך לנסות שוב את הבקשות באמצעות השהיה מעריכית קטועה לפני ניסיון חוזר. מידע נוסף על השהיה מעריכית לפני ניסיון חוזר (exponential backoff) זמין במאמר השהיה מעריכית לפני ניסיון חוזר. עם זאת, יש שני מקרים מיוחדים לפתרון הבעיה הזו: שיחות `jobs.get` ושיחות `jobs.insert`. `jobs.get` שיחות אם קיבלתם שגיאה 503 כשביצעתם בדיקה של `jobs.get`, המתינו כמה שניות ובצעו את הבדיקה שוב. אם העבודה מסתיימת אבל כוללת אובייקט שגיאה שמכיל את הערך `backendError`, העבודה נכשלה. אפשר לנסות שוב את העבודה בלי לחשוש לגבי עקביות הנתונים. `jobs.insert` calls אם השגיאה הזו מופיעה כשמבצעים קריאה ל-`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	השגיאה הזו מוחזרת כשהחיוב לא מופעל בפרויקט.	מפעילים את החיוב בפרויקט בCloud de Confiance מסוף.
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, ולכן מומלץ גם להשתמש במערכת רישום ודיווח בצד הלקוח כדי לקבל חישובים מדויקים יותר של שיעור הכשל.

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

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

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

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