Configure Azure SQL Database resource for scale and performance

5. 9, 53, 56. Other Azure SQL Database configuration settings

In this video, we're going to have a look at the other tabs in the Create an Azure SQL Database. So, first of all, we have got networking, so we've got two different parts of these firewall rules. First of all, do you want to allow Azure services and resources to access the server? In other words, maybe you've got something within Azure that wants to communicate with the database. So if so, you have to say yes. If not, then you can leave it as "no." Do you want to add the current client IP address? So this is useful if you personally wish to have a look at the database. I'm going to say yes here. So that would be a public endpoint. You can also add a private endpoint. So, notwithstanding services and resources, you could have a private connection from a private IP address within a virtual network. So if there's something very specific that you want access to, you can do that if it's got an IP network. So you can have communication between these different devices.

Now, you note that I can't actually change this at the moment, but I can modify it from the Firewalls and Virtual Networks Blade that I can select after the database creation. Now going down, we've got a connection policy. So how are things going to be connected? So, there are two different possibilities. Either it goes directly to the node hosting database, or it goes via an Azure SQL database gateway. So you can see that the default uses both policies. It uses the Redirect policy if it's inside Azure and the proxy if the connection is from outside Azure. So if I was connecting, it would go through a gateway. And if another device or service is connected to yours, then it would go through the redirect policy. In other words, direct And that's just the default. So you can change it here. You've got the encrypted settings or connection. You have got TLS, that's the transport layer security, and one two is the latest version. So that's for more modern computers. If you're going to security, you can have a free trial of Azure defender for SQL for 30 days. It's already enabled on the selected server.

And if you're wondering why you couldn't change these, it's because we are putting them onto an existing server. If you're creating a new server, then we can set this up for the server. You can have sample data or you can go from a backup. So your most recent geo replicated backups can also specify the database collection. So, database collation, how do you put letters in alphabetical order, a to Z? Now, sometimes it's not as easy as you might think. And so, if you're used to Western European or even English, then you might think there's no issue. But think about some languages that have got accents. Think about languages which are not Western European. And we have got two sets of choices that we can make in addition to the standard collision that we use. So the standard here is the Latin one. We can be case insensitive. That's CI, or case-sensitive. That's CS. In other words, does a capital A get collated? Is it in the same position as the lower case A? And then we have accent-sensitive or accent-insensitive AI. So is an E the same sorting position as an E with an accent? So these are some things to consider when you're configuring an Azure SQL database. Nice.

6. 12. calculate resource requirements, including Elastic pool requirements

Now, this video is probably a bit of a recap of what we've previously seen. We need to work out how to calculate the resource requirements. Now, there are two purchasing models as we've seen: the V core-based model and the DTU-based purchasing model. So this is a package of compute storage and I/O resources. With simple preconfigured resources, it’s more complicated. For the Codebase model, we have independent scaling of compute, storage, and IO resources. It's flexible, but you can see you've got control, and it's very transparent in terms of what you're getting. And you can use the Azure hybrid benefit for cost savings. The business critical service tier includes three replicas, but it's about 2.7 times the price of the general purpose version.

With the DTU-based purchasing model, it can be difficult to work out how many DTUs you need. You should factor in the following: the maximum storage bytes. So you can see, for the higher service tier, you get 500GB for the standard, 250GB, and for the basic, you just get 2GB. So, the more storage you need, the higher the actual tier that you should go for. You should also have a look at the average DTU utilisation multiplied by the number of databases. That can give you a good idea. Additionally, have a look at the number of concurrently peaking databases multiplied by the peak DTU utilisation per database. So, in other words, let's say you have gotten databases with an average utilisation DTU of ten. Well, you need 100, but maybe that's just the average. You have four databases which peak at 30 DPUs at the same time. Well, you'll need 120 DTUs, so it would be whichever is the higher. Now, should you use a pool or not a pool? Well, it's down to you. You need to work out. Do your databases peak at the same time? If they do, then a pool is probably not for you if they peak at different times. And have a think about whether you can level it out better by using an elastic pool. But do bear in mind that the unit price for Edtu pools is a 50% premium if you go for the DTU-based purchasing model.

