排查 BigQuery 配额错误

BigQuery 设有各种配额，用于限制传入请求的速率和数量。这些配额可搭配使用以保护后端系统，并在您提交大型作业时帮助防止意料之外的计费。本文档介绍了如何诊断和减少由配额导致的特定错误。

如果本文档中未列出您的错误消息，请参阅错误消息，其中提供了更通用的错误信息。

概览

如果 BigQuery 操作因配额限制而失败，API 会返回 HTTP 403 Forbidden 状态代码。响应正文会详细说明已达到的限制。响应正文类似于以下内容：

{
  "code" : 403,
  "errors" : [ {
    "domain" : "global",
    "message" : "Quota exceeded: ...",
    "reason" : "quotaExceeded"
  } ],
  "message" : "Quota exceeded: ..."
}

载荷中的 message 字段会说明超出了哪个限制。例如，message 字段可能会显示 Exceeded rate limits: too many table update operations for this table。

一般来说，配额限制分为两类，由响应载荷中的 reason 字段指示。

• rateLimitExceeded。该值表示短期限制。如需解决这些限制问题，请在几秒后重试执行此操作。在两次重试尝试之间使用指数退避算法。也就是说，以指数方式增加每次重试之间的延迟时间。

• quotaExceeded。该值表示长期限制。如果您达到了长期配额上限，则应等待 10 分钟或更长时间，然后再重试操作。如果您持续达到其中一个长期配额限制，则应分析您的工作负载以寻求缓解问题的方法。缓解措施可能包括优化工作负载或申请增加配额。

注意：某些配额以每日配额的形式表示。例如，每个表的加载作业数量都有一个每日配额。不过，这些配额会在 24 小时内逐步补充，因此您无需在达到限制后等待整整 24 小时。

对于 quotaExceeded 错误，请检查错误消息以了解超出了哪个配额限制。然后分析您的工作负载，查看能否避免达到配额。例如，优化查询性能可以缓解并发查询的配额错误。

在某些情况下，您可以通过与 BigQuery 支持团队联系或与 Google Cloud 销售人员联系来增加配额，但我们建议您先尝试本文档中列出的建议。

诊断

如需诊断问题，请执行以下操作：

• 使用 INFORMATION_SCHEMA 视图分析潜在的问题。这些视图包含有关 BigQuery 资源（包括作业、预留和流式插入）的元数据。

  例如，以下查询使用 INFORMATION_SCHEMA.JOBS 视图列出过去一天中与配额相关的所有错误：

  SELECT
   job_id,
   creation_time,
   error_result
  FROM `region-us`.INFORMATION_SCHEMA.JOBS
  WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY) AND
        error_result.reason IN ('rateLimitExceeded', 'quotaExceeded')
  

• 在 Cloud Audit Logs 中查看错误。

  例如，使用日志浏览器，以下查询会返回消息字符串中包含 Quota exceeded 或 limit 的错误：

  resource.type = ("bigquery_project" OR "bigquery_dataset")
  protoPayload.status.code ="7"
  protoPayload.status.message: ("Quota exceeded" OR "limit")
  

  在此示例中，状态代码 7 表示 PERMISSION_DENIED，它对应于 HTTP 403 状态代码。

  如需查看其他 Cloud Audit Logs 查询示例，请参阅 BigQuery 查询。

并发查询配额错误

如果某个项目同时运行的交互式查询数量超出了为该项目指定的限制，则您可能会遇到此错误。

如需详细了解此限制，请参阅并发交互式查询数上限。

错误消息

Exceeded rate limits: too many concurrent queries for this project_and_region

诊断

如果您尚未确定具体是哪些查询作业返回了此错误，请执行以下操作：

• 检查是否有与失败查询并发运行的其他查询。

  例如，如果您的失败查询是于世界协调时间 (UTC) 2021-06-08 12:00:00 在 us 区域提交的，请对提交失败查询的项目中的 INFORMATION_SCHEMA.JOBS 视图运行以下查询：

  DECLARE failed_query_submission_time DEFAULT CAST('2021-06-08 12:00:00' AS TIMESTAMP);
  
  SELECT
   job_id,
   state,
   user_email,
   query
  FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
  WHERE creation_time >= date_sub(failed_query_submission_time, INTERVAL 1 DAY)
  AND job_type = 'QUERY'
  AND priority = 'INTERACTIVE'
  AND start_time >= failed_query_submission_time
  AND (end_time <= failed_query_submission_time OR state != 'DONE')
  

