פתרון בעיות בהגדרות ההעברה

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

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

בדיקת השגיאות

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

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

resource.type="bigquery_dts_config"
labels.run_id="RUN_ID"
resource.labels.config_id="CONFIG_ID"

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

• ‫RUN_ID: מספר המזהה של הרצת משימה ספציפית
• ‫CONFIG_ID: מספר המזהה של משימת הגדרת ההעברה

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

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

בעיות כלליות

כשמנסים לאבחן בעיות כלליות בהעברה, כדאי לבדוק את הדברים הבאים:

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

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

שגיאה: An unexpected issue was encountered. If this issue persists, please contact customer support.

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

שגיאה: INTERNAL: An internal error occurred and the request could not be completed. This is usually caused by a transient issue...

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

שגיאה: Quota Exceeded.

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

אם אתם טוענים ייצוא של נתוני חיוב ב-Cloud ל-BigQuery, יכול להיות שתופיע השגיאה Quota Exceeded. גם טבלאות הייצוא של החיוב ב-Cloud וגם טבלאות היעד ב-BigQuery שנוצרו על ידי שירות העברת הנתונים ל-BigQuery מחולקות למחיצות. אם בוחרים באפשרות overwrite כשמגדירים משימות כאלה של שירות העברת הנתונים ל-BigQuery, יכולות להופיע שגיאות מכסה בהתאם לכמות הנתונים שמיוצאים. איך פותרים בעיות שקשורות למכסות ולמגבלות?

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

שגיאה: The caller does not have permission.

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

• החשבון שמחובר למסוף Cloud de Confiance :

  

• צריך לבחור חשבון כדי להמשיך לשירות העברת הנתונים ל-BigQuery:

  

שגיאה: Access Denied: ... Permission bigquery.tables.get denied on table ...

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

שגיאה: region violates constraint constraints/gcp.resourceLocations on the resource projects/project_id

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

שגיאה: Please look into the errors[] collection for more details.

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

שגיאה: Network Attachment with connected endpoints cannot be deleted.

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

שגיאה: Error while reading data, error message: CSV processing encountered too many errors, giving up.

פתרון: השגיאה הזו יכולה להתרחש כשיש חוסר התאמה בין הגדרת קובץ ה-CSV במקור הנתונים לבין הגדרת קובץ ה-CSV בהגדרות ההעברה. לדוגמה, השגיאה הזו יכולה לקרות אם הערך של Header rows to skip מוגדר ל-0, אבל קובץ ה-CSV של המקור מכיל שורת כותרת אחת או יותר. כדי לתקן את השגיאה הזו, צריך לוודא שהגדרות ה-CSV בהגדרות ההעברה נכונות ותואמות להגדרות של קובץ ה-CSV במקור.

שגיאה: Error 400: DTS service agent needs iam.serviceAccounts.getAccessToken permission or [SERVICE_ACCOUNT] doesn't exist.

הסיבה: השגיאה הזו מציינת שלסוכן השירות של שירות העברת הנתונים ל-BigQuery‏ (DTS) אין את ההרשאה הנדרשת כדי להתחזות לחשבון השירות שמשמש להעברה. בדרך כלל זה קורה בתרחישים של הרשאה בין פרויקטים, או כשההעברה מוגדרת באמצעות כלים של תשתית כקוד (IaC) כמו Terraform.

פתרון: מקצים את התפקיד "יצירת אסימונים בחשבון שירות" (roles/iam.serviceAccountTokenCreator) לסוכן השירות של DTS בחשבון השירות הספציפי שאליו הוא צריך להתחזות.

gcloud iam service-accounts add-iam-policy-binding service_account \
--member serviceAccount:service-destination_project_number@gcp-sa-bigquerydatatransfer.s3ns-system.iam.gserviceaccount.com \
--role roles/iam.serviceAccountTokenCreator

כאשר:

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

שגיאה: For asset "ASSET", no eligible column found for splitting (Reason: Primary or Indexed Key columns found, but none are of supported types (INTEGER, TINYINT, SMALLINT, FLOAT, REAL, DOUBLE, NUMERIC, BIGINT, DECIMAL, DATE, BOOLEAN))

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