If you go for the Vcobasedpurchasing model, it's the same. However, you can't have elastic pools with the hyperscale model. Now, you should note that single databases can be moved in and out of elastic pools. They are isolated from other databases, they are portable, and they can be dynamically scaled up and down. That's not the same as auto scaling. You can scale it. Now, for elastic pools, you can assign resources that are shared by all pool databases, and you can dynamically scale or auto scale resources up and down. How much does it cost? Well, you need to work out what it is you want. You have seen previously that there is an estimate over here, but this gives you a few more options. So you can have a look at GEN Five or different hardware types. You can have a look at the service tier, the region, the currency display pricing by the month or the hour. And you can also show Azure Hybrid benefit pricing as well for single databases or elastic pools. So these are some of the things to think about when you're calculating resource requirements. Which purchasing model and tier are you going to be using? elastic pools? What storage do you need? Can you get away with DTUs or should you go for the Vcar purchasing model?

7. 13, 71. evaluate database partitioning techniques, such as database sharding

In this video, we're going to look at how we can improve performance for very big databases. Now, we've got, for instance, a table here. So a table with all of these roles and all of these columns It's not a big table, 540 rows. I've only got a basic database and that's absolutely fine. But what if it wasn't 500 rows, 500 billion roles, some huge figure? How could I best allow the end user to be able to get access to their information?

Well, here we have a bird's eye view of this table, so we can actually just see it with the cons. So what does this table have? Well, it has storage space represented here. As you know, maximum storage capacity can be exceeded in survey. We've seen that with the SQL database you can go up to four terabytes depending on what capacity you have, whether it be or DTUs. Yes, you can go up to 100 terabytes if you want with the hyper scale. But there are also other problems. You have computing resource limits, so exceeding these might result in a timeout. Then you have network bandwidth limits. So, exceeding this can result in a failed request. Now, you can add more viscous. So this is called vertical scaling, or scaling vertically. So you can add disc capacity, processing power, memory, and network connections.

And this can be good in the short term. However, you may run into the same problem later. So perhaps there should be another solution, a more permanent solution. All we can do is we can take this table and we can divide it up. Now, there are lots of ways we can divide it up. For example, we could divide it up if this was, as it said, a sales order detail by month or by year. So we have 2015 in one particular table, one database separate and from a completely different database with the 2018 data, from the 2021 data, from 2024. Each of these could be in separate tables or in a separate database. You'd need some way so that when requests come in, you would have a way of going, "You want this particular data." Well, it's in here. So this is called "scaling horizontally." Now, there are reasons why you might want to consider this. Yes, it adds to the complexity, but if you've got hardware limits, you no longer have to worry about them because you can scale them out. You can increase performance by putting small amounts of data in a single partition or a single database. And multiple data stores can be accessed at the same time. For instance, if you've got these areset up as separate databases, each of which will have its own separate hard drives. There could be security considerations.

So you might have sensitive and non-sensitivepartitions, as we want to see later. For administration You could have different strategies for monitoring, management, and backup per partition. Now, I should tell you that backing up a particular partition can be a lot quicker than backing up the entire data set. So let's suppose we had from 2015 all the way to 2024. Well, that could take a long time to back up. But if we had instead a backup strategy of just backing up the latest month daily and then maybe the latest year monthly, and then these archived, we only need a long-term backup. You can have different hardware services, premium or standard, as required, and you can increase availability. So, for instance, if for some reason, 2015 data fails, Well, while it's offline, yes, we wouldn't be able to access it, but you'd be able to access all the rest of it. Now, if you're doing this sort of strategy where we're taking the same data and dividing it up into different partitions, which is also known as database sharding or sharp sharding, then we could, for instance, have a lookup strategy. So we could have a table which has a shardkey and a map which shows where they are stored. So, this offers as much control as you need. So you can say that for any particular role you have in this particular database, this particular shard. Of course, it does require additional overhead, of course, on that. Or you can use a range strategy, as I was suggesting earlier, so we could have it by month or by year. So you can use sequential shards keys in ranges.

So similar data is kept on the same storage node, so you can retrieve multiple items in a single operation. So, if I wanted to have everything from the fourth to the seventh of January 2024, well,that would be in the same shard. If I used the lookup strategy, we might have data from the fourth, fifth, and sixth years, and we'd have to get it all up into the same query. Now, this doesn't necessarily provide optimal balancing. For example, you might be in a seasonal industry, and so your November table might be much bigger than your June table. And rebalancing these shares is difficult. How do you rebalance June? Do you have to split it up or something? And then there is a hash strategy where there is some random element for distribution, so it reduces hotspots because there is no cluster that is going to be more used, or this particular shard isn't going to be more used by any of the data that is distributed evenly among the shards, so you have a more even data load distribution. Computing hash, which is what you need for this hash strategy, might increase over time, and rebalancing the shards can be difficult.

