Azure SQL DB: Dove siamo arrivati ?

Azure SQL DB: Dove siamo arrivati ?
Ferrari Luca – Microsoft Sr. PFE Azure SQL DB: Dove siamo arrivati ?

Organizers GetLatestVersion.it

Sponsors

Agenda Azure SQL DB: Cos’è e cosa ha ? Deployment models DTU vs vCore
Serverless Hyperscale Q&A

Azure SQL DB: Cos’è e cosa ha ?

Data platform continuum
PaaS & SaaS Azure SQL Database Virtualized Database Shared lower cost IaaS SQL Server in Azure VM Virtualized Machines Virtual SQL Server Private Cloud Virtualized Machine + Appliance Objective: One of the first things to understand in any discussion of Azure versus on-premises SQL Server databases is that you can use it all. The Microsoft data platform leverages SQL Server technology and makes it available across physical on-premises machines, private cloud environments, third-party hosted private cloud environments, and public cloud. This enables you to meet unique and diverse business needs through a combination of on-premises and cloud-hosted deployments, while using the same set of server products, development tools, and expertise across these environments. Talking Points: As seen in the diagram, each offering can be characterized by the level of administration you have over the infrastructure (on the X axis), and by the degree of cost efficiency achieved by database level consolidation and automation (on the Y axis). When designing an application, four basic options are available for hosting the SQL Server part of the application: SQL Server on nonvirtualized physical machines SQL Server in on-premises virtualized machines (private cloud) SQL Server in Azure Virtual Machine (public cloud) Azure SQL Database (public cloud) Physical SQL Server Physical Machine (raw iron) Dedicated higher cost Higher administration Lower administration

Build 2015 3/13/ :57 PM Cosa è ? Managed by Microsoft Managed by customer Machine-learning capability On-premises costs tend to be driven by hardware and data center management costs Infrastructure-as-a-Service reduces cost categories related to data center and compute Platform-as-a-Service off-loads customers’ most administrative tasks to Azure, further improving efficiency with machine-learning capabilities for performance and security Managed Instance: instance-level deployment for lift-shift existing apps to Azure, fully backward compatible Single database: database-level deployment for new apps On-premises Infrastructure (as a Service) Intellignt performance/security Applications Applications Applications Data Data Data High availability /DR/Backups High availability /DR/Backups High Availability/ DR/Backups Database Provision/ Patch/Scaling Database Provision/ Patch/Scaling Database Provision/ Patch/Scaling O/S provision /patching O/S O/S Azure SQL Database is a fully-managed platform-as-a-service. This means Microsoft operates SQL Server for you, assuming much of the daily maintenance, administration and infrastructure costs of your IT organization. Quickly realize spend and operational efficiencies you may not have otherwise experienced with your on-premises or hosted solution. Along with ensured availability and performance, features of Azure SQL Database include: Provisioning and resizing (w/ Azure Portal experience) Built-in auto HA (99.99%) Automatic backup Point-in-time-restore (database-level) Active geo-replication Intelligent performance optimization and security of your databases Virtualization Virtualization Virtualization Hardware Hardware Hardware Datacenter Management Datacenter Management Datacenter Management SQL Server Azure SQL VMs Azure SQL Database © 2014 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Cosa è ? Azure SQL Database is a fully-managed platform-as-a-service (PaaS). Based on the latest stable version of the Microsoft SQL Server database engine

Cosa ha ? Azure SQL Database include (My Fav. Top 5):
Built-in auto HA (99.99%) Automatic backup Point-in-time-restore (database-level) Geo-replication Intelligent performance optimization and security

Cosa ha ? Learn & Adapt Privacy & trust Business Continuity
Operational analytics Columnstore In-Memory OLTP Predictable performance Query Store Index Optimization Automatic tuning Auto query plan correction Performance Insight in OMS Adaptive Query Processing SQL Graph Advanced analytics Native PREDICT R Services Activity monitoring Engine Audit Threat Detection Centralized dashboard OMS Access control SQL Firewall RLS, Dynamic data masking AAD and MFA Data protection Encrypt in motion (TLS) Always Encrypted (equality) TDE & BYOK Service endpoint Always Encrypted (secure enclave) Discovery & assessment Vulnerability assessment HA-DR built-in 99.99% SLA Geo-restore Active geo replicas (4) Multi-AZ Zone-redundant Backup and restore Backup with health check 35 days PITR 10 years data retention Distributed application Change Tracking Transaction replication Data sync SSIS service Read scale-out VNET endpoints

