高密度エラスティック プールでのリソース管理Resource management in dense elastic pools

適用対象: Azure SQL Database

Azure SQL Database のエラスティック プールは、リソース使用量が異なる多数のデータベースを管理するためのコスト効果の高いソリューションです。Azure SQL Database elastic pools is a cost-effective solution for managing many databases with varying resource usage. 特定の時点では プール内のデータベースのサブセットのみがコンピューティング リソースを使用する という前提で、エラスティック プール内のすべてのデータベースにより、CPU、メモリ、ワーカー スレッド、ストレージ スペース、tempdb などのリソースの同じ割り当てが共有されます。All databases in an elastic pool share the same allocation of resources, such as CPU, memory, worker threads, storage space, tempdb, on the assumption that only a subset of databases in the pool will use compute resources at any given time . この前提により、エラスティック プールのコスト効率が高くなります。This assumption allows elastic pools to be cost-effective. お客様は、個々のデータベースで必要になる可能性のあるすべてのリソースに対して料金を支払うのではなく、プール内のすべてのデータベース間で共有される、はるかに少ないリソースのセットに対して支払います。Instead of paying for all resources each individual database could potentially need, customers pay for a much smaller set of resources, shared among all databases in the pool.

リソース管理Resource governance

リソースを共有するには、リソース消費量の多いデータベースによって同じエラスティック プール内の他のデータベースが影響を受ける "迷惑な隣人" 効果を最小限にするため、システムでリソースの使用量を慎重に制御する必要があります。Resource sharing requires the system to carefully control resource usage to minimize the "noisy neighbor" effect, where a database with high resource consumption affects other databases in the same elastic pool. 同時に、高可用性とディザスター リカバリー (HADR)、バックアップと復元、監視、クエリ ストア、自動チューニングなどの機能が確実に機能するよう、システムで十分なリソースを提供する必要があります。At the same time, the system must provide sufficient resources for features such as high availability and disaster recovery (HADR), backup and restore, monitoring, Query Store, Automatic tuning, etc. to function reliably.

Azure SQL Database では、これらの目標を達成するために、複数のリソース ガバナンス メカニズムが使用されます。これには、プロセス レベルのリソース ガバナンスのための Windows のジョブ オブジェクト、ストレージ クォータ管理のための Windows のファイル サーバー リソース マネージャー (FSRM)、Azure SQL Database 内にリソース ガバナンスを実装するための SQL Server の Resource Governor が変更および拡張されたバージョンが含まれます。Azure SQL Database achieves these goals by using multiple resource governance mechanisms, including Windows Job Objects for process level resource governance, Windows File Server Resource Manager (FSRM) for storage quota management, and a modified and extended version of SQL Server Resource Governor to implement resource governance within SQL Database.

エラスティック プールの主な設計目標は、優れたコスト効率です。The primary design goal of elastic pools is to be cost-effective. このため、システムは意図的に、" 高密度 " のプールを作成できるようになっています。これは、データベースの数が許容される上限に近いか達していても、コンピューティング リソースの割り当てが適度であるようなプールです。For this reason, the system intentionally allows customers to create dense pools, that is pools with the number of databases approaching or at the maximum allowed, but with a moderate allocation of compute resources. 同じ理由から、システムでは、必要なすべてのリソースが内部プロセス用に予約されるのではなく、内部プロセスとユーザー ワークロードでリソースを共有できるようになっています。For the same reason, the system doesn't reserve all potentially needed resources for its internal processes, but allows resource sharing between internal processes and user workloads.

この方法により、お客様は、高密度エラスティック プールを使用して、適切なパフォーマンスと大幅なコスト削減を実現できます。This approach allows customers to use dense elastic pools to achieve adequate performance and major cost savings. ただし、高密度プール内の多数のデータベースに対するワークロードにかなりの負荷がかかっている場合、リソースの競合が大きくなります。However, if the workload against many databases in a dense pool is sufficiently intense, resource contention becomes significant. リソースが競合すると、ユーザー ワークロードのパフォーマンスが低下し、内部プロセスに悪影響を及ぼす可能性があります。Resource contention reduces user workload performance, and can negatively impact internal processes.

重要

