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

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

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

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

• כדאי לבדוק את הדף Cloud de Confiance by S3NS Service Health כדי לראות אם יש הפסקות שירות ידועות ב-BigQuery שעלולות להשפיע על הביצועים של השאילתות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

משך הביצוע

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• תחרות על משבצות (slotContention)
• שאילתות איחוד בעוצמה גבוהה (highCardinalityJoins)
• המכסה להצגת השאלות בסדר אקראי לא מספיקה (insufficientShuffleQuota)
• חלוקת נתונים לא מאוזנת (partition skew) (partitionSkew)

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

הקצאת הזמנות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הפעלות בו-זמניות של משימות

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

אפשר להריץ שאילתה בתצוגה המפורטת 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 כדי לבדוק את העניין.

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

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

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

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

כדי להשתמש ב-Gemini Cloud Assist כדי לפתור בעיה בביצוע שאילתה או בעיה בביצועים:

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

   כניסה ל-BigQuery

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

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

   • למה JOB_ID נכשל?
   • למה העבודה הזו נמשכת כל כך הרבה זמן? JOB_ID
   • תסכם את הביצועים שלי בעבודה ב-24 השעות האחרונות.

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

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

פתרון סכימת 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 statement conflicts.

כדי לפתור את השגיאה הזו, מריצים פעולות 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.

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

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

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

מחרוזת שגיאה: 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

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

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

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

שגיאה 403 חריגה מהמכסה

מחרוזת שגיאה: 403 Quota exceeded: Your table exceeded quota for total number of DML jobs writing to a table, pending + running.

הוראות DML לשינוי כמו UPDATE, ‏ DELETE ו-MERGE מתווספות לתור לכל טבלה, עם אורך תור מקסימלי של 20. השגיאה הזו מתרחשת אם שולחים הצהרות נוספות של DML לשינוי בטבלה שכבר יש בה 20 משימות במצב 'בהמתנה' או 'פועל'. כדי לפתור את השגיאה הזו:

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

שגיאה בטעינת התצוגה כשמשתמשים בתוצאות שמורות במטמון

מחרוזת שגיאה: BigQuery data export: There was an error loading this view. IAM setPolicy failed for Dataset <PROJECT_ID>. One or more users named in the policy do not belong to a permitted customer.

השגיאה הזו מציינת שלא הוענקה גישה למזהי הלקוחות שלכם ב-Google Workspace בהגבלת המדיניות של הארגון. מידע על שימוש באילוץ iam.allowedPolicyMemberDomains זמין במאמר שימוש באילוץ iam.allowedPolicyMemberDomains להטמעה של הגבלת שיתוף בדומיין.

שגיאות ב-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 מספיק משאבים להשלמת השאילתה.

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

מחרוזת שגיאה: 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

TensorFlow worker out of memory

מחרוזת שגיאה: Resources exceeded during query execution: TensorFlow worker out of memory.

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

כדי לפתור את השגיאה הזו:

1. שימוש במודלים מרוחקים של Gemini Enterprise Agent Platform: אם המודלים חורגים ממגבלות הזיכרון, אפשר לפרוס את המודל ב-Agent Platform באמצעות השלבים של Vertex AI SDK ל-Python לפריסת מודל, ואז לגשת אליו באמצעות מודלים מרוחקים. כך דרישות הזיכרון מועברות לתשתית ייעודית של Agent Platform.

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

3. שימוש בפונקציות פחות אינטנסיביות: אם השגיאה מתרחשת במהלך קריאה ל-ML.EXPLAIN_PREDICT, נסו להריץ את העבודה עם ML.PREDICT כדי לבדוק אם המודל יכול לפעול בלי התקורה הנוספת של תכונות ההסבר.

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

   SELECT BYTE_LENGTH(TO_JSON_STRING(t)) AS row_size
   FROM your_table AS t
   ORDER BY row_size DESC
   LIMIT 10

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

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

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

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

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

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

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

מחרוזת שגיאה: 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. בדוגמה הבאה מוצגות שאילתות עם שימוש גבוה במשאבים בשלושת הימים האחרונים:

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, כדאי להקטין את גודל השורה בקבצים. כדאי לבדוק את המגבלות הספציפיות על הגודל של פורמט הקובץ שאתם מעלים:

• דרישות לגבי קובץ קלט בפורמט 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.

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

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