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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מציאות במטמון (cache hits)

כדי לוודא שהביצוע המהיר של המשימה היה מציאה במטמון, בודקים את הערך של 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

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

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

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

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

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

הקצאת הזמנה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ניצול המקום השמור

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

כדי להבין אם משימה ביקשה משבצות נוספות, בודקים את המדד של היחידות המשוערות שניתנות להרצה, שהוא estimatedRunnableUnits מהתגובה של Job API, או period_estimated_runnable_units בתצוגה INFORMATION_SCHEMA.JOBS_TIMELINE. אם הערך של המדד הזה גדול מ-0, יכול להיות שהמשימה הייתה יכולה להפיק תועלת מ-slots נוספים באותו זמן. כדי להעריך את אחוז זמן הביצוע של המשימה שבו המשימה הייתה יכולה להפיק תועלת ממשבצות נוספות, מריצים את השאילתה הבאה בתצוגה 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. נכנסים לדף BigQuery במסוף Cloud de Confiance .

   כניסה ל-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) (UPDATE, DELETE או MERGE) מנסות לשנות נתונים באותה מחיצה בטבלה בו-זמנית, או כשהטבלה נחתכת בזמן שפקודת DML פועלת.

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

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

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

זיהוי המשימה שמתנגשת עם המשימה הנוכחית

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

SELECT
  job_id,
  query,
  start_time,
  end_time
FROM
  `region-REGION`.INFORMATION_SCHEMA.JOBS
WHERE
  creation_time BETWEEN
    TIMESTAMP_SUB(TIMESTAMP 'FAILED_JOB_START_TIME', INTERVAL 1 DAY)
    AND TIMESTAMP 'FAILED_JOB_END_TIME'
  AND destination_table.table_id = 'TABLE_NAME'
  AND destination_table.dataset_id = 'DATASET_NAME'
  AND statement_type IN ('UPDATE', 'DELETE', 'MERGE')
  AND start_time <= 'FAILED_JOB_END_TIME'
  AND (end_time >= 'FAILED_JOB_START_TIME' OR end_time IS NULL)
ORDER BY
  start_time;

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

• ‫REGION: שם האזור שבו נמצא מערך הנתונים, לדוגמה us.
• ‫FAILED_JOB_START_TIME: חותמת הזמן של תחילת המשימה שנכשלה, לדוגמה 2026-09-01 09:55:00 UTC.
• ‫FAILED_JOB_END_TIME: חותמת הזמן של סיום המשימה שנכשלה, לדוגמה 2026-09-01 10:00:00 UTC.
• ‫TABLE_NAME: שם הטבלה שפקודת ה-DML שנכשלה ניסתה לעדכן.
• ‫DATASET_NAME: שם מערך הנתונים שמכיל את הטבלה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מחרוזת השגיאה: Query exceeded limit for bytes billed: LIMIT_BYTES. REQUIRED_BYTES or higher required.

שגיאת ה-HTTP‏ 400 Bad Request‏ (reason: bytesBilledLimitExceeded) מתרחשת כשההערכה של מספר הבייטים לחיוב לפני הרצת השאילתה (REQUIRED_BYTES) חורגת ממגבלת הבייטים שהוגדרה ב-maximumBytesBilled (LIMIT_BYTES). השגיאה ב-BigQuery מתרחשת לפני הרצת השאילתה, והחשבון לא מחויב על השאילתה.

בתמחור על פי דרישה יש מינימום של 10MB‏ (10,485,760 בייטים) לכל טבלה שאליה מפנים, וההערכה לפני ההפעלה של טבלאות מסודרות באשכולות מחשבת גבול עליון בכל המחיצות התואמות לפני שמתרחש גיזום האשכולות. לכן, הערך של REQUIRED_BYTES יכול להיות גבוה יותר ממספר הבייטים שנסרקו בפועל כשהשאילתה פועלת.

כדי לפתור את הבעיה תוכלו לנסות אחד מהפתרונות הבאים:

• תצוגה מקדימה של כמות הבייטים המשוערת באמצעות הרצה יבשה. מריצים הרצה יבשה (bq query --dry_run ב-CLI של bq או configuration.dryRun = true ב-API) או בודקים את הכלי לאימות שאילתות במסוף Cloud de Confiance כדי לבחון את totalBytesProcessed לפני שמריצים את השאילתה.
• לבצע אופטימיזציה של השאילתה כדי לסרוק פחות בייטים. בחרו רק את העמודות שהשאילתה צריכה במקום להריץ את SELECT *, וסננו לפי עמודות מחולקות למחיצות כדי ש-BigQuery יוכל לקצץ מחיצות במהלך האומדן שלפני ההרצה. סינון בעמודות מקובצות מפחית את מספר הבייטים בפועל שמחויבים כשמריצים את השאילתה, אבל לא מפחית את האומדן של הגבול העליון לפני ההרצה שנבדק מול maximumBytesBilled. למידע נוסף, ראו צמצום הנתונים שעוברים עיבוד.
• להגדיל את המגבלה של maximumBytesBilled. מגדירים את מגבלת הבייטים של maximumBytesBilled לערך ששווה לערך של REQUIRED_BYTES שדווח בהודעת השגיאה או גבוה ממנו, באמצעות Maximum bytes billed (בקטע Query settings > Advanced options) במסוף Cloud de Confiance , הדגל --maximum_bytes_billed ב-CLI של bq או מאפיין הגדרת המשימה configuration.query.maximumBytesBilled ב-API.

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

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

