Database Throughput Unit – DTU Monitoring % of current Performance Level Utilization 75% Read 50% Write CPU 60% Memory (coming) Compute Writes Reads Memory Bounding Box

BasicStandardPremium Performance Levels (DTU) 1S1: 5 S2: 25 P1: 100 P2: 200 P3: 800 ASDB results3,467 tx/hourS1: 283 tx/minute S2: 1,470 tx/minute P1: 98 tx/second P2: 192 tx/second P3: 730 tx/second Maximum DB size2GB250GB500GB Price per day/month (-50% during Preview) $0.16 / $4.995S1: $1.30 / $40 S2: $6.45 / $200 P1: $30 / $930 P2: $60 / $1,860 P3: $240 / $7,440

Fabrikam InvoiceOrder Inventory RootCust. #1 Cust. #2 Cust. #nRootShard #1 Shard #2 Shard #n S2 Cust. #1 Basic Cust. #2 P1 Root P3 Fabrikam S1 Invoice S2 Order S1 Inventory Basic Shard #1 P2 Shard #2 S2 Root

SaaS Customer DB1 Customer DB2 Customer DB3 Customer DB N …

Directory Shard 1Shard

Example Sharded Model

Business Continuity Problem

High availability platform Reads are completed at the primary Writes are replicated to secondaries DB Single Logical Database Up to 4 synchronous replicas Transparent automatic failover Uptime SLA of 99.95% P S S Write Ack Read Value Write Ack P S S

Point In Time Restore Automatic Backup –Full backups once a week, diff backup once a day, log backups every 5 min –Daily backup files uploaded to geo-redundant Azure Storage Self-service restore –REST API, PowerShell or Portal –Creates a side-by-side database copy Tiered Retention Policy –Basic edition: last daily backup –Standard edition: 7 days –Premium edition: 30 days sabcp01bl21 sabcp02bl21 sabcp03bl21 Restore as a new database LS XYZ Copy backups to Azure Storage DB DB1

Active Geo-replication (Premium tier) RTO<1h, RPO<5m Automatic data replication and synchronization REST and PowerShell API to opt-in and failover DMV to guide failover decisions User controlled placement of up to 4 secondaries Creates secondary database with matching performance level Geo-replication LS ABC US East US West X Failover to secondary database LS XYZ

Design pattern #1 Active-passive compute with coupled failover Optimized for co-located app and data tier Secondary is not used for app access Failover involves DNS change

Design pattern #2 Active-active compute with decoupled failover Optimized isolated load balancing of the end user traffic Secondary is used for readonly access Failover does not involve DNS change

Design pattern #3 Active-passive compute with decoupled failover Optimized for partial failures of the application stack Secondary is not used for application access Failover involve DNS change

BCDR Summary RTO<24h*, RPO<24h RTO<2h RPO<30m RTO<1h, RPO<5m * Target only, depends on the data size and scale of restores ** Not all disaster recovery features are available today

ScenarioBasic TierStandard TierPremium Tier Local failures Azure DB upgrades and maintenance Accidental data corruption Regional disaster DR Drill Online application upgrade Application failure Online application relocation Load balancing

Basic: 1  5 DTU S1: 5  15 DTU S2: 25  50 DTU P1: 100 DTU (unchanged) P2: 200 DTU (unchanged) P3: 800 DTU (unchanged)