• 如果您对 INFORMATION_SCHEMA.JOBS_BY_PROJECT 的查询失败并显示相同错误，请在 Cloud Shell 终端中运行 bq ls 命令以列出正在运行的查询：

  bq ls -j --format=prettyjson -n 200 | jq '.[] | select(.status.state=="RUNNING")| {configuration: .query, id: .id, jobReference: .jobReference, user_email: .user_email}'

解决方法

要解决此配额错误，请执行以下操作：

• 暂停作业。如果上述诊断确定查询数的增加应由某个进程或工作流负责，则暂停该进程或工作流。

• 使用具有批量优先级的作业。批量查询不会计入并发速率限制。运行批量查询时，您可以同时启动多个查询。批量查询使用的资源与交互式（按需）查询相同。BigQuery 会替您将每个批量查询排队，并在 BigQuery 共享资源池中有空闲资源的情况下开始查询，

  或者，您也可以创建一个单独的项目来运行查询。

• 分发查询。根据查询的性质和业务需求，将负载组织和分发到不同的项目中。

• 分散运行时间。将负载分散到更长的时间范围内。如果您的报告解决方案需要运行许多查询，请尝试在查询开始时引入一些随机性。例如，不同时启动所有报告。

• 使用 BigQuery BI Engine。如果您使用商业智能 (BI) 工具创建在 BigQuery 中查询数据的信息中心时遇到此错误，我们建议您使用 BigQuery BI Engine。在这种用例下，BigQuery BI Engine 是最佳选择。

• 优化查询和数据模型。通常，您可以重写查询，以便提高其运行效率。例如，如果您的查询包含通用表表达式 (CTE) - WITH 子句（在查询的多个位置引用），则此计算会完成多次。最好将 CTE 完成的计算保存到临时表中，后续在查询中引用它。

  多次联接也可能会造成低效。在这种情况下，您可能希望考虑使用嵌套和重复的列。这种方法通常可以提高数据的局部化程度，消除对于部分联接的需求，并且从整体上减少资源消耗量并缩短查询运行时间。

  优化查询可以降低其费用，这样在您使用固定价格时，就能通过自己的槽运行更多查询。如需了解详情，请参阅优化查询性能简介。

• 优化查询模型。BigQuery 不是关系型数据库，它并未针对无限数量的小型查询进行过优化。运行大量小型查询会造成您的配额快速耗尽。使用小型数据库产品运行这些查询的效率要更高。BigQuery 是一个大型数据仓库，这也是其主要用例。它最适合用于对大量数据执行分析查询。

• 保留数据（已保存的表）。预处理 BigQuery 中的数据，并将其存储在其他表中。例如，如果使用不同的 WHERE 条件执行许多类似的计算密集型查询，则系统不会缓存其结果。每次运行此类查询时也会消耗资源。通过预计算数据并将其存储在表中，您就可以提高此类查询的性能并缩短其处理时间。表中的这种预先计算的数据可通过 SELECT 查询进行查询。这通常可以在 ETL 过程中的注入期间完成，或者使用计划查询或具体化视图完成。

• 提高配额限制。您也可以提高配额限制以解决此错误。如需提高此限制，请与支持团队联系或与销售人员联系。增加配额申请可能需要几天的时间才能处理完毕。为了在您的请求中提供更多信息，我们建议您的请求包含作业的优先级、运行查询的用户以及受影响的方法。

  限制应用于项目级。但是，增加每个项目的并发作业数量会减少每个并发运行的查询可用的槽数，这可能会降低单个查询的性能。如需提升性能，我们建议您在提高并发查询限制时增加槽数。

  如需详细了解如何提高此限制，请参阅配额和限制。如需详细了解槽，请参阅槽预留。

列分区表的分区修改数配额错误

如果您的列分区表达到每天允许的分区修改次数配额，BigQuery 会返回此错误。分区修改数涵盖以下所有加载作业、复制作业和查询作业的总操作数：向目标分区附加数据、覆盖目标分区，或者使用 DML DELETE、INSERT、MERGE、TRUNCATE TABLE 或 UPDATE 语句向表写入数据。

如需查看每个列分区表每天的分区修改数限制的值，请参阅分区表。

错误消息

Quota exceeded: Your table exceeded quota for
Number of partition modifications to a column partitioned table

解决方法

此配额无法增加。 要解决此配额错误，请执行以下操作：

