פתרון בעיות שקשורות לשאילתות

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

פתרון בעיות שקשורות לשאילתות איטיות

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

  1. כדאי לבדוק את הדף Google Cloud Service Health כדי לראות אם יש הפסקות שירות ידועות ב-BigQuery שיכולות להשפיע על הביצועים של השאילתות.

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

    • אם רוב הזמן שחלף נבע מזמני יצירה ארוכים, אפשר לפנות אל Cloud Customer Care לקבלת עזרה.

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

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

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

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

השוואה בין ביצוע איטי לביצוע מהיר של אותה שאילתה

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

פגיעות במטמון

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

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

עיכובים במכסה

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

משך הביצוע

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

אם הערכים של finalExecutionDurationMs דומים מאוד, אבל ההבדל בזמן הביצוע הכולל בין שתי השאילתות, שמחושב כ-startTime - endTime, גדול בהרבה, יכול להיות שהייתה הפעלה חוזרת של ביצוע שאילתה פנימית עבור העבודה האיטית בגלל בעיה זמנית אפשרית. אם אתם רואים את דפוס ההבדלים הזה שוב ושוב, פנו אל Cloud Customer Care לקבלת עזרה.

בייטים שעובדו

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

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

טבלאות שאליהן יש הפניה

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

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

הבדלים בטבלאות שאליהן מתייחסים יכולים להסביר שינויים בtotalBytesProcessed.

שימוש בתצוגה מהותית

אם השאילתה מפנה אל תצוגות חומריות, יכול להיות שההבדלים בביצועים נובעים מכך שתצוגות חומריות נבחרו או נדחו במהלך ביצוע השאילתה. בודקים את MaterializedViewStatistics כדי להבין אם תצוגות חומריות כלשהן שנעשה בהן שימוש בשאילתה המהירה נדחו בשאילתה האיטית. בודקים את השדות chosen ו-rejectedReason באובייקט MaterializedView.

נתונים סטטיסטיים של שמירת מטא-נתונים במטמון

בשביל שאילתות שכוללות טבלאות BigLake ב-Amazon S3 או טבלאות BigLake ב-Cloud Storage עם מטמון מטא-נתונים מופעל, אפשר להשוות את הפלט של MetadataCacheStatistics כדי לבדוק אם יש הבדל בשימוש במטמון המטא-נתונים בין השאילתה האיטית לבין השאילתה המהירה, ולראות את הסיבות לכך. לדוגמה, יכול להיות שמטמון המטא-נתונים נמצא מחוץ לחלון maxStaleness של הטבלה.

השוואה בין נתונים סטטיסטיים של BigQuery BI Engine

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

בדיקת ההבדלים בתובנות לגבי ביצועי השאילתות

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

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

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

כדי להתחיל, כדאי לעיין במדדים Wait ms ו-Shuffle output bytes שמתוארים בקטע הסבר על מידע בשלב השאילתה.

אזהרות לגבי משאבים בתצוגה INFORMATION_SCHEMA.JOBS

מריצים שאילתה בשדה query_info.resource_warning של התצוגה המפורטת INFORMATION_SCHEMA.JOBS כדי לבדוק אם יש הבדל בין האזהרות שנותחו על ידי BigQuery לבין המשאבים שבשימוש.

ניתוח נתונים סטטיסטיים של עומסי עבודה

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

ממוצע משבצות הזמן לשנייה

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

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

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

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

מודלים של ניהול עומסי עבודה וגודל ההזמנה

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

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

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

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

בו-זמניות של משימות

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

אפשר להריץ שאילתה בתצוגה INFORMATION_SCHEMA.JOBS כדי למצוא את המספר הממוצע של עבודות מקבילות שפועלות בו-זמנית עם שאילתה מסוימת בפרויקט.

אם יש יותר מפרויקט אחד שמוקצה להזמנה, צריך לשנות את השאילתה כך שתשתמש ב-JOBS_BY_ORGANIZATION במקום ב-JOBS_BY_PROJECT כדי לקבל נתונים מדויקים ברמת ההזמנה.

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

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

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

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

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

ניצול הזמנות

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

