Azure SQL Database におけるデータベース パフォーマンスの監視Monitoring database performance in Azure SQL Database

Azure での SQL データベースのパフォーマンスの監視は、選択したデータベース パフォーマンスのレベルに対するリソース使用率を監視することから始めます。Monitoring the performance of a SQL database in Azure starts with monitoring the resource utilization relative to the level of database performance you choose. DTU ベースの購入モデルまたは仮想コアベースの購入モデル (プレビュー) では、監視することで、データベースに余分な容量があるかどうかや、リソースが上限に達したことで問題が発生しているかどうかを判断でき、さらに、データベースのパフォーマンス レベルとサービス レベルを調整する必要があるかどうかを判断することもできます。Monitoring helps you determine whether your database has excess capacity or is having trouble because resources are maxed out, and then decide whether it's time to adjust the performance level and service tiers of your database in the DTU-based purchasing model or vCore-based purchasing model (preview). データベースの監視には、Azure Portal のグラフィカル ツールや SQL の動的管理ビューを使用できます。You can monitor your database using graphical tools in the Azure portal or using SQL dynamic management views.

ヒント

データベース パフォーマンスの自動監視には、Azure SQL Intelligent Insights を使用します。Use Azure SQL Intelligent Insights for automatic monitoring of your database performance. パフォーマンスの問題が検出されたら、問題の詳細と根本原因分析 (RCA) が記載された診断ログが生成されます。Once a performance issue is detected, a diagnostic log is generated with details and Root Cause Analysis (RCA) of the issue. 可能な場合は、パフォーマンス改善の推奨事項も提供されます。Performance improvement recommendation is provided when possible.

Azure ポータルを使用したデータベースの監視Monitor databases using the Azure portal

Azure Portal では、データベースを選択して [監視] グラフをクリックすると、単一のデータベースの使用率を監視することができます。In the Azure portal, you can monitor a single database’s utilization by selecting your database and clicking the Monitoring chart. これにより、[メトリック] ウィンドウが表示されます。[グラフの編集] ボタンをクリックすると、内容を編集できます。This brings up a Metric window that you can change by clicking the Edit chart button. 次のメトリックを追加します。Add the following metrics:

  • CPU の割合CPU percentage
  • DTU の割合DTU percentage
  • データ IO の割合Data IO percentage
  • データベース サイズの割合Database size percentage

これらのメトリックを追加すると、[監視] グラフでこれらを引き続き確認しながら、[メトリック] ウインドウにさらに詳細な情報を表示することができます。Once you’ve added these metrics, you can continue to view them in the Monitoring chart with more information on the Metric window. 4 つのメトリックはいずれも、データベースの DTU を基準とする平均使用率を示しています。All four metrics show the average utilization percentage relative to the DTU of your database. サービス レベルの詳細については、DTU ベースの購入モデル仮想コアベースの購入モデル (プレビュー) に関する記事を参照してください。See the DTU-based purchasing model and vCore-based purchasing model (preview) articles for more information about service tiers.

データベース パフォーマンスのサービス階層の監視

また、パフォーマンス メトリックに対してアラートを構成することができます。You can also configure alerts on the performance metrics. [メトリック] ウィンドウの [アラートの追加] ボタンをクリックします。Click the Add alert button in the Metric window. ウィザードの指示に従ってアラートを構成します。Follow the wizard to configure your alert. メトリックが特定のしきい値を超えた場合、またはメトリックが特定のしきい値を下回った場合に警告するオプションがあります。You have the option to alert if the metrics exceed a certain threshold or if the metric falls below a certain threshold.

たとえば、データベースのワークロードが増加する見込みの場合、データベースのいずれかのパフォーマンス メトリックが 80% に達すると電子メールのアラートを送信するように構成できます。For example, if you expect the workload on your database to grow, you can choose to configure an email alert whenever your database reaches 80% on any of the performance metrics. このアラートは、1 つ上位のパフォーマンス レベルに切り替えるタイミングを示す早期の警告として使用できます。You can use this as an early warning to figure out when you might have to switch to the next higher performance level.