アクティブなデータベースが多数ある高密度プールでは、プール内のデータベースの数を、DTU および仮想コアのエラスティック プールについて記載された最大数まで増やすことができない可能性があります。In dense pools with many active databases, it may not be feasible to increase the number of databases in the pool up to the maximums documented for DTU and vCore elastic pools.

リソースの競合やパフォーマンスの問題を発生させることなく高密度プールに配置できるデータベースの数は、同時にアクティブになっているデータベースの数と、各データベースのユーザー ワークロードによるリソース消費量によって決まります。The number of databases that can be placed in dense pools without causing resource contention and performance problems depends on the number of concurrently active databases, and on resource consumption by user workloads in each database. この数は、ユーザー ワークロードの変化に応じて変わる可能性があります。This number can change over time as user workloads change.

高密度のプールでリソースの競合が発生する場合、お客様は次の 1 つまたは複数の操作を選択して軽減できます。When resource contention occurs in a densely packed pool, customers can choose one or more of the following actions to mitigate it:

  • クエリ ワークロードを調整してリソースの消費量を減らすか、時間の経過に応じて複数のデータベース間でリソース消費を分散します。Tune query workload to reduce resource consumption, or spread resource consumption across multiple databases over time.
  • 一部のデータベースを別のプールに移動するか、スタンドアロン データベースにすることにより、プールの密度を下げます。Reduce pool density by moving some databases to another pool, or by making them standalone databases.
  • プールをスケールアップしてリソースを増やします。Scale up the pool to get more resources.

最後の 2 つの操作の実装方法については、この記事の後半にある「運用に関する推奨事項」を参照してください。For suggestions on how to implement the last two actions, see Operational recommendations later in this article. リソースの競合を減らすと、ユーザーのワークロードと内部プロセスの両方にメリットがあり、システムで予想されるサービス レベルを確実に維持できます。Reducing resource contention benefits both user workloads and internal processes, and lets the system reliably maintain expected level of service.

リソース消費量の監視Monitoring resource consumption

高密度エラスティック プールを使用しているお客様は、リソースの競合によるパフォーマンスの低下を回避するため、リソースの消費を予防的に監視し、リソースの競合の増加がワークロードに影響を与え始めたらタイムリーに対処する必要があります。To avoid performance degradation due to resource contention, customers using dense elastic pools should proactively monitor resource consumption, and take timely action if increasing resource contention starts affecting workloads. ユーザーのワークロードの変化、データの量と分散の変化、プールの密度の変更、Azure SQL Database サービスの変更などにより、プール内のリソースの使用量は時間と共に変化するため、継続的に監視することが重要です。Continuous monitoring is important because resource usage in a pool changes over time, due to changes in user workload, changes in data volumes and distribution, changes in pool density, and changes in the Azure SQL Database service.

Azure SQL Database では、この種の監視に関連する複数のメトリックが提供されています。Azure SQL Database provides several metrics that are relevant for this type of monitoring. メトリックごとに推奨されている平均値を超えた場合は、プール内のリソースの競合を示しており、前述の操作のいずれかを使用して対処する必要があります。Exceeding the recommended average value for each metric indicates resource contention in the pool, and should be addressed using one of the actions mentioned earlier.