כדי להבין אם העבודה ביקשה משבצות נוספות, אפשר לעיין במדד של יחידות הפעלה משוערות, שהוא estimatedRunnableUnits בתגובה של Job API, או period_estimated_runnable_units בתצוגה INFORMATION_SCHEMA.JOBS_TIMELINE. אם הערך של המדד הזה גדול מ-0, יכול להיות שהמשימה הייתה יכולה להרוויח מחריצים נוספים באותו זמן. כדי להעריך את אחוז הזמן של ביצוע המשימה שבו המשימה הייתה יכולה להפיק תועלת מחריצים נוספים, מריצים את השאילתה הבאה מול התצוגה INFORMATION_SCHEMA.JOBS_TIMELINE:

SELECT
  ROUND(COUNTIF(period_estimated_runnable_units > 0) / COUNT(*) * 100, 1) AS execution_duration_percentage
FROM `myproject`.`region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
WHERE job_id = 'my_job_id'
GROUP BY job_id;
 התוצאה אמורה להיראות כך: 
+---------------------------------+
|   execution_duration_percentage |
+---------------------------------+
|                            96.7 |
+---------------------------------+

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

אם אחוז הניצול גבוה וההזמנה לא נוצלה במלואה במהלך התקופה הזו, פנו אל Cloud Customer Care כדי לבדוק את העניין.

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

מסקנות לא חד-משמעיות לגבי מטא-נתונים של משרות וניתוח עומסי עבודה

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

פתרון בעיות של שאילתות שנכשלו באמצעות Gemini Cloud Assist

כדי להשתמש ב-Gemini Cloud Assist כדי לזהות את הסיבה לכשל בשאילתה:

  1. במסוף Google Cloud , עוברים לדף BigQuery.

    כניסה ל-BigQuery

  2. בסרגל הכלים Google Cloud , לוחצים עלspark Open or close Gemini Cloud Assist chat.

  3. כותבים את ההנחיה בחלונית Cloud Assist, כולל מזהה המשרה. לדוגמה: Why did JOB_ID fail?

פתרון בעיות שקשורות לשאילתה שנכשלה באמצעות gcpdiag

‫gcpdiag הוא כלי בקוד פתוח. זה לא מוצר נתמך רשמית של Google Cloud . אפשר להשתמש בgcpdiagכלי כדי לזהות ולפתור Google Cloudבעיות בפרויקט. מידע נוסף זמין בפרויקט gcpdiag ב-GitHub.

הכלי gcpdiag עוזר לכם לנתח שאילתות שנכשלו ב-BigQuery כדי להבין אם יש סיבה ידועה לשורש הבעיה ופתרון לכישלון הספציפי.

מריצים את הפקודה gcpdiag.

אפשר להריץ את הפקודה gcpdiag מ-Google Cloud CLI:

מסוףGoogle Cloud

  1. משלימים את הפקודה הבאה ואז מעתיקים אותה. 
    2. gcpdiag runbook bigquery/failed_query \
   --parameter project_id=PROJECT_ID \
   --parameter bigquery_job_region=JOB_REGION \
   --parameter bigquery_job_id=JOB_ID \
   --parameter bigquery_skip_permission_check=SKIP_PERMISSION_CHECK
  2. פותחים את Google Cloud המסוף ומפעילים את Cloud Shell.
    3. פתיחת מסוף Cloud
  3. מדביקים את הפקודה שהועתקה.
  4. מריצים את הפקודה gcpdiag, שמורידה את תמונת ה-Docker‏ gcpdiag, ואז מבצעת בדיקות אבחון. אם יש הוראות לגבי הפלט, פועלים לפיהן כדי לתקן את הבדיקות שנכשלו.

Docker

אפשר להריץ את gcpdiag באמצעות wrapper שמתחיל את gcpdiag בקונטיינר של Docker. צריך להתקין את Docker או את Podman.

  1. מעתיקים את הפקודה הבאה ומריצים אותה בתחנת העבודה המקומית. 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. מריצים את הפקודה gcpdiag. 
    ./gcpdiag runbook bigquery/failed_query \
   --parameter project_id=PROJECT_ID \
   --parameter bigquery_job_region=JOB_REGION \
   --parameter bigquery_job_id=JOB_ID \
   --parameter bigquery_skip_permission_check=SKIP_PERMISSION_CHECK

כאן אפשר לראות את הפרמטרים הזמינים של קובץ ה-runbook הזה.

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

  • ‫PROJECT_ID: מזהה הפרויקט שמכיל את המשאב.
  • ‫JOB_REGION: האזור שבו בוצעה המשימה ב-BigQuery.
  • ‫JOB_ID: מזהה המשימה של משימת BigQuery.
  • ‫SKIP_PERMISSION_CHECK: (אופציונלי) מגדירים את הערך True אם רוצים לדלג על בדיקת ההרשאות הרלוונטית ולזרז את ההרצה של חוברת ההפעלה (ערך ברירת המחדל הוא False).

דגלים שימושיים:

  • ‫--universe-domain: אם רלוונטי, הדומיין של Trusted Partner Sovereign Cloud שמארח את המשאב
  • ‫--parameter או -p: פרמטרים של Runbook

רשימה ותיאור של כל הדגלים של כלי gcpdiag מופיעים בהוראות השימוש ב-gcpdiag.

החלטה לגבי סכימת Avro

מחרוזת שגיאה: Cannot skip stream

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

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

שאילתות מקבילות שמתנגשות

מחרוזת שגיאה: Concurrent jobs in the same session are not allowed

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

פקודות DML מתנגשות

מחרוזת שגיאה: Could not serialize access to table due to concurrent update

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

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

שאילתות משנה עם קורלציה

מחרוזת שגיאה: Correlated subqueries that reference other tables are not supported unless they can be de-correlated

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

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

  • מסירים את כל הסעיפים ORDER BY, ‏LIMIT, ‏EXISTS, ‏NOT EXISTS או IN משאילתת המשנה.
  • אפשר להשתמש בשאילתה עם כמה הצהרות כדי ליצור טבלה זמנית שאליה תהיה הפניה בשאילתת המשנה.
  • צריך לנסח מחדש את השאילתה כדי להשתמש ב-CROSS JOIN במקום זאת.

אין מספיק הרשאות לבקרת גישה ברמת העמודה

מחרוזות שגיאה:

  • Access denied: Requires fineGrainedGet permission on the read columns to execute the DML statements
  • ‫`Access denied: User does not have permission to access policy tag projects/PROJECT_ID/locations/LOCATION/taxonomies/TAXONOMY_ID/policyTags/POLICY_TAG_ID on column PROJECT_ID.DATASET.TABLE.COLUMN.'