下位のパフォーマンス レベルにダウングレードできるかどうかを判断するために、パフォーマンス メトリックを利用することもできます。The performance metrics can also help you determine if you are able to downgrade to a lower performance level. たとえば、Standard S2 データベースを使用していて、すべてのパフォーマンス メトリックは、どの時点でもデータベースの平均的な使用率が 10% を超えないとします。Assume you are using a Standard S2 database and all performance metrics show that the database on average does not use more than 10% at any given time. この場合、データベースは Standard S1 で快適に動作します。It is likely that the database will work well in Standard S1. ただし、下位のパフォーマンス レベルへの移行を決定する前に、急上昇や変動するワークロードに注意してください。However, be aware of workloads that spike or fluctuate before making the decision to move to a lower performance level.

DMV を使用したデータベースの監視Monitor databases using DMVs

Portal で公開されているものと同じメトリックを、システム ビューからも利用できます。それは、サーバーの論理 master データベースの sys.resource_stats と、ユーザー データベースの sys.dm_db_resource_stats です。The same metrics that are exposed in the portal are also available through system views: sys.resource_stats in the logical master database of your server, and sys.dm_db_resource_stats in the user database. 詳細度の低いデータをより長い期間で監視する必要がある場合は、sys.resource_stats を使用します。Use sys.resource_stats if you need to monitor less granular data across a longer period of time. 詳細度の高いデータをより短い期間で監視する必要がある場合は、sys.dm_db_resource_stats を使用します。Use sys.dm_db_resource_stats if you need to monitor more granular data within a smaller time frame. 詳細については、Azure SQL Database のパフォーマンス ガイダンスに関する記事を参照してください。For more information, see Azure SQL Database Performance Guidance.

注意

sys.dm_db_resource_stats は、提供終了になった Web および Business Edition データベースで使用された場合、空の結果セットを返します。sys.dm_db_resource_stats returns an empty result set when used in Web and Business edition databases, which are retired.

リソース使用量の監視Monitor resource use

SQL Database Query Performance Insight およびクエリ ストアを使用して、リソースの使用量を監視できます。You can monitor resource usage using SQL Database Query Performance Insight and Query Store.

また、次の 2 つのビューを使用して使用量を監視することもできます。You can also monitor usage using these two views:

sys.dm_db_resource_statssys.dm_db_resource_stats

sys.dm_db_resource_stats ビューは、すべての SQL データベースで使用できます。You can use the sys.dm_db_resource_stats view in every SQL database. sys.dm_db_resource_stats ビューには、サービス レベルに関連した最近のリソース使用率データが表示されます。The sys.dm_db_resource_stats view shows recent resource use data relative to the service tier. CPU、データ IO、ログ書き込み、メモリの平均 (%) が 15 秒ごとに記録され、1 時間保持されます。Average percentages for CPU, data IO, log writes, and memory are recorded every 15 seconds and are maintained for 1 hour.

このビューにはリソース使用率が詳細に表示されるので、現状の分析やトラブルシューティングが目的の場合、最初に sys.dm_db_resource_stats を使用してください。Because this view provides a more granular look at resource use, use sys.dm_db_resource_stats first for any current-state analysis or troubleshooting. たとえば次のクエリは、現在のデータベースの過去 1 時間の平均リソース使用率と最大リソース使用率を表示します。For example, this query shows the average and maximum resource use for the current database over the past hour:

SELECT  
    AVG(avg_cpu_percent) AS 'Average CPU use in percent',
    MAX(avg_cpu_percent) AS 'Maximum CPU use in percent',
    AVG(avg_data_io_percent) AS 'Average data IO in percent',
    MAX(avg_data_io_percent) AS 'Maximum data IO in percent',
    AVG(avg_log_write_percent) AS 'Average log write use in percent',
    MAX(avg_log_write_percent) AS 'Maximum log write use in percent',
    AVG(avg_memory_usage_percent) AS 'Average memory use in percent',
    MAX(avg_memory_usage_percent) AS 'Maximum memory use in percent'
FROM sys.dm_db_resource_stats;  

その他のクエリについては、sys.dm_db_resource_stats の例を参照してください。For other queries, see the examples in sys.dm_db_resource_stats.

sys.resource_statssys.resource_stats

master データベースの sys.resource_stats ビューには、特定のサービス レベルとパフォーマンス レベルで SQL データベースのパフォーマンスを監視するのに役立つ追加情報があります。The sys.resource_stats view in the master database has additional information that can help you monitor the performance of your SQL database at its specific service tier and performance level. データは 5 分ごとに集められ、約 14 日間保持されます。The data is collected every 5 minutes and is maintained for approximately 14 days. このビューは、過去に SQL データベースでリソースがどのように使用されたかを長期にわたり分析する際に役立ちます。This view is useful for a longer-term historical analysis of how your SQL database uses resources.

