Core responsibility of a DBA is to make sure that the databases they are responsible for are maintained properly. In a nutshell this usually means that you are taking backups of the data, checking the consistency of the databases and maintaining statistics and indexes. Performing these tasks gives the DBA the ability to provide the agreed SLAs for the system.
However the trade-off for doing all these tasks is that it requires some computing resources and it can sometimes impact the performance of the connecting applications, and through that the SLAs in a negative way.
In this post we’ll look at how to implement low impact database maintenance routines for environments that have large databases and are accessed 24/7 by the users.
Very recently I was working on a customer databases, when I more or less stumbled on a something I had not noticed before. Apparently at some point the latest version of SQL Server (I was working with Azure SQL DB) had a new security enhancement added into it called Feature Restrictions. As this was something I had not heard about before, I figured this would be a good opportunity to dig in and learn more about it.
Note: As I was finishing up this post to add links and such, I noticed that the official documentation from Microsoft regarding Feature Restrictions has completely vanished.
I just realized that it has been awhile since my last post, so I figured it’s time to do one before the end of the year. Last few months have been rather hectic with me migrating new workloads to Cloud as well as taking the time to visit PASS Summit 2019 to learn more about Microsoft Data Platform.
I also wanted to finish up my year of blogging by writing about a topic close to my heart, the evolution of the DBA role in the Cloud era. I did have a session about this topic in SQLSaturday Finland earlier this year and I will be doing a PASS Cloud Virtual Group presentation about it on January 16th.
In this post we’ll be looking at one of the Cloud technologies that have significant impact on the DBA role in the future, Platform-as-a-Service databases.
You’re now reading the 4th and final post in my SQL Server Backups to Azure series. In previous posts I’ve described how to setup an Azure Storage Account, Blob Storage container an how to take SQL Server backups there. This time we’ll take a look at one more option that puts our backups on autopilot, with destination to cloud!
The feature I am writing about is Managed Backups, option that has been available since SQL Server 2014 but one that I have not seen often used. One reason for that maybe being, that there’s an unfixed feature that makes enabling it bit difficult if you’re not aware of the workaround.
Despite this shortcoming, if you have SQL Servers (on-premise or Cloud) but no DBA to care for them, I’d recommend that you take a look at this option.
You are now reading the 3rd part of the 4 part series on backing up databases to Azure. In Part 1 we looked at some of the benefits of using Azure for your backups and in Part 2 we setup the Storage Account with the Block Blob storage container.
In this post we’ll take a look at how to use the freshly created Blob storage with our customized backup routines.
Backups, backups and backups. That’s pretty much my answer to what should be the top 3 priority topics that any DBA needs to understand well. And that’s what we’re going to be looking at this post, backups! Backups play a vital and important role in keeping your data (and in some cases your career) safe, but they are also great way to migrate data from one location to another.
In this post we’ll look into migration scenario, how to move data from one instance to another and then back again.
Filegroups are an interesting and useful (if not actually all that fun, despite the title) concept within SQL Server. They provide not just a way to group objects like tables together, but also provide a mechanism to help us to speed up the backup, restore and recovery of the databases. And sometimes they can even give us a little help with the performance or to migrate data to disks that have more space available.
In this post, focus will be in archiving a table that we no longer need by making a read-only copy of it. In a real world scenario we’d also consider putting that to a slower disk, if it’s not frequently used, but my demo environment only has a single data disk.