השגיאות האלה מתרחשות כשמנסים להריץ שאילתת SQL או הצהרת DML‏ DELETE, UPDATE או MERGE בלי לקבל את התפקיד Fine-Grained Reader בעמודות שמשתמשות בבקרת גישה ברמת העמודה. התפקיד הזה מוקצה לחשבונות משתמשים כחלק מהגדרת תג מדיניות. מידע נוסף על ההשפעה על פעולות כתיבה מבקרת גישה ברמת העמודה

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

פתרון בעיות בשאילתות מתוזמנות

יכולות להיות בעיות שמתעוררות במהלך ההגדרה או ההפעלה של שאילתות מתוזמנות.

שאילתה מתוזמנת מפעילה ריצות כפולות

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

כדי לצמצם את הסיכון להפעלות כפולות, כדאי לתזמן את השאילתות לזמן שאינו עגול, למשל כמה דקות לפני או אחרי השעה (לדוגמה, 08:58 או 09:03). מידע נוסף זמין במאמר בנושא תזמון שאילתות.

פרטי כניסה לא תקינים לשאילתות מתוזמנות

מחרוזות שגיאה:

  • Error code: INVALID_USERID
  • Error code 5: Authentication failure: User Id not found
  • PERMISSION_DENIED: BigQuery: Permission denied while getting Drive credentials

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

כדי לפתור את השגיאה הזו, מבצעים את השלבים הבאים:

פרטי כניסה לא תקינים לחשבון שירות

מחרוזת שגיאה: HttpError 403 when requesting returned: The caller does not have permission

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

הזמן של תמונת המצב שגוי

מחרוזת שגיאה: Invalid snapshot time

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

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

המשימה כבר קיימת

מחרוזת שגיאה: Already Exists: Job <job name>