次のグラフは、Premium データベースの CPU リソース使用率を示しています (P2 パフォーマンス レベル、1 週間における毎時間の使用率)。The following graph shows the CPU resource use for a Premium database with the P2 performance level for each hour in a week. このグラフは月曜日から始まります。5 営業日が経過した後の週末ではアプリケーションの活動が大幅に減っていることがわかります。This graph starts on a Monday, shows 5 work days, and then shows a weekend, when much less happens on the application.

SQL database resource use

このデータから、このデータベースのピーク CPU 負荷は現在のところ、P2 パフォーマンス レベルに対して 50% をわずかに超える CPU 利用率になっていることがわかります (火曜日の昼)。From the data, this database currently has a peak CPU load of just over 50 percent CPU use relative to the P2 performance level (midday on Tuesday). アプリケーションのリソース プロファイルにおいて CPU が支配的要因である場合、P2 がワークロードに常に対処できる最適なパフォーマンス レベルであると決定できます。If CPU is the dominant factor in the application’s resource profile, then you might decide that P2 is the right performance level to guarantee that the workload always fits. 時間の経過と共にアプリケーションの規模が大きくなると予測される場合、アプリケーションがパフォーマンス レベルの制限に達しないように、リソース バッファーを余分に確保しておくことをお勧めします。If you expect an application to grow over time, it's a good idea to have an extra resource buffer so that the application doesn't ever reach the performance-level limit. パフォーマンス レベルを上げると、要求を効果的に処理するための十分な能力がないデータベースで発生するおそれのある、ユーザーに見えるエラーを回避できます。これは特に待機時間が重要な環境に当てはまります。If you increase the performance level, you can help avoid customer-visible errors that might occur when a database doesn't have enough power to process requests effectively, especially in latency-sensitive environments. たとえば、データベース呼び出しの結果に基づいて Web ページを描画するアプリケーションをサポートしているデータベースなどです。An example is a database that supports an application that paints webpages based on the results of database calls.

アプリケーションの種類が異なれば、同じグラフの解釈が異なる場合があります。Other application types might interpret the same graph differently. たとえば、あるアプリケーションで給与データを毎日処理し、同じグラフを生成する場合、P1 パフォーマンス レベルでこの種の "一括ジョブ" モデルに問題なく対応できる可能性があります。For example, if an application tries to process payroll data each day and has the same chart, this kind of "batch job" model might do fine at a P1 performance level. P1 パフォーマンス レベルの DTU は 100 で、P2 パフォーマンス レベルの DTU は 200 です。The P1 performance level has 100 DTUs compared to 200 DTUs at the P2 performance level. P1 パフォーマンス レベルのパフォーマンスは P2 パフォーマンス レベルの半分となります。The P1 performance level provides half the performance of the P2 performance level. このため、P2 における 50% の CPU 使用率は、P1 における 100% の CPU 使用率に相当します。So, 50 percent of CPU use in P2 equals 100 percent CPU use in P1. アプリケーションにタイムアウトがない場合、当日に完了するのであれば、ジョブに 2 時間かかっても 2.5 時間かかっても問題ないものと思われます。If the application does not have timeouts, it might not matter if a job takes 2 hours or 2.5 hours to finish, if it gets done today. このカテゴリのアプリケーションではおそらく、P1 パフォーマンス レベルを利用できます。An application in this category probably can use a P1 performance level. 1 日の中にはリソース使用率が低くなる時間帯があるという事実を利用できます。このため、"大きなピーク" が 1 日のそのような時間帯のいずれかに波及することがあります。You can take advantage of the fact that there are periods of time during the day when resource use is lower, so that any "big peak" might spill over into one of the troughs later in the day. ジョブを毎日定刻に完了できる限り、P1 パフォーマンス レベルがこの種のアプリケーションに適している (コストが削減される) 場合があります。The P1 performance level might be good for that kind of application (and save money), as long as the jobs can finish on time each day.

