I always follow a contained user model when setting up users within my Azure SQL Database. I do this so the user in question has access to only specific database(s) and does not have a login to the server. It becomes even more apparent the importance of this when you design a solution based on failover groups.
When a failover occurs to the secondary, I want a pleasant experience for the user. With the contained user model, the user goes with the database. I don’t want to do admin work on the new primary (post failover). Let’s see.
There is a new (ish) interface to looking and configuring backups for your Azure SQL Database. This can be found within the settings section of the SQL Server.
As you can see, by default we have 7 days retention to allow for PITR – Point In Time Recovery, anything longer you will need to setup long term retention.
If you are building database solutions in Azure , using Azure SQL Database then you will know that you have a purchasing option decision to make. That being should you use a vCore model or DTU approach?
Being in the cloud does have many benefits, from lower administration to fast scaling but another “side effect” of operating in Azure SQL Database is the cloud first nature of changes. By this I basically mean new features always get pushed to Azure first before the classic on-premises version so some gems come to light.
There are many factors to consider when you are thinking about the move to Azure SQL Database (PaaS) – this could be single databases (provisioned compute or serverless) to elastic pools. Going through your head should be how many vCores do you want? What are the I/O requirements, do we need access to certain features like in-memory OLTP? But what about the memory requirements? This has always been a key requirement for SQL Server – those wonderful words – Min / Max memory settings.
How does this relate to Azure? Well it all depends on your vCore count and the generation of hardware we select during the build process.
If you have been following me or generally topics around Azure SQL Database and security you would know that it is important to leverage Advanced Data Security (ADS) for Azure SQL Database, if you remember this meant having tools such as advanced threat protection, vulnerability scans at your finger tips.
Data engineers, pipe line developers, general data enthusiasts will be spending most of their time within a notebook. Here you develop your code, nice visualisations and commentary boxes are possible too, a very rich web-based interface and is best experienced with google chrome ( in my opinion).
I have spent many long weekends getting stuck into Azure Databricks, plenty of time to understand the core functionality from mounting storage, streaming data, knowing the delta lake and how it fits into the bigger picture with tech like Event hubs, Azure SQL DW, Power BI etc.
So, I am going to show you how easy it is to create a cluster (that’s the end goal), you will appreciate the ease of deployment for huge amounts of infrastructure.
All About Data 