Fun joke heard at a recent conference: “What color is the sky when you have no clouds? Azure.” Cue big laffs at Microsoft’s expense. The reality, though, is that SQL Azure – the version of SQL Server that lives in Microsoft’s Azure cloud computing service – is a pretty important product. Especially for organizations that only use SQL Server to support third-party applications, cloud-based databases promise to offer less overhead, more turnkey operations, and other advantages. There are potential downsides, of course, but this article isn’t about whether or not Azure (or any cloud service) is right for you; it’s about what the “Reluctant DBA” needs to know if their organization does choose to push some of their data into Azure.
The neat thing about SQL Azure is that, by and large, you manage it a lot like you would manage a local SQL Server installation, only you don’t worry at all about the actual hardware. You still get to create logins, you still have databases, you still rebuild indexes, and so on. Azure isn’t like the “shared hosted SQL Server” that hosting providers have offered for years; with Azure, it doesn’t look like you’re sharing anything with anyone. In many respects, it’s as if some Microsoft ninjas broke into your datacenter, picked up your SQL Server computers, and carried them off to their data center. Apart from the location of the hardware, not much changes.
That said, the Azure team – like most of Microsoft these days – is buying into Windows PowerShell in a big way, and the SQL Server technology teams are continuing to expand their support for, and reliance on, Windows PowerShell. So if you’re planning to automate any of your SQL Server tasks, start wrapping your head around PowerShell right now. If, however, you’re only looking to manage and maintain a few Azure-based databases from time to time, then the GUI tools you know and love can continue to do the job. Azure’s big deal is that it moves the computing activity out of your own datacenter, and that it can make your data potentially available anywhere in the world through the back-end magic of the platform itself. What Azure doesn’t do is really change how you plan, secure, maintain, or troubleshoot your databases. Backups don’t even become less critical: You’re not likely to face a disaster recovery scenario with Azure, but you still may want the ability to roll a table back to a specific point in time to undo some unwanted change, and backups are still the key to that.
From a DBA perspective, you’ll be facing the following tasks:
- Rebuilding and reorganizing indexed on a regular basis. Azure doesn’t change the way indexes work or how SQL Server uses them.
- Grabbing backups with whatever frequency is appropriate for your organization.
- Managing logins and database users, as well as database roles, application roles, and other security principals within SQL Server itself.
If you’re already used to performing these tasks in a local SQL Server installation, then performing them in an Azure-based database won’t offer you a lot of challenges. That’s actually one of the biggest selling points of Azure versus other companies’ cloud offerings: It works (more or less) just like the SQL Server product you’re already used to