Azure SQL Database では、各サーバーの master データベースの sys.resource_stats ビューにアクティブなデータベース別のリソース利用情報が公開されます。Azure SQL Database exposes consumed resource information for each active database in the sys.resource_stats view of the master database in each server. テーブルのデータは 5 分おきに集計されます。The data in the table is aggregated for 5-minute intervals. Basic、Standard、Premium のサービス レベルでは、データをテーブルに表示するのに 5 分を超える時間がかかる可能性があります。このため、このデータはほぼリアルタイムの分析よりも過去の分析に役に立ちます。With the Basic, Standard, and Premium service tiers, the data can take more than 5 minutes to appear in the table, so this data is more useful for historical analysis rather than near-real-time analysis. sys.resource_stats ビューに照会すると、データベースの最近の履歴が表示され、選択した予約で必要なときに望ましいパフォーマンスが発揮されたかどうかを検証できます。Query the sys.resource_stats view to see the recent history of a database and to validate whether the reservation you chose delivered the performance you want when needed.

注意

次の例で sys.resource_stats に照会するためには、論理 SQL データベース サーバーの master データベースに接続する必要があります。You must be connected to the master database of your logical SQL database server to query sys.resource_stats in the following examples.

次の例は、このビューのデータが表示されているところです。This example shows you how the data in this view is exposed:

SELECT TOP 10 *
FROM sys.resource_stats
WHERE database_name = 'resource1'
ORDER BY start_time DESC

The sys.resource_stats catalog view