Azure SQL Database — Everything built-in
Intelligent performance Scales on the fly Business continuity Works in your environment Advanced threat pprotection Realize automatic performance improvements from continuous assessment and innovation Change service tiers, performance levels, and storage dynamically without downtime Easily manage and monitor business critical functions for reliable operations Develop your app and connect to SQL Database with the tools and platforms you prefer Build security-enhanced apps with built-in protection and industry- leading compliance Objective: This slide is intended to break down the features and services of Azure SQL Database. Talking Points: Scales on the fly - Scale performance anytime, anywhere, without app downtime When demand for your app grows from a handful of devices and customers to millions, SQL Database is the database service that can scale along with you—on the fly and with no app downtime. Business Continuity – Easily manages and monitor your business critical functions Your mission critical applications are core to your business and their uptime and performance are critical to successfully deploying them to Azure. Azure SQL Database has all the critical features to ensure business continuity built in and deployed in seconds. Learns and adapts – Learn and adapt dynamically with your app As your app runs, Azure SQL Database continuously learns your unique app patterns, adaptively tunes your performance, and automatically improves reliability and data protection—freeing you to focus on your app. Works with your environment - Work within your preferred development environments Develop your app with the tools and platforms you prefer. Microsoft Azure SQL Database make it easy to connect to SQL Database with a variety of technologies enabling you to focus on developing business logic and apps using tools you are familiar with. Protects and secures – Help protect and secure your app data Build security-enhanced apps in the cloud with built-in data protection, high availability, and security features—without implementing custom code. With physical and operational security built in to Azure, SQL Database can help you meet the most stringent regulatory compliances. Recover from disaster Reduce the impact of a disaster on your business. Using azure tools for business continuity to ensure that your data is resilient from disaster. With automated backups and active geo-replication in up to four secondary readable locations you can be sure that your data is safe. Using failover groups ensures that during a outage in one location a secondary location can automatically can take over and ensure minimum outage time.

Deployment models

Deployments models Azure SQL Database Single Database Elastic Pool
Managed Instance Database-scoped deployment option with predictable workload performance Shared resource model optimized for greater efficiency of multi-tenant applications Instance-scoped deployment option with high compatibility with SQL Server and full PaaS benefits Best for apps that require resource guarantee at database level Best for SaaS apps with multiple databases that can share resources at database level, achieving better cost efficiency Best for modernization at scale with low friction and effort Overview: Azure SQL Database provides you with several deployment options to meet your workload needs. It’s the same SQL engine for all these options. Talking Points: There are three hosting options available in Azure SQL Database: Each standalone database is assigned a certain amount of resources via performance tiers: Basic, Standard, and Premium. The emphasis of this offering focuses on a simplified database-scoped programming model and applications with a predictable pattern and relatively stable workload. An elastic database pool is a shared resource model that enables higher resource utilization efficiency, and all the databases within an elastic pool share predefined resources within the same pool. The emphasis of this offering is on a simplified database-scoped programming model for multi-tenant SaaS apps. The workload pattern is well-defined and is highly cost-effective in multi-tenant scenarios. For ISVs with SaaS apps, the savings can be significant, in the hundreds of thousands of dollars or more. A SQL Database Managed Instance offers a simplified instance-scoped programming model that is like an on-premises SQL Server instance. The databases in a SQL Database Managed Instance share the resources allocated to the Managed Instance, and the Managed Instance also represents the management grouping for these databases. The emphasis of this offering is on high compatibility with the programming model of an on-premises SQL Server and out-of-box support for a large majority of SQL Server features and accompanying tools/services. There are also three service tiers available in Azure SQL Database [click to next slide]

Fully-managed service
Deployment models Azure SQL Database Single Database Elastic Pool Managed Instance Fully-managed service PaaS Regularly patched by MS Based on latest stable SQL version Scalable Scale resources based on needs Easy Few differences in T-SQL