And of course, if you're trying to get getsequential data like from the fourth to the seventh of January, well, again, just like the Lookupstrategy, you'd be all over the place. So the lookup strategy is using an ashard key where you can control it. The hash strategy is one which is done more randomly, and you've got, of course, the range strategy. Now you can use file groups to help you find it. Groups can't be used. In the Azure SQL database you've only got what's called a primary file group, but in the virtual machine and in the managed instance you can add additional files, datafiles, put them into file groups and then say OK, I'm going to create this partition function. So if you have a value, let's say this is your sales order detail ID. If this value is one or less, then it goes into the first file. If it's 100 or less, it goes into second. If it's 10 or less, then it goes into the third. Anything else goes into the fourth. And these are the individual files. So you create the partition function to say okay, these are my limits, and then the partition scheme to say okay, we're using this particular partition function and putting them into these files.

So partition function is concerned with what goes and partition scheme is concerned with where it goes. Now, this is just one way of partitioning. So this is a table partition. Another table partition is if we split the table up. So, for instance, this is probably not the best example, but maybe we have some of the data in one particular table or partition and some in another partition. So each partition holds a subset of the columns, so you might be using some much more frequently than the others, and the others can be separated away and only retrieved when needed. Additionally, some cons may be more sensitive, and they can be separated away, then you can have different security considerations. Now, of course, we would need some way of being able to join all these partitions. So you would need, for instance, the same primary key in each. So that's how you can partition tables, how you can partition databases. Well, you don't need to have all of your tables in the same database if you don't want to. And this is called functional partitioning. So we can have different tables in each partition. So here's one partition, and here's another relating to function. So store data could be in one partition, employee data or address data could be in another. So some tables could be more sensitive. For instance, address details could be sensitive to things like the GDPR, the General Data Protection Regulation of the European Union.

So they could be separated away into another partition with additional security requirements. So these are some of the techniques that you can use for horizontal partitioning or sharding vertical partitioning. You can also scale vertically as well to add more compute power and other things like network and functional partitioning, where you can partition the tables according to a function. And these techniques can be combined. Where possible, you should keep the data geographically close to the users so that it can be accessed with less latency. You should obviously consider the ease with which you can do each of these, but you should also consider the backup. So when we're talking about having said the 2015data since that several years ago, how often does that really need to be backed up? It's not going to change archiving, including deleting. So do you need all of the data? Is there now a time when you can just archive the data offline and only bring it back? Or what's called rehydrating it when needed? Also, think about high availability and disaster recovery requirements for your partition. Again, the 2015 data. Do you really need such high availability? Maybe you do, maybe you don't. And what about disaster recovery? You probably need a quicker response time for newer data, more active data than you do, perhaps for 2015. And of course, if you need a quicker response time, you might well have to pay extra to achieve it. So this is the Data and Table database. Partitioning strategies include partitioning, also known as databasesharding, vertical partitioning, functional partitioning, and just adding more resources to an existing database. also called "scaling vertically" or "vertical scaling."

8. 72. evaluate the use of compression for tables and indexes

In this video, we're going to have a look at compressing data tables and indexes. Now, first of all, why should you compress? Well, you get reduced to space, so that's useful for data which is infrequently used. The downside is, however, it takes extra time and compute power to compress and retrieve the data. Now, there are three main types of compression, one of which is, of course, none. There is no compression whatsoever.

The second way is raw compression. So individual rows? So, for instance, suppose we had a Char60 as opposed to a bar charts Char 60 contains 60 spaces of data, or 60 characters. So, char and Char will be compressed. You can get savings of around up to 50%in English, German, Hindi, and Turkish; and around up to 40%in Vietnamese; but only about 15% in Japanese. So it really does depend on what your language is. Char and NVA types already have a compression technique, so there wasn't actually a benefit for compression. Now, for numbers like INTs, everything apart from tiny into storage can be reduced. Moving down to one byte. Tiny into itself only takes one bite, so that can't actually be reduced. Certain types of dates, like date time, date time two, and daytime offset, will be compressed. Others won't actually benefit from any compression.