• 请更改表的分区以在每个分区中添加更多数据，以减少分区总数。例如，从每天分区更改为每月分区，或更改对表进行分区的方式。
• 使用聚簇，而不是分区。
• 如果您经常从存储在 Cloud Storage 中的多个小文件中加载数据，此时每个文件会使用一个作业，请将多个加载作业合并到一个作业中。如需从多个 Cloud Storage URI 加载数据，您可以使用逗号分隔列表（例如 gs://my_path/file_1,gs://my_path/file_2），也可以使用通配符（例如 gs://my_path/*）。

  如需了解详情，请参阅批量加载数据。

• 如果使用单行查询（即 INSERT 语句）将数据写入表中，请考虑将多个查询合并为一个查询，以减少作业数量。用作关系型数据库时，BigQuery 的执行性能不佳，因此我们不建议高速执行单行 INSERT 语句。
• 如果您打算高速率插入数据，请考虑使用 BigQuery Storage Write API。它是用于高性能数据注入的推荐解决方案。BigQuery Storage Write API 功能强大，包括“正好一次”传送语义。如需了解限制和配额，请参阅 Storage Write API，若要查看使用此 API 的费用，请参阅 BigQuery 数据注入价格。

流式插入配额错误

本部分提供了一些有关排查与将数据流式插入 BigQuery 相关的配额错误的提示。

在某些区域中，如果您不为每一行填写 insertId 字段，则流式插入将具有更高的配额。如需详细了解流式插入的配额，请参阅流式插入。BigQuery 流式传输的配额相关错误取决于是否存在 insertId。

错误消息

如果 insertId 字段为空，则可能会出现以下配额错误：

配额限制	错误消息
每个项目每秒字节数	REGION 区域内项目 PROJECT_ID 中 gaia_id 为 GAIA_ID 的实体已超出每秒插入字节数的配额。

如果填写了 insertId 字段，则可能会出现以下配额错误：

配额限制	错误消息
每个项目每秒的行数	REGION 中的项目 PROJECT_ID 已超出每秒流式插入行数的配额。
每个表每秒的行数	表 TABLE_ID 已超出每秒流式插入行数的配额。
每个表每秒字节数	表 TABLE_ID 已超出每秒流式插入字节数的配额。

insertId 字段的用途是删除重复的插入行。如果具有相同 insertId 的多个插入内容均在几分钟之内发送至 BigQuery，则 BigQuery 将写入单个版本的记录。但是，我们无法保证系统会自动删除重复的数据。为了最大限度的提高流式数据处理效率，我们建议您不要添加 insertId，而是使用手动去重。如需了解详情，请参阅确保数据一致性。

诊断

使用 STREAMING_TIMELINE_BY_* 视图分析流式流量。这些视图会每隔一分钟汇总流式统计信息（按错误代码分组）。配额错误显示在结果中，其 error_code 等于 RATE_LIMIT_EXCEEDED 或 QUOTA_EXCEEDED。

根据达到的特定配额限制，请查看 total_rows 或 total_input_bytes。如果错误是表级配额，请按 table_id 进行过滤。

例如，以下查询显示每分钟注入的总字节数，以及配额错误总数：

SELECT
 start_timestamp,
 error_code,
 SUM(total_input_bytes) as sum_input_bytes,
 SUM(IF(error_code IN ('QUOTA_EXCEEDED', 'RATE_LIMIT_EXCEEDED'),
     total_requests, 0)) AS quota_error
FROM
 `region-us`.INFORMATION_SCHEMA.STREAMING_TIMELINE_BY_PROJECT
WHERE
  start_timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY)
GROUP BY
 start_timestamp,
 error_code
ORDER BY 1 DESC

解决方法

要解决此配额错误，请执行以下操作：

• 如果您使用 insertId 字段进行重复信息删除，并且您的项目位于支持较高流式配额的区域中，我们建议您移除 insertId 字段。此解决方案可能需要执行一些额外的步骤来手动移除重复数据。如需了解详情，请参阅手动移除重复数据。

• 如果您未使用 insertId，或者不能将其移除，请监控 24 小时时间段的流式流量并分析配额错误：

  • 如果您看到的大多数是 RATE_LIMIT_EXCEEDED 错误而不是 QUOTA_EXCEEDED 错误，而您的总体流量低于配额的 80%，则这些错误可能指示暂时达到峰值。您可以通过在两次重试之间使用指数退避算法来重试操作，以消除这些错误。

  • 如果您使用 Dataflow 作业插入数据，请考虑使用加载作业，而非流式插入。如需了解详情，请参阅设置插入方法。如果您将 Dataflow 与自定义 I/O 连接器搭配使用，请考虑改为使用内置 I/O 连接器。如需了解详情，请参阅自定义 I/O 模式。

  • 如果您看到 QUOTA_EXCEEDED 错误或总体流量持续超过配额的 80%，请提交增加配额的申请。如需了解详情，请参阅申请更高配额限制。

  • 您可能还希望考虑将流式插入替换为新的 Storage Write API，该 API 具有更高的吞吐量、更低的价格和许多实用功能。

加载 CSV 文件配额错误

如果您使用带有 --allow_quoted_newlines 标志的 bq load 命令加载大型 CSV 文件，则可能会遇到此错误。

错误消息

Input CSV files are not splittable and at least one of the files is larger than
the maximum allowed size. Size is: ...

解决方法

要解决此配额错误，请执行以下操作：

• 将 --allow_quoted_newlines 标志设置为 false。
• 将 CSV 文件拆分为多个小于 4 GB 的较小区块。

如需详细了解在将数据加载到 BigQuery 时适用的限制，请参阅加载作业。

表导入或查询附加配额错误

在表达到标准表的每天表操作数限制时，BigQuery 将返回此错误消息。表操作数涵盖以下所有加载作业、复制作业和查询作业的总操作数：向目标表附加数据、覆盖目标表，或者使用 DML DELETE、INSERT、MERGE、TRUNCATE TABLE 或 UPDATE 语句将数据写入表。

如需查看每天的表操作数限制的值，请参阅标准表。

错误消息

Your table exceeded quota for imports or query appends per table

诊断

如果您尚未确定大多数表操作数来自何处，请执行以下操作：

1. 记下失败的查询、加载或复制作业写入的项目、数据集和表。

2. 使用 INFORMATION_SCHEMA.JOBS_BY_* 表详细了解修改该表的作业。

   以下示例使用 JOBS_BY_PROJECT 查找在 24 小时的时间段内，按照作业类型分组的作业的每小时计数。如果您希望多个项目写入表，请将 JOBS_BY_PROJECT 替换为 JOBS_BY_ORGANIZATION。

   SELECT
     TIMESTAMP_TRUNC(creation_time, HOUR),
     job_type,
     count(1)
   FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
   #Adjust time
   WHERE creation_time BETWEEN "2021-06-20 00:00:00" AND "2021-06-21 00:00:00"
   AND destination_table.project_id = "my-project-id"
   AND destination_table.dataset_id = "my_dataset"
   AND destination_table.table_id = "my_table"
   GROUP BY 1, 2
   ORDER BY 1 DESC
   

解决方法

此配额无法增加。 要解决此配额错误，请执行以下操作：

• 如果您经常从存储在 Cloud Storage 中的多个小文件中加载数据，此时每个文件会使用一个作业，请将多个加载作业合并到一个作业中。如需从多个 Cloud Storage URI 加载数据，您可以使用逗号分隔列表（例如 gs://my_path/file_1,gs://my_path/file_2），也可以使用通配符（例如 gs://my_path/*）。

  如需了解详情，请参阅批量加载数据。

• 如果使用单行查询（即 INSERT 语句）将数据写入表中，请考虑将多个查询合并为一个查询，以减少作业数量。用作关系型数据库时，BigQuery 的执行性能不佳，因此我们不建议高速执行单行 INSERT 语句。
• 如果您打算高速率插入数据，请考虑使用 BigQuery Storage Write API。它是用于高性能数据注入的推荐解决方案。BigQuery Storage Write API 功能强大，包括“正好一次”传送语义。如需了解限制和配额，请参阅 Storage Write API，若要查看使用此 API 的费用，请参阅 BigQuery 数据注入价格。

表元数据更新操作的最大速率限制错误

当表达到标准表的每个表的表元数据更新操作速率上限时，BigQuery 会返回此错误。 表操作包括附加或覆盖目标表的所有加载作业、复制作业和查询作业的合并总数，或者使用 DML DELETE、INSERT、MERGE、TRUNCATE TABLE 或 UPDATE 将数据写入表的合并总数。

如需查看每个表的表元数据更新操作的速率上限值，请参阅标准表。

错误消息

Exceeded rate limits: too many table update operations for this table

诊断

元数据表更新可以来自修改表元数据的 API 调用，或源自修改表内容的作业。如果您尚未确定表元数据的大多数更新操作的来源，请执行以下操作：

确定 API 调用

1. 转到 Google Cloud 导航菜单 ，然后选择 Logging > 日志浏览器：

   转到日志浏览器

2. 通过运行以下查询来过滤日志，以查看表操作：

   resource.type="bigquery_dataset"
   protoPayload.resourceName="projects/my-project-id/datasets/my_dataset/tables/my_table"
   (protoPayload.methodName="google.cloud.bigquery.v2.TableService.PatchTable" OR
   protoPayload.methodName="google.cloud.bigquery.v2.TableService.UpdateTable" OR
   protoPayload.methodName="google.cloud.bigquery.v2.TableService.InsertTable")
   

确定作业

以下查询返回修改项目中受影响的表的作业列表。如果您希望组织中的多个项目写入表，请将 JOBS_BY_PROJECT 替换为 JOBS_BY_ORGANIZATION。

SELECT
 job_id,
 user_email,
 query
#Adjust region
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
#Adjust time
WHERE creation_time BETWEEN "2021-06-21 10:00:00" AND "2021-06-21 20:00:00"
AND destination_table.project_id = "my-project-id"
AND destination_table.dataset_id = "my_dataset"
AND destination_table.table_id = "my_table"

如需了解详情，请参阅 BigQuery 审核日志概览。

解决方法

此配额无法增加。 要解决此配额错误，请执行以下操作：

• 降低表元数据的更新速率。
• 在作业或表操作之间添加延迟，以确保将更新速率控制在限制范围内。

• 对于数据插入或修改，请考虑使用 DML 操作。DML 操作不会受到每个表的表元数据更新操作速率上限速率限制的影响。

  DML 操作还有其他限制和配额。如需了解详情，请参阅使用数据操纵语言 (DML)。

• 如果您经常从存储在 Cloud Storage 中的多个小文件中加载数据，此时每个文件会使用一个作业，请将多个加载作业合并到一个作业中。如需从多个 Cloud Storage URI 加载数据，您可以使用逗号分隔列表（例如 gs://my_path/file_1,gs://my_path/file_2），也可以使用通配符（例如 gs://my_path/*）。

  如需了解详情，请参阅批量加载数据。

• 如果使用单行查询（即 INSERT 语句）将数据写入表中，请考虑将多个查询合并为一个查询，以减少作业数量。用作关系型数据库时，BigQuery 的执行性能不佳，因此我们不建议高速执行单行 INSERT 语句。
• 如果您打算高速率插入数据，请考虑使用 BigQuery Storage Write API。它是用于高性能数据注入的推荐解决方案。BigQuery Storage Write API 功能强大，包括“正好一次”传送语义。如需了解限制和配额，请参阅 Storage Write API，若要查看使用此 API 的费用，请参阅 BigQuery 数据注入价格。

API 请求的最大数量限制错误

如果针对每种方法，您的每个用户对 BigQuery API 发出的 API 请求数量达到速率限制，BigQuery 将返回此错误，例如，来自服务帐号的 tables.get 方法调用，或来自不同用户电子邮件的 jobs.insert 方法调用。如需了解详情，请参阅所有 BigQuery API 中的每种方法每个用户每秒的 API 请求数上限速率限制。

注意：BigQuery API 速率限制不适用于流式插入 API 请求。

错误消息

Too many API requests per user per method for this user_method

诊断

如果您尚未确定达到此速率限制的方法，请执行以下操作：

对于服务帐号

1. 转到托管服务帐号的项目。

2. 在 Google Cloud Console 中，转到 API 信息中心。

   如需获得有关如何查看 API 详细使用情况信息的说明，请参阅使用 API 信息中心。

3. 在 API 信息中心内，选择 BigQuery API。

4. 如需查看更详细的使用情况信息，请选择指标，然后执行以下操作：

   1. 对于选择图表，选择流量（按 API 方法）。

   2. 按服务帐号的凭据过滤图表。您可能会在发现错误的时间范围内看到某个方法的相关数据激增。

对于 API 调用

某些 API 调用会在 Cloud Logging 的 BigQuery 审核日志中记录错误。如需确定达到限制的方法，请执行以下操作：

1. 在控制台中，转到 Google Cloud 导航菜单 ，然后为您的项目选择日志记录 > 日志浏览器：

   转到日志浏览器

2. 运行以下查询来过滤日志：

    resource.type="bigquery_resource"
    protoPayload.authenticationInfo.principalEmail="<user email or service account>"
    "Too many API requests per user per method for this user_method"
    In the log entry, you can find the method name under the property protoPayload.method_name.
    

   如需了解详情，请参阅 BigQuery 审核日志概览。

解决方法

要解决此配额错误，请执行以下操作：

• 减少 API 请求数，或增加多次 API 请求之间的延迟时间，以使请求数保持在此限制内。

• 如果只是偶尔超出该限制，您可以使用指数退避算法，在遇到此特定错误时重试。

• 如果您经常插入数据，请考虑使用流式插入，因为流式插入不受 BigQuery API 配额的影响。但是，流式插入 API 需要收取相关费用，并且具有自己的一组限制和配额。

  如需了解流式插入的费用，请参阅 BigQuery 价格。

• 使用 Dataflow 和 BigQuery I/O 连接器将数据加载到 BigQuery 时，您可能会遇到 tables.get 方法的此错误。如需解决此问题，请执行以下操作：

  • 将目标表的创建处置方式设置为 CREATE_NEVER。如需了解详情，请参阅创建处置方式。

  • 使用 Apache Beam SDK 2.24.0 或更高版本。在旧版 SDK 中，CREATE_IF_NEEDED 处置会调用 tables.get 方法以检查表是否存在。

• 您可以联系支持团队或销售人员以申请增加配额。如需额外的配额，请参阅申请增加配额。增加配额申请可能需要几天的时间才能处理完毕。为了在您的请求中提供更多信息，我们建议您的请求包含作业的优先级、运行查询的用户以及受影响的方法。

您的项目已超出扫描的查询字节数免费配额

如果免费用量层级中运行查询时，并且帐号达到每月可查询的数据大小限制，BigQuery 会返回此错误。如需详细了解查询（分析），请参阅免费层级。

错误消息

Your project exceeded quota for free query bytes scanned

解决方法

如需继续使用 BigQuery，您需要将帐号升级到付费 Cloud Billing 帐号。

与每个项目每秒的 tabledata.list 字节数上限有关的配额错误

如果错误消息中提及的项目编号所对应的项目达到每个项目每秒可通过 tabledata.list API 调用读取的数据大小上限，BigQuery 将返回此错误。如需详细了解每分钟表数据列表字节数限制，请参阅 tabledata.list 请求。

错误消息

Your project:[project number] exceeded quota for tabledata.list bytes per second per project

解决方法

要解决此错误，请执行以下操作：

• 一般来说，我们建议不要超出此限制；例如，通过延长各请求之间的间隔时间。如果该错误没有频繁发生，则使用指数退避算法实现重试可以解决此问题。
• 如果您的用例需要快速、频繁地从表中读取大量数据，我们建议使用 BigQuery Storage Read API，而不是 tabledata.list API。

• 如果上述建议不起作用，您可以执行以下操作，以从控制台 API 信息中心申请增加配额：

  1. 转到控制台 API 信息中心。
  2. 在该信息中心内，过滤配额：Tabledata list bytes per minute (default quota)。
  3. 选择配额，然后按照申请更高配额限制中的说明操作。

  审核和处理请求可能需要几天时间。

与每个项目每天的复制作业数上限有关的配额错误

如果项目中运行的复制作业数超过每日上限，BigQuery 将返回此错误。如需详细了解每天的复制作业数限制，请参阅复制作业。

错误消息

Your project exceeded quota for copies per project

诊断

如果您想收集有关复制作业来源的更多数据，您可以尝试以下操作：

• 如果您的复制作业位于单个或少数几个区域，您可以尝试查询这些特定区域的 INFORMATION_SCHEMA.JOBS 表。例如：

  SELECT
  creation_time, job_id, user_email, destination_table.project_id, destination_table.dataset_id, destination_table.table_id
  FROM `PROJECT_ID`.`REGION_NAME`.INFORMATION_SCHEMA.JOBS
  WHERE
  creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 2 DAY) AND CURRENT_TIMESTAMP()
  AND job_type = "COPY"
  order by creation_time DESC
  

  REGION_NAME 部分应替换为区域名称，包括 region- 前缀。例如 region-us、region-asia-south1。您还可以根据相关时间范围调整时间间隔。
• 如需查看所有区域中的全部复制作业，您可以在 Cloud Logging 中使用以下过滤条件：

  resource.type="bigquery_resource"
  protoPayload.methodName="jobservice.insert"
  protoPayload.serviceData.jobInsertRequest.resource.jobConfiguration.tableCopy:*
  

解决方法

• 如果频繁复制操作的目标是创建数据快照，请考虑改用表快照。与复制完整表相比，表快照更具成本效益、速度上也更快。
• 您可以联系支持团队或销售人员以申请增加配额。审核和处理请求可能需要几天时间。我们建议您在请求中注明优先级、用例和项目 ID。