Six months ago how you would go about setting up Active geo replication for your SQL Databases would be different to today, yes things (naturally) do change but for this specific area it has changed for the better – again something that you would expect right?
If you know me by now I like rebuilding indexes and that is no different in Azure. Now we have the ability to resume a paused rebuilding operation rather than cancelling it (Feature currently in public preview). I like this because I have the flexibility to pause it if I feel that it is taking up too much DTU (Database Transaction Unit) usage hence I can free up resources for other operations.
Who should be running DBCC CHECKDB for Azure SQL Database? Should it be Microsoft or should customers be scheduling it? All official information just tells you that you CAN run it (below shows the green tick) but still no clarity around the question.
Quite a mouth full for a title but never the less very exciting. With the new version of SQL Server Management Studio (SSMS) 17.2 You now have the option to use Azure AD authentication for Universal Authentication with Multi-factor authentication (MFA) enabled, by that I mean use a login via SSMS that is enabled for MFA where below I will show you the two step verification using a push notification to my iPhone. (Yes iPhone I love it)
Scaling up and down your SQL Database is something that is quite common to do. I want to discuss the impact of moving up and down tiers, in terms of your transactions and connections.
Azure does a lot for your SQL Database, from backups to automatic tuning but it still doesn’t have an index maintenance policy straight out of the box via the portal. Some may not care about rebuilding your indexes but it is still something I like to do, the question is, how can I automate this because I am not a fan of manually running code for index rebuilds.
The answer is via Azure Automation.
So the decision to move to the cloud has been made but there is a fear from people that once it happens they will lose control of their job function. Does this sound familiar? DBA’s, you will be needed but expect some sort of change (That’s my opinion).
Once you go cloud, there is no going back. This is false and from a database perspective you can migrate back to your own set of servers.
We all want high performing applications and when you are in the cloud that is no different, if anything it is even more important. With this post I will discuss some areas where I have been “stung” by so you can learn from my mistakes when using Azure SQL Database. Then I will dedicate a section on what tools you can use to help with your performance tuning exercises.
So here we go, the first installment of my cloud blog series. From my experience this concern is a common one, especially when relating it to the database layer. Data “leaks” via security breaches have been getting some real negative press lately, what tools and techniques do you have to protect your Azure SQL Databases? The answer is – A LOT across different components and that is what I will cover in this blog post.
