一般的なベスト プラクティス

Cloud SQL インスタンスは、前のオペレーションが完了するまで、新しいオペレーション リクエストを受け付けません。準備が整う前に新しいオペレーションを開始しようとすると、オペレーション リクエストは失敗します。こうしたオペレーションには、インスタンスの再起動も含まれます。

Google Cloud Console のインスタンス ステータスには、オペレーションが実行されているかどうかは反映されません。緑色のチェックマークは、インスタンスが RUNNABLE 状態にあることのみを示します。オペレーションが実行中かどうかを確認するには、[オペレーション] タブに移動して、最新のオペレーションのステータスをチェックします。

インスタンス設定のストレージの自動増量を有効にするが無効になっているか、ストレージの自動増量の上限が有効になっている場合、Cloud SQL が実行できる重要なデータベース メンテナンス オペレーションに対応するためには、少なくとも 20% の空き容量を確保します。

利用可能なディスク容量が 20% を下回った場合にアラートを受信するには、しきい値を上回る場合に値を 0.8 として通知するディスク使用率指標の指標ベースのアラート ポリシーを作成します。詳細については、指標ベースのアラート ポリシーを作成するをご覧ください。

使用可能な CPU のうち、インスタンスが使用している割合は、Google Cloud コンソールのインスタンスの詳細ページで確認できます。詳細については、指標をご覧ください。また、指標しきい値のアラート ポリシーを作成するを使用して、CPU 使用率をモニタリングし、指定したしきい値でアラートを受信することもできます。

過剰な使用を回避するために、インスタンスの CPU 数を増やせます。CPU 数を変更するには、インスタンスの再起動が必要です。インスタンスがすでに CPU の最大数に達している場合は、データベースを複数のインスタンスにシャーディングする必要があります。

メモリ不足の兆候を調べる際は、主に 使用量 指標を使用してください。メモリ不足のエラーを回避するには、この指標を 90% 未満に保つことをおすすめします。

また、総使用量 指標を使用して、データベース コンテナが使用しているメモリやオペレーティング システムのキャッシュが割り当てたメモリなど、Cloud SQL インスタンスで使用されている使用可能なメモリの割合を確認することもできます。

2 つの指標の差を観察することで、プロセスによって使用されているメモリの量と、オペレーティング システムのキャッシュで使用されているメモリの量を把握できます。このキャッシュ内のメモリは再利用できます。

メモリ不足の問題を予測するには、両方の指標を確認してまとめて解釈します。指標が高い場合は、インスタンスのメモリが不足している場合があります。要因としては、カスタム構成によるもの、ワークロードのサイズが不足しているインスタンスのため、またはこれらの要因の組み合わせの可能性があります。

Cloud SQL インスタンスをスケーリングしてメモリのサイズを増やします。インスタンスのメモリサイズを変更するには、インスタンスを再起動する必要があります。インスタンスがすでに最大メモリサイズになっている場合は、データベースを複数のインスタンス間でシャーディングする必要があります。Google Cloud コンソールで両方の指標をモニタリングする方法については、指標をご覧ください。

• vCPU: 40
• メモリ: 262144 MB
• MAXDOP: 8
• cost threshold for parallelism: 120
• tempdb ファイル: 8。自動拡張を防ぐために事前にサイズが設定されます。
• ユーザー データベース ファイル: 自動拡張は 64-128 MB に設定されています。自動拡張を防ぐために事前にサイズが設定されます。
• ストレージ: >= 4TB（最適な IOPS を実現したい場合）

さまざまな I/O タイプとサイズをテストします。SQL Server の永続ディスク ストレージに発行される I/O のサイズは、IOPS とスループットに影響します。SQL Server のワークロードが IOPS の上限またはスループットの上限に達すると、ワークロードが制限されます。Cloud SQL で使用されているストレージ タイプは PD SSD で、高パフォーマンスのエンタープライズ レベルのワークロードに適しています。

次のように VM をカスタマイズして、パフォーマンスを最大化してください。