השגיאה הזו יכולה להתרחש במשימות של שאילתות שצריכות להעריך מערכים גדולים, כך שייקח יותר זמן מהממוצע ליצור משימת שאילתה. לדוגמה, שאילתה עם פסקה WHERE כמו WHERE column IN (<2000+ elements array>).

כדי לפתור את השגיאה הזו, מבצעים את השלבים הבאים:

  • אפשר לאפשר ל-BigQuery ליצור ערך אקראי של jobId במקום לציין ערך.
  • משתמשים בשאילתה עם פרמטרים כדי לטעון את המערך.

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

המשרה לא נמצאה

מחרוזת שגיאה: Job not found

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

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

המיקום לא נמצא

מחרוזת שגיאה: Dataset [project_id]:[dataset_id] was not found in location [region]

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

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

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

מחרוזת שגיאה: Query fails due to reaching the execution time limit

אם השאילתה חורגת ממגבלת הזמן להרצת שאילתות, אפשר לבדוק את זמן ההרצה של הרצות קודמות של השאילתה על ידי הפעלת שאילתה על התצוגה INFORMATION_SCHEMA.JOBS, בדומה לדוגמה הבאה:

SELECT TIMESTAMP_DIFF(end_time, start_time, SECOND) AS runtime_in_seconds
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE statement_type = 'QUERY'
AND query = "my query string";

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

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

מחרוזת שגיאה: responseTooLarge

השגיאה הזו מתרחשת כשהתוצאות של השאילתה גדולות יותר מגודל התגובה המקסימלי.

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

ההזמנה לא נמצאה או שחסרים בה משבצות זמן

מחרוזת שגיאה: Cannot run query: project does not have the reservation in the data region or no slots are configured

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

הטבלה לא נמצאה

מחרוזת שגיאה: Not found: Table [project_id]:[dataset].[table_name] was not found in location [region]

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

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

יותר מדי פקודות DML

מחרוזת שגיאה: Too many DML statements outstanding against <table-name>, limit is 20

השגיאה הזו מתרחשת כשחורגים מהמגבלה של 20 הצהרות DML בסטטוס PENDING בתור של טבלה אחת. השגיאה הזו מתרחשת בדרך כלל כששולחים משימות DML לטבלה יחידה מהר יותר ממה ש-BigQuery יכול לעבד.

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

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

העסקה בוטלה בגלל עדכון שמתבצע בו-זמנית

מחרוזת שגיאה: Transaction is aborted due to concurrent update against table [table_name]

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

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

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

מחרוזת שגיאה: Error 412: The job references a table that belongs to a failover dataset in the ... region (PROJECT_ID:DATASET_ID). However, only jobs that run on a reservation with the "ENTERPRISE_PLUS" edition can modify or write to failover datasets. Please also make sure that the job that is writing to the failover dataset is running in the current primary location.

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

שגיאות ב-SQL מדור קודם

יכולות להופיע השגיאות הבאות כשמשתמשים ב-SQL מדור קודם.

Cannot be queried with legacy SQL

מחרוזת שגיאה: cannot be queried with legacy SQL. Please consider switching to standard SQL

השגיאה הזו יכולה להתרחש באחד משני תרחישים:

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

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

אי אפשר להריץ שאילתות על טבלאות עם עמודות ששמן שונה באמצעות SQL מדור קודם

מחרוזת שגיאה: Table project:dataset.table with renamed columns cannot be queried with legacy SQL. Please consider switching to standard SQL or dropping column my_column

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

למשתמש אין הרשאה

מחרוזות שגיאה:

  • Access Denied: Project [project_id]: User does not have bigquery.jobs.create permission in project [project_id].
  • User does not have permission to query table project-id:dataset.table.
  • Access Denied: User does not have permission to query table or perhaps it does not exist.

השגיאות האלה יכולות להתרחש כשמריצים שאילתה בלי ההרשאה bigquery.jobs.create בפרויקט שממנו מריצים את השאילתה, בלי קשר להרשאות שיש לכם בפרויקט שמכיל את הנתונים.

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

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

