Skip to content

Commit 209daa8

Browse files
authored
Merge pull request #88080 from jovanpop-msft/patch-111
Added why using business critical tier
2 parents f160a61 + d3f2e49 commit 209daa8

File tree

1 file changed

+11
-0
lines changed

1 file changed

+11
-0
lines changed

articles/sql-database/sql-database-service-tier-business-critical.md

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -40,6 +40,17 @@ In addition, Business Critical cluster has built-in [Read Scale-Out](sql-databas
4040

4141
Business Critical service tier is designed for the applications that require low-latency responses from the underlying SSD storage (1-2 ms in average), fast recovery if the underlying infrastructure fails, or need to off-load reports, analytics, and read-only queries to the free of charge readable secondary replica of the primary database.
4242

43+
The key reasons why you should choose Business Critical service tier instead of General Purpose tier are:
44+
- Low IO latency requirements – workload that needs the fast response from the storage layer (1-2 milliseconds in average) should use Business Critical tier.
45+
- Frequent communication between application and database. Application that cannot leverage application-layer caching or [request batching](sql-database-use-batching-to-improve-performance.md) and need to send many SQL queries that must be quickly processed are good candidates for Business Critical tier.
46+
- Large number of updates – insert, update, and delete operations modify the data pages in memory (dirty page) that must be saved to data files with `CHECKPOINT` operation. Potential database engine process crash or a failover of the database with a large number of dirty pages might increase recovery time in General Purpose tier. Use Business Critical tier if you have a workload that causes many in-memory changes.
47+
- Long running transactions that modify data. Transactions that are opened for a longer time prevent truncation of log file that might increase log size and number of [Virtual log files (VLF)](https://docs.microsoft.com/sql/relational-databases/sql-server-transaction-log-architecture-and-management-guide#physical_arch). High number of VLF can slow down recovery of database after failover.
48+
- Workload with reporting and analytic queries that can be redirected to the free-of-charge secondary read-only replica.
49+
- Higher resiliency and faster recovery from the failures. In a case of system failure, the database on primary instance will be disabled and one of the secondary replicas will be immediately became new read-write primary database that is ready to process the queries. Database engine doesn't need to analyze and redo transactions from the log file and load all data in the memory buffer.
50+
- Advanced data corruption protection - Business Critical tier leverages database replicas behind-the-scenes for business continuity purposes, and so the service also then leverages automatic page repair, which is the same technology used for SQL Server database [mirroring and availability groups](https://docs.microsoft.com/sql/sql-server/failover-clusters/automatic-page-repair-availability-groups-database-mirroring). In the event that a replica cannot read a page due to a data integrity issue, a fresh copy of the page will be retrieved from another replica, replacing the unreadable page without data loss or customer downtime. This functionality is applicable in General Purpose tier if the database has geo-secondary replica.
51+
- Higher availability - Business Critical tier in Multi-AZ configuration guarantees 99.995% availability, compared to 99.99% of General Purpose tier.
52+
- Fast geo-recovery - Business Critical tier configured with geo-replication has a guaranteed Recovery point objective (RPO) of 5 sec and Recovery time objective (RTO) of 30 sec for 100% of deployed hours.
53+
4354
## Next steps
4455

4556
- Find resource characteristics (number of cores, IO, memory) of Business Critical tier in [Managed Instance](sql-database-managed-instance-resource-limits.md#service-tier-characteristics), Single database in [vCore model](sql-database-vcore-resource-limits-single-databases.md#business-critical-service-tier-for-provisioned-compute) or [DTU model](sql-database-dtu-resource-limits-single-databases.md#premium-service-tier), or Elastic pool in [vCore model](sql-database-vcore-resource-limits-elastic-pools.md#business-critical-service-tier-storage-sizes-and-compute-sizes) and [DTU model](sql-database-dtu-resource-limits-elastic-pools.md#premium-elastic-pool-limits).

0 commit comments

Comments
 (0)