• ディスクサイズが 4 TB 以上の場合、より高いスループットと IOPS が得られます。
• vCPU が高いほど、IOPS とスループットが向上します。より高い vCPU を使用する場合、DB の並列処理待機時間が増加する可能性があるので、モニタリングしてください。
• 最適なパフォーマンスを得るには、I/O を並行して発行し、より高い I/O キューの深さを実現します。

autogrow を割合ではなく MB 単位で設定します。要件に合わせて最適な増分量を設定します。また、自動拡張が開始する前に、量の増加をプロアクティブに管理します。

さらに、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
        

• DBCC CHECKDB を PHYSICAL_ONLY と実行します。

        USE DATABASE_NAME
        DBCC CHECKDB WITH PHYSICAL_ONLY,
        NO_INFOMSGS, ALL_ERRORMSGS
        

インスタンスのテーブル数を常に 10,000 個未満にします。データベース テーブルが多すぎると、データベースのアップグレードに時間がかかる可能性があります。

バックアップとエクスポートは、データの冗長性を確保して保護するための方法です。それらはそれぞれ異なるシナリオで機能し、堅牢なデータ保護戦略でお互いを補います。

バックアップは簡単で、インスタンスのデータをバックアップ作成時の状態に復元する手段を提供します。ただし、バックアップにはいくつかの制限があります。インスタンスを削除すると、バックアップも削除されます。単一のデータベースまたはテーブルをバックアップすることはできません。また、インスタンスが配置されているリージョンを使用できない場合、使用可能なリージョンにあるバックアップからそのインスタンスを復元することはできません。

データの再作成に使用できる外部ファイルが Cloud Storage に作成されるため、エクスポートは作成するのに時間がかかります。インスタンスを削除しても、エクスポートは影響を受けません。また、選択するエクスポート形式に応じて、単一のデータベースまたはテーブルだけをエクスポートすることもできます。

Enterprise または標準 SQL Server インスタンスでエクスポート バックアップ機能を使用する場合は、SQL Server によってすでにネイティブに圧縮されているバックアップを圧縮しようとするため、GZ アーカイブ ファイルの作成は避けてください。

Google Cloud コンソールや Terraform を使用して作成した Cloud SQL インスタンスを使用すると、デフォルトで誤削除を防止できます。

保護を強化するため、Cloud SQL のエクスポート機能を使用してデータをエクスポートします。Cloud Scheduler と REST API を使用して、エクスポートの管理を自動化します。より高度なシナリオでは、Cloud Scheduler と Cloud Run functions を使用して自動化します。

このフラグは、Cloud SQL が内部プールに割り当てることができるメモリ量を制限します。

このフラグの値を設定しない場合は、Cloud SQL がインスタンスの RAM のサイズに基づいて値を自動的に管理します。また、インスタンスのサイズを変更すると、Cloud SQL は新しいインスタンス サイズの推奨事項を満たすようにフラグの値を自動的に調整します。

インスタンスにこのフラグの値を指定しないことを強くおすすめします。値を 80% より大きく設定すると、メモリ不足の問題により、不安定性、パフォーマンスの低下、データベースのクラッシュが発生する可能性があります。

このフラグの値を手動で管理する場合は、手動で設定します。その結果、Cloud SQL は自動管理を無効にします。インスタンスのサイズを変更する場合は、新しいサイズの推奨値に合わせて値を再検討することを検討してください。

max server memory データベース フラグを設定するには、次の式を使用することをおすすめします。

• OS とエージェント用に 1.4 GB のメモリを予約します。
• サーバーの RAM が 16 GB 以下の場合は、4 GB の RAM ごとに 1 GB のメモリを予約します。
• サーバーの RAM が 16 GB を超える場合は、4 GB のメモリを残し、16 GB を超える RAM の 8 GB ごとに 1 GB のメモリを予約します。

たとえば、インスタンスの RAM が 104 GB
（106,496 MB）の場合、次のように予約します。

• OS とエージェント用に 1.4 GB のメモリ
• 4 GB のメモリ（RAM が 104 GB で、16 GB より大きいため）
• 11 GB のメモリ: 16 GB を超える RAM は 88 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 を無効にすることを検討してください。