Deployment models Azure SQL Database Fully-managed service
Single Database Elastic Pool Managed Instance Fully-managed service Built on the same infrastructure as Single Database Provides the same benefits (PaaS) Predictable performance/budget Features purchase resources for a pool shared by multiple databases to accommodate unpredictable periods of usage by individual databases. well suited for a large number of databases with specific utilization patterns Elastic Jobs

Deployment models Azure SQL Database Fully-managed service
Single Database Elastic Pool Managed Instance Fully-managed service Provides the same benefits (PaaS) SQL Server compatibility Fully-fledged SQL instance with nearly 100% compat with on-premise Full isolation and security Contained within your VNet Private IP addresses Express Route / VPN connectivity

DTU vs vCore

Independent scalability
DTU vs vCore Pre-packaged, bundled unit that represents the database power Designed for predictable performance, but somewhat inflexible and limited in options DTU sizing offers simplicity of choice Storage Compute vCore model Independent scalability DTU model Simple, preconfigured This model allows you to independently choose compute and storage resources. It also allows you to use Azure Hybrid Benefit for SQL Server to gain cost savings. Best for customers who value flexibility; control and transparency Overview: Azure SQL Database enables you to easily purchase fully managed PaaS database engine that fits your performance and cost needs. Depending on the deployment model of Azure SQL Database, you can select the purchasing model that fits your needs: Talking Points: Azure SQL Database give you flexible purchasing models to have simple preconfigured compute & storage or independent control over compute & storage. vCore model. This model allows you to independently choose compute and storage resources. It also allows you to use Azure Hybrid Benefit for SQL Server to gain cost savings. Best for customers who value flexibility; control and transparency Customers can select compute and storage independently Allows customers to right-size their compute requirements in the cloud vCore sizing offers flexibility of choice Database Transaction Unit (DTU) model. Bundled measure of compute, storage and IO resources. Best for customers who want simple, pre-configured resource options Reference

Dtu Database Transaction Unit
A blended measure of CPU, memory, reads, and writes etc… Not available for Managed Instances Basic Standard Premium Target workload Development and production Uptime SLA 99.99% Maximum backup retention 7 days 35 days CPU Low Low, Medium, High Medium, High IO throughput (approximate) 1-5 IOPS per DTU 25 IOPS per DTU IO latency (approximate) 5 ms (read), 10 ms (write) 2 ms (read/write) Columnstore indexing N/A S3 and above Supported In-memory OLTP Maximum storage size 2 GB 1 TB 4 TB

vCore Virtual core Number of core your SQL Database will use
Balance performance requirements and price with two hardware generations Match your on-premise application behavior *M-series (preview), and Fsv2-series (preview) Gen 4 Gen 5 Hardware Intel E v3 (Haswell) 2.4 GHz processors vCore = 1 PP (physical core) Intel E v4 (Broadwell) 2.3 GHz processors, fast eNVM SSD vCore=1 LP (hyper-thread) Performance levels 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 16, 24 vCores 2, 4, 6, 10, 12, 14, 16, 18, 20, 24, 32, 40, 80 vCores Memory 7 GB per vCore 5.1 GB per vCore Storage 5 GB to 4 TB with 1 GB increments. Premium blob storage 5 GB to 4 TB with 1GB increments. Local SSD storage. Hyperscale: from5 GB to 100 TB with 1GB increments and only charge for storage based on usage. Here’s a double-click on the performance summary we just spoke about on the previous slide. You will be able to further balance price and performance requirements with the ability to choose between two hardware generations, Gen 4 and Gen 5. Our goal is to enable maximum flexibility so you can choose a performance configuration that most closely matches the needs of your application. In particular, Gen 4 hardware offers more memory per vCore. However, Gen 5 hardware allows you to scale up compute much higher. We want to make these differences transparent so you can achieve the optimal price/performance ratio for your application.