次の例では、sys.resource_stats カタログ ビューを使用して、SQL データベースでのリソースの使用状況に関する情報を取得するさまざまな方法を示します:The next example shows you different ways that you can use the sys.resource_stats catalog view to get information about how your SQL database uses resources:

  1. データベース userdb1 の過去 1 週間のリソース使用率を確認するには、このクエリを実行します。To look at the past week’s resource use for the database userdb1, you can run this query:

     SELECT *
     FROM sys.resource_stats
     WHERE database_name = 'userdb1' AND
           start_time > DATEADD(day, -7, GETDATE())
     ORDER BY start_time DESC;
    
  2. ワークロードがパフォーマンス レベルにどの程度適合しているかを評価するには、リソース メトリック (CPU、読み取り、書き込み、ワーカー数、セッション数) の各点を分析する必要があります。To evaluate how well your workload fits the performance level, you need to drill down into each aspect of the resource metrics: CPU, reads, writes, number of workers, and number of sessions. 次に、sys.resource_stats を使用してこれらのリソース メトリックの平均値と最大値を報告するように修正したクエリを示します:Here's a revised query using sys.resource_stats to report the average and maximum values of these resource metrics:

     SELECT
         avg(avg_cpu_percent) AS 'Average CPU use in percent',
         max(avg_cpu_percent) AS 'Maximum CPU use in percent',
         avg(avg_data_io_percent) AS 'Average physical data IO use in percent',
         max(avg_data_io_percent) AS 'Maximum physical data IO use in percent',
         avg(avg_log_write_percent) AS 'Average log write use in percent',
         max(avg_log_write_percent) AS 'Maximum log write use in percent',
         avg(max_session_percent) AS 'Average % of sessions',
         max(max_session_percent) AS 'Maximum % of sessions',
         avg(max_worker_percent) AS 'Average % of workers',
         max(max_worker_percent) AS 'Maximum % of workers'
     FROM sys.resource_stats
     WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
  3. 各リソース メトリックの平均値と最大値に関するこの情報に基づいて、選択したパフォーマンス レベルにワークロードが適合しているかどうかを評価できます。With this information about the average and maximum values of each resource metric, you can assess how well your workload fits into the performance level you chose. 通常、sys.resource_stats からの平均値が目標サイズに対する有効な基準となります。Usually, average values from sys.resource_stats give you a good baseline to use against the target size. これを主要なものさしとしてください。It should be your primary measurement stick. たとえば、S2 パフォーマンス レベルで Standard サービス レベルを使用しているとします。For an example, you might be using the Standard service tier with S2 performance level. CPU と IO の読み取り/書き込みの平均使用率が 40% を下回り、ワーカーの平均数が 50 を下回り、セッションの平均数が 200 を下回っています。The average use percentages for CPU and IO reads and writes are below 40 percent, the average number of workers is below 50, and the average number of sessions is below 200. このワークロードには、S1 パフォーマンス レベルが適している可能性があります。Your workload might fit into the S1 performance level. データベースがワーカーとセッションの制限内に収まるかどうかは簡単にわかります。It's easy to see whether your database fits in the worker and session limits. CPU、読み取り、書き込みに関して、データベースが下位のパフォーマンス レベルに適合するかどうかを確認するには、下位パフォーマンス レベルの DTU 数を現在のパフォーマンス レベルの DTU 数で割り、その計算結果に 100 を掛けます。To see whether a database fits into a lower performance level with regards to CPU, reads, and writes, divide the DTU number of the lower performance level by the DTU number of your current performance level, and then multiply the result by 100:

    S1 DTU / S2 DTU * 100 = 20 / 50 * 100 = 40S1 DTU / S2 DTU * 100 = 20 / 50 * 100 = 40

    この結果は、2 つのパフォーマンス レベルの間の相対的パフォーマンス差異を百分率で表したものになります。The result is the relative performance difference between the two performance levels in percentage. リソースの使用がこの量を超えていない場合、ワークロードは下位のパフォーマンス レベルに適合する可能性があります。If your resource use doesn't exceed this amount, your workload might fit into the lower performance level. ただし、リソース使用率の値を全範囲で見て、どのくらいの頻度でデータベースのワークロードが下位のパフォーマンス レベルに適合するかを割合の観点から判断する必要があります。However, you need to look at all ranges of resource use values, and determine, by percentage, how often your database workload would fit into the lower performance level. 次のクエリは、この例で計算した 40% のしきい値に基づき、リソース ディメンション別の適合率を出力します。The following query outputs the fit percentage per resource dimension, based on the threshold of 40 percent that we calculated in this example:

     SELECT
         (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 40 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU Fit Percent'
         ,(COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 40 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log Write Fit Percent'
         ,(COUNT(database_name) - SUM(CASE WHEN avg_data_io_percent >= 40 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical Data IO Fit Percent'
     FROM sys.resource_stats
     WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    

    データベースのサービス レベル目標 (SLO) に基づき、ワークロードが下位のパフォーマンス レベルに適合するかどうかを判断できます。Based on your database service level objective (SLO), you can decide whether your workload fits into the lower performance level. データベース ワークロード SLO が 99.9% で、上記のクエリが 3 つすべてのリソース ディメンションに対して 99.9% を超える値を返す場合、そのワークロードはおそらく下位のパフォーマンス レベルに適合します。If your database workload SLO is 99.9 percent and the preceding query returns values greater than 99.9 percent for all three resource dimensions, your workload likely fits into the lower performance level.

    適合率を見ると、SLO を満たすために上位のパフォーマンス レベルに移行する必要があるかどうかもわかります。Looking at the fit percentage also gives you insight into whether you should move to the next higher performance level to meet your SLO. たとえば、userdb1 では過去 1 週間の CPU 使用率が次のようになっています。For example, userdb1 shows the following CPU use for the past week:

    平均 CPU 使用率 (%)Average CPU percent 最大 CPU 使用率 (%)Maximum CPU percent
    24.524.5 100.00100.00

    平均 CPU は、パフォーマンス レベルの制限の約 4 分の 1 であり、データベースのパフォーマンス レベルにうまく適合するでしょう。The average CPU is about a quarter of the limit of the performance level, which would fit well into the performance level of the database. ただし最大値は、データベースがパフォーマンス レベルの制限に到達することを示しています。But, the maximum value shows that the database reaches the limit of the performance level. 次に上位のパフォーマンス レベルに移動する必要がありますか。Do you need to move to the next higher performance level? ワークロードが 100% に到達する回数を確認し、それをデータベースのワークロード SLO と比較します。Look at how many times your workload reaches 100 percent, and then compare it to your database workload SLO.

     SELECT
     (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU fit percent'
     ,(COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log write fit percent'
     ,(COUNT(database_name) - SUM(CASE WHEN avg_data_io_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical data IO fit percent'
     FROM sys.resource_stats
     WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    

    このクエリが 3 つのリソース ディメンションのいずれにも 99.9% 未満の値を返す場合、次の上位のパフォーマンス レベルに移行すること、またはアプリケーションの調整手法を使用して SQL データベースの負荷を減らすことを検討してください。If this query returns a value less than 99.9 percent for any of the three resource dimensions, consider either moving to the next higher performance level or use application-tuning techniques to reduce the load on the SQL database.

  4. この演習では、予測される将来のワークロードの増加も考慮しています。This exercise also considers your projected workload increase in the future.

エラスティック プールでは、このセクションで説明した手法を使用して、プール内の個々のデータベースを監視できます。For elastic pools, you can monitor individual databases in the pool with the techniques described in this section. ただし、プールを全体として監視することもできます。But you can also monitor the pool as a whole. 詳細については、エラスティック プールの監視と管理に関する記事を参照してください。For information, see Monitor and manage an elastic pool.

同時要求の最大数Maximum concurrent requests

同時要求の数を確認するには、SQL データベースで次の Transact-SQL クエリを実行します。To see the number of concurrent requests, run this Transact-SQL query on your SQL database:

SELECT COUNT(*) AS [Concurrent_Requests]
FROM sys.dm_exec_requests R

オンプレミス SQL Server データベースのワークロードを分析するには、分析したい特定のデータベースでフィルター処理するようにこのクエリを変更します。To analyze the workload of an on-premises SQL Server database, modify this query to filter on the specific database you want to analyze. たとえば、MyDatabase という名前のオンプレミス データベースがある場合、次の Transact-SQL クエリはそのデータベースの同時要求の数を返します。For example, if you have an on-premises database named MyDatabase, this Transact-SQL query returns the count of concurrent requests in that database:

SELECT COUNT(*) AS [Concurrent_Requests]
FROM sys.dm_exec_requests R
INNER JOIN sys.databases D ON D.database_id = R.database_id
AND D.name = 'MyDatabase'

これはある時点のスナップショットにすぎません。This is just a snapshot at a single point in time. ワークロードと同時要求の要件をさらに詳しく理解するには、時間をかけて多くのサンプルを収集する必要があります。To get a better understanding of your workload and concurrent request requirements, you'll need to collect many samples over time.

同時ログインの最大数Maximum concurrent logins

ユーザーやアプリケーションのパターンを分析すれば、ログインの頻度を理解できます。You can analyze your user and application patterns to get an idea of the frequency of logins. さらに、テスト環境で実際の負荷を実行し、この上限やこの記事で説明されている他の制限に達していないことを確認できます。You also can run real-world loads in a test environment to make sure that you're not hitting this or other limits we discuss in this article. 同時ログイン数または履歴を表示できる単一のクエリや動的管理ビュー (DMV) はありません。There isn’t a single query or dynamic management view (DMV) that can show you concurrent login counts or history.

複数のクライアントで同じ接続文字列を使用している場合、サービスによってそれぞれのログインが認証されます。If multiple clients use the same connection string, the service authenticates each login. 10 人のユーザーが同じユーザー名とパスワードを使ってデータベースに同時に接続した場合、10 件の同時ログインが発生します。If 10 users simultaneously connect to a database by using the same username and password, there would be 10 concurrent logins. この制限は、ログインと認証の期間のみに適用されます。This limit applies only to the duration of the login and authentication. 同じ 10 人のユーザーがデータベースに順番に接続した場合、同時ログイン数が 1 より大きくなることはありません。If the same 10 users connect to the database sequentially, the number of concurrent logins would never be greater than 1.

注意

この制限は現在のところ、エラスティック プールのデータベースには適用されません。Currently, this limit does not apply to databases in elastic pools.

セッションの最大数Maximum sessions

現在アクティブなセッションの数を確認するには、SQL データベースで次の Transact-SQL クエリを実行します。To see the number of current active sessions, run this Transact-SQL query on your SQL database:

SELECT COUNT(*) AS [Sessions]
FROM sys.dm_exec_connections

オンプレミス SQL Server のワークロードを分析する場合は、特定のデータベースが対象になるようにクエリを変更してください。If you're analyzing an on-premises SQL Server workload, modify the query to focus on a specific database. このクエリは、Azure SQL Database への移行を検討している場合に、データベースの潜在的なセッション ニーズを判断するのに役立ちます。This query helps you determine possible session needs for the database if you are considering moving it to Azure SQL Database.

SELECT COUNT(*)  AS [Sessions]
FROM sys.dm_exec_connections C
INNER JOIN sys.dm_exec_sessions S ON (S.session_id = C.session_id)
INNER JOIN sys.databases D ON (D.database_id = S.database_id)
WHERE D.name = 'MyDatabase'

ここでも、これらのクエリはある時点の数を返します。Again, these queries return a point-in-time count. 時間をかけて複数のサンプルを集めると、セッションの使用状況を正確に把握できます。If you collect multiple samples over time, you’ll have the best understanding of your session use.

SQL Database 分析の場合、sys.resource_stats ビューにクエリを実行し、active_session_count 列を確認して、セッションの過去の統計値を取得できます。For SQL Database analysis, you can get historical statistics on sessions by querying the sys.resource_stats view and reviewing the active_session_count column.

次の手順Next steps