So that's raw compression. It looks at what it can compress for each of the individual items, but it's highly dependent on the field types. So VAR, Charles, Enchase, and timings won't be compressed at all. And only daytime, date, and time will be compressed in the date types. So you'll have most of the savings in Char and Char. Now, you can also have page compression. Now, this consists of three operations. First of all, raw compression, which we've already talked about, and then prefix compression. So I want to show you what that is. Suppose we have got this table, so you can imagine there is a fair bit which can be compressed. So we start off with garden equipment or house equipment with all of these. So what I can do is put garden equipment up top and house equipment up here as well, so I can say prefix one and prefix two. And I'll also include the space at the end as well. So in this bit, what I can do is say garden equipment space changed to prefix one and house equipment space changed to prefix two. Now, of course, it won't actually be called prefix one, prefix two, and it won't take that many bites. So you can see, hopefully, how much more compact it can be. So all of this is put into the page header into an area called the compression information structure. It's actually just after the page header, so references are made to the value in the prefix.

And there is one more additional item which I didn't put in how many characters there will be. So let's say there are 17 characters there. So this will probably say, give me the first 17 characters of this. So that's useful if we have garden things. So if that's the case, we can't say garden equipment, but we can say, give me the prefix one, but just the first seven characters. So that's prefix compression. Dictionary compression is done after prefix compression. So prefix compression is done by looking at one particular column. Dictionary compression is looked after for all the columns. So if the values after prefix compression are the same, then this can be optimized. So let's say we had another column and, for some reason, we had prefix one four. Well, if it made any sense, then that could be put into the compression information structure. And there's my prefix free. And so this gets replaced with the prefix free. So you can see the idea it's looking for things that it can move into the compression information structure.

So we got raw compression first. Again, that's dependent on file types or column types. Then we have prefix compression, which is about the same column, and then dictionary compression, which is about all the columns. Now, there's probably one more bit that you need to know about: page compression. What are pages? Well, a page is a set of rows and it's up to 8192 characters. That is called a page. So pages are uncompressed at first. Page compression is only used when additional roles can be fitted on a full page. So let's say that we go back to the beginning and let's say that this is sufficient for an entire page. And I want to put an extra rags in here. Well, it won't fit. So the question now is, well, how can we make it fit? Well, we can use all of these compression techniques. Now, I should point out, compression doesn't affect backup and restore.

As a result, this is available in Azure SQL Database, Azure SQL managed instances, and some SQL Server instances on virtual machines. It's available in SQL Server 2016 Service Pack One in all editions. Before that, it was only available in the very expensive Enterprise edition, the top of the line. So what can you compress? You can compress tables. So tables are either stored with a cluster index or without. So a table without a clustered index is called a "heap." You can't use data compression with tables that have sparse columns. So if you set up a particular column to be called sparse, meaning there's not much data in there, and you want it to have a certain amount of space reduction, then you can't use data compression on those tables. If you want to change the compression option, say from raw to page or raw to off in a clustered index, then you would need to drop the clustered index and rebuild the table. You can also compress the indexes. So you can compress a non-clustered index. By default, they are not compressed. You can also compress a complete index now. You can't compress system tables. Now, in the previous video, we were talking about partitions. If you've got a table with lots of different partitions, then different partitions can be compressed using different settings. So let's see how you can enable compression. Well, you can go to the table or anything else and go to Storage Managed Compression. So you can see that option with indexes storage manage Compression.

So if you do that, then you'll be given this screen here. Welcome to the data compression wizard. And what sort of compression do you want? neither raw nor page So you can see how many rows there would be. And if you have lots of different partitions, then they'll be shown that you can also use the same compression type for all partitions. Now, if this wasn't an Azure SQL Database, you could also calculate the amount of current space in the compressed space. However, in Azure SQL Database, that functionality doesn't work. So click Next and you can either run it immediately or you can create a script. So what I'm going to do is create a script for a new query window. And here you can see the SQL code. So it is alter table, name of table, reboot partition, so it could be one, for instance, two, or all. And then with data compression equals page, raw or none in brackets. And it's a similar thing for an index. As a result, we both index the name of the index on the name of the table. So let's say we got this index on a particular table and then reboot partition equals all with data compression equals page, raw or none.