Dtu vs vCore DTUs vCores Basic Standard Premium General Purpose
Business Critical Hyperscale Small databases particularly those in development phases General purpose databases with moderate performance requirements Mission-critical databases with high performance and high-availability requirements Data applications with basic IO and basic availability requirements Business critical data applications with fast IO and high availability requirements VLDB OLTP and HTAP workloads with highly scalable storage and read-scale requirements Objective: Use Microsoft Azure SQL Database service tiers (editions) to dial in cloud database performance and capabilities to suit your application. For more about the pricing of different service tiers, see SQL Database pricing details. Talking Points: Basic, Standard, Premium, and Premium RS service tiers offer predictable performance, flexible business continuity options, and streamlined billing. In addition, with multiple performance levels, you can have the flexibility to choose the level that best meet your workload demands. Since Web and Business service tiers (editions) were retired in September 2015, consider using Basic, Standard, Premium, or Premium RS for newly created databases. For more information, see Web and Business Edition Sunset FAQ. Premium RS tier provides the same performance levels, security features and business continuity features as the Premium tier albeit at a reduced SLA Should your workload increase or decrease, you can easily change the performance characteristics of a database in the Microsoft Azure Management Portal. Select your database, click Scale, and then choose a new service tier. For more information, see Changing Database Service Tiers and Performance Levels. The features available with each service tier fall into the following categories: Performance and scalability: Basic, Standard, Premium, and Premium RS service tiers have one or more performance levels that offer predictable performance. Performance levels are expressed in Database Throughput Units (DTUs), which provide a quick way to compare the relative performance of a database. For more detailed information about performance levels and DTUs, see Azure SQL Database Service Tiers and Performance Levels. In addition to the performance level, for all database service tiers, you also pick a maximum database size supported by the service tier. For more information on the supported database sizes, see CREATE DATABASE. Business continuity: These features help you recover your database from human and application errors, or datacenter failures. Many built-in features, such as geo-restore, are available with Basic, Standard, Premium, and Premium RS service tiers. For more information, see Azure SQL Database Business Continuity. Auditing: With Basic, Standard, Premium, and Premium RS service tiers, you can track logs and events that occur in a database. For more information, see Azure SQL Database Performance Guidance. Source:

Demo: Deployment

Serverless

Serverless Azure SQL Database serverless is a compute tier for single databases. Auto-Scale based on workload demand Auto-Pause

Serverless CPU usage Number vCores 8:00 9:00 10:00 11:00 12:00 13:00
14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 Min vcores Number vCores 4 CPU usage 1 Inactive Paused Max vcores Vcores used Vcores billed

Serverless The minimum vCores and maximum vCores are configurable parameters that define the range of compute capacity available for the database. Memory and IO limits are proportional to the vCore range specified.  Min vCore = 0.5 Max vCore = 16

Serverless The autopause delay is a configurable parameter that defines the period of time the database must be inactive before it is automatically paused. The database is automatically resumed when the next login or other activity occurs. Alternatively, autopausing can be disabled. 1 hour min inactive period

Serverless The cost for a serverless database is the summation of the compute cost and storage cost. When compute usage is between the min and max limits configured, the compute cost is based on vCore and memory used. When compute usage is below the min limits configured, the compute cost is based on the min vCores and min memory configured. When the database is paused, the compute cost is zero and only storage costs are incurred. The storage cost is determined in the same way as in the provisioned compute tier.

Why serverless ? Compute requirements for new apps may be unknown
Developers struggle to provide sufficient capacity and resources to support apps Managing unpredictable and intermittent workloads is costly and time-consuming Businesses struggle to ensure that database provisioning consistently aligns with workload requirements Development and test workloads. E-commerce apps with seasonal retail spikes. Content management apps to support unpredictable publishing schedules. Many applications today are built for scenarios with intermittent and unpredictable usage patterns. Oftentimes these apps may be brand new and the compute requirements are unknown. Or, the apps may have highly unpredictable and intermittent usage. We see this a lot in scenarios like line-of-business applications, dev/test databases, content management and e-commerce systems. Developers, are focused on creating great experiences for their users. But one of the challenges they face is ensuring there is enough capacity and resources available to support their apps. They don’t want to spend their time worrying about managing resources – they want to build great apps and know that they’ll perform the way they need to when called upon.

Serverless Vs Provisioned
Serverless databases… Databases with provisioned compute… Scale up or down to meet workload requirements, instead of pre-provisioning Bill on a per-second basis Provision compute resources upfront Bill on an hourly basis Common scenarios Common scenarios Workloads with unpredictable and intermittent usage patterns or performance requirements Workloads where the requirements are unknown and you can delegate compute sizing to the service Workloads with regular and substantial compute utilization Multiple databases with bursty usage patterns that can be consolidated into a single server and use elastic pools for better price optimization

