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

MySQL | PostgreSQL | SQL Server

このページでは、Cloud SQL のパフォーマンス、耐久性、可用性を高めるためのベストプラクティスを示します。

Cloud SQL インスタンスで問題が発生した場合は、トラブルシューティングの際に次の点を確認してください。

インスタンスの構成と管理

ベストプラクティス	詳細
オペレーションガイドラインを参照し、その手順に沿ってご使用のインスタンスが Cloud SQL SLA の対象であることを確認してください。
中断更新がいつ発生するかを制御するため、プライマリインスタンスのメンテナンスの時間枠を構成してください。	メンテナンスの時間枠をご覧ください。
インスタンスを定期的に削除して再作成する場合は、新しいインスタンス ID が使用可能になる確率を高めるため、インスタンス ID にタイムスタンプを使用してください。
前のオペレーションが完了する前に管理オペレーションを開始しないでください。	Cloud SQL インスタンスは、前のオペレーションが完了するまで、新しいオペレーションリクエストを受け付けません。準備が整う前に新しいオペレーションを開始しようとすると、オペレーションリクエストは失敗します。こうしたオペレーションには、インスタンスの再起動も含まれます。 Google Cloud コンソールのインスタンスステータスには、オペレーションが実行されているかどうかは反映されません。緑色のチェックマークは、インスタンスが `RUNNABLE` 状態にあることのみを示します。オペレーションが実行中かどうかを確認するには、[オペレーション] タブに移動して、最新のオペレーションのステータスをチェックします。
重要なデータベースのメンテナンスに対応するストレージを構成します。	インスタンス設定のストレージの自動増量を有効にするが無効になっているか、ストレージの自動増量の上限が有効になっている場合、Cloud SQL が実行する可能性のある重要なデータベースメンテナンスオペレーションに対応できるよう、少なくとも 20% の空き容量を確保します。利用可能なディスク容量が 20% を下回った場合にアラートを受信するには、ディスク使用率指標に対して指標ベースのアラートポリシーを作成し、しきい値を上回る条件とし、値を 0.8 に設定します。詳細については、指標ベースのアラートポリシーを作成するをご覧ください。
CPU の過剰使用を防ぎます。	使用可能な CPU のうちインスタンスが使用している割合は、Google Cloud コンソールのインスタンスの詳細ページで確認できます。詳細については、指標をご覧ください。また、指標しきい値のアラートポリシーを作成するを使用して、CPU 使用率をモニタリングし、指定したしきい値でアラートを受信することもできます。過剰な使用を回避するためには、インスタンスの CPU 数を増やします。CPU 数を変更するには、インスタンスの再起動が必要です。インスタンスがすでに CPU の最大数に達している場合は、データベースを複数のインスタンスにシャーディングする必要があります。
メモリ不足を回避します。	メモリ不足の兆候を調べる際は、主に使用量指標を使用してください。メモリ不足のエラーを回避するには、この指標を 90% 未満に保つことをおすすめします。また、総使用量指標を使用すると、データベースコンテナが使用しているメモリやオペレーティングシステムのキャッシュが割り当てたメモリなどを含め、Cloud SQL インスタンスで使用されている使用可能なメモリの割合を確認できます。これら 2 つの指標の差を観察することで、プロセスによって使用されているメモリの量と、オペレーティングシステムのキャッシュで使用されているメモリの量を把握できます。このキャッシュ内のメモリは再利用できます。メモリ不足の問題を予測するには、両方の指標を確認してまとめて解釈します。指標が高い場合は、インスタンスのメモリが不足している場合があります。要因としては、カスタム構成によるもの、ワークロードに対してインスタンスのサイズが小さすぎる場合、またはこれらの要因の組み合わせの可能性があります。 Cloud SQL インスタンスをスケーリングしてメモリのサイズを増やします。インスタンスのメモリサイズを変更するには、インスタンスを再起動する必要があります。インスタンスがすでに最大メモリサイズに達している場合は、データベースを複数のインスタンス間でシャーディングする必要があります。Google Cloud コンソールで両方の指標をモニタリングする方法について、詳細は指標をご覧ください。
Cloud SQL で最適に動作するよう SQL Server を設定してください。	SQL Server の設定をご覧ください。
テスト実行に合わせてインスタンスを最適に調整してください。	次の表は、テスト実行に適した構成値を示しています。 vCPU: `40` メモリ: `262144 MB` MAXDOP: `8` 並列処理のコストしきい値: `120` tempdb ファイル: `8`。自動拡張を防ぐために事前にサイズが設定されます。ユーザーデータベースファイル: 自動拡張は `64-128` MB に設定されています。自動拡張を防ぐために事前にサイズが設定されます。ストレージ: `>= 4TB`（最適な IOPS を実現したい場合）
SQL Server をデプロイする前に、I/O サブシステムの容量を決定してください。	さまざまな 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 キューの深さを実現します。
インデックスの断片化やインデックスの欠落を防ぎます。	データの変更頻度に応じて、インデックスを再編成するか、インデックスを再構築するようにスケジュールを設定します。また、断片化を減らすために適切なフィルファクタを設定します。SQL Server でインデックスの欠落をモニタリングします。これを防ぐことでパフォーマンスが向上する可能性があります。
統計情報を定期的に更新してください。	統計情報が古くなっている場合、SQL クエリオプティマイザーによって最適ではないクエリプランが生成される可能性があります。特に、大量のデータが変更された後は、統計情報を更新するようにしてください。クエリストアを使用して、最適ではないクエリプランを持つ SQL Server をモニタリングし、トラブルシューティングします。
データベースファイルが不必要に大きくなるのを防ぎます。	`autogrow` を割合ではなく MB 単位で設定します。要件に合わせて最適な増分量を設定します。また、自動拡張が開始する前に、量の増加をプロアクティブに管理します。さらに、Cloud SQL でストレージの自動増量を有効にする機能を有効にして、データベースとインスタンスの空き容量が不足している場合に Cloud SQL が保存容量を追加できるようにします。
データベースの整合性の問題を検出するには、少なくとも 1 週間に 1 度、`DBCC CHECKDB` を実行します。	`DBCC CHECKDB` は、データベース内のすべてのオブジェクトの整合性をチェックします。`DBCC CHECKDB` を毎週実行することで、データベースが破損していないことを確認できます。`DBCC CHECKDB` はリソースを大量に消費するオペレーションであり、インスタンスのパフォーマンスに影響する可能性があります。本番環境サーバーで `DBCC CHECKDB` を実行しないでください。本番環境サーバーで `DBCC CHECKDB` を実行する代わりに、次のいずれかのオプションを使用することをおすすめします。データベースのクローンを作成し、そのクローンデータベースに対して `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

データアーキテクチャ

ベストプラクティス	詳細
大規模なインスタンスを、可能な限り小規模なインスタンスに分割します。	可能であれば、大規模なインスタンスを 1 つ使用するより、小規模な Cloud SQL インスタンスを多数使用することをおすすめします。大規模なモノリシックインスタンスを管理する場合、小規模なインスタンスグループでは生じない問題に直面します。
あまりに多くのデータベーステーブルを使用しないでください。	インスタンスのテーブル数を常に 10,000 個未満にします。データベーステーブルが多すぎると、データベースのアップグレードに時間がかかる可能性があります。
データベースの照合	SQL Server の新しいインスタンスのインストール、データベースのバックアップの復元、サーバーとクライアントデータベースの接続のいずれにおいても、使用するデータのロケール要件、並べ替え順序、大文字と小文字の区別を理解しておくことが重要です。サーバー、データベース、列、または式に対して照合を選択すると、データに特定の特性が割り当てられます。これらの特性は、データベースでの多くのオペレーションの結果に影響します。たとえば、`ORDER BY` を使用してクエリを作成するときに、結果セットの並べ替え順序は、データベースに適用される照合順序や、`COLLATE` 句で指定される照合順序によって異なる場合があります。詳細については、データベース照合と Unicode のサポートをご覧ください。
クエリの設計	データベースまたはクエリのパフォーマンスを最適化するため、同じクエリ内で多数のテーブル（16 個以上）を使用していないことを確認します。
クエリのモニタリング	クエリは時間の経過とともに劣化する場合があります。アプリケーションとクエリのパフォーマンスを継続してモニタリングすることが重要です。劣化する理由の一つはハッシュベイルアウトです。再帰的なハッシュ結合やハッシュベイルアウトはサーバーのパフォーマンスを低下させます。トレースにハッシュ警告イベントが多数含まれている場合は、結合されている列の統計情報を更新します。詳しくは、ハッシュベイルアウトをご覧ください。

アプリケーションの実装

ベストプラクティス	詳細
接続プーリングや指数バックオフなどの適切な接続管理方法を使用してください。	これらの手法は、アプリケーションのリソース使用を効率化して Cloud SQL の接続上限内に収めるのに役立ちます。詳細とコードサンプルについては、データベース接続の管理をご覧ください。
メンテナンスの時間枠内でいつでも発生する可能性があるメンテナンス更新に対するアプリケーションのレスポンスをテストしてください。	セルフサービスメンテナンスを試して、メンテナンス更新をシミュレートします。メンテナンス中は、インスタンスが一時的に使用できなくなり、既存の接続が切断されます。メンテナンスロールアウトをテストすることで、アプリケーションによる定期メンテナンスの処理方法や、システムを迅速に復旧する方法を確認できます。
いつでも発生する可能性があるフェイルオーバーに対するアプリケーションのレスポンスをテストしてください。	Google Cloud コンソール、gcloud CLI、または API を使用すると、手動でフェイルオーバーを開始できます。フェイルオーバーの開始をご覧ください。
大規模なトランザクションは回避します。	トランザクションのサイズを小さくして、短時間で終わるようにしてください。大規模なデータベース更新が必要な場合は、1 つの大規模なトランザクションではなく、複数の小規模なトランザクションを使用してください。
Cloud SQL Auth Proxy を使用している場合は、必ず最新のバージョンを使用してください。	Cloud SQL Auth Proxy の最新状態の維持をご覧ください。

データのインポートとエクスポート

ベストプラクティス	詳細
小規模なインスタンスのインポートを高速化してください。	小規模なインスタンスでは、一時的にインスタンスの CPU と RAM を追加して、大規模なデータセットをインポートする際のパフォーマンスを強化できます。
Cloud SQL にインポートするデータをエクスポートする場合は、適切な手順を使用してください。	外部管理データベースサーバーからデータをエクスポートするをご覧ください。

バックアップとリカバリ

ベストプラクティス	詳細
適切な Cloud SQL 機能を使用してデータを保護してください。	バックアップとエクスポートは、データの冗長性を確保して保護するための方法です。これらは異なるシナリオでそれぞれ機能し、堅牢なデータ保護戦略でお互いを補います。バックアップは簡単で、インスタンスのデータをバックアップ作成時の状態に復元する手段を提供します。ただし、バックアップにはいくつかの制限があります。インスタンスを削除すると、バックアップも削除されます。単一のデータベースまたはテーブルをバックアップすることはできません。また、インスタンスが配置されているリージョンを使用できない場合、使用可能なリージョンにあるバックアップからそのインスタンスを復元することはできません。データの再作成に使用できる外部ファイルが 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 Storage に作成されるため、エクスポートは作成するのに時間がかかります。インスタンスを削除しても、エクスポートは影響を受けません。また、選択するエクスポート形式に応じて、単一のデータベースまたはテーブルだけをエクスポートすることもできます。

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

インスタンスとバックアップを誤って削除しないように保護します。

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

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

SQL Server の設定

Cloud SQL には SQL Server の一部の設定が推奨されています。以下のトピックでは、いくつかの推奨事項について説明します。

グローバル構成設定

設定推奨事項

max worker threads デフォルト値の 0 のままにします。この設定は、CPU の数に基づいて SQL Server で使用可能なスレッド数を定義します。この値は、起動時に SQL Server エンジンによって自動的に計算されます。

max server memory (MB)

このフラグは、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 の割合を示します。

インスタンス階層（MB）	サーバーの最大メモリ（MB）	%（合計）
3840	1440	37
4096	1632	39
5792	2912	50
8192	4704	57
11584	7248	62
16384	10848	66
23168	16800	72
32768	25200	76
46336	37072	80
65568	53888	82
92704	77648	83
131136	111248	84
185440	158784	85
262272	226000	86
370880	321056	86
524544	455488	86
741792	645600	87

インスタンスのメモリ使用量をモニタリングするには、次の指標を使用します。

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 Server データベースのパフォーマンスを最適化するには、次に示す SQL Server 設定をおすすめします。

設定	推奨事項
`cost threshold for parallelism`	これは、SQL オプティマイザーが並列処理でクエリを実行する場合のしきい値です。デフォルト値の `5` では、並列で実行されるクエリが多すぎるため、並列スレッドでのデータベースの待機時間が長くなります。このタイプの競合を減らすには、値を大きくします。 `maxdop` が `1` に設定されている場合、値は無視されます。
`max degree of parallelism (MAXDOP)`	並列処理によるデータベースの待機時間を短縮するには、使用可能な論理プロセッサの数に関する具体的な推奨事項に基づいて、この値を調整します。このオプションを 1 に設定すると、パフォーマンスが慎重に測定されます。
`optimize for ad hoc workloads`	プランのキャッシュに、単回使用のプランを多数設定しないでください。単回使用のアドホックバッチを多く含むワークロードでプランキャッシュの効率を向上させるには、このオプションを `1` に設定します。
`tempdb`	自動拡張が不要になるように、`tempdb` のサイズを事前に設定します。`tempdb` 内のファイルはすべて同じサイズで、ファイル拡張も同じにする必要があります。 `tempdb` 競合が発生した場合のデータベースの待機タイプは、`PAGELATCH_UP` のように表示されます。競合を減らすには、さらにファイルを追加します。プロセッサの数が 8 以下の場合は、論理プロセッサと同じファイル数を使用します。プロセッサ数が 8 を超える場合は、8 個のデータファイルを使用します。競合が解決しない場合は、競合が発生しなくなるまでファイルの数を増やします（4 の倍数になるように増やします）。

ワークロードによっては、次の設定も変更することをおすすめします。

設定	推奨事項
`Close Cursor on Commit Enabled`	デフォルト値は `off` です。これは、トランザクションを commit してもカーソルは自動的にクローズしないことを意味します。
`Default Cursor`	このオプションは、T-SQL コードで使用されるカーソルのスコープを制御します。この設定を変更する場合は、アプリケーションコードに悪影響がないかどうかを評価してください。
`Page Verify`	このオプションを使用すると、SQL Server がディスクに書き込みを行う前にデータベースページのチェックサムを計算し、ページヘッダーに格納できます。ページを再度読み込むと、チェックサムが再計算され、ページの整合性が検証されます。推奨値は `checksum` です。
`Parameterization`	デフォルト値は `simple` です。SQL Server では、シンプルなパラメータ化により、クエリ内のリテラル値をパラメータに置換できます。Microsoft は、この値の変更方法やプランガイドで使用する方法に関するガイドラインを提供しています。

保持するデータベース設定

SQL Server データベースのパフォーマンスを最適化するには、次の SQL Server の設定のデフォルト値をそのまま使用します。

設定	保持するデフォルト値
`Auto Close`	`False`。この設定をオンにすると、接続を開始または終了します。また、接続のたびにプロシージャがフラッシュされます。アクセス頻度が高いデータベースでは、パフォーマンスが低下する可能性があります。
`Auto Shrink`	`False`。これをオンにすると、データベースとインデックスの断片化やその他のパフォーマンスの問題が発生する可能性があります。その他の問題の詳細については、SQL Server のブログをご覧ください。
`Date Correlation Optimization Enabled`	`False`。これを有効にすると、オプティマイザーが関連する 2 つのテーブル間の日付関係を検出し、最適化します。SQL Server でこれを追跡すると、パフォーマンスのオーバーヘッドが発生します。
`Legacy Cardinality Estimation`	`False`。この設定を有効にすると、SQL Server がカーディナリティを正確に計算できない場合があります。
`Parameter Sniffing`	`ON`。データベーステーブルからパラメータスニッフィングを使用すると、再利用可能な実行計画を作成できます。テーブルのデータが均等に分散していない場合、結果として作成された実行計画でパフォーマンスの問題が発生する可能性があります。このようなデータの場合は、この設定を変更するのではなく、クエリストアの他のオプションを使用してください。
`Query Optimizer Fixes`	`False`。有効にすると、SQL Server カーディナリティ推定のパフォーマンスに影響する可能性があります。有効にする場合は、クエリ回帰がないことをテストで確認します。
`Auto Create Statistics`	`True`。このオプションを使用すると、SQL Server はクエリプランのカーディナリティの推測値を改善できる単一列の統計情報を作成できます。
`Auto Update Statistics`	`True`。このオプションを使用すると、SQL Server は、テーブルのカーディナリティに基づく再コンパイルのしきい値を使用して、古い統計情報を更新します。
`Auto Update Statistics Asynchronously`	`False`。このオプションを有効にすると、現在のクエリ実行に古い統計情報を使用し、将来のワークロードに役立つように統計情報を非同期で更新するように SQL クエリオプティマイザーに指示します。ただし、頻繁に実行されるクエリの応答時間が予想される場合や、統計情報の更新を待機している間にクライアントリクエストのタイムアウトが頻繁に発生する場合は、このオプションを有効にして `Auto Update Statistics` を無効にすることを検討してください。
`Target Recovery Time (Seconds)`	`60`。この設定は、ダーティページをバッファプールからディスクにフラッシュする頻度を増減させることにより、データベースの復旧時間の上限を設定します。トランザクションの多いワークロードで、この設定値が低いと、最大値に近いストレージ IOPS が発生したときにパフォーマンスのボトルネックになる可能性があります。

トレースフラグの設定

SQL Server のトレースフラグは、特定の特性の設定、SQL Server データベースの動作の変更、SQL Server の問題のデバッグに使用されます。

一部の SQL Server トレースフラグは Cloud SQL でサポートされており、データベースフラグで設定できます。推奨される設定は次のとおりです。

トレースフラグ	推奨
`1204`	`Yes`。ただし、デッドロックが頻発するほどワークロードの負荷が高いサーバーは除きます。デッドロックに関与しているロックのリソースとタイプ、現在影響を受けるコマンドを返します。
`1222`	`Yes`。ただし、デッドロックが頻発するほどワークロードの負荷が高いサーバーは除きます。
`1224`	`No`。これにより、メモリ使用量が増加し、データベースのメモリを圧迫する原因となります。
`2528`	`No`。オブジェクトの並列チェックがデフォルトで、これが推奨の設定です。並列度は、データベースエンジンによって自動的に計算されます。
`3205`	`No`。バックアップ用テープドライブは Cloud SQL for SQL Server の機能です。
`3226`	`No`。ただし、TLOG バックアップなど、頻繁なバックアップが必要な場合を除きます。
`3625`	`No`。root アカウントにはシステム管理者権限がないため、一部のエラーメッセージを表示できない場合があります。
`4199`	`No`。これはカーディナリティ推定に影響し、クエリの回帰につながる可能性があります。
`4616`	`No`。この制限により、アプリケーションロールのセキュリティが低下します。アプリケーションの要件に基づいて検証する必要があります。
`7806`	`Yes`。データベースサーバーが応答しなくなった場合、診断用の接続を確立する際に専用管理者接続（DAC）が唯一の方法になることがあります。

次のステップ

データベースエンジンによる一般的なプラクティスの詳細については、以下をご覧ください。