שגיאה: Permission bigquery.tables.create denied.

התסמין:

Error code 7 : Access Denied : Dataset [PROJECT_ID]:[DATASET_ID] : Permission bigquery.tables.create denied on dataset [PROJECT_ID]:[DATASET_ID] (or it may not exist).

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

הסיבה: השגיאה הזו מתרחשת כשהרצת ההעברה ב-Cloud Storage כוללת יותר מ-10,000 קבצים, ולא ניתנה ההרשאה bigquery.tables.create. כשההעברות חורגות מ-10,000 קבצים, השירות מפצל את הנתונים לטבלאות זמניות שנוצרות באופן דינמי. כדי לעשות את זה, צריך את ההרשאה bigquery.tables.create, גם אם הפרויקט רשום להעברות בנפח גבוה (או אם אושרה לו הגדלת מכסה).

פתרון: כדי להעביר יותר מ-10,000 קבצים, צריך לוודא ששתי הדרישות הבאות מתקיימות:

1. אימות המכסה וההרשמה לתכונה: ודאו שהפרויקט שלכם רשום להעברות בנפח גבוה ב-Cloud Storage (יותר מ-10,000 קבצים). אם אתם צריכים להעביר יותר מ-10,000 קבצים, פנו לתמיכה כדי לבקש להגדיל את המכסה של מספר הקבצים המקסימלי לכל הפעלת העברה.

2. נותנים את ההרשאות הנדרשות ב-IAM: נותנים לחשבון השירות או לזהות המשתמש שמפעילים את ההעברה את ההרשאה bigquery.tables.create בקבוצת הנתונים של היעד. ההרשאה הזו כלולה בתפקידים BigQuery Data Editor (roles/bigquery.dataEditor) ו-BigQuery Admin (roles/bigquery.admin). אם אתם ממשיכים לראות שגיאות אחרי שהענקתם את ההרשאות הנדרשות, יכול להיות שתצטרכו לפנות לתמיכה כדי לאשר את סטטוס רשימת ההיתרים שלכם.

   חלופות: אם אתם לא יכולים להעניק את ההרשאות הנדרשות או להמתין להגדלת המכסה ולשינוי ההגדרות, אתם יכולים:

   • צמצמו את מספר הקבצים בכל הפעלת העברה ל-10,000 או פחות. לדוגמה, השתמשו בתווים כלליים ספציפיים יותר של URI או פצלו את ההעברה לכמה הגדרות קטנות יותר.
   • להעברות חד-פעמיות או לטעינות דחופות, השתמשו במשימת טעינה של BigQuery או בהצהרת LOAD DATA. שתי האפשרויות האלה תומכות במספר מקסימלי גבוה יותר של קבצים לכל משימת טעינה.

בעיות שקשורות להרשאות

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

שגיאה: BigQuery Data Transfer Service is not enabled for <project_id>

שגיאה: BigQuery Data Transfer Service has not been used in project <project_id> before or it is disabled ...

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

1. במסוף Cloud de Confiance , נכנסים לדף IAM & Admin.

   כניסה לדף IAM & Admin

2. מסמנים את התיבה Include S3NS-provided role grants.

3. מוודאים שחשבון השירות בשם service-<project_number>@gcp-sa-bigquerydatatransfer.s3ns-system.iam.gserviceaccount.com מופיע, או שניתן לו התפקיד BigQuery Data Transfer Service Agent בשירות העברת הנתונים ל-BigQuery.

   

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

gcloud projects add-iam-policy-binding PROJECT_NUMBER \
--member serviceAccount:service-PROJECT_NUMBER@gcp-sa-bigquerydatatransfer.s3ns-system.iam.gserviceaccount.com \
--role roles/bigquerydatatransfer.serviceAgent

מחליפים את PROJECT_NUMBER במספר הפרויקט שמשויך לחשבון השירות הזה.

שגיאה: There was an error loading this table. Check that the table exists and that you have the correct permissions.

פתרון:

1. נכנסים לדף BigQuery במסוף Cloud de Confiance .

   כניסה ל-BigQuery