Demo: Serverless deployment

Hyperscale

Hyperscale Hyperscale is a new, highly scalable service tier that adapts on-demand to your workload's needs, auto-scaling up to 100TB per database. Storage dynamically adapts to your workloads’ needs, auto-scaling up to 100TB. Provision one or more additional compute nodes that can serve your read-only workload and use them as a hot-standby, in case of failover. Perform operations in constant time, regardless of the size of the data operation. Compute and storage resources scale rapidly and independently without sacrificing performance. 100 TB Azure SQL Database Hyperscale is a new, highly scalable service tier that adapts on- demand to your workload's needs Quickly auto-scaling up to 100TB per database eliminates the need to pre- provision storage resources, significantly expanding the potential for app growth without storage size limits. Rapid scale up/down and point-in-time restore, regardless of the database size Fewer size-of-data operations Higher log throughput than current service tiers Scale-out read-only workload with read-scale replicas without data copy Why Hyperscale: Database size > 4TB HTAP workload Support OLTP app and interactive BI Very high cost to change applications Higher data ingest throughput Fast copy Grow beyond 8TB for General Purpose or beyond 4TB for Business Critical and swap Fast scaling operations for cost saving

Hyperscale Compute Log Service Page Servers Remote Data Storage
Read & Write Read Only Compute Stateless, Local SSD Cache Log Service Local SSD Cache Log Service Landing Zone (Azure Premium Storage) Log Destaging Log Cache Page Servers Local SSD Cache Page Servers Long Term Storage for PITR (Azure Standard Storage) Log Covering RBPEX Data Cache Covering RBPEX Data Cache ….. Covering RBPEX Data Cache 128GB data file 128GB data file 128GB data file Overview: Here are the high-level components that make up Hyperscale Talking Points: Hyperscale is built based on a new cloud-born architecture which decouples compute, log and storage. Compute. The compute node is where the relational engine lives, so all the language elements, query processing, and so on, occur. All user interactions with a Hyperscale database happen through these compute nodes. Compute nodes have SSD-based caches (labeled RBPEX - Resilient Buffer Pool Extension in the preceding diagram) to minimize the number of network round trips required to fetch a page of data. There is one primary compute node where all the read-write workloads and transactions are processed. There are one or more secondary compute nodes that act as hot standby nodes for failover purposes, as well as act as read-only compute nodes for offloading read workloads (if this functionality is desired). Log Service: Local SSD cache Page Servers. Page servers are systems representing a scaled-out storage engine. Each page server is responsible for a subset of the pages in the database. Nominally, each page server controls 1 terabyte of data. No data is shared on more than one page server (outside of replicas that are kept for redundancy and availability). The job of a page server is to serve database pages out to the compute nodes on demand, and to keep the pages updated as transactions update data. Page servers are kept up-to-date by playing log records from the log service. Page servers also maintain SSD-based caches to enhance performance. Long-term storage of data pages is kept in Azure Storage for additional reliability. Log service. The log service node accepts log records from the primary compute node, persists them in a durable cache, and forwards the log records to the rest of the compute nodes (so they can update their caches) as well as the relevant page server(s), so that the data can be updated there. In this way, all data changes from the primary compute node are propagated through the log service to all the secondary compute nodes and page servers. Finally, the log record(s) are pushed out to long-term storage in Azure Storage, which is an infinite storage repository. This mechanism removes the necessity for frequent log truncation. The log service also has local cache to speed up access. Remote Data Storage. The Azure storage node is the final destination of data from page servers. This storage is used for backup purposes as well as for replication between Azure regions. Backups consist of snapshots of data files. Restore operation are fast from these snapshots and data can be restored to any point in time. Remote Data Storage Azure Storage Data Pages Data Pages ….. Data Pages File Snapshots File Snapshots File Snapshots Azure Storage