כשמטפלים בשגיאות האלה, כדאי לקחת בחשבון את הנקודות הבאות:

  • חשבונות שירות: לחשבונות שירות צריכה להיות ההרשאה bigquery.jobs.create בפרויקט שממנו הם מופעלים, וההרשאה bigquery.tables.getData בכל הטבלאות והתצוגות שהשאילתה מפנה אליהן.

  • תפקידים בהתאמה אישית: בתפקידי IAM בהתאמה אישית, ההרשאה bigquery.jobs.create צריכה להיכלל באופן מפורש בתפקיד הרלוונטי, וצריכה להיות הרשאה bigquery.tables.getData בכל הטבלאות והתצוגות שהשאילתה מפנה אליהן.

  • מערכי נתונים משותפים: כשעובדים עם מערכי נתונים משותפים בפרויקט נפרד, יכול להיות שעדיין תצטרכו את ההרשאה bigquery.jobs.create בפרויקט כדי להריץ שאילתות או עבודות במערך הנתונים הזה.

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

ההרשאה bigquery.reservations.use נדחתה בהזמנה

מחרוזת שגיאה:

  • Access Denied: Reservation projects/project/locations/region/reservations/reservation_name: Permission bigquery.reservations.use denied on reservation projects/project/locations/region/reservations/reservation_name (or it may not exist)

השגיאה הזו מתרחשת כשמנסים להריץ שאילתה בהזמנה ספציפית באמצעות ההצהרה SET @@reservation, ולמשתמש או לחשבון השירות חסרה ההרשאה bigquery.reservations.use. כדי לזהות איזה גורם ניסה לבצע את הפעולה הזו, אפשר לבדוק את הכשל ב-Cloud Logging או בדף המשימות של BigQuery.

שגיאות אחרות של Access Denied

מחרוזות שגיאה:

  • Access Denied: Dataset project_id:dataset_id: Permission bigquery.datasets.get denied on dataset project_id:dataset_id (or it may not exist).
  • Access Denied: Dataset project_id:dataset_id: Permission bigquery.datasets.update denied on dataset project_id:dataset_id (or it may not exist).
  • Access Denied: BigQuery BigQuery: User does not have permission to access data protected by policy tag

כדי לפתור בעיות כלליות של שגיאות Access Denied ב-BigQuery, אפשר להשתמש בכלי הניתוח למדיניות כדי לקבוע איזו גישה יש לישות למשאב.

בכלי הניתוח למדיניות, מציינים את משאב BigQuery שאליו מנסים לגשת (לדוגמה, //bigquery.googleapis.com/projects/YOUR_PROJECT/datasets/YOUR_DATASET/tables/YOUR_TABLE) ואת כתובת האימייל של המשתמש או חשבון השירות שמקבל את השגיאה Access Denied בתור הישות המורשית. בניתוח מוצגות ההרשאות של חשבון המשתמש במשאב, שאפשר להשוות אותן להרשאות החסרות בהודעת השגיאה.

הצפנת היעד לא אפשרית בסקריפטים

מחרוזת שגיאה: configuration.query.destinationEncryptionConfiguration cannot be set for scripts

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

הגישה נדחתה בגלל מדיניות הארגון

מחרוזת שגיאה: IAM setPolicy failed for Dataset DATASET: Operation denied by org policy on resource.

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

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

בעיות שקשורות לחריגה ממגבלות המשאבים

הבעיות הבאות מתרחשות כשאין ל-BigQuery מספיק משאבים להשלמת השאילתה.

השאילתה חורגת ממשאבי ה-CPU

מחרוזת שגיאה: Query exceeded resource limits

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

השאילתה חורגת ממשאבי הזיכרון

מחרוזת שגיאה: Resources exceeded during query execution: The query could not be executed in the allotted memory

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

אין מספיק מקום במקבץ

מחרוזת שגיאה: Out of stack space due to deeply nested query expression during query resolution.

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

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

הייתה חריגה מהמשאבים במהלך הרצת השאילתה

מחרוזת שגיאה: Resources exceeded during query execution: The query could not be executed in the allotted memory. Peak usage: [percentage]% of limit. Top memory consumer(s): ORDER BY operations.

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

כדי לפתור את השגיאה הזו, מומלץ להימנע משימוש בערכים גדולים של OFFSET בשאילתות ORDER BY ... LIMIT. אפשרות אחרת היא להשתמש בפונקציה האנליטית (window function) ROW_NUMBER() שניתנת להרחבה כדי להקצות דרגות על סמך הסדר שנבחר, ואז לסנן את הדרגות האלה באמצעות פסקה WHERE. לדוגמה:

SELECT ...
FROM (
  SELECT ROW_NUMBER() OVER (ORDER BY ...) AS rn
  FROM ...
)
WHERE rn > @start_index AND rn <= @page_size + @start_index  -- note that row_number() starts with 1

השאילתה חורגת ממשאבי ה-Shuffle

מחרוזת שגיאה: Resources exceeded during query execution: Your project or organization exceeded the maximum disk and memory limit available for shuffle operations

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

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

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

השאילתה מורכבת מדי

מחרוזת שגיאה: Resources exceeded during query execution: Not enough resources for query planning - too many subqueries or query is too complex

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

  • WITH סעיפים שמוטמעים עמוק או שנעשה בהם שימוש חוזר.
  • תצוגות שמוטמעות עמוק או שנעשה בהן שימוש חוזר.
  • שימוש חוזר באופרטור UNION ALL.

כדי לפתור את השגיאה הזו, אפשר לנסות את האפשרויות הבאות:

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

כדי לעקוב באופן יזום אחרי שאילתות שמתקרבות למגבלת המורכבות, אפשר להשתמש בשדה query_info.resource_warning בתצוגה INFORMATION_SCHEMA.JOBS. בדוגמה הבאה מוחזרות שאילתות עם שימוש גבוה במשאבים ב-3 הימים האחרונים:

SELECT
  ANY_VALUE(query) AS query,
  MAX(query_info.resource_warning) AS resource_warning
FROM
  <your_project_id>.`region-us`.INFORMATION_SCHEMA.JOBS
WHERE
  creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 3 DAY)
  AND query_info.resource_warning IS NOT NULL