2. לוחצים על מערך הנתונים של היעד שמשמש להעברה.

3. לוחצים על התפריט שיתוף ואז על הרשאות.

4. מרחיבים את התפקיד BigQuery Data Editor.

5. מוודאים שסוכן השירות של שירות העברת הנתונים ל-BigQuery נוסף לתפקיד הזה. אם לא, מקצים את התפקיד "עריכת נתונים ב-BigQuery" (roles/bigquery.dataEditor) לסוכן השירות של שירות העברת הנתונים ל-BigQuery.

שגיאה: A permission denied error was encountered: PERMISSION_DENIED. Please ensure that the user account setting up the transfer config has the necessary permissions, and that the configuration settings are correct

פתרון:

1. נכנסים לדף העברת נתונים במסוף Cloud de Confiance .

   מעבר אל "העברות נתונים"

2. לוחצים על ההעברה שנכשלה ואז על הכרטיסייה Configuration.

3. מוודאים שלבעלי ההעברה שרשומים בשדה User יש את כל ההרשאות הנדרשות למקור הנתונים.

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

שגיאה: Authentication failure: User Id not found. Error code: INVALID_USERID

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

שגיאה: The user does not have permission

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

• הפעלה של צירוף חשבונות שירות בין פרויקטים
• הרשאה לחשבון שירות בפרויקטים שונים (כדי לתת את ההרשאות הנדרשות)

שגיאה: HttpError 403 when requesting returned "The caller does not have permission"

googleapiclient.errors.HttpError: <HttpError 403 when requesting returned "The caller does not have permission". Details: "The caller does not have permission">

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

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

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

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

1. מזהים את חשבונות השירות שמשויכים לפרויקט באמצעות מסוף Cloud de Confiance , על ידי מעבר אל IAM & Admin > Service Accounts. בתצוגה הזו מופיעים כל חשבונות השירות של הפרויקט הנוכחי.
2. כדי להשבית את המדיניות בפרויקט שבו נמצאים חשבונות השירות, מריצים את הפקודה הבאה: כדי להשבית את המדיניות הזו, המשתמש צריך להיות אדמין של מדיניות הארגון. רק אדמין ארגוני יכול להקצות למשתמש את התפקיד הזה.

gcloud resource-manager org-policies disable-enforce iam.disableCrossProjectServiceAccountUsage --project=[PROJECT-ID]

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

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

שגיאה: Data Transfer Service is not authorized to pull message from the provided Pub/Sub subscription.

פתרון: מוודאים שלסוכן השירות של שירות העברת הנתונים ל-BigQuery הוקצה התפקיד pubsub.subscriber:

1. נכנסים לדף Pub/Sub במסוף Cloud de Confiance .

   כניסה ל-Pub/Sub

2. בוחרים את המינוי ל-Pub/Sub שבו השתמשתם בהעברה מבוססת-האירועים.

3. אם חלונית המידע מוסתרת, לוחצים על Show info panel בפינה הימנית העליונה.

4. בכרטיסייה Permissions, מוודאים שלסוכן השירות של שירות העברת הנתונים ל-BigQuery יש את התפקיד pubsub.subscriber.

אם לסוכן השירות לא הוקצה התפקיד pubsub.subscriber. לוחצים על person_add Add principal כדי לתת את התפקיד pubsub.subscriber ל-service-PROJECT_NUMBER@gcp-sa-bigquerydatatransfer.s3ns-system.iam.gserviceaccount.com.

שגיאה: Cloud Pub/Sub API has not been used in project PROJECT_NUMBER before or it is disabled.

פתרון: מוודאים ש-Cloud Pub/Sub API מופעל בפרויקט:

1. במסוף Cloud de Confiance , נכנסים לדף APIs & Services.

   כניסה אל APIs & Services

2. לוחצים על Enable APIs and services.

3. מחפשים את Cloud Pub/Sub API, בוחרים בתוצאה הראשונה ולוחצים על הפעלה.

שגיאה: Data Transfer Service does not have required permission to use project quota of project PROJECT_NUMBER to access Pub/Sub.