メトリックの名前Metric name 説明Description 推奨される平均値Recommended average value
avg_instance_cpu_percent エラスティック プールに関連付けられている SQL プロセスの CPU 使用率。基になるオペレーティング システムによって測定されます。CPU utilization of the SQL process associated with an elastic pool, as measured by the underlying operating system. すべてのデータベースの sys.dm_db_resource_stats ビュー、および master データベースの sys.elastic_pool_resource_stats ビューで使用できます。Available in the sys.dm_db_resource_stats view in every database, and in the sys.elastic_pool_resource_stats view in the master database. このメトリックは Azure Monitor にも出力され (sqlserver_process_core_percent という名前で)、Azure portal で表示できます。This metric is also emitted to Azure Monitor, where it is named sqlserver_process_core_percent, and can be viewed in Azure portal. この値は、同じエラスティック プール内のすべてのデータベースについて同じです。This value is the same for every database in the same elastic pool. 70% 未満。Below 70%. 90% までの短時間の急増がときどき発生するのは、許容される場合があります。Occasional short spikes up to 90% may be acceptable.
max_worker_percent ワーカー スレッドの使用率。Worker thread utilization. プール内の各データベースおよびプール自体に対して提供されます。Provided for each database in the pool, as well as for the pool itself. ワーカー スレッド数の制限はデータベース レベルとプール レベルで異なるため、両方のレベルでこのメトリックを監視することをお勧めします。There are different limits on the number of worker threads at the database level, and at the pool level, therefore monitoring this metric at both levels is recommended. すべてのデータベースの sys.dm_db_resource_stats ビュー、および master データベースの sys.elastic_pool_resource_stats ビューで使用できます。Available in the sys.dm_db_resource_stats view in every database, and in the sys.elastic_pool_resource_stats view in the master database. このメトリックは Azure Monitor にも出力され (workers_percent という名前で)、Azure portal で表示できます。This metric is also emitted to Azure Monitor, where it is named workers_percent, and can be viewed in Azure portal. 80% 未満。Below 80%. 100% まで急増すると、接続の試行とクエリが失敗します。Spikes up to 100% will cause connection attempts and queries to fail.
avg_data_io_percent 読み取りおよび書き込みの物理 IO に対する IOPS 使用率。IOPS utilization for read and write physical IO. プール内の各データベースおよびプール自体に対して提供されます。Provided for each database in the pool, as well as for the pool itself. IOPS の値の制限はデータベース レベルとプール レベルで異なるため、両方のレベルでこのメトリックを監視することをお勧めします。There are different limits on the number of IOPS at the database level, and at the pool level, therefore monitoring this metric at both levels is recommended. すべてのデータベースの sys.dm_db_resource_stats ビュー、および master データベースの sys.elastic_pool_resource_stats ビューで使用できます。Available in the sys.dm_db_resource_stats view in every database, and in the sys.elastic_pool_resource_stats view in the master database. このメトリックは Azure Monitor にも出力され (physical_data_read_percent という名前で)、Azure portal で表示できます。This metric is also emitted to Azure Monitor, where it is named physical_data_read_percent, and can be viewed in Azure portal. 80% 未満。Below 80%. 100% までの短時間の急増がときどき発生するのは、許容される場合があります。Occasional short spikes up to 100% may be acceptable.
avg_log_write_percent トランザクション ログ書き込み IO に対するスループットの使用率。Throughput utilizations for transaction log write IO. プール内の各データベースおよびプール自体に対して提供されます。Provided for each database in the pool, as well as for the pool itself. ログ スループットの制限はデータベース レベルとプール レベルで異なるため、両方のレベルでこのメトリックを監視することをお勧めします。There are different limits on the log throughput at the database level, and at the pool level, therefore monitoring this metric at both levels is recommended. すべてのデータベースの sys.dm_db_resource_stats ビュー、および master データベースの sys.elastic_pool_resource_stats ビューで使用できます。Available in the sys.dm_db_resource_stats view in every database, and in the sys.elastic_pool_resource_stats view in the master database. このメトリックは Azure Monitor にも出力され (log_write_percent という名前で)、Azure portal で表示できます。This metric is also emitted to Azure Monitor, where it is named log_write_percent, and can be viewed in Azure portal. このメトリックが 100% に近づくと、すべてのデータベースの変更 (INSERT、UPDATE、DELETE、MERGE ステートメント、SELECT...When this metric is close to 100%, all database modifications (INSERT, UPDATE, DELETE, MERGE statements, SELECT … INTO、BULK INSERT など) が遅くなります。INTO, BULK INSERT, etc.) will be slower. 90% 未満。Below 90%. 100% までの短時間の急増がときどき発生するのは、許容される場合があります。Occasional short spikes up to 100% may be acceptable.
oom_per_second エラスティック プールでのメモリ不足 (OOM) エラーの割合。これは、メモリ負荷のインジケーターです。The rate of out-of-memory (OOM) errors in an elastic pool, which is an indicator of memory pressure. sys.dm_resource_governor_resource_pools_history_ex ビューで使用できます。Available in the sys.dm_resource_governor_resource_pools_history_ex view. このメトリックを計算するサンプル クエリについては、「」を参照してください。See Examples for a sample query to calculate this metric. 00
avg_storage_percent エラスティック プール内のすべてのデータベースのデータによって使用される記憶領域の合計。Total storage space used by data in all databases within an elastic pool. データベース ファイル内の空き領域は含まれません。Does not include empty space in database files. master データベースの sys.elastic_pool_resource_stats ビューで使用できます。Available in the sys.elastic_pool_resource_stats view in the master database. このメトリックは Azure Monitor にも出力され (storage_percent という名前で)、Azure portal で表示できます。This metric is also emitted to Azure Monitor, where it is named storage_percent, and can be viewed in Azure portal. 80% 未満。Below 80%. データが増加しないプールの場合、100% に近くなってもかまいません。Can approach 100% for pools with no data growth.
avg_allocated_storage_percent エラスティック プール内のすべてのデータベースに格納されているデータベース ファイルによって使用される記憶領域の合計。Total storage space used by database files in storage in all databases within an elastic pool. データベース ファイル内の空き領域が含まれます。Includes empty space in database files. master データベースの sys.elastic_pool_resource_stats ビューで使用できます。Available in the sys.elastic_pool_resource_stats view in the master database. このメトリックは Azure Monitor にも出力され (allocated_data_storage_percent という名前で)、Azure portal で表示できます。This metric is also emitted to Azure Monitor, where it is named allocated_data_storage_percent, and can be viewed in Azure portal. 90% 未満。Below 90%. データが増加しないプールの場合、100% に近くなってもかまいません。Can approach 100% for pools with no data growth.
tempdb_log_used_percent tempdb データベースのトランザクション ログ領域使用率。Transaction log space utilization in the tempdb database. 1 つのデータベースに作成される一時オブジェクトは同じエラスティック プール内の他のデータベースに認識されませんが、tempdb は同じプール内のすべてのデータベースの共有リソースです。Even though temporary objects created in one database are not visible in other databases in the same elastic pool, tempdb is a shared resource for all databases in the same pool. プール内の 1 つのデータベースから tempdb で開始された、実行時間の長いトランザクションまたは孤立したトランザクションにより、トランザクション ログの大部分が消費され、同じプール内の他のデータベースのクエリが失敗する可能性があります。A long running or orphaned transaction in tempdb started from one database in the pool can consume a large portion of transaction log, and cause failures for queries in other databases in the same pool. sys.dm_db_log_space_usage ビュー、および sys.database_files ビューから派生します。Derived from sys.dm_db_log_space_usage and sys.database_files views. このメトリックは Azure Monitor にも出力され、Azure portal で表示できます。This metric is also emitted to Azure Monitor, and can be viewed in Azure portal. このメトリックの現在の値を返すサンプル クエリについては、「」を参照してください。See Examples for a sample query to return the current value of this metric. 50% 未満。Below 50%. 散発的な 80% までの急増が許容されます。Occasional spikes up to 80% are acceptable.

