Merge pull request #49407 from jovanpop-msft/master

removed duplicated content

Author: PRMerger14

articles/sql-database/sql-database-service-tiers.md

@@ -64,7 +64,6 @@ To gain deeper insight into the resource (DTU) consumption of your workload, use
 - Drill down into the details of a query, view its text and history of resource utilization.
 - Access performance tuning recommendations that show actions performed by [SQL Database Advisor](sql-database-advisor.md).
 
-
 ### What are elastic Database Transaction Units (eDTUs)?
 Rather than provide a dedicated set of resources (DTUs) that may not always be needed for a SQL Database that is always available, you can place databases into an [elastic pool](sql-database-elastic-pool.md) on a SQL Database server that shares a pool of resources among those databases. The shared resources in an elastic pool are measured by elastic Database Transaction Units or eDTUs. Elastic pools provide a simple cost effective solution to manage the performance goals for multiple databases having widely varying and unpredictable usage patterns. An elastic pool guarantees resources cannot be consumed by one database in the pool, while ensuring each database in the pool always has a minimum amount of necessary resources available. 
 
@@ -80,8 +79,6 @@ If you are looking to migrate an existing on-premises or SQL Server virtual mach
 ### How do I know if I could benefit from an elastic pool of resources?
 Pools are suited for a large number of databases with specific utilization patterns. For a given database, this pattern is characterized by a low utilization average with relatively infrequent utilization spikes. SQL Database automatically evaluates the historical resource usage of databases in an existing SQL Database server and recommends the appropriate pool configuration in the Azure portal. For more information, see [when should an elastic pool be used?](sql-database-elastic-pool.md)
 
-### What happens when I hit my maximum DTUs?
-Performance levels are calibrated and governed to provide the resources needed to run your database workload up to the maximum allowed for your selected service tier/performance level. If your workload is hitting one of the CPU/Data IO/Log IO limits, you will continue to receive the maximum level of resources allowable, but you will also likely experience increased query latencies. These limits do not result in any errors, but rather a slowdown in the workload, unless the slowdown becomes so severe that queries start timing out. If you reach the  maximum allowed concurrent user sessions/requests (worker threads), you will see explicit errors. See [Azure SQL Database resource limits]( sql-database-resource-limits.md#what-happens-when-database-resource-limits-are-reached) for information on resource limits not related to CPU, memory, data IO, or transaction log IO.
 
 ### Correlating benchmark results to real world database performance
 It is important to understand that all benchmarks are representative and indicative only. The transaction rates achieved with the benchmark application will not be the same as those that might be achieved with other applications. The benchmark comprises a collection of different transaction types run against a schema containing a range of tables and data types. While the benchmark exercises the same basic operations that are common to all OLTP workloads, it does not represent any specific class of database or application. The goal of the benchmark is to provide a reasonable guide to the relative performance of a database that might be expected when scaling up or down between performance levels. In reality, databases are of different sizes and complexity, encounter different mixes of workloads, and will respond in different ways. For example, an IO-intensive application may hit IO thresholds sooner, or a CPU-intensive application may hit CPU limits sooner. There is no guarantee that any particular database will scale in the same way as the benchmark under increasing load.