Azure SQL Database – General Overview – Refresh Part 1

I see the other contributions as a personal refresh of my knowledge of the Azure SQL Database and all its numerous features. After a long time, it was necessary to deal with it in detail again and show my own experience with learning that “writing down” helps remember the content and essential points. So I’ll just use the next (albeit perhaps shorter) blog posts to let you take part in my “refresh.” This is also relevant because the Microsoft product group has set the pace during the past few months and has presented numerous new features or optimizations to the existing ones. (Thanks for that ;-))

Understanding Azure SQL Database

Basically, it is about the Azure service, which provides us with a SQL Server database. There are numerous options for deployment or in the form. Starting with selecting the required service (aka “What do I or my application need?”). Continuing with “How many databases does your (new or existing) application really need?” If it is a further development of your own, you may still influence certain functionalities; this is hardly possible with existing in-house developments or purchased products. Example VMWare … here as a rule, at least 3 databases are required, with Sharepoint even more, with a CRM system may be only one.

But to understand, it is not about, for example, that my client-capable CRM creates a separate database for each client, but instead that only one (!) database is required per client, so no “cross-database” queries are used.

If you should make a statement here, you are one step further. You can at least once decide that Azure SQL Database is the right product. Now comes perhaps the most challenging point, but which (under certain circumstances) is good retrospectively can be adjusted.

Microsoft provides us with a Platform-as-a-Service database service in Azure based on the last stable version SQL Server. We as administrators don’t have to worry about a lot here, as Microsoft already does a lot for us, such as upgrades, backup, or monitoring. I will come back to the individual points later. We don’t have to worry about “high availability” either. All Azure SQL Database Services (depending on SKU and deployment) have at least 99.99% availability and can therefore also be used for critical and high-performance business applications.

As we know it from SQL Server, relational and non-relational data structures can also be used in the cloud, also in-memory technologies.

Choosing options for your requirements

The Azure Service SQL Database can be used in different versions and performance classes to meet almost every requirement.

• Single or pool database
• Hyperscale
• Serverless

Each individual deployment can still be divided into the various performance classes, which I will explain in more detail later. Aspects such as CPU, RAM, database size, and service life play a role here to make an optimal decision.

Deployment differences of an Azure SQL Database

If you decide that you only need one database, then the Azure SQL Single-DB (or Singleton) is the optimal one. Azure provides a single database in a shared environment, which is so isolated or isolated that you don’t have to worry about something happening here (i.e., no external access from outside your own database). Each Azure Single DB receives its own compute resources and can then use them exclusively.

For example, suppose you have several small databases with different loads at different times. In that case, you can choose an Azure SQL Elastic Pool. Several individual databases are configured in a pool, which can then share the shared compute resources depending on usage and workload.

Depending on the application’s requirements or the business, both single and elastic pool databases can be dynamically scaled to the workload to be processed.

Microsoft differentiates between serverless and server-based in these performance classes, with server-based also being subdivided into “General Purpose / Universal” and “Business Critical / Company-critical” and further into the Compute’s possibilities -Select resources in vCore- or DTU-based. There is currently no serverless deployment for the elastic pools, but there is a distinction between GeneralPurpose and BusinessCritical and the division into DTU (Data Transaction Units) and vCores.

I’ll get to the availability, monitoring, and backup of Azure SQL databases in one of the other blog posts.