これらのメトリックに加えて、Azure SQL Database には、実際のリソース ガバナンスの制限を返すビューや、リソース プール レベルおよびワークロード グループ レベルでのリソース使用率の統計を返す追加のビューが用意されています。In addition to these metrics, Azure SQL Database provides a view that returns actual resource governance limits, as well as additional views that return resource utilization statistics at the resource pool level, and at the workload group level.

ビューの名前View name 説明Description
sys.dm_user_db_resource_governancesys.dm_user_db_resource_governance 現在のデータベースまたはエラスティック プールのリソース ガバナンス メカニズムによって使用されている実際の構成と容量の設定が返されます。Returns actual configuration and capacity settings used by resource governance mechanisms in the current database or elastic pool.
sys.dm_resource_governor_resource_poolssys.dm_resource_governor_resource_pools 現在のリソース プールの状態、リソース プールの現在の構成、およびリソース プールの累積統計に関する情報が返されます。Returns information about the current resource pool state, the current configuration of resource pools, and cumulative resource pool statistics.
sys.dm_resource_governor_workload_groupssys.dm_resource_governor_workload_groups ワークロード グループの累積統計と、ワークロード グループの現在の構成が返されます。Returns cumulative workload group statistics and the current configuration of the workload group. このビューを pool_id 列の sys.dm_resource_governor_resource_pools と結合して、リソース プールの情報を取得できます。This view can be joined with sys.dm_resource_governor_resource_pools on the pool_id column to get resource pool information.
sys.dm_resource_governor_resource_pools_history_exsys.dm_resource_governor_resource_pools_history_ex 過去 32 分間のリソース プール使用率の統計が返されます。Returns resource pool utilization statistics for the last 32 minutes. 各行は 20 秒間隔を表します。Each row represents a 20-second interval. delta_ 列では、間隔の間の各統計の変化が返されます。The delta_ columns return the change in each statistic during the interval.
sys.dm_resource_governor_workload_groups_history_exsys.dm_resource_governor_workload_groups_history_ex 過去 32 分間のワークロード グループ使用率の統計が返されます。Returns workload group utilization statistics for the last 32 minutes. 各行は 20 秒間隔を表します。Each row represents a 20-second interval. delta_ 列では、間隔の間の各統計の変化が返されます。The delta_ columns return the change in each statistic during the interval.

