תצוגת משרות
התצוגה INFORMATION_SCHEMA.JOBS מכילה מטא-נתונים כמעט בזמן אמת על כל המשימות ב-BigQuery בפרויקט הנוכחי.
התפקידים הנדרשים
כדי לקבל את ההרשאות שנדרשות לשליחת שאילתות לתצוגה INFORMATION_SCHEMA.JOBS, בקשו מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:
- BigQuery User (
roles/bigquery.user) - BigQuery Resource Viewer (
roles/bigquery.resourceViewer)
להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.
התפקידים המוגדרים מראש האלה כוללים את ההרשאות שנדרשות כדי לשלוח שאילתות לתצוגה INFORMATION_SCHEMA.JOBS. כדי לראות בדיוק אילו הרשאות נדרשות, אפשר להרחיב את הקטע ההרשאות הנדרשות:
ההרשאות הנדרשות
כדי לשלוח שאילתות לתצוגה INFORMATION_SCHEMA.JOBS, נדרשות ההרשאות הבאות:
-
bigquery.jobs.listAll -
bigquery.jobs.create
יכול להיות שתקבלו את ההרשאות האלה באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש אחרים.
מידע נוסף על הרשאות ב-BigQuery זמין במאמר בקרת גישה באמצעות IAM.
סכימה
הנתונים הבסיסיים מחולקים למחיצות לפי העמודה creation_time ומקובצים לפי project_id ו-user_email. העמודה query_info מכילה מידע נוסף על עבודות השאילתה.
הסכימה של התצוגה INFORMATION_SCHEMA.JOBS היא:
| שם העמודה | סוג הנתונים | ערך |
|---|---|---|
bi_engine_statistics |
RECORD |
אם הפרויקט מוגדר לשימוש ב-BI Engine, השדה הזה מכיל את BiEngineStatistics.
אחרת NULL.
|
cache_hit |
BOOLEAN |
אם תוצאות השאילתה של המשימה הזו הגיעו מהמטמון.
אם יש לכם משימה של הצהרה עם כמה שאילתות, הערך של cache_hit בשאילתת ההורה הוא NULL.
|
creation_time |
TIMESTAMP |
(עמודת חלוקה למחיצות) מועד היצירה של המשימה הזו. החלוקה למחיצות מבוססת על הזמן בשעון UTC של חותמת הזמן הזו. |
destination_table |
RECORD |
טבלת היעד של התוצאות, אם יש כאלה. |
dml_statistics |
RECORD |
אם העבודה היא שאילתה עם פקודת DML, הערך הוא רשומה עם השדות הבאים:
NULL.העמודה הזו מופיעה בתצוגות INFORMATION_SCHEMA.JOBS_BY_USER ו-INFORMATION_SCHEMA.JOBS_BY_PROJECT.
|
end_time |
TIMESTAMP |
שעת הסיום של המשימה, באלפיות השנייה מאז ראשית הזמן. השדה הזה מייצג את הזמן שבו המשימה נכנסת למצב DONE. |
error_result |
RECORD |
פרטים על שגיאות כאובייקטים מסוג ErrorProto. |
job_creation_reason.code |
STRING |
מציין את הסיבה ברמה גבוהה ליצירת המשימה. הערכים האפשריים:
|
job_id |
STRING |
המזהה של המשימה, אם נוצרה משימה. אחרת, מזהה השאילתה של שאילתה שמשתמשת במצב יצירה אופציונלית של משימות. לדוגמה, bquxjob_1234. |
job_stages |
RECORD REPEATED |
שלבי השאילתה של המשימה.
הערה: הערכים בעמודה הזו ריקים בשאילתות שקוראות מטבלאות עם כללי מדיניות גישה ברמת השורה. מידע נוסף על שיטות מומלצות לאבטחה ברמת השורה ב-BigQuery זמין במאמר שיטות מומלצות לאבטחה ברמת השורה ב-BigQuery. |
job_type |
STRING |
סוג המשימה. הערכים האפשריים: QUERY, LOAD, EXTRACT, COPY או NULL. הערך NULL מציין משימה ברקע.
|
labels |
RECORD |
מערך של תוויות שנוספו למשימה כצמדי מפתח/ערך. |
object_storage_stats |
RECORD REPEATED |
נתונים סטטיסטיים על השימוש במאגר אובייקטים ובמטמון של משימת שאילתה.
הערך הוא רשומה חוזרת עם השדות הבאים:
|
parent_job_id |
STRING |
המזהה של המשימה הראשית, אם יש כזו. |
priority |
STRING |
העדיפות של המשימה הזו. הערכים התקינים כוללים את INTERACTIVE ו-BATCH. |
project_id |
STRING |
(Clustering column) מזהה הפרויקט. |
project_number |
INTEGER |
מספר הפרויקט. |
query |
STRING |
טקסט של שאילתת SQL. |
referenced_tables |
RECORD |
מערך של ערכי STRUCT שמכילים את השדות הבאים של STRING לכל טבלה שהשאילתה מפנה אליה: project_id, dataset_id ו-table_id. השדה הזה מאוכלס רק עבור משימות של שאילתות שלא מגיעות מהמטמון.
|
referenced_logical_views |
RECORD |
מערך של ערכי STRUCT שמכילים את השדות הבאים של STRING לכל תצוגה לוגית שאליה מתייחסת השאילתה: project_id, dataset_id ו-table_id. השדה הזה מאוכלס רק במשימות שאילתה שלא נמצאו במטמון.
|
reservation_id |
STRING |
שם ההזמנה הראשית שהוקצתה לעבודה הזו, בפורמט RESERVATION_ADMIN_PROJECT:RESERVATION_LOCATION.RESERVATION_NAME.בפלט הזה:
|
reservation_group_path |
ARRAY<STRING> |
קבוצת ההזמנות שאליה ההזמנה מקושרת.
לדוגמה, אם ההזמנה מקושרת לקבוצה my-group, השדה reservation_group_path מכיל רשימה כמו: [my-group]. |
edition |
STRING |
המהדורה שמשויכת להזמנה שהוקצתה למשימה הזו. מידע נוסף על מהדורות זמין במאמר מבוא למהדורות של BigQuery. |
session_info |
RECORD |
פרטים על הסשן שבו המשימה הזו הופעלה, אם יש כזה. |
start_time |
TIMESTAMP |
שעת ההתחלה של המשימה, באלפיות השנייה מאז ראשית זמן יוניקס (Unix epoch). השדה הזה מייצג את הזמן שבו המשימה עוברת מהמצב PENDING למצב RUNNING או DONE. |
state |
STRING |
מצב ההפעלה של הג'וב. הסטטוסים התקינים הם PENDING, RUNNING ו-DONE.
|
statement_type |
STRING |
סוג הצהרת השאילתה. לדוגמה, DELETE, INSERT, SCRIPT, SELECT או UPDATE. רשימה של ערכים תקינים מופיעה בקטע QueryStatementType.
|
timeline |
RECORD |
ציר הזמן של השאילתה של המשימה. כולל תמונות מצב של ביצוע שאילתות. |
total_bytes_billed |
INTEGER |
אם הפרויקט מוגדר לשימוש בתמחור על פי דרישה, השדה הזה מכיל את סך כל הבייטים שחויבו עבור המשימה. אם הפרויקט מוגדר לשימוש בתמחור לפי תעריף קבוע, לא מחויבים על בייטים והשדה הזה הוא רק לצורכי מידע.
הערה: הערכים בעמודה הזו ריקים בשאילתות שקוראות מטבלאות עם מדיניות גישה ברמת השורה. מידע נוסף זמין במאמר שיטות מומלצות לאבטחה ברמת השורה ב-BigQuery. |
total_bytes_processed |
INTEGER |
מספר הבייטים הכולל שעובדו על ידי המשימה. הערה: הערכים בעמודה הזו ריקים בשאילתות שקוראות מטבלאות עם כללי מדיניות גישה ברמת השורה. מידע נוסף זמין במאמר שיטות מומלצות לאבטחה ברמת השורה ב-BigQuery. |
total_modified_partitions |
INTEGER |
המספר הכולל של המחיצות שהמשימה שינתה. השדה הזה מאוכלס במשימות LOAD ו-QUERY.
|
total_slot_ms |
INTEGER |
מספר אלפיות השנייה של המשבצת שהוקצו למשימה במשך כל הזמן שהיא הייתה במצב RUNNING, כולל ניסיונות חוזרים. |
total_services_sku_slot_ms |
INTEGER |
המספר הכולל של אלפיות השנייה של ה-slot למשימה שפועלת בשירותים חיצוניים ומחויבת במק"ט של השירותים. השדה הזה מאוכלס רק עבור משימות שכוללות עלויות של שירותים חיצוניים, והוא מייצג את סך השימוש בעלויות ששיטת החיוב שלהן היא "SERVICES_SKU". |
transaction_id |
STRING |
המזהה של העסקה שבה המשימה הזו הופעלה, אם רלוונטי. |
user_email |
STRING |
(Clustering column) כתובת האימייל או חשבון השירות של המשתמש שביצע את העבודה. |
principal_subject |
STRING |
ייצוג מחרוזת של הזהות של חשבון המשתמש שהפעיל את העבודה. |
query_info.resource_warning |
STRING |
הודעת האזהרה שמופיעה אם השימוש במשאבים במהלך עיבוד השאילתה חורג מהסף הפנימי של המערכת. אם עבודת השאילתה הושלמה בהצלחה, השדה resource_warning יאוכלס. עם resource_warning, מקבלים נקודות על הגרף נוספות לאופטימיזציה של השאילתות ולהגדרת מעקב אחרי מגמות הביצועים של קבוצת שאילתות מקבילה באמצעות query_hashes.
|
query_info.query_hashes.normalized_literals |
STRING |
מכיל את ערך ה-hash של השאילתה. normalized_literals הוא גיבוב (hash) הקסדצימלי של STRING שמתעלם מהערות, מערכי פרמטרים, מפונקציות בהגדרת המשתמש (UDF) ומליטרלים.
ערך הגיבוב יהיה שונה אם התצוגות הבסיסיות ישתנו, או אם השאילתה מפנה באופן מרומז לעמודות, כמו SELECT *, וסכימת הטבלה משתנה.
השדה הזה מופיע בשאילתות GoogleSQL שהצליחו, אבל לא נמצאו במטמון. |
query_info.performance_insights |
RECORD |
תובנות לגבי הביצועים של המשרה. |
query_info.optimization_details |
STRUCT |
האופטימיזציות מבוססות-ההיסטוריה של המשימה. העמודה הזו מופיעה רק בתצוגה JOBS_BY_PROJECT.
|
transferred_bytes |
INTEGER |
מספר הבייטים הכולל שהועבר בשאילתות BigQuery Omni, כמו משימות העברה של BigQuery Omni. |
materialized_view_statistics |
RECORD |
נתונים סטטיסטיים של תצוגות מהותיות שנכללו במשימת שאילתה. (תצוגה מקדימה) |
metadata_cache_statistics |
RECORD |
נתונים סטטיסטיים על השימוש באינדקס של עמודות המטא-נתונים בטבלאות שאליהן מפנה משימת שאילתה. |
search_statistics |
RECORD |
נתונים סטטיסטיים של שאילתת חיפוש. |
query_dialect |
STRING |
השדה הזה יהיה זמין במהלך מאי 2025.
הניב של השאילתה ששימש למשימה. הערכים התקינים כוללים:
במשימות שנשלחו על ידי משתמשים, השדה הזה מאוכלס רק במשימות של שאילתות. אפשר לשלוט בבחירה של ניב השאילתה שמוגדר כברירת מחדל באמצעות הגדרות התצורה. במשימות ברקע, הערך של השדה הזה לא נשלט על ידי הגדרות ברירת המחדל של ניב השאילתה, ולא משפיע על משימות שנשלחות על ידי משתמשים. בחלק מהמשימות ברקע, הערך מושמט. |
continuous |
BOOLEAN |
האם העבודה היא שאילתה מתמשכת. |
continuous_query_info.output_watermark |
TIMESTAMP |
מייצג את הנקודה שעד אליה השאילתה המתמשכת עיבדה נתונים בהצלחה. |
vector_search_statistics |
RECORD |
נתונים סטטיסטיים של שאילתת חיפוש וקטורי. |
external_service_costs |
RECORD |
מערך של מידע על עלויות השירות החיצוני של משימת שאילתה. |
ml_statistics.model_type |
STRING |
אם העבודה היא שאילתה ליצירת מודל של BigQuery ML, השדה הזה מציין את סוג המודל שנוצר. לכל שאר המשרות, הערך הוא NULL.
|
כששולחים שאילתה ל-INFORMATION_SCHEMA.JOBS כדי למצוא סיכום של עלות משימות השאילתה, צריך להחריג את סוג ההצהרה SCRIPT, אחרת יכול להיות שחלק מהערכים ייספרו פעמיים. השורה SCRIPT כוללת ערכי סיכום של כל עבודות הצאצא שהופעלו כחלק מהעבודה הזו.
כדי לשמור על יציבות, מומלץ לציין במפורש את העמודות בשאילתות של סכימת המידע במקום להשתמש בתו כללי לחיפוש (SELECT *). ציון מפורש של העמודות מונע את קריסת השאילתות אם הסכימה הבסיסית משתנה.
משימות של שאילתות עם כמה הצהרות
משימת שאילתה עם כמה הצהרות היא משימת שאילתה שמשתמשת בשפה פרוצדורלית.
משימות של שאילתות עם כמה הצהרות בדרך כלל מגדירות משתנים באמצעות DECLARE או כוללות הצהרות של בקרת זרימה כמו IF או WHILE. כששולחים שאילתה ל-INFORMATION_SCHEMA.JOBS, יכול להיות שתצטרכו לזהות את ההבדל בין משימת שאילתה עם כמה הצהרות לבין משימות אחרות. למשימת שאילתה עם כמה הצהרות יש את המאפיינים הבאים:
-
statement_type=SCRIPT -
reservation_id=NULL
עבודות לילדים
לכל אחת ממשימות הצאצא של משימת שאילתה עם כמה הצהרות יש parent_job_id שמצביע על משימת השאילתה עם כמה הצהרות עצמה. הוא כולל ערכי סיכום של כל המשימות הצאצא שבוצעו כחלק מהמשימה הזו.
אם אתם שולחים שאילתה ל-INFORMATION_SCHEMA.JOBS כדי למצוא סיכום של עלויות משימות השאילתה, אתם צריכים להחריג את סוג ההצהרה SCRIPT. אחרת, יכול להיות שחלק מהערכים, כמו total_slot_ms, ייספרו פעמיים.
שמירת נתונים
בתצוגה הזו מוצגות משימות שפועלות, יחד עם היסטוריית המשימות מ-180 הימים האחרונים.
אם פרויקט מועבר לארגון (או שאין לו ארגון או שהוא מועבר מארגון אחר), אי אפשר לגשת למידע על המשימות שנוצרו לפני תאריך ההעברה דרך התצוגה INFORMATION_SCHEMA.JOBS, כי בתצוגה הזו נשמרים רק נתונים שנוצרו החל מתאריך ההעברה.
היקף ותחביר
שאילתות בתצוגה הזו חייבות לכלול מזהה אזור. בטבלה הבאה מוסבר היקף האזור בתצוגה הזו:
| שם התצוגה | היקף המשאב | היקף האזור |
|---|---|---|
[PROJECT_ID.]`region-REGION`.INFORMATION_SCHEMA.JOBS[_BY_PROJECT] |
רמת הפרויקט | REGION |
-
PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance (אופציונלי). אם לא מציינים פרויקט, המערכת משתמשת בפרויקט שמוגדר כברירת מחדל. -
REGION: כל שם של אזור של מערך נתונים. לדוגמה,`region-us`.
אומדני שאילתות של הרצה יבשה
כשמבצעים הרצה של שאילתה שמפנה לתצוגה INFORMATION_SCHEMA.JOBS, מספר הבייטים המשוערים לעיבוד עשוי להיות גבוה משמעותית ממספר הבייטים בפועל שעובדו במהלך ביצוע השאילתה.
ההערכה המוגזמת הזו מתרחשת כי החישוב של הרצת בדיקה מתייחס רק למסננים בcreation_timeעמודת החלוקה למחיצות של נתוני הבסיס. הוא לא מביא בחשבון מסננים בעמודות אשכולות, כמו המסנן המשתמע project_id או המסנן user_email, אם הם צוינו במשפט WHERE.
הנתונים שנסרקים בפועל יכולים להיות קטנים משמעותית מהאומדן של ההרצה היבשה, במיוחד בפרויקטים או אצל משתמשים עם פחות משימות.
אם לא מציינים מסנן ב-creation_time, לא מתבצע גיזום מחיצות, והאומדן של ההרצה היבשה משקף סריקה של כל המחיצות של הנתונים הבסיסיים. עם זאת, יכול להיות שאשכולות הנתונים עדיין יפחיתו את מספר הבייטים בפועל שעובדו בהשוואה לאומדן הזה.
דוגמאות
כדי להריץ את השאילתה בפרויקט שאינו פרויקט ברירת המחדל, מוסיפים את מזהה הפרויקט בפורמט הבא:
`PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
-
PROJECT_ID: מזהה הפרויקט -
REGION_NAME: האזור של הפרויקט.
לדוגמה, `myproject`.`region-us-central1`.INFORMATION_SCHEMA.JOBS.
השוואה בין נתוני השימוש בעבודות על פי דרישה לבין נתוני החיוב
בפרויקטים שמשתמשים בתמחור על פי דרישה, אתם יכולים להשתמש בתצוגה INFORMATION_SCHEMA.JOBS כדי לבדוק את חיובי המחשוב בתקופה נתונה.
בפרויקטים שבהם נעשה שימוש בתמחור לפי קיבולת (יחידות קיבולת), אפשר להשתמש בINFORMATION_SCHEMA.RESERVATIONS_TIMELINE כדי לבדוק את חיובים על מחשוב בתקופה מסוימת.
השאילתה הבאה מפיקה נתונים מצטברים משוערים יומיים של נפח הנתונים ב-TiB שחויבתם עליו, ושל החיובים שנובעים מכך. בקטע מגבלות מוסבר מתי יכול להיות שההערכות האלה לא יהיו זהות לחיוב שלכם.
רק בדוגמה הזו, צריך להגדיר את המשתנים הנוספים הבאים. כדי שיהיה קל להשתמש בהם, אפשר לערוך אותם כאן.
-
START_DATE: התאריך המוקדם ביותר לחישוב הממוצע (כולל). -
END_DATE: התאריך האחרון לצבירה (כולל). -
PRICE_PER_TIB: המחיר על פי דרישה לכל TiB שמשמש להערכות חיוב.
CREATE TEMP FUNCTION isBillable(error_result ANY TYPE) AS ( -- You aren't charged for queries that return an error. error_result IS NULL -- However, canceling a running query might incur charges. OR error_result.reason = 'stopped' ); -- BigQuery hides the number of bytes billed on all queries against tables with -- row-level security. CREATE TEMP FUNCTION isMaybeUsingRowLevelSecurity( job_type STRING, tib_billed FLOAT64, error_result ANY TYPE) AS ( job_type = 'QUERY' AND tib_billed IS NULL AND isBillable(error_result) ); -- Built-in BigQuery ML models apply a 50x billing multiplier to -- total_bytes_billed for on-demand CREATE_MODEL queries. CREATE TEMP FUNCTION isNativeBqmlModel(model_type STRING) AS ( model_type IN ( 'LINEAR_REGRESSION', 'LOGISTIC_REGRESSION', 'KMEANS', 'MATRIX_FACTORIZATION', 'PCA', 'ARIMA', 'ARIMA_PLUS', 'ARIMA_PLUS_XREG', 'CONTRIBUTION_ANALYSIS', 'TRANSFORM_ONLY') ); WITH query_params AS ( SELECT date 'START_DATE' AS start_date, -- inclusive date 'END_DATE' AS end_date, -- inclusive ), usage_with_multiplier AS ( SELECT job_type, error_result, creation_time, -- Jobs are billed by end_time in PST8PDT timezone, regardless of where -- the job ran. EXTRACT(date FROM end_time AT TIME ZONE 'PST8PDT') billing_date, total_bytes_billed / 1024 / 1024 / 1024 / 1024 * IF( statement_type = 'CREATE_MODEL' AND isNativeBqmlModel(ml_statistics.model_type), 50, 1) AS total_tib_billed, CASE statement_type WHEN 'SCRIPT' THEN 0 ELSE PRICE_PER_TIB END AS multiplier, FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE statement_type <> 'SCRIPT' ) SELECT billing_date, sum(total_tib_billed * multiplier) estimated_charge, sum(total_tib_billed) estimated_usage_in_tib, countif(isMaybeUsingRowLevelSecurity(job_type, total_tib_billed, error_result)) AS jobs_using_row_level_security, FROM usage_with_multiplier, query_params WHERE 1 = 1 -- Filter by creation_time for partition pruning. AND date(creation_time) BETWEEN date_sub(start_date, INTERVAL 2 day) AND date_add(end_date, INTERVAL 1 day) AND billing_date BETWEEN start_date AND end_date AND isBillable(error_result) GROUP BY billing_date ORDER BY billing_date;
מגבלות
ב-BigQuery מוסתרים חלק מהנתונים הסטטיסטיים של שאילתות בטבלאות עם אבטחה ברמת השורה. השאילתה שסופרת את מספר המשימות שהושפעו היא
jobs_using_row_level_security, אבל אין לה גישה לשימוש שניתן לחיוב.התמחור של שאילתות על פי דרישה ב-BigQuery ML תלוי בסוג המודל שנוצר. הפונקציה
isNativeBqmlModelבשאילתה לדוגמה בודקת אתml_statistics.model_typeומפעילה את המכפיל פי 50 רק על מודלים מובנים. במודלים חיצוניים של Vertex AI, העלות שלtotal_bytes_billedכבר כוללת את עלויות האימון החיצוניות שהומרו, בשיעור של פי 1.בפרוצדורות של Apache Spark משתמשים במודל תמחור דומה, אבל החיובים מדווחים כמק"ט של תשלום לפי שימוש במהדורת BigQuery Enterprise.
INFORMATION_SCHEMA.JOBSמתעד את השימוש הזה כ-total_bytes_billed, אבל לא יכול לקבוע איזה מק"ט מייצג השימוש.
חישוב הניצול הממוצע של חריצי עיבוד
בדוגמה הבאה מחושב השימוש הממוצע ב-slots לכל השאילתות ב-7 הימים האחרונים בפרויקט נתון. חשוב לדעת שהחישוב הזה הכי מדויק לפרויקטים שבהם השימוש ב-slots עקבי לאורך השבוע. אם השימוש במשבצות בפרויקט לא עקבי, יכול להיות שהמספר הזה יהיה נמוך מהצפוי.
כדי להריץ את השאילתה:
SELECT SUM(total_slot_ms) / (1000 * 60 * 60 * 24 * 7) AS avg_slots FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE -- Filter by the partition column first to limit the amount of data scanned. -- Eight days allows for jobs created before the 7 day end_time filter. creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY) AND CURRENT_TIMESTAMP() AND job_type = 'QUERY' AND statement_type != 'SCRIPT' AND end_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP();
התוצאה אמורה להיראות כך:
+------------+ | avg_slots | +------------+ | 3879.1534 | +------------+
אפשר לבדוק את השימוש בנתונים ממקום שמור מסוים באמצעות WHERE reservation_id = "…". הנתון הזה יכול לעזור לכם לקבוע את אחוז השימוש בהזמנה לאורך זמן. במשימות של סקריפטים, המשימה הראשית מדווחת גם על השימוש הכולל ב-slots של המשימות המשניות שלה. כדי למנוע ספירה כפולה, צריך להשתמש ב-WHERE statement_type != "SCRIPT" כדי להחריג את המשימה הראשית.
אם רוצים לבדוק את ניצול ה-slots הממוצע למשימות ספציפיות, משתמשים ב-total_slot_ms / TIMESTAMP_DIFF(end_time, start_time, MILLISECOND).
ספירת שאילתות פעילות מהזמן האחרון לפי עדיפות השאילתה
בדוגמה הבאה מוצג מספר השאילתות שהתחילו ב-7 השעות האחרונות, מקובצות לפי עדיפות (אינטראקטיבית או באצ'):
SELECT priority, COUNT(*) active_jobs FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 hour) AND job_type = 'QUERY' GROUP BY priority;
התוצאה אמורה להיראות כך:
+-------------+-------------+ | priority | active_jobs | +-------------+-------------+ | INTERACTIVE | 2 | | BATCH | 3 | +-------------+-------------+
השדה priority מציין אם השאילתה היא INTERACTIVE או BATCH.
הצגת ההיסטוריה של משימות הטעינה
בדוגמה הבאה מוצגת רשימה של כל המשתמשים או חשבונות השירות ששלחו משימת טעינה באצווה לפרויקט נתון. לא צוין גבול זמן, ולכן השאילתה הזו סורקת את כל ההיסטוריה הזמינה.
SELECT user_email AS user, COUNT(*) num_jobs FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE job_type = 'LOAD' GROUP BY user_email;
התוצאה אמורה להיראות כך:
+--------------+ | user | +--------------+ | abc@xyz.com | | xyz@xyz.com | | bob@xyz.com | +--------------+
קבלת מספר משימות הטעינה כדי לקבוע את מכסת המשימות היומית שנוצלה
בדוגמה הבאה מוחזר מספר המשימות לפי יום, מערך נתונים וטבלה, כדי שתוכלו לקבוע כמה ממכסת המשימות היומית נוצלה.
SELECT DATE(creation_time) as day, destination_table.project_id as project_id, destination_table.dataset_id as dataset_id, destination_table.table_id as table_id, COUNT(job_id) AS load_job_count FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY) AND CURRENT_TIMESTAMP() AND job_type = "LOAD" GROUP BY day, project_id, dataset_id, table_id ORDER BY day DESC;
התוצאה אמורה להיראות כך:
+-------------+------------+-------------+----------+-----------------+ |day | project_id | dataset_id | table_id | load_job_count | +-------------+------------+-------------+----------+-----------------+ | 2020-10-10 | my_project | dataset1 | orders | 58 | | 2020-10-10 | my_project | dataset1 | product | 20 | | 2020-10-10 | my_project | dataset1 | sales | 11 | +-------------+------------+-------------+----------+-----------------+
Get the last few failed jobs (קבלת המשימות האחרונות שנכשלו)
בדוגמה הבאה מוצגות שלוש המשימות האחרונות שנכשלו:
SELECT job_id, creation_time, user_email, error_result FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE error_result.reason != "Null" ORDER BY creation_time DESC LIMIT 3;
התוצאות אמורות להיראות כך:
+------------+--------------------------+------------------+-------------------------------------+ | job_id | creation_time | user_email | error_result | +------------+--------------------------+------------------+-------------------------------------+ | bquxjob_1 | 2020-10-10 00:00:00 UTC | abc@example.com | Column 'col1' has mismatched type...| | bquxjob_2 | 2020-10-11 00:00:00 UTC | xyz@example.com | Column 'col1' has mismatched type...| | bquxjob_3 | 2020-10-11 00:00:00 UTC | bob@example.com | Column 'col1' has mismatched type...| +------------+--------------------------+------------------+-------------------------------------+
שליחת שאילתה על רשימת המשימות שפועלות במשך זמן רב
בדוגמה הבאה מוצגת רשימת המשימות ארוכות הטווח שנמצאות במצב RUNNING או PENDING במשך יותר מ-30 דקות:
SELECT job_id, job_type, state, creation_time, start_time, user_email FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE state!="DONE" AND creation_time <= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 MINUTE) ORDER BY creation_time ASC;
התוצאה אמורה להיראות כך:
+-----------+----------+---------+--------------------------------+--------------------------------+------------------+ | job_id | job_type | state | creation_time | start_time | user_email | +-----------+----------+---------+--------------------------------+--------------------------------+------------------+ | bquxjob_1 | QUERY | RUNNING | 2023-05-03 05:07:22.818000 UTC | 2023-05-03 05:07:22.905000 UTC | abc@example.com | | bquxjob_2 | QUERY | PENDING | 2023-05-01 02:05:47.925000 UTC | 2023-05-01 02:05:47.998000 UTC | xyz@example.com | | bquxjob_3 | QUERY | PENDING | 2023-05-01 02:05:47.925000 UTC | 2023-05-01 02:05:47.998000 UTC | abc@example.com | +-----------+----------+---------+--------------------------------+--------------------------------+------------------+
שאילתות שמשתמשות במצב יצירה אופציונלית של משימות
בדוגמה הבאה מוצגת רשימה של שאילתות שהופעלו במצב אופציונלי של יצירת משימות, ש-BigQuery לא יצר עבורן משימות.
SELECT job_id, FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE TIMESTAMP_TRUNC(creation_time, DAY) = '2024-06-12' AND job_creation_reason.code IS NULL LIMIT 3;
התוצאות אמורות להיראות כך:
+-----------+ | job_id | | +-----------+ | bquxjob_1 | | bquxjob_2 | | bquxjob_3 | +-----------+
בדוגמה הבאה מוצג מידע על שאילתה שהופעלה במצב יצירה אופציונלית של משימות, ש-BigQuery לא יצר עבורה משימה.
SELECT job_id, statement_type, priority, cache_hit, job_creation_reason.code AS job_creation_reason_code, total_bytes_billed, total_bytes_processed, total_slot_ms, state, error_result.message AS error_result_message, FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE TIMESTAMP_TRUNC(creation_time, DAY) = '2024-06-12' AND job_id = '2Lm09bHxDEsoVK8zwzWJomLHU_Ud%1910479b151' -- queryId
הערה: השדה job_id מכיל את ה-queryId של השאילתה כשלא נוצרה משימה בשביל השאילתה הזו.
התוצאות אמורות להיראות כך:
+-----------+----------------+-------------+-----------+--------------------------+--------------------+---------------------+---------------+-------+----------------------+ | job_id | statement_type | priority | cache_hit | job_creation_reason_code | total_bytes_billed | total_bytes_processed | total_slot_ms | state | error_result_message | +-----------+----------------+-------------+-----------+--------------------------+--------------------+---------------------+---------------+-------+----------------------+ | bquxjob_1 | SELECT | INTERACTIVE | false | null | 161480704 | 161164718 | 3106 | DONE | null | +-----------+----------------+-------------+-----------+--------------------------+--------------------+---------------------+---------------+-------+----------------------+
בדוגמה הבאה מוצגת רשימה של שאילתות שהופעלו במצב יצירה אופציונלית של משימות, שבהן BigQuery יצר משימות.
SELECT job_id, job_creation_reason.code AS job_creation_reason_code FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE TIMESTAMP_TRUNC(creation_time, DAY) = '2024-06-12' AND job_creation_reason.code IS NOT NULL AND job_creation_reason.code != 'REQUESTED' LIMIT 3
התוצאות אמורות להיראות כך:
+-----------+--------------------------+ | job_id | job_creation_reason_code | +-----------+--------------------------+ | bquxjob_1 | LARGE_RESULTS | | bquxjob_2 | LARGE_RESULTS | | bquxjob_3 | LARGE_RESULTS | +-----------+--------------------------+
בייטים שעובדו לכל זהות משתמש
בדוגמה הבאה מוצג סך הבייטים שחויבו עבור משימות שאילתה לכל משתמש:
SELECT user_email, SUM(total_bytes_billed) AS bytes_billed FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE job_type = 'QUERY' AND statement_type != 'SCRIPT' GROUP BY user_email;
הערה: כדאי לעיין בהסתייגות לגבי העמודה total_bytes_billed במסמכי הסכימה של התצוגות JOBS.
התוצאות אמורות להיראות כך:
+---------------------+--------------+ | user_email | bytes_billed | +---------------------+--------------+ | bob@example.com | 2847932416 | | alice@example.com | 1184890880 | | charles@example.com | 10485760 | +---------------------+--------------+
סיכום השימוש בגיליונות מקושרים לפי משתמש ברמת הפרויקט
אם אין לכם הרשאות ברמת הארגון או שאתם צריכים לעקוב רק אחרי פרויקט ספציפי, הריצו את השאילתה הבאה כדי לזהות את המשתמשים המובילים בגיליונות מקושרים בפרויקט ב-30 הימים האחרונים. השאילתה צוברת את המספר הכולל של השאילתות, סך הבייטים שחויבו וסך כל אלפיות השנייה של ה-slot לכל משתמש. המידע הזה עוזר להבין את השימוש במשאבים ולזהות את הצרכנים העיקריים שלהם.
SELECT
user_email,
COUNT(*) AS total_queries,
SUM(total_bytes_billed) AS total_bytes_billed,
SUM(total_slot_ms) AS total_slot_ms
FROM
-- This view queries the project you are currently running the query in.
`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
-- Filter for jobs created in the last 30 days
creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
-- Filter for jobs originating from Connected Sheets
AND job_id LIKE 'sheets_dataconnector%'
-- Filter for completed jobs
AND state = 'DONE'
AND (statement_type IS NULL OR statement_type <> 'SCRIPT')
GROUP BY
user_email
ORDER BY
total_bytes_billed DESC
LIMIT
10;
מחליפים את REGION_NAME באזור של הפרויקט.
לדוגמה, region-us.
התוצאה אמורה להיראות כך:
+---------------------+---------------+--------------------+-----------------+ | user_email | total_queries | total_bytes_billed | total_slot_ms | +---------------------+---------------+--------------------+-----------------+ | alice@example.com | 152 | 12000000000 | 3500000 | | bob@example.com | 45 | 8500000000 | 2100000 | | charles@example.com | 210 | 1100000000 | 1800000 | +---------------------+---------------+--------------------+-----------------+
איפה אפשר למצוא את יומני העבודות של שאילתות בגיליונות מקושרים ברמת הפרויקט
אם אין לכם הרשאות ברמת הארגון או שאתם צריכים לעקוב רק אחרי פרויקט ספציפי, הריצו את השאילתה הבאה כדי לראות יומן מפורט של כל השאילתות של גיליונות מקושרים בפרויקט הנוכחי:
SELECT
job_id,
creation_time,
user_email,
total_bytes_billed,
total_slot_ms,
query
FROM
-- This view queries the project you are currently running the query in.
`region-REGION_NAME.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE
creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
AND job_id LIKE 'sheets_dataconnector%'
AND state = 'DONE'
AND (statement_type IS NULL OR statement_type <> 'SCRIPT')
ORDER BY
creation_time DESC;
מחליפים את REGION_NAME באזור של הפרויקט.
לדוגמה, region-us.
התוצאה אמורה להיראות כך:
+---------------------------------+---------------------------------+------------------+--------------------+-----------------+---------------------------------+ | job_id | creation_time | user_email | total_bytes_billed | total_slot_ms | query | +---------------------------------+---------------------------------+------------------+--------------------+-----------------+---------------------------------+ | sheets_dataconnector_bquxjob_1 | 2025-11-06 00:26:53.077000 UTC | abc@example.com | 12000000000 | 3500000 | SELECT ... FROM dataset.table1 | | sheets_dataconnector_bquxjob_2 | 2025-11-06 00:24:04.294000 UTC | xyz@example.com | 8500000000 | 2100000 | SELECT ... FROM dataset.table2 | | sheets_dataconnector_bquxjob_3 | 2025-11-03 23:17:25.975000 UTC | bob@example.com | 1100000000 | 1800000 | SELECT ... FROM dataset.table3 | +---------------------------------+---------------------------------+------------------+--------------------+-----------------+---------------------------------+
פירוט לפי שעה של הבייטים שעובדו
בדוגמה הבאה מוצג סך הבייטים שחויבו עבור משימות שאילתה, במרווחים של שעה:
SELECT TIMESTAMP_TRUNC(end_time, HOUR) AS time_window, SUM(total_bytes_billed) AS bytes_billed FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE job_type = 'QUERY' AND statement_type != 'SCRIPT' GROUP BY time_window ORDER BY time_window DESC;
התוצאה אמורה להיראות כך:
+-------------------------+--------------+ | time_window | bytes_billed | +-------------------------+--------------+ | 2022-05-17 20:00:00 UTC | 1967128576 | | 2022-05-10 21:00:00 UTC | 0 | | 2022-04-15 17:00:00 UTC | 41943040 | +-------------------------+--------------+
משימות של שאילתות לכל טבלה
בדוגמה הבאה אפשר לראות כמה פעמים כל טבלה שנשלחה אליה שאילתה ב-my_project אוזכרה על ידי משימת שאילתה:
SELECT t.project_id, t.dataset_id, t.table_id, COUNT(*) AS num_references FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS, UNNEST(referenced_tables) AS t GROUP BY t.project_id, t.dataset_id, t.table_id ORDER BY num_references DESC;
התוצאה אמורה להיראות כך:
+------------+------------+----------+----------------+ | project_id | dataset_id | table_id | num_references | +------------+------------+----------+----------------+ | my_project | dataset1 | orders | 58 | | my_project | dataset1 | products | 40 | | other_proj | dataset1 | accounts | 12 | +------------+------------+----------+----------------+
מספר המשימות של שאילתות SQL מדור קודם לכל פרויקט
השדה query_dialect ב-INFORMATION_SCHEMA זמין ממאי 2025. בדוגמה הבאה אפשר לראות כמה משימות של שאילתות SQL מדור קודם מבוצעות על ידי פרויקטים.
SELECT project_id, -- Implicitly defaulted to LegacySQL since the query dialect was not specified -- in the request. COUNTIF(query_dialect = 'DEFAULT_LEGACY_SQL') AS default_legacysql_query_jobs, -- Explicitly requested LegacySQL. COUNTIF(query_dialect = 'LEGACY_SQL') AS legacysql_query_jobs, FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE query_dialect = 'DEFAULT_LEGACY_SQL' OR query_dialect = 'LEGACY_SQL' GROUP BY project_id ORDER BY default_legacysql_query_jobs DESC, legacysql_query_jobs DESC;
מספר המחיצות ששונו על ידי שאילתות ומשימות טעינה לכל טבלה
בדוגמה הבאה מוצג מספר המחיצות ששונו על ידי שאילתות עם פקודות DML ומשימות טעינה, לכל טבלה. שימו לב שהשאילתה הזו לא מציגה את total_modified_partitions למשימות העתקה.
SELECT destination_table.table_id, SUM(total_modified_partitions) AS total_modified_partitions FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE DATE(creation_time, "America/Los_Angeles") = CURRENT_DATE() GROUP BY table_id ORDER BY total_modified_partitions DESC
מספר ממוצע של משבצות לאלפית שנייה שבהן נעשה שימוש במשימה
בדוגמה הבאה מוסבר איך לחשב את המספר הממוצע של משבצות שבהן נעשה שימוש במשימה במהלך הביצוע. האפשרות הזו יכולה לעזור לכם לפתור בעיות שקשורות לשאילתות איטיות ולהשוות בין ביצוע איטי של שאילתה לבין ביצוע מהיר של אותה שאילתה. השוואה בין הערך הזה לבין הגודל הכולל של ההזמנה והמספר הממוצע של משימות בו-זמניות שבוצעו בפרויקט או בהזמנה, יכולה לעזור לכם להבין אם כמה שאילתות התחרו על משבצות באותו זמן במהלך הביצוע.
מספר גבוה יותר של משבצות בממוצע מצביע על הקצאה של יותר משאבים לעבודה, ובדרך כלל מוביל לביצוע מהיר יותר.
SELECT ROUND(SAFE_DIVIDE(total_slot_ms,TIMESTAMP_DIFF(end_time, start_time, MILLISECOND)), 1) as avg_slots_per_ms FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE job_id = 'JOB_ID'
מחליפים את JOB_ID ב-job_id שאתם בודקים.
התוצאה תהיה דומה לזו:
+------------------+ | avg_slots_per_ms | +------------------+ | 17.0 | +------------------+
השאילתות הכי יקרות לפי פרויקט
בדוגמה הבאה מפורטות השאילתות הכי יקרות ב-my_project לפי זמן השימוש במשבצת:
SELECT job_id, query, user_email, total_slot_ms FROM `my_project`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE EXTRACT(DATE FROM creation_time) = current_date() ORDER BY total_slot_ms DESC LIMIT 3
אפשר גם לראות את השאילתות הכי יקרות לפי עיבוד הנתונים, כמו בדוגמה הבאה:
SELECT job_id, query, user_email, total_bytes_processed FROM `my_project`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE EXTRACT(DATE FROM creation_time) = current_date() ORDER BY total_bytes_processed DESC LIMIT 3
התוצאה של כל אחת מהדוגמאות דומה לתוצאה הבאה:
+-----------+---------------------------------+-----------------------+---------------+ | job_id | query | user_email | total_slot_ms | +-----------+---------------------------------+-----------------------+---------------+ | bquxjob_1 | SELECT ... FROM dataset.table1 | bob@example.com | 80,000 | | bquxjob_2 | SELECT ... FROM dataset.table2 | alice@example.com | 78,000 | | bquxjob_3 | SELECT ... FROM dataset.table3 | charles@example.com | 75,000 | +-----------+---------------------------------+-----------------------+---------------+
איך רואים פרטים על אזהרה לגבי משאב
אם מופיעה הודעת השגיאה Resources exceeded (חרגת ממכסת המשאבים), אפשר לשלוח שאילתה לגבי השאילתות בחלון זמן:
SELECT query, query_info.resource_warning FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time BETWEEN TIMESTAMP("2022-12-01") AND TIMESTAMP("2022-12-08") AND query_info.resource_warning IS NOT NULL LIMIT 3;
מעקב אחרי אזהרות לגבי משאבים מקובצות לפי תאריך
אם מופיעה הודעת השגיאה Resources exceeded, אפשר לעקוב אחרי המספר הכולל של אזהרות לגבי משאבים שמקובצות לפי תאריך, כדי לדעת אם יש שינויים בעומס העבודה:
WITH resource_warnings AS ( SELECT EXTRACT(DATE FROM creation_time) AS creation_date FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 14 DAY) AND query_info.resource_warning IS NOT NULL ) SELECT creation_date, COUNT(1) AS warning_counts FROM resource_warnings GROUP BY creation_date ORDER BY creation_date DESC;
הערכת השימוש ב-slots והעלות של שאילתות
בדוגמה הבאה מחושב המספר הממוצע והמספר המקסימלי של יחידות ה-slot לכל משימה באמצעות estimated_runnable_units.
אם אין לכם הזמנות, הערך של reservation_id הוא NULL.
SELECT project_id, job_id, reservation_id, EXTRACT(DATE FROM creation_time) AS creation_date, TIMESTAMP_DIFF(end_time, start_time, SECOND) AS job_duration_seconds, job_type, user_email, total_bytes_billed, -- Average slot utilization per job is calculated by dividing total_slot_ms by the millisecond duration of the job SAFE_DIVIDE(job.total_slot_ms,(TIMESTAMP_DIFF(job.end_time, job.start_time, MILLISECOND))) AS job_avg_slots, query, -- Determine the max number of slots used at ANY stage in the query. -- The average slots might be 55. But a single stage might spike to 2000 slots. -- This is important to know when estimating number of slots to purchase. MAX(SAFE_DIVIDE(unnest_job_stages.slot_ms,unnest_job_stages.end_ms - unnest_job_stages.start_ms)) AS jobstage_max_slots, -- Check if there's a job that requests more units of works (slots). If so you need more slots. -- estimated_runnable_units = Units of work that can be scheduled immediately. -- Providing additional slots for these units of work accelerates the query, -- if no other query in the reservation needs additional slots. MAX(unnest_timeline.estimated_runnable_units) AS estimated_runnable_units FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS AS job CROSS JOIN UNNEST(job_stages) as unnest_job_stages CROSS JOIN UNNEST(timeline) AS unnest_timeline WHERE DATE(creation_time) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) AND CURRENT_DATE() AND project_id = 'my_project' AND (statement_type != 'SCRIPT' OR statement_type IS NULL) GROUP BY 1,2,3,4,5,6,7,8,9,10 ORDER BY job_id;
התוצאה לדוגמה דומה לתוצאה הבאה:
+-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+ |project_id | job_id | reservation_id | creation_date | job_duration_seconds | job_type | user_email | total_bytes_billed | job_avg_slots| query | jobstage_max_slots | estimated_runnable_units | +-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+ | project1 | bquxjob1 | reservation1 | 2020-10-10 | 160 | LOAD | abc@example.com | 161480704 | 2890 | SELECT ... FROM dataset.table1 | 2779.1534 | 1000 | | project1 | bquxjob2 | reservation2 | 2020-12-10 | 120 | LOAD | abc@example.com | 161480704 | 2890 | SELECT ... FROM dataset.table1 | 2779.1534 | 1000 | | project1 | bquxjob3 | reservation1 | 2020-12-10 | 120 | LOAD | abc@example.com | 161480704 | 2890 | SELECT ... FROM dataset.table1 | 1279.1534 | 998 | +-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+
הצגת תובנות לגבי הביצועים של שאילתות
בדוגמה הבאה מוחזרות כל משימות השאילתה שיש להן תובנות לגבי הביצועים מהפרויקט שלכם ב-30 הימים האחרונים, יחד עם כתובת URL שמקשרת לתרשים של ביצוע השאילתה במסוף Cloud de Confiance .
SELECT `bigquery-public-data`.persistent_udfs.job_url( project_id || ':us.' || job_id) AS job_url, query_info.performance_insights FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE DATE(creation_time) >= CURRENT_DATE - 30 -- scan 30 days of query history AND job_type = 'QUERY' AND state = 'DONE' AND error_result IS NULL AND statement_type != 'SCRIPT' AND EXISTS ( -- Only include queries which had performance insights SELECT 1 FROM UNNEST( query_info.performance_insights.stage_performance_standalone_insights ) WHERE slot_contention OR insufficient_shuffle_quota OR bi_engine_reasons IS NOT NULL OR high_cardinality_joins IS NOT NULL OR partition_skew IS NOT NULL UNION ALL SELECT 1 FROM UNNEST( query_info.performance_insights.stage_performance_change_insights ) WHERE input_data_change.records_read_diff_percentage IS NOT NULL );
הצגת משימות לרענון מטא-נתונים
בדוגמה הבאה מפורטות משימות הרענון של המטא-נתונים בשש השעות האחרונות:
SELECT * FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE job_id LIKE '%metadata_cache_refresh%' AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR) ORDER BY start_time desc LIMIT 10;
מחליפים את REGION_NAME באזור שלכם.
ניתוח הביצועים לאורך זמן של שאילתות זהות
בדוגמה הבאה מוצגות 10 המשימות האיטיות ביותר ב-7 הימים האחרונים, שהריצו את אותה שאילתה:
DECLARE querytext STRING DEFAULT( SELECT query FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE job_id = 'JOB_ID' LIMIT 1 ); SELECT start_time, end_time, project_id, job_id, TIMESTAMP_DIFF(end_time, start_time, SECOND) AS run_secs, total_bytes_processed / POW(1024, 3) AS total_gigabytes_processed, query FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE query = querytext AND total_bytes_processed > 0 AND creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) ORDER BY 5 DESC LIMIT 3;
מחליפים את JOB_ID בכל job_id שהריץ את השאילתה שאתם מנתחים.
הצגת משרות עם תובנות לגבי התחרות על משבצות זמן
כדי לראות את העבודות עם התובנות לגבי התחרות על משבצות, מריצים את השאילתה הבאה:
SELECT job_id, creation_time, query_info.performance_insights, FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS j, UNNEST(query_info.performance_insights.stage_performance_standalone_insights) i WHERE (j.statement_type != "SCRIPT" OR j.statement_type IS NULL) AND i IS NOT NULL AND i.slot_contention
בפלט מוצגות תובנות שונות לגבי הביצועים של משימות, כולל התחרות על משבצות:
+------------+-------------------------+-------------------------------------------------+----------------------------------------------------------------------------+ | job_id | creation_time | performance_insights.avg_previous_execution_ms | performance_insightsstage_performance_standalone_insights.slot_contention | +------------+-------------------------+-------------------------------------------------+----------------------------------------------------------------------------+ | bquxjob_1 | 2025-08-08 00:00:00 UTC | null | true | | bquxjob_2 | 2025-08-08 00:00:00 UTC | 42689 | true | | bquxjob_3 | 2025-08-08 00:00:00 UTC | 42896 | true | +------------+-------------------------+-------------------------------------------------+----------------------------------------------------------------------------+
קבלת משימות עם אותו גיבוב (hash) של שאילתה
השאילתה הבאה מחזירה את מזהי המשימות עם אותו גיבוב של שאילתה כמו של משימה ספציפית:
SELECT j.job_id, j.creation_time, j.query FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS j WHERE j.job_id != "JOB_IDENTIFIER" AND j.query_info.query_hashes.normalized_literals = ( SELECT sub.query_info.query_hashes.normalized_literals FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS sub WHERE sub.job_id = "JOB_IDENTIFIER" LIMIT 1 ) ORDER BY j.creation_time DESC;
התוצאה אמורה להיראות כך:
+--------------+---------------------------+------------------------------------------------+ | job_id | creation_time | query | +--------------+---------------------------+------------------------------------------------+ | bquxjob_1 | 2019-10-10 00:00:00 UTC | SELECT ... FROM dataset.table1 WHERE x = "a" | | bquxjob_2 | 2019-10-10 00:00:01 UTC | SELECT ... FROM dataset.table1 WHERE x = "b" | | bquxjob_3 | 2019-10-10 00:00:02 UTC | SELECT ... FROM dataset.table1 WHERE x = "c" | +--------------+---------------------------+------------------------------------------------+
הצגת המספר הממוצע של משימות שרצות במקביל למשימה מסוימת באותו פרויקט
בדוגמה הבאה מוסבר איך לחשב את המספר הממוצע של משימות שפועלות במקביל למשימת שאילתה ספציפית באותו פרויקט.
החישוב הזה עוזר לקבוע אם מספר גדול יותר של משימות בו-זמניות באותו פרויקט גרם לבעיות של תחרות על משבצות. כדאי לאסוף את הנתונים האלה כשפותרים בעיות של שאילתות איטיות או כשמשווים בין הרצות של שאילתות איטיות ומהירות.
אם יש הרבה יותר שאילתות מקבילות שפועלות מהצפוי, בודקים אם התחילו יותר משימות, אם נתוני השאילתה השתנו או אם שני הדברים קרו.
WITH job_metadata AS ( SELECT creation_time, end_time, job_type FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE job_id = 'JOB_ID' -- If you know the date the job was created, add the following line to speed up the query by providing the date in UTC: -- AND DATE(creation_time) = 'YYYY-MM-DD' ), intervals AS ( SELECT TIMESTAMP_ADD(creation_time, INTERVAL (seconds_offset) SECOND) AS ts, job_type FROM job_metadata, UNNEST (GENERATE_ARRAY(0, IF(TIMESTAMP_DIFF(end_time, creation_time, SECOND) > 0, TIMESTAMP_DIFF(end_time, creation_time, SECOND), 1))) as seconds_offset ), concurrent_jobs AS ( SELECT int.ts, COUNT(*) as concurrent_jobs_count FROM intervals int JOIN `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT j ON int.ts BETWEEN j.creation_time and j.end_time WHERE job_id != 'JOB_ID' AND j.job_type = int.job_type GROUP BY int.ts) SELECT ROUND(AVG(concurrent_jobs_count),1) as average_concurrent_jobs FROM concurrent_jobs
מחליפים את מה שכתוב בשדות הבאים:
JOB_ID: מזהה משימה של השאילתה שאתם מנתחים
REGION_NAME: האזור של הפרויקט
התוצאה אמורה להיראות כך:
+-------------------------+ | average_concurrent_jobs | +-------------------------+ | 2.8 | +-------------------------+
קבלת בייטים שעובדו על ידי משימות חילוץ
בדוגמה הבאה מחושב הערך של total_bytes_processed עבור EXTRACT סוגי עבודות. מידע על מכסות של עבודות חילוץ זמין במאמר בנושא מדיניות המכסות לעבודות חילוץ.
אפשר להשתמש בסך הבייטים שעובדו כדי לעקוב אחרי השימוש המצטבר, ולוודא שמשימות החילוץ לא חורגות מהמגבלה של 50TiB ליום:
SELECT DATE(creation_time) as day, project_id as source_project_id, SUM(total_bytes_processed) AS total_bytes_processed FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY) AND CURRENT_TIMESTAMP() AND job_type = "EXTRACT" GROUP BY day, source_project_id ORDER BY day DESC;
קבלת נתוני שימוש של משימות העתקה
מידע על העתקת משימות מופיע במאמר העתקת טבלה. בדוגמה הבאה מוסבר איך להשתמש במשימות העתקה:
SELECT DATE(creation_time) as day, project_id as source_project_id, CONCAT(destination_table.project_id,":",destination_table.dataset_id,".",destination_table.table_id) as destination_table, COUNT(job_id) AS copy_job_count FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY) AND CURRENT_TIMESTAMP() AND job_type = "COPY" GROUP BY day, source_project_id, destination_table ORDER BY day DESC;
איך בודקים את השימוש באופטימיזציה של האחסון בטבלאות מנוהלות של Apache Iceberg
בדוגמה הבאה מוצג השימוש באופטימיזציה של אחסון בטבלה מנוהלת של Iceberg.
SELECT job_id, reservation_id, edition, total_slot_ms, total_bytes_processed, state FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR) AND user_email = "bigquery-adminbot@system.s3ns-system.iam.gserviceaccount.com" AND query LIKE "CALL BQ.OPTIMIZE_STORAGE(%)";
קבלת נתוני השימוש במטא-נתונים של טבלת הייצוא של טבלה מנוהלת ב-Iceberg
בדוגמה הבאה מוצג השימוש ב-Iceberg EXPORT TABLE METADATA FROM.
SELECT job_id, user_email, start_time, end_time, TIMESTAMP_DIFF(end_time, start_time, SECOND) AS duration_seconds, total_bytes_processed, reservation_id, CASE WHEN reservation_id IS NULL THEN 'PAYG (On-demand)' WHEN reservation_id != '' THEN 'Reservation' ELSE 'Unknown' END AS compute_type, query FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE job_type = 'QUERY' AND end_time IS NOT NULL -- Filter for queries containing the specified pattern (case-insensitive) AND REGEXP_CONTAINS(LOWER(query), r"export table metadata from") ORDER BY start_time DESC LIMIT 3;
התאמת התנהגות השימוש במשבצות מתוך תרשימי משאבים אדמיניסטרטיביים
כדי לבדוק את אופן השימוש במשבצות, בדומה למידע שמוצג בתרשימי המשאבים של האדמין, אפשר לשלוח שאילתה לתצוגה INFORMATION_SCHEMA.JOBS_TIMELINE.