Hyperscale ….. ….. RBPEX Talking points: Hyperscale Approach:
Local SSD Cache RBPEX Resilient Buffer Pool Extension Read & Write Read Only Log Pathway Data Pathway Secondary Primary RBPEX Data Cache RBPEX Data Cache RBPEX Data Cache RBPEX Data Cache Primary Compute sqlservr.exe Secondary Compute sqlservr.exe Secondary Compute sqlservr.exe Secondary Compute sqlservr.exe Log Service Compute Landing Zone (Azure Premium Storage) Log Destaging Log Cache Page Servers Long Term Storage for PITR (Azure Standard Storage) Log Covering RBPEX Data Cache Covering RBPEX Data Cache ….. Covering RBPEX Data Cache 128 GB data file 128 GB data file 128 GB data file Overview: Architecture of Hyperscale Talking points: Hyperscale Approach: Split the SQL Engine Maintain the query engine for 100% compatibility Re-architect the storage layer for the cloud Physically split compute and storage Scale out storage to 100TB and more Scaling Compute a constant time operation. Instantly spin up compute nodes for offloading reads Adding Compute nodes is a constant time operation and DOES NOT impact Primary Compute performance Transaction Commit latency - few milliseconds (Initial Preview). Envisioned to be sub-milliseconds in the latter stages using ultra ssd Instantaneous [file-snapshot] backups. Backup/Restore operations no longer impact the perf (IO). Data Pages Data Pages ….. Data Pages File Snapshots File Snapshots File Snapshots Azure Storage

Hyperscale - Write Primary Compute Secondary Compute <2.5ms
Primary compute write log to the log landing zone - <2.5ms latency Commit transactions after hardening the log Async log apply to the secondary compute Async log apply to page servers Page server writes data to data files at checkpoints Tx commit Primary Compute Secondary Compute <2.5ms Log landing zone Log Service Memory cache Long term log storage Overview: IO performance is another differentiator between Hyperscale and General Purpose & Business Critical. Hyperscale has a higher log throughput because you don’t need the round trip anymore. Talking points Primary compute write log to the log landing zone - <2.5ms latency Commit transactions after hardening the log Async log apply to the secondary compute Async log apply to page servers Page server writes data to data files at checkpoints Page Server Page Server Page Server Data File Data File Data File

Hyperscale - Read Cache Miss Cache Hit Compute RBPEX Page Server RBPEX
Pre-build RBPEX when page server instance started Two page-server replicas guarantee IO latency RBPEX on compute nodes is proportional to # of vCores Hit local RBPEX - < 0.5ms Hit page server RBPEX - < 2ms Optimized for OLTP workload – operating on hot data Use Column Store index to optimize HTAP/OLAP workload Cache Miss Cache Hit Compute RBPEX Page request Read request Read request Page Server RBPEX Azure Storage Data File Overview: IO performance is another differentiator between Hyperscale and General Purpose & Business Critical. Hyperscale provides different layers of cache. The read IO performance is somewhere between General Purpose and Business Critical tiers. Talking points Compute nodes have a local persistent storage/cache Pre-build RBPEX when page server instance started Two page-server replicas guarantee IO latency RBPEX on compute nodes is proportional to # of vCores Hit local RBPEX - < 0.5ms Hit page server RBPEX - < 2ms Optimized for OLTP workload – operating on hot data Use Column Store index to optimize HTAP/OLAP workload Build RBPEX

Hyperscale GP HS BC RBPEX Files <0.5ms for all data access
Azure Storage ~2ms for all data access HS Azure Storage RBPEX Page Servers <0.5ms for hot data access ~2ms otherwise Proportional to compute size Full coverage BC Files <0.5ms for all data access Overview: Read IO performance is one of the biggest differences between the service tiers. Talking Points: General Purpose stores data on Azure Storage with ~2ms Read IO performance. Business Critical stores data on SSD with <0.5ms Read IO performance. Best for critical OLTP workloads that are sensitive IOPS Hyperscale has multiple layers of cache to provide mix IO performance between General Purpose and Business Critical. Ideal mix workloads where OLPT hits the hot data access (<0.5ms) and the rest of the workload is hitting the Azure Storage. Attached SSD Remote Storage

Demo: Hyperscale

Thanks!

Azure SQL DB: Dove siamo arrivati ?

Similar presentations

Presentation on theme: "Azure SQL DB: Dove siamo arrivati ?"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Azure SQL DB: Dove siamo arrivati ?

Similar presentations

Presentation on theme: "Azure SQL DB: Dove siamo arrivati ?"— Presentation transcript:

Similar presentations

About project

Feedback