これらのビューを使って、リソースの使用率を監視し、ほぼリアルタイムでリソースの競合のトラブルシューティングを行うことができます。These views can be used to monitor resource utilization and troubleshoot resource contention in near real-time. プライマリ レプリカおよび読み取り可能なセカンダリ レプリカ (geo レプリカを含む) のユーザー ワークロードは、SloSharedPool1 リソース プールと UserPrimaryGroup.DBId[N] ワークロード グループに分類されます。N はデータベース ID の値を表します。User workload on the primary and readable secondary replicas, including geo-replicas, is classified into the SloSharedPool1 resource pool and UserPrimaryGroup.DBId[N] workload group, where N stands for the database ID value.

高密度プールを使用しているお客様は、現在のリソース使用率を監視するだけでなく、リソース使用率の履歴データを別のデータ ストアに保持することもできます。In addition to monitoring current resource utilization, customers using dense pools can maintain historical resource utilization data in a separate data store. このデータを予測分析に使用し、過去および季節の傾向に基づいてリソース使用率を事前に管理できます。This data can be used in predictive analysis to proactively manage resource utilization based on historical and seasonal trends.

運用に関する推奨事項Operational recommendations

リソースに十分な余裕を残しておくLeave sufficient resource headroom . リソースの競合とパフォーマンスの低下が発生した場合の軽減策としては、前に説明したように、影響を受けているエラスティック プールからの一部のデータベースの移動や、プールのスケールアップなどがあります。If resource contention and performance degradation occurs, mitigation may involve moving some databases out of the affected elastic pool, or scaling up the pool, as noted earlier. ただし、これらの操作を完了するには、追加のコンピューティング リソースが必要です。However, these actions require additional compute resources to complete. 特に、Premium プールと Business Critical プールでこれらの操作を行うと、移動するデータベースのすべてのデータを転送したり、プールをスケールアップする場合はエラスティック プール内のすべてのデータベースを転送したりする必要があります。In particular, for Premium and Business Critical pools, these actions require transferring all data for the databases being moved, or for all databases in the elastic pool if the pool is scaled up. データ転送は、実行時間が長く、リソースを大量に消費する操作です。Data transfer is a long running and resource-intensive operation. 既にプールに高いリソース負荷がかかっている場合は、軽減操作自体によってパフォーマンスがさらに低下します。If the pool is already under high resource pressure, the mitigating operation itself will degrade performance even further. 極端なケースでは、必要なリソースを使用できないために、データベースの移動やプールのスケールアップではリソースの競合を解決できない場合さえあります。In extreme cases, it may not be possible to solve resource contention via database move or pool scale-up because the required resources are not available. このような状況では、影響を受けているエラスティック プールのクエリ ワークロードを一時的に減らすことが、唯一の解決策になる場合があります。In this case, temporarily reducing query workload on the affected elastic pool may be the only solution.

高密度プールを使用するお客様は、前に説明したように、リソース使用率の傾向を厳密に監視し、メトリックが推奨範囲内に留まっていて、エラスティック プールに十分なリソースがまだ残っている間に、対策を講じる必要があります。Customers using dense pools should closely monitor resource utilization trends as described earlier, and take mitigating action while metrics remain within the recommended ranges and there are still sufficient resources in the elastic pool.