השגיאה הזו מתרחשת כשתוצאות השאילתה גדולות מגודל התגובה המקסימלי, או כששורה אחת חורגת ממגבלת הגודל של שורה ב-API בארכיטקטורת REST.

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

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

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

• Response too large to return. Message before conversion exceeds max row limit, limit: LIMIT actual: ACTUAL
• Response too large to return. single row too big to return due to byte limit, actual: ACTUAL limit: LIMIT

שגיאת ה-HTTP‏ 403 Forbidden‏ (reason: responseTooLarge) מתרחשת כשקוראים תוצאות של שאילתות או שורות בטבלה באמצעות השיטות jobs.getQueryResults או tabledata.list של ה-API בארכיטקטורת REST (כולל הצגת תוצאות במסוף Cloud de Confiance או בכלי שורת הפקודה של BigQuery), ושורה אחת שעברה סריאליזציה ולא עברה הטמעה חורגת מהגודל המקסימלי של שורה שנתמך על ידי נקודת הקצה של עימוד ב-REST (‏‎20MB ל-jobs.getQueryResults או ‎100MB ל-tabledata.list). בדרך כלל זה קורה בטבלאות עם סכימות רחבות, שדות ARRAY או STRUCT חוזרים עם הטמעה עמוקה, או ערכי STRING או BYTES גדולים.

כדי לקרוא שורות שחורגות ממגבלות הגודל של API בארכיטקטורת REST, אתם יכולים:

• להשתמש ב-BigQuery Storage Read API. קוראים את הטבלה או את טבלת היעד של השאילתה הזמנית באמצעות Storage Read API, שמעביר נתונים בפורמט בינארי של Apache Arrow או Avro ותומך בקריאות עם תפוקה גבוהה של מבני שורות גדולים ומורכבים.
• מייצאים את הטבלה ל-Cloud Storage. מייצאים את הטבלה או את תוצאות השאילתה ל-Cloud Storage באמצעות הצהרת EXPORT DATA או משימת חילוץ (לדוגמה, בפורמט Avro,‏ Parquet או JSON) וקוראים את הקבצים שיוצאו מ-Cloud Storage.
• להקרין או לצבור פחות עמודות. במקום להריץ את SELECT *, בחרו רק את העמודות או שדות המשנה הספציפיים שנדרשים לאפליקציה, או בטלו את הקינון של מערכים חוזרים בשאילתה כדי ששורות הפלט הנפרדות לא יחרגו ממגבלת הגודל.

חסר פרמטר חובה

מחרוזת השגיאה: Required parameter is missing: PARAMETER_NAME

שגיאת ה-HTTP‏ 400 Bad Request‏ (reason: required) היא שגיאת אימות של ה-API לפני ההפעלה. היא מתרחשת כשלא מספקים שדה חובה ב-payload של בקשת ה-API או בכתובת ה-URL, או כשמאפיין חובה באובייקט ההגדרה של ספריית הלקוח הוא null או None.

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

• לעיון במאמרי העזרה של ה-API בארכיטקטורת REST בודקים את PARAMETER_NAME בהודעת השגיאה, וגם את גוף הבקשה הנדרש ואת הפרמטרים של השאילתה לשיטה במאמרי העזרה של BigQuery REST API, כדי לוודא שהקוד מאכלס את כל שדות החובה.
• אימות הפרמטרים של ספריית הלקוח. אם אתם משתמשים בספריית לקוח של BigQuery (כמו ספריית הלקוח של Java או Python), עיינו במסמכי התיעוד של ספריית הלקוח כדי לבדוק מהם הפרמטרים הנדרשים של ה-method שאתם קוראים לה.
• בודקים את אובייקט ההגדרות האישיות לפני שקוראים ל-API. משתמשים בכלי לניפוי באגים או בפקודת רישום ביומן כדי לבדוק את אובייקט ההגדרה של המשימה או הבקשה מיד לפני שהקריאה ל-API מתבצעת, ובודקים אם יש ערכי None או null שהוקצו למאפיינים הנדרשים כמו destinationTable.

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

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

כדי לבדוק את המשימות בסטטוס PENDING שממלאות את התור לצד המשימות בסטטוס RUNNING שעשויות לחסום את ההוצאה שלהן מהתור, שולחים שאילתה לתצוגה INFORMATION_SCHEMA.JOBS:

SELECT
  project_id,
  job_id,
  creation_time,
  user_email,
  statement_type,
  state
FROM
  `region-us`.INFORMATION_SCHEMA.JOBS
WHERE
  statement_type IN ('UPDATE', 'DELETE', 'MERGE')
  AND state IN ('RUNNING', 'PENDING')
ORDER BY
  creation_time DESC;

פתרון אפשרי אחד הוא לקבץ כמה פעולות 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‏ (INSERT,‏ UPDATE,‏ DELETE ו-MERGE) שכותבות לטבלה אחת – גם במצב PENDING וגם במצב RUNNING – חורג ממכסת ההרצה בו-זמנית של הטבלה.

השגיאה limit is 20 מגבילה באופן ספציפי את התור PENDING לפקודות DML שמשנות נתונים (UPDATE,‏ DELETE ו-MERGE), אבל השגיאה 403 Quota exceeded חלה על המספר הכולל של כל משימות ה-DML (INSERT וגם DML שמשנות נתונים) שכותבות לטבלה בו-זמנית. מכיוון ש-DML לשינוי נתונים כבר מוגבל על ידי מגבלת התור של 20 משימות, שגיאת המכסה 403 מתרחשת בדרך כלל כששולחים יותר מדי שאילתות INSERT בו-זמנית בטבלה אחת. כדי לפתור את השגיאה הזו:

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

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

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

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

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

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

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

מחרוזת השגיאה: Query exceeded resource limits. This query used CPU_SECONDS_USED CPU seconds but would charge only ANALYSIS_MEGABYTES_BILLEDM Analysis bytes. This exceeds the ratio supported by the on-demand pricing model. Please consider moving this workload to a capacity-based pricing model, which does not have this limit. CPU_SECONDS_USED CPU seconds were used, and this query must use less than CPU_SECONDS_LIMIT CPU seconds.

השגיאה הזו (billingTierLimitExceeded) מתרחשת כששאילתה שמשתמשת בתמחור על פי דרישה חורגת מהמגבלה המקסימלית של שימוש במעבד (CPU) לכל נתונים שנסרקו, שהיא בערך 256 שניות מעבד לכל MiB של נתונים שנסרקו. זה קורה כששאילתה על פי דרישה מבצעת פעולות שדורשות הרבה משאבי מעבד (CPU) – כמו פעולות CROSS JOIN לא מוגבלות, תנאי איחוד לא מדויקים, ביטויים רגולריים מורכבים, פונקציות אנליטיות (window functions) לא מחולקות למחיצות או פונקציות JavaScript UDF שדורשות הרבה משאבי מחשוב – על כמות קטנה יחסית של נתונים סרוקים.

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

• מבצעים אופטימיזציה של השאילתה. משנים את ה-SQL כדי להפחית את התקורה של החישוב ביחס לנתונים שנסרקו. למשל, מסירים מכפלות קרטזיות לא מכוונות (פעולות CROSS JOIN ללא סינון), מחליפים פרדיקטים לא מדויקים של צירוף, מפשטים ביטויים רגולריים מורכבים, מוסיפים משפטי PARTITION BY לפונקציות אנליטיות בחלונות גדולים ללא חלוקה למחיצות או מבצעים אופטימיזציה של פונקציות JavaScript בהגדרת המשתמש (UDF). למידע נוסף, קראו את המאמרים הימנעות מדפוסי אנטי-SQL, מבוא לאופטימיזציה של ביצועי שאילתות ופתרון בעיות של חריגה מהמשאבים.
• מעבר לתמחור מבוסס-קיבולת מריצים את עומס העבודה באמצעות תמחור מבוסס-קיבולת (משבצות). בתמחור מבוסס-קיבולת, השאילתות לא כפופות למגבלת היחס בין מעבד (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

נגמר הזיכרון של ה-worker ב-TensorFlow

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

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

באופן כללי, מומלץ להוסיף לרשימת ההיתרים את שמות ה-DNS של Google. טווחי כתובות ה-IP שמשותפים בקבצים https://documentation.s3ns.fr/ipranges/goog.json ו-https://documentation.s3ns.fr/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 מסוימת, אפשר גם לזהות דילוגים של חבילות בכתובות IP ספציפיות של GFE:

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, או אם המכונה עם איזון עומסים מצומצמת אנכית בהתאם לעומס (scale down), מה שעלול לגרום למיחזור של כתובת ה-IP של נקודת הקצה. אם מאזני העומסים של GFE מנתקים את החיבור, הלקוח צריך לתפוס את הבקשה שזמן הקצוב שלה לתפוגה חלף ולנסות שוב את הבקשה לנקודת הקצה של ה-DNS. חשוב לוודא שלא משתמשים באותה כתובת IP עד שהבקשה תצליח, כי יכול להיות שכתובת ה-IP השתנתה.

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

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

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