Now what I'm going to do now is connect to my on-premises SQL Server. So this could be like, for instance, a virtual machine. And you'll see if I go down to arable, if I go into storage and manage compression, and you can see we can create partitions there. As I said, partitions aren't available apart from the primary partition in Azure SQL Database, and say, I want this to go into a raw or page. You can see that we do actually have a calculation of current space and requested compressed space as well. Now we can also estimate it in TSQL, but again, we can't do this in Azure SQL Database. So if I create a new query, I can say execs mate data compression savings. So then I would need to put in the schema name, in this case, DBR, the document or object name. So, in this case, TBL employees and other things. If I wanted to, if it was an index, I could put the index number, the partition number, and the type of compression I'm looking at. And you can see at the moment we go from 88 GB to 80. But as I say, that doesn't work in the Azure SQL database. So I'll just close that now. Disconnect.

This sort of table, which is called a raw store table, so it stores it in pages with lots of different rows, isn't the only kind of object. There's also a column store table as well. So unlike the raw star, which stores all these rows, and there's one page and then another set of rows on another page and so on, the column store concentrates on individual columns and then mashes them together whenever needed. It was initially used for data warehouses but then expanded to include a column store table or any other object. Columns are always compressed. So this is column store compression. Now, indexes work best when you scan large amounts of data, like fact tables in data warehouses, column store indexes, and they're generally clustered. No clustered column store indexes are only used when a data type, such as XML, text, or image, is not supported by an clustered index. So the major thing about column store objects is that they're already compressed. Now they can be compressed further using column store compression by using column store archival compression. So what that does is save even more space.

We don't need to go into the ins and outs of how this works. But the major thing you need to know about column store archival compression is that it's best to be used when the data is not often read but you need the data to be retained for regulatory or business reasons. Yes, it does save space. Yes, it does save input and output. However, there is a very high compute cost to uncompressing it, which far outweighs any saving that you might have for the I or the input output. So don't use it unless it's for data which is not often read and you want to save the space. The data needs to be retained for regulatory or business reasons. And of course, on the web, saving space means saving money. So for column store tables, they are already compressed using column store compression. We can compress it further using column store archival compression but for raw store tables, so the standard tables, then you can choose from NUM, you can choose from raw, and you can choose from Page, which has three elements: the raw compression, the page compression, and then dictionary compression, which looks at all of the columns on a particular page.

9. 14. set up SQL Data Sync

In this video we're going to see how we can set up SQL data sync. Sync. Short for Synchronization. So let's suppose that we've got these three databases. So it could be that we have an Azure SQL database and another database which is an anon prem database, or it could be a virtual machine. Now, what Azure SQL Data Sync allows you to do is synchronise data across multiple databases. Now, in order to do that, your tables need to have a primary key, and you can't change this primary key.

So if, for instance, you have a row with a primary key of 200 and you want to change it to 300, then you would have to delete the raw and add the raw and say this is a primary key of 300. It's not a huge restriction. Additionally, it doesn't work with Azure SQL managed instances. So you've got to have the Azure SQL database in the VM or on-premises version. So what we need to do is define one of these Azure SQL databases as the Hub database. So let's choose this one. So that's the Hub database, so the others, therefore, will be member databases.

So these are either Azure SQL databases or Onprem or VMs, so not managed instances. And the idea is that if anything changes in any one of these databases, it gets replicated. So if it changes in the Hub, then it goes out to the member databases. If it changes in a member database, it goes back to the Hub, which then goes out to all of the other member databases. So we've got bidirectional changes here, so we can have changes in any one. Of course, there should be some sort of conflict resolution. If I change something in both a Hub and a member database, then we need to say, well, the Hub wins or the member wins. Now how can we set it up? Well, we need a database which is going to keep track of everything. We call this a sync metadata database. So this is going to be an Azure SQL database which is going to be in the same region as the Hub database. Microsoft suggests that it should ideally be an empty database.

So, in other words, it's one that you can create at the time of setting up the SQL data sync. There will be tables created and there will be a frequent workload run. So we're nearly there in terms of visualising what it is. Just one additional thing for any on-premiseVMs. We need, in addition to the sync hub, which is automatically set up here, we need a programme called a Sync Agent. So that's the way of basically doing this arrow. So much for getting information in and getting information out. And here you can see that you can download the data sync agent for your onpremises databases here. So I'll just download it very small, ten megabytes, so let's run this. You need to be able to put in a username and password that can reach the SQL Data Sync Service. So it needs to have network access. So I'll do that now and click Next and then we can install it and in just a few seconds it installs. Now if you get error messages saying that you don't have sufficient permissions to be able to install it, then make sure your username and your password are correct. So for your username, I've used my computer name, then a backslash, and then my account. So I'm on Windows ten. I have a Microsoft account. So this is my email address, the password, that is the password for the Microsoft account and not your PIN that you would enter.