リソース使用率は、各データベースと各エラスティック プールでの、時間と共に変化する複数の要因に依存します。Resource utilization depends on multiple factors that change over time for each database and each elastic pool. 高密度プールで最適な価格/パフォーマンス比を実現するには、継続的な監視と再調整が必要です。調整では、より使用率の高いプールから使用率の低いプールにデータベースを移動し、ワークロードの増加に対応するために必要に応じて新しいプールを作成します。Achieving optimal price/performance ratio in dense pools requires continuous monitoring and rebalancing, that is moving databases from more utilized pools to less utilized pools, and creating new pools as necessary to accommodate increased workload.

"ホット" データベースを移動しないDo not move "hot" databases . プール レベルでのリソース競合の主な原因が、使用率が高い少数のデータベースである場合、これらのデータベースを使用率の低いプールに移動したり、スタンドアロン データベースにしたりすることがあります。If resource contention at the pool level is primarily caused by a small number of highly utilized databases, it may be tempting to move these databases to a less utilized pool, or make them standalone databases. しかし、データベースの使用率が高い状態の間にこの操作を行うことはお勧めできません。移動操作によって、移動対象のデータベースとプール全体のパフォーマンスがさらに低下するためです。However, doing this while a database remains highly utilized is not recommended, because the move operation will further degrade performance, both for the database being moved, and for the entire pool. 代わりに、使用率が低下するまで待つか、または使用率が低いデータベースを移動して、プール レベルでリソースの負荷を軽減します。Instead, either wait until high utilization subsides, or move less utilized databases instead to relieve resource pressure at the pool level. ただし、使用率が非常に低いデータベースを移動しても、プール レベルでのリソースの使用率はあまり変わらないため、このケースではメリットはありません。But moving databases with very low utilization does not provide any benefit in this case, because it does not materially reduce resource utilization at the pool level.

"検査" プールに新しいデータベースを作成するCreate new databases in a "quarantine" pool . データベースごとのテナント モデルを使用するアプリケーションなど、新しいデータベースが頻繁に作成されるシナリオでは、既存のエラスティック プールに配置された新しいデータベースにより、予期せず、大量のリソースが消費され、プール内の他のデータベースや内部プロセスに影響する可能性があります。In scenarios where new databases are created frequently, such as applications using the tenant-per-database model, there is risk that a new database placed into an existing elastic pool will unexpectedly consume significant resources and affect other databases and internal processes in the pool. このリスクを軽減するには、リソースが十分に割り当てられた "検査" プールを別に作成します。To mitigate this risk, create a separate "quarantine" pool with ample allocation of resources. リソース消費パターンがまだ不明な新しいデータベースには、このプールを使用します。Use this pool for new databases with yet unknown resource consumption patterns. 1 週間や 1 か月など、1 ビジネス サイクルだけデータベースをこのプールに保持すると、そのリソース消費量がわかり、この追加リソース使用量に対応できる十分な容量を持つプールに移動することができます。Once a database has stayed in this pool for a business cycle, such as a week or a month, and its resource consumption is known, it can be moved to a pool with sufficient capacity to accommodate this additional resource usage.

使用済み領域と割り当て済み領域の両方を監視するMonitor both used and allocated space . 割り当て済みのプール領域 (プール内のすべてのデータベースに格納されているすべてのデータベース ファイルの合計サイズ) が最大プール サイズに達すると、領域不足エラーが発生することがあります。When allocated pool space (total size of all database files in storage for all databases in a pool) reaches maximum pool size, out-of-space errors may occur. 割り当て済み領域が高い傾向にあり、最大プール サイズに達しようとしている場合は、軽減策として次のような選択肢があります。If allocated space trends high and is on track to reach maximum pool size, mitigation options include:

  • プールから一部のデータベースを移動して、割り当て済み領域の合計を減らすMove some databases out of the pool to reduce total allocated space
  • データベース ファイルを圧縮して、ファイルに割り当てられた空き領域を削減するShrink database files to reduce empty allocated space in files
  • 最大プール サイズをより大きくしたサービス目標にプールをスケールアップするScale up the pool to a service objective with a larger maximum pool size

