配额限制：节点资源受每个用户的配额限制。如果未提前申请增加配额，可能会导致计算资源过载，这可能不在 SLA 的涵盖范围内。需要 Google 进行审批的配额增加申请通常会在一天内完成。
预配不足的会话：Spanner 客户端使用 gRPC 通道与 Google Cloud 端点进行通信，以执行查询和管理操作。如果您的客户端环境提供的通道不足以支持工作负载的请求量，则您的应用可能会遇到高延迟时间和低请求吞吐量，这可能不在 SLA 的涵盖范围内。
连接过载：许多 Spanner API 在发生暂时性故障（例如查询中的事务死锁、网络问题或管理 API 的速率限制）时可以安全地进行重试。过于激进的重试可能会使现有连接不堪重负，从而导致资源耗尽或进一步节流。延迟时间增加或吞吐量减少可能不在 SLA 的涵盖范围内。如需了解详情，请参阅管理客户端超时和重试。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-09。"],[],[],null,["# Spanner operational guidelines\n\nThis page describes some of the user-controlled configurations that can cause an\noutage for a Spanner instance to be excluded from the\nSpanner Service Level Agreement (SLA), which excludes outages\n\"caused by factors outside of Google's reasonable control\". It also provides\nguidelines on how to avoid these configurations.\n\nSpanner manages many aspects of database operations, such as\nsplitting and rebalancing data, replication, failover, and all hardware and\nsoftware updates. You can configure many of these behaviors with built-in\nsettings and administrative APIs. Your workloads also depend on other components\nin addition to Spanner, such as your applications and network.\nThese customer-controlled configurations may increase the risk of instance\ndowntime, depending on your database load and other configuration parameters.\n\nIf your instance becomes unhealthy, and if Google determines that the instance\nis out of compliance with the operational limits described on this page, then\nany resulting downtime may not be covered by (or does not count against) the\nSpanner SLA.\n| **Note:** You're responsible for monitoring your Spanner instances and verifying that they are correctly sized and configured for the type of workloads that you're running.\n\nConfigurations excluded from the Spanner SLA\n--------------------------------------------\n\nThe following configurations are excluded from the Spanner SLA:\n\n- If your instance is configured and used in a way that causes the workload to overload the instance, then it isn't covered by the SLA.\n- Downtime of instances that results from your voluntary actions or inactions isn't covered by the SLA\n- If you disable the [Spanner API](/spanner/docs/getting-started/set-up#set_up_a_project) or other Google Cloud APIs that are required to create and connect to Spanner, then it isn't covered by the SLA.\n- Unavailability of the Spanner API that is the result of your network configuration, such as proxy and firewall rules, isn't covered by the SLA.\n- Application unavailability due to out-of-date or misconfigured [clients](/spanner/docs/reference/libraries) isn't covered by the SLA. In particular, verify that you are using recent client versions with supported dependencies. For example, Java applications should use [Google's BOM](/java/docs/bom) (bill of materials) with a package manager, such as Gradle or Maven.\n\nWe recommend that you set up alerts and monitoring using\n[Cloud Monitoring](/spanner/docs/monitoring-cloud).\n\n### Configurations to avoid\n\nTo maintain Spanner SLA coverage, you must avoid the following\nconfigurations:\n\n- **CPU overload** : If your CPU utilization is consistently high, then your instance isn't properly sized for your workload, and the instance might not be covered by the SLA. Spanner [CPU utilization recommendations](/spanner/docs/compute-capacity#change-compute-capacity) provide overhead for a failover event, where the remaining compute resources help to accommodate traffic from unavailable parts of the instance. You can use Spanner [CPU utilization metrics](/spanner/docs/cpu-utilization) to monitor CPU utilization.\n- **Full storage** : Spanner bills you only for the storage that you use. However, each node, or unit of compute, has a [limit](/spanner/quotas#database-limits) for the amount of storage it can manage. If your instance isn't properly sized for the addressable storage per node, then the instance might not be covered by the SLA. You can use Spanner [storage utilization metrics](/spanner/docs/storage-utilization) to monitor storage utilization.\n- **Quota limit:** Node resources are limited by per-user [quotas](/spanner/quotas). Failure to request quota increases in advance might result in compute resource overload, which might not be covered by the SLA. Quota increase requests that require approval from Google are typically fulfilled within one day.\n- **Under provisioned sessions** : Spanner clients use [gRPC channels](/spanner/docs/sessions#configure_the_number_of_sessions_and_grpc_channels_in_the_pools) to communicate with Google Cloud endpoints for queries and administration. If your client environments don't provide enough channels to support the request volume of a workload, your applications might experience high latency and low request throughput that might not be covered by the SLA.\n- **Connection overload:** Many Spanner APIs can be safely retried in the event of a transient failure, such as a transaction deadlock in a query, a network issue, or rate limits for administrative APIs. Overly aggressive retries might overwhelm existing connections, causing resource exhaustion or additional throttling. The increased latency or reduced throughput might not be covered by the SLA. For more information, see [managing client timeouts and retries](/spanner/docs/custom-timeout-and-retry).\n- **Hard disk drive (HDD) overload:** [Tiered storage](/spanner/docs/tiered-storage) lets you store your Spanner data on a mix of solid-state drives (SSD) and hard disk drives (HDD). If your disk load on HDD storage reaches 100%, your Spanner instance experiences significantly increased latency and might not be covered by the SLA. You can use Spanner [tiered storage metrics](/spanner/docs/monitoring-console#tiered_storage_charts_and_metrics) to monitor disk load.\n\nWhat's next\n-----------\n\n- Learn [best practices for improving Spanner performance and availability using the launch checklist](/spanner/docs/launch-checklist)."]]