פתרון: מוודאים שלסוכן השירות של שירות העברת הנתונים ל-BigQuery הוקצה התפקיד serviceusage.serviceUsageConsumer:

1. במסוף Cloud de Confiance , נכנסים לדף IAM & Admin.

   כניסה לדף IAM & Admin

2. מסמנים את התיבה Include S3NS-provided role grants.

3. מוודאים שחשבון השירות עם השם service-<project_number>@gcp-sa-bigquerydatatransfer.s3ns-system.iam.gserviceaccount.com מוצג ושהוקצה לו התפקיד Service Usage Consumer.

   

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

הפעלות של העברות לא מופעלות מיד אחרי שמתקבל אירוע. יכול להיות שיחלפו כמה דקות עד שהרצת ההעברה תופעל. כדי לבדוק את הסטטוס של הפעלת ההעברה הבאה, אפשר לבדוק את השדה Target date for next run בהיסטוריית ההפעלות. בשדה הזה מוצג מועד ההפעלה הבא, או שמוצג הכיתוב waiting for events to schedule next run אם לא התקבלו אירועים. אם העליתם או עדכנתם קבצים בקטגוריה של Cloud Storage, אבל הערך של Target date for next run לא התעדכן ולא הופעלו הרצות במשך 10-20 דקות, נסו את הפתרון הבא.

פתרון: מוודאים שהמינוי ל-Pub/Sub שצוין בהגדרות ההעברה יכול לקבל הודעות שפורסמו מאירועים ב-Cloud Storage:

1. נכנסים לדף Pub/Sub במסוף Cloud de Confiance .

   כניסה ל-Pub/Sub

2. בוחרים את המינוי ל-Pub/Sub שבו השתמשתם בהעברה מבוססת-האירועים.

3. בכרטיסייה Metrics, בודקים את התרשים "Oldest unacked message age" כדי לראות אם יש הודעות.

אם לא מתפרסמות הודעות, צריך לבדוק אם התראות Pub/Sub מוגדרות כמו שצריך ב-Cloud Storage. כדי לבדוק את הגדרות ההתראות שמשויכות לקטגוריה, אפשר להשתמש בפקודה הבאה של Google Cloud CLI:

gcloud storage buckets notifications list gs://BUCKET_NAME

מחליפים את BUCKET_NAME בשם הקטגוריה שמשמשת להתראות. במאמר הגדרת התראות Pub/Sub ל-Cloud Storage מוסבר איך מגדירים התראות Pub/Sub ל-Cloud Storage.

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

בעיות במכסות

שגיאה: Quota exceeded: Your project exceeded quota for imports per project.

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

שגיאה: RESOURCE_EXHAUSTED: Rate limit exceeded. (או שגיאות דומות של הגבלת קצב של יצירת בקשות כשמעבירים נתונים מאפליקציות של צד שלישי כמו ServiceNow,‏ Facebook Ads,‏ Confluence או PayPal)

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

• אימות מקור השגיאה: בודקים את יומני ההרצה של ההעברה. אם הודעת השגיאה מתייחסת למחבר החיצוני או למקור הנתונים של הצד השלישי, הגבלת הקצב נאכפה על ידי הפלטפורמה החיצונית.
• בודקים את הגבלת קצב של יצירת בקשות של ה-API בפלטפורמה של הצד השלישי: נכנסים לפלטפורמה החיצונית כדי לבדוק את השימוש ב-API ואת הגבלת קצב של יצירת בקשות (לדוגמה, שדרוג אפליקציית פייסבוק Ads ל-Advanced Access או בדיקת הגבלת קצב של יצירת בקשות של ה-API בארכיטקטורת REST הנכנס ב-ServiceNow), ומוודאים שאין תהליכי עבודה מקבילים שמשתמשים באותם פרטי כניסה.
• להפחית את תדירות ההעברות או לפרוס את לוחות הזמנים: משנים את לוח הזמנים של הגדרות ההעברה כך שההעברות יפעלו בתדירות נמוכה יותר, ונמנעים מהפעלת העברות מקבילות לאותו חשבון חיצוני בו-זמנית.