使用済みのプール領域 (ファイル内の空き領域を除く、プール内のすべてのデータベースのデータの合計サイズ) が高い傾向にあり、最大プール サイズに達しようとしている場合は、軽減策として次のような選択肢があります。If used pool space (total size of data in all databases in a pool, not including empty space in files) trends high and is on track to reach maximum pool size, mitigation options include:

  • プールから一部のデータベースを移動して、使用済み領域の合計を減らすMove some databases out of the pool to reduce total used space
  • データベースの外部にデータを移動 (アーカイブ) するか、必要なくなったデータを削除するMove (archive) data outside of the database, or delete no longer needed data
  • データ圧縮を実施するImplement data compression
  • 最大プール サイズをより大きくしたサービス目標にプールをスケールアップするScale up the pool to a service objective with a larger maximum pool size

サーバーを過度に高密度にするのを避けるAvoid overly dense servers . Azure SQL Database では、サーバーあたり最大 5,000 個のデータベースがサポートされています。Azure SQL Database supports up to 5000 databases per server. 何千ものデータベースを含むエラスティック プールを使用しているお客様は、データベースの総数をサポートされている上限以下にして、1 台のサーバーに複数のエラスティック プールを配置することを検討できます。Customers using elastic pools with thousands of databases may consider placing multiple elastic pools on a single server, with the total number of databases up to the supported limit. しかし、何千ものデータベースが含まれるサーバーでは、運用上の課題が生じます。However, servers with many thousands of databases create operational challenges. たとえば、ポータルでのデータベースの表示など、サーバー上のすべてのデータベースを列挙する必要がある操作は遅くなります。Operations that require enumerating all databases on a server, for example viewing databases in the portal, will be slower. サーバー レベルのログインやファイアウォール規則の正しくない変更などの操作エラーは、多くのデータベースに影響します。Operational errors, such as incorrect modification of server level logins or firewall rules, will affect a larger number of databases. サーバーを誤って削除すると、削除したサーバー上のデータベースを復旧するために Microsoft サポートによる支援が必要になり、影響を受けるすべてのデータベースで長時間の停止が発生します。Accidental deletion of the server will require assistance from Microsoft Support to recover databases on the deleted server, and will cause a prolonged outage for all affected databases.

サーバーあたりのデータベースの数を、サポートされている最大数より少ない数に制限することをお勧めします。We recommend limiting the number of databases per server to a lower number than the maximum supported. 多くのシナリオでは、サーバーあたり最大 1,000 から 2,000 個のデータベースを使用するのが最適です。In many scenarios, using up to 1000-2000 databases per server is optimal. サーバーを誤って削除する可能性を減らすために、サーバーまたはそのリソース グループに削除ロックを設定することをお勧めします。To reduce the likelihood of accidental server deletion, we recommend placing a delete lock on the server or its resource group.

以前は、同じサーバー上でエラスティック プール内へ、エラスティック プール外へ、またはエラスティック プール間でデータベースを移動する操作を含む特定のシナリオは、サーバー間でデータベースを移動するより高速でした。In the past, certain scenarios involving moving databases in, out, or between elastic pools on the same server were faster than when moving databases between servers. 現在では、すべてのデータベースの移動は、転送元と転送先のサーバーに関係なく、同じ速度で実行されます。Currently, all database moves execute at the same speed regardless of source and destination server.

Examples

メモリ使用率の監視Monitoring memory utilization

このクエリでは、過去 32 分間の各リソース プールの oom_per_second メトリックが計算されます。This query calculates the oom_per_second metric for each resource pool, over the last 32 minutes. このクエリは、エラスティック プール内の任意のデータベースで実行できます。This query can be executed in any database in an elastic pool.

SELECT pool_id,
       name AS resource_pool_name,
       IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
       SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;

tempdb ログ領域の使用率の監視Monitoring tempdb log space utilization

このクエリは、tempdb_log_used_percent メトリックの現在の値を返し、その最大許容サイズを基準として tempdb トランザクション ログの相対的な使用率を示します。This query returns the current value of the tempdb_log_used_percent metric, showing the relative utilization of the tempdb transaction log relative to its maximum allowed size. このクエリは、エラスティック プール内の任意のデータベースで実行できます。This query can be executed in any database in an elastic pool.

SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
           SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
           FROM tempdb.sys.database_files
           WHERE type_desc = N'LOG'
           ) AS df
;

次のステップNext steps