常見的最佳做法

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

Cloud SQL 執行個體要待到完成前一項作業後，才能接受新的作業要求。如果試圖提前啟動新作業，作業要求會失敗。重新啟動執行個體也包含在內。

Google Cloud 主控台中的執行個體狀態無法反映作業是否正在執行。綠色勾號只代表執行個體的狀態為 RUNNABLE。如要查看是否正在執行作業，請前往「Operations」(作業)分頁查看最新的作業狀態。

如果啟用自動增加儲存空間的執行個體設定已停用，或是已啟用自動增加儲存空間限制，請務必至少保留 20% 的可用空間，以便 Cloud SQL 執行任何重要的資料庫維護作業。

如要接收可用磁碟空間低於 20% 的警報，請為「磁碟使用率」指標建立以指標為基礎的警報政策，並將「門檻位置」設為「高於門檻」，值為 .8。詳情請參閱「建立以指標為基礎的警告政策」。

您可以在 Google Cloud 控制台的執行個體詳細資料頁面中，查看執行個體使用的可用 CPU 百分比。詳情請參閱「指標」一文。您也可以建立指標門檻快訊政策，監控 CPU 用量，並在達到指定門檻時收到快訊通知。

為避免 CPU 使用率過高，您可以增加執行個體的 CPU 數量。變更 CPU 需要重新啟動執行個體。如果執行個體已達 CPU 數量上限，您必須將資料庫分割成多個執行個體。

如要查看記憶體耗盡的跡象，請主要使用「用量」指標。為避免記憶體不足錯誤，建議您將這個指標保持在 90% 以下。

您也可以使用 total_usage 指標，查看 Cloud SQL 執行個體使用的可用記憶體百分比，包括資料庫容器使用的記憶體，以及作業系統快取所分配的記憶體。

觀察這兩項指標的差異，即可瞭解程序與作業系統快取使用了多少記憶體。您可以重新利用此快取中的記憶體。

如要預測記憶體不足的問題，請同時查看並解讀這些指標。如果指標顯示過高，表示執行個體的記憶體可能不足。這可能是因為自訂設定、執行個體不敷工作負載需求，或是上述因素的組合所致。

調整 Cloud SQL 執行個體，以增加記憶體容量。 變更執行個體的記憶體大小時，必須重新啟動執行個體。如果執行個體已達到記憶體大小上限，您必須將資料庫分割成多個執行個體。如要進一步瞭解如何在 Google Cloud 控制台中監控這兩項指標，請參閱「指標」一文。

• vCPU：40
• 記憶體：262144 MB
• MAXDOP：8
• 平行處理費用門檻：120
• tempdb 檔案：8。預先設定大小，以免自動成長。
• 使用者資料庫檔案：Autogrow 設定為 64-128 MB。預先設定大小，以免發生自動成長情形。
• 儲存空間：>= 4TB 可提供最佳 IOPS

測試各種 I/O 類型和大小。從 SQL Server 發送至永久磁碟儲存空間的 I/O 大小會影響 IOPS 和處理量。當 SQL Server 工作負載達到 IOPS 上限或吞吐量上限時，系統會降低工作負載。Cloud SQL 使用的儲存類型為 SSD 永久磁碟，適合高效能企業級工作負載。

如要自訂 VM 以盡可能提升效能，請按照下列步驟操作：

• 磁碟大小為 4 TB 以上可提供更高的總處理量和 IOPS。
• 越高的 vCPU 可提供更多 IOPS 和總處理量。使用較多 vCPU 時，請監控資料庫等待並行處理的情況，因為這可能也會增加。
• 為獲得最佳效能，請並行發出 I/O，以達到更高的 I/O 佇列深度。

請以 MB 為單位設定 autogrow，而非以百分比為單位，並使用符合需求的增量值。此外，請在自動成長功能啟用前主動管理成長。

此外，請確認已啟用 Cloud SQL 的「啟用自動增加儲存空間」功能，以便在資料庫和執行個體的儲存空間用盡時，Cloud SQL 可增加儲存空間。

• 複製資料庫，並在複製資料庫上執行 DBCC CHECKDB。
• 將備份還原至其他執行個體，然後在已還原的執行個體資料庫上執行 DBCC CHECKDB。如要進一步瞭解如何還原執行個體，請參閱「還原執行個體」。

使用下列程式碼片段，在資料庫上執行 DBCC CHECKDB：

• (建議做法) 使用 EXTENDED_LOGICAL_CHECKS 執行 DBCC CHECKDB。這是一項全面但耗用資源較多的檢查。

        USE DATABASE_NAME
        DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS,
        DATA_PURITY,NO_INFOMSGS, ALL_ERRORMSGS
        

• 使用 PHYSICAL_ONLY 執行 DBCC CHECKDB：

        USE DATABASE_NAME
        DBCC CHECKDB WITH PHYSICAL_ONLY,
        NO_INFOMSGS, ALL_ERRORMSGS
        