So you may enter a four-digit number to open up your computer. It's not that. So it's your Microsoft account. So for that, you can check whether you've got the right password by going to your account at Microsoft.com and signing in there, where you'd sign in with your email address in this case and your password, which is not 3579, which is something a bit more complicated. You can find your email address if you're using Windows ten by going to the Task Manager and clicking on Users at the top. You can find your computer name by going to yourFile Explorer and going to My Computer or Computer or this PC, right clicking, and going to Properties. So I see my device name just here. So that is how you can install Microsoft SQL Data Sync Agent. But that only needs to be used if you have another Prem or a SQL Server on a virtual machine. It doesn't need to be set up for an Azure SQL database. So now let's go into Azure itself and go into the portal, and we'll go into our SQL database. So not the server, but the database. And if we go near the bottom of this page, we can see data management sync to other databases. So I'll click that. So we don't have any sync groups and we don't have any sync agents.

So I'm going to go to a new sync group. So create a sync group on the Hub database. So this here database is your Hub database. It needs to be in the same region as the sync metadata database. So we're going to give it a sync name. So this is a sync group name. We can use an existing Bit database. So there is my server, or I can create a new database. And if I create a new database, then we'll get these configurations, including the configured database. So I'll just leave it at that. So I'll just put in my metadata database name, select my server, and set the pricing tier. Fine, just leave it as that. Click "okay." Now, automatic sync refers to whether or not a device performs an automatic or manual sync. So you can see that there's a frequency that you can also get it to synchronize. I'm just going to leave that off and then the conflict resolution. So what happens if a hub database changes a record, a row and a member database changes this as well? So who wins? I'm going to say the Hub wins. You can see if there's a private connection as well. So you can see it is now submitting, putting it into a JSON, an Arm template, and deploying it. So I'm just going to pause this video until it's deployed. So after a few minutes, you can see that the deployment succeeded and that the sync group name was created.

So I need to refresh this. And here we can see this sync group name, the database sync group, which has got one database at the moment, which is my DP 300. So here I can add an Azure database or I can add an on-premises database. So if I was to add an on-premises database, then I would next have to choose a sync gateway. So I'll just create a new agent. So you can see I need to download the client sync agent. I need the agent's name. So this is something that you make up. So this is my sync agent name and I will create and generate a key. And you can see it's processing. And here you can see an agent key has been generated. Use this key in the installed clientsync agent to register this agent. So I'm going to copy it, paste it to the clipboard. Then I launch Microsoft SQL Data Sync on my desktop. So I'm going to submit the agent key name and that opens up this dialogue box and there's my agentkey and then the login and password used by the local agent to connect to the sync metadata database. So this is your existing username and password for the member database. And then you can test the connection, make sure you have the firewall all set up and everything else. Now, if you want to add additional databases to your databases, this is why you do it. So add it to your database and it needs to be existing. So you may notice that there are no options to create a new database. You've also got sync directions.

So does it sync from the Hub to the Hub? In other words, both directions are bi-directional from the member. And then you need to put in your existing username and password for the member database and then say whether it uses a private link or not. And then when that's done, you can go to the tables. So I'll go to a particular database and you can select the tables to sync. And tables without a primary key are not supported. So that might be why I can't see anything here. So you can see there's a bit of work that needs to be done to be able to set this up. But once you've set it up, then you will have databases that have been synchronized. So to do this, we go to your hub database, we go to sync to other databases, we add a new sync group, we add any sync clients that might be necessary for your osprey, and then we can add any tables that you want to synchronize. And then by the end, we will have a hub database synchronizing with these member databases, which can be Azure, SQL Database, on Prem, or VM member databases.

Prepared by Top Experts, the top IT Trainers ensure that when it comes to your IT exam prep and you can count on ExamSnap Administering Microsoft Azure SQL Solutions certification video training course that goes in line with the corresponding Microsoft DP-300 exam dumps, study guide, and practice test questions & answers.