GROUP BY
  query_info.query_hashes.normalized_literals
LIMIT
  1000

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

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

למשימות של שאילתות:

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

  • אפשר לנסות להסיר פסקה של ORDER BY.
  • אם השאילתה משתמשת ב-JOIN, מוודאים שהטבלה הגדולה יותר נמצאת בצד ימין של הסעיף. חשוב גם לוודא שהנתונים לא מכילים מפתחות איחוד כפולים.
  • אם השאילתה משתמשת ב-FLATTEN, צריך לקבוע אם היא נחוצה לתרחיש השימוש. מידע נוסף זמין במאמר בנושא נתונים בתצוגת עץ ונתונים חוזרים.
  • אם השאילתה משתמשת ב-EXACT_COUNT_DISTINCT, כדאי להשתמש ב-COUNT(DISTINCT) במקום.
  • אם השאילתה שלכם משתמשת ב-COUNT(DISTINCT <value>, <n>) עם ערך גדול של <n>, כדאי להשתמש במקום זאת ב-GROUP BY. מידע נוסף זמין במאמר COUNT(DISTINCT).
  • אם השאילתה משתמשת בפונקציה UNIQUE, כדאי להשתמש במקום זאת בפונקציה GROUP BY או בפונקציה אנליטית (window function) בתוך שאילתת משנה.
  • אם השאילתה יוצרת הרבה שורות באמצעות פסקה LIMIT, כדאי לסנן לפי עמודה אחרת, למשל ROW_NUMBER(), או להסיר לגמרי את הפסקה LIMIT כדי לאפשר כתיבה מקבילה.
  • אם השאילתה השתמשה בתצוגות מקוננות עמוקות ובסעיף WITH, הדבר עלול לגרום לגידול אקספוננציאלי במורכבות, וכך להגיע למגבלות.
  • משתמשים בטבלאות זמניות במקום בסעיפי WITH. יכול להיות שצריך לחשב מחדש סעיף WITH כמה פעמים, מה שהופך את השאילתה למורכבת ולכן לאיטית. שמירת תוצאות ביניים בטבלאות זמניות מפחיתה את המורכבות.
  • מומלץ להימנע משימוש בשאילתות UNION ALL.
  • אם בשאילתה נעשה שימוש ב-MATCH_RECOGNIZE, צריך לשנות את הפסקה PARTITION BY כדי להקטין את גודל המחיצות, או להוסיף פסקה של PARTITION BY אם היא לא קיימת.

מידע נוסף זמין במקורות המידע הבאים:

למשימות טעינה:

אם אתם טוענים קובצי Avro או Parquet, כדאי להקטין את גודל השורה בקבצים. כדאי לבדוק את המגבלות הספציפיות על הגודל של פורמט הקובץ שאתם מעלים:

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

ל-Storage API:

מחרוזת שגיאה: Stream memory usage exceeded

במהלך קריאה של Storage Read API ReadRows, יכול להיות שיופיעו הודעות השגיאה האלה לגבי חלק מהזרמים עם שימוש גבוה בזיכרון.RESOURCE_EXHAUSTED זה יכול לקרות כשקוראים מטבלאות רחבות או מטבלאות עם סכימה מורכבת. כדי לפתור את הבעיה, צריך להקטין את גודל השורה של התוצאה על ידי בחירה של פחות עמודות לקריאה (באמצעות הפרמטר selected_fields) או על ידי פישוט סכימת הטבלה.

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

בקטעים הבאים מוסבר איך לפתור בעיות בקישוריות כשמנסים ליצור אינטראקציה עם BigQuery:

הוספה לרשימת ההיתרים של Google DNS

אפשר להשתמש בכלי Dig של Google IP כדי לפתור את נקודת הקצה של BigQuery DNS‏ bigquery.googleapis.com לכתובת IP של רשומת A יחידה. מוודאים שכתובת ה-IP הזו לא חסומה בהגדרות חומת האש.

באופן כללי, מומלץ להוסיף לרשימת ההיתרים את שמות ה-DNS של Google. טווחי כתובות ה-IP שמשותפים בקבצים https://www.gstatic.com/ipranges/goog.json ו-https://www.gstatic.com/ipranges/cloud.json משתנים לעיתים קרובות, ולכן מומלץ להוסיף לרשימת ההיתרים שמות של שרתי DNS של Google במקום זאת. ריכזנו כאן רשימה של שמות DNS נפוצים שמומלץ להוסיף לרשימת ההיתרים:

  • *.1e100.net
  • *.google.com
  • *.gstatic.com
  • *.googleapis.com
  • *.googleusercontent.com
  • *.appspot.com
  • *.gvt1.com

זיהוי שרת ה-proxy או חומת האש שמשמיטים מנות

כדי לזהות את כל קפיצות החבילות בין הלקוח לבין ממשק הקצה של Google‏ (GFE), מריצים פקודה של traceroute במחשב הלקוח. הפקודה הזו יכולה להדגיש את השרת שמשמיט חבילות שמכוונות אל GFE. דוגמה לפקודה traceroute:

traceroute -T -p 443 bigquery.googleapis.com

אפשר גם לזהות את הקפיצות של החבילות עבור כתובות IP ספציפיות של GFE אם הבעיה קשורה לכתובת IP מסוימת:

traceroute -T -p 443 142.250.178.138

אם יש בעיה של פסק זמן בצד של Google, תראו שהבקשה מגיעה עד ל-GFE.

אם אתם רואים שהמנות אף פעם לא מגיעות ל-GFE, פנו לאדמין הרשת כדי לפתור את הבעיה.

יצירת קובץ PCAP וניתוח חומת האש או שרת ה-Proxy

יוצרים קובץ לכידת מנות (PCAP) ומנתחים את הקובץ כדי לוודא שחומת האש או ה-proxy לא מסננים מנות לכתובות IP של Google ומאפשרים למנות להגיע ל-GFE.

הנה דוגמה לפקודה שאפשר להריץ באמצעות הכלי tcpdump:

tcpdump -s 0 -w debug.pcap -K -n host bigquery.googleapis.com

הגדרה של ניסיונות חוזרים לפתרון בעיות קישוריות לסירוגין

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

אם זיהיתם בעיה שקשורה לזמני קצובים לתפוגה (timeout) עקביים בצד של Google, וניסיונות חוזרים לא עוזרים, צרו קשר עם Cloud Customer Care והקפידו לצרף קובץ PCAP חדש שנוצר על ידי הפעלת כלי ללכידת מנות כמו tcpdump.

המאמרים הבאים