請將執行個體的表格數量控制在 10,000 以下。資料庫資料表過多可能會影響資料庫升級時間。

備份和匯出是提供資料備援和資料保護的兩種方式。這兩種方式可在不同情境下各自提供保護，在健全的資料保護策略中下，兩者相輔相成。

建立備份既輕鬆又快速，能夠將執行個體上的資料還原至你在備份時的狀態。不過備份有一些限制。如果刪除執行個體，也會一併刪除備份。您無法備份單一資料庫或資料表。而且如果執行個體所在的地區無法使用，即使您身在可用的地區，也無法透過備份還原執行個體。

匯出所需的時間較長，因為會在 Cloud Storage 建立外部檔案，讓您用來重新建立資料。即使刪除執行個體，也不會影響到匯出的資料。此外，您只能匯出單一資料庫或資料表，視您選擇的匯出格式而定。

在 Enterprise 或 Standard SQL Server 執行個體上使用匯出備份功能時，請勿建立 GZ 封存檔，因為這會嘗試壓縮 SQL Server 已原生壓縮的備份。

您在 Google Cloud 控制台或透過 Terraform 建立的 Cloud SQL 執行個體，預設會啟用防止意外刪除功能。

使用 Cloud SQL 中的匯出功能，匯出資料以便進一步保護。搭配使用 Cloud Scheduler 和 REST API，自動管理匯出作業。如要處理更進階的情況，請使用 Cloud Scheduler 搭配 Cloud Run 函式進行自動化。

這個標記會限制 Cloud SQL 可為其內部集區分配的記憶體量。

如果您未為此標記設定值，Cloud SQL 會根據執行個體的 RAM 大小自動管理這個值。此外，如果您調整執行個體大小，Cloud SQL 會自動調整標記的值，以符合我們建議的新執行個體大小。

強烈建議您不要為執行個體指定這項旗標的值。如果您將值設為大於 80%，可能會因為記憶體不足而導致不穩定、效能降低和資料庫當機。

如果您想自行管理這個標記的值，請手動設定。因此，Cloud SQL 會停用自動管理功能。如果您要調整執行個體大小，請考慮重新檢查值，以便符合新大小的建議值。

建議您使用下列公式設定
max server memory 資料庫標記：

• 為作業系統和代理程式保留 1.4 GB 記憶體。
• 如果伺服器的 RAM 小於或等於 16 GB，請為每 4 GB RAM 保留 1 GB 的記憶體。
• 如果伺服器的 RAM 大於 16 GB，請保留 4 GB 記憶體，並為每 8 GB 的 RAM (大於 16 GB) 保留 1 GB 記憶體。

舉例來說，如果執行個體的 RAM 為 104 GB
(106496 MB)，請預留：

• 系統和代理程式需要1.4 GB 的記憶體
• 4 GB 記憶體，因為 104 GB 大於 16 GB
• 11 GB 記憶體，因為 104 GB 的 RAM 大於 16 GB (104-16=88)，而 88 除以 8 等於 11

在這個範例中，您必須保留 16.4 GB 的記憶體。因此，請針對此旗標的值指定 89702 MB
[(104-16.4) * 1024 = 89702]。

下表列出幾種熱門虛擬機器 (VM) 等級的建議值和總 RAM 百分比：

如要監控執行個體的記憶體用量，請使用下列指標：

• database/memory/usage
• database/sqlserver/memory/buffer_cache_hit_ratio
• database/sqlserver/memory/memory_grants_pending
• database/sqlserver/memory/page_life_expectancy

詳情請參閱「監控 Cloud SQL 執行個體」。

這是 SQL 最佳化工具使用並行處理方式執行查詢的門檻。5 的預設值可能會導致並行執行的查詢過多，進而增加並行執行緒的資料庫等待時間。如要減少這類爭用情形，請提高該值。

當 maxdop 設為 1 時，系統會忽略這個值。

如要減少因並行處理而造成的資料庫等待時間，請根據可用的邏輯處理器數量，調整這個值的建議值。如果將這個選項設為 1，請務必謹慎評估成效。

避免在方案快取中放入大量一次性方案。如要針對含有許多一次性臨時批次作業的工作負載，提升其方案快取效率，請將這個選項設為 1。

預先設定 tempdb 的大小，這樣就不需要自動調整大小。tempdb 中的所有檔案應具有相同的大小，且具有相同的檔案成長集。

tempdb 爭用情況的資料庫等待類型會顯示為 PAGELATCH_UP。如要減少競爭，請新增更多檔案。

如果處理器數量小於或等於 8，請使用與邏輯處理器相同數量的檔案。如果處理器數量超過 8，請使用 8 個資料檔案。如果爭用情形持續發生，請以 4 的倍數增加檔案數量，直到爭用情形消除為止。

不過，如果您希望經常執行的查詢有可預測的回應時間，或是應用程式在等待統計資料更新時經常發生用戶端要求逾時的情形，建議您啟用這個選項並停用 Auto Update Statistics。