Voice of the DBA

Tag: administration

Is the Time of the DBA Ending?

I ran across a piece on the fall of the DBA (or part of a piece), and wondered if this is the time when the DBA is disappearing. I do know that plenty of organizations never formally adopted the DBA as a position, and plenty more have abandoned it. Not that there aren’t people managing databases, but they have moved into Database Engineer, SRE, or plain old sysadmin. They might even have another job but function as an accidental DBA.

The DBA role has often been a mix of many things. Certainly, this is a tactical, operations role that keeps systems running, dealing with performance, security, and availability. DBAs also fix quality issues in production, deploy code changes, and often advise developers on what works well and what doesn’t. They tend to be a bit of insurance against things going wrong as well as the scapegoat when anything does go wrong. I found the DBA role to be a constantly changing, never-ending grab-bag of challenges on a regular basis.

Those tasks don’t go away with a title change, nor with a move to the cloud, the adoption of NoSQL data stores, or the move to a DevOps style of software development. They might get handled by another role or team, but they still need to be dealt with. The DBA might need to change titles or groups, and they might need to learn how to use automation, GitOps, or some other new protocol for handling the work. As the article linked above mentions, they may need to tackle work at a higher level, not the manual, click, click repetitive process they might have followed in the past. The trend is often to work smarter, not harder.

As with any change, there will be people who succeed and do better in the future, as well as those that find their best days behind them. I find change often brings opportunities if I am open to them and make an effort to look for those opportunities. You might find your title changes and you can ask for more compensation or more interesting work as the role changes.

Embrace change, learn something new and find a way to make change work to your advantage. There is always a way to make this happen.

Steve Jones

Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

March 4, 2022
Backup Architecture

I saw a question posted recently on what data is included in a full SQL Server database backup. I hadn’t seen that question in some time, but the post was a good reminder that this is not an intuitive concept, and new data professionals might not understand how a full backup works. If you don’t know, you should do a little research (and write a #SQLNewBlogger post for yourself).

The way a SQL Server backup works, either with an on-premises install or the Azure SQL Database version, is well known and documented. Even if you can’t make a “normal full backup” in Azure SQL Database, the process is the same. You don’t have to run the backup, as Azure does that for you, but you can specify a restore and understand which data will be available in your restored database.

Cosmos DB is a different type of data store, existing only in Azure and storing non-relational data. The service has been promoted quite a bit, and some of you might even be using it. Do you understand how backups, and more importantly, how restores work?

I ran across an article that discusses the way Cosmos DB continuous backup works. This process isn’t quite what I’d expect. Changes are backed up locally (either LRS or ZRS), which makes sense. However, all changes (called mutations for some reason) are backed up within 100s, asynchronously. That’s good, and it’s not perfect, but it’s pretty good. What’s more, you can restore a container, a database, or the entire account. That matches up closely with what I expect in Azure SQL, including the need to restore into a new account. What isn’t great is that stored procedures, triggers, and UDFs aren’t restored.

As with any sort of backup and restore operation, you should be sure you understand the way operations occur, the impact of restores, and the costs involved. You get charged for backup space and restores. Maybe the most important thing to know is how to perform a restore. If you have a problem, you want to be sure that you not only know the mechanics of restoring data but how to reconcile any potential changes between the old and new database, as well as how to ensure all other objects (stored procs, etc.) are put back in place and clients are directed to the correct database.

This process might not be as simple as MS Docs describes, and certainly, I’ve found SQL Server restores are not always as simple as we might like. Practice ahead of time and be sure you can recover a system in a way that meets your clients’ needs.

Steve Jones

Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

February 21, 2022
New Tagging in SQL Monitor to Keep Organized

I recently got an update from the SQL Monitor PM on the progress we’ve made across all the teams. We have a number focusing on different aspects of the product, and they’ve built an impressive produce over the years. I remember when it was SQL Response and only provided alerting. Now it’s an Enterprise Monitoring solution for SQL Server.

One of the additions that was added across the last few months is tagging. Traditionally the monitored instances and databases are organized in categories, which is OK, but very limited. Below you can see at monitor.red-gate.com that we have instances in various categories: production, azure database, staging, test, and simulation.

Tagging is a much more flexible structure that makes it easy to classify and filter your estate. There are plenty of cases where you might not only have an instance set as Production, but perhaps it’s a US or UK server and you want to know the geography. Maybe there is a need to know this instance also relates to CRM v a data warehouse system. Tagging makes that easy.

Filtering with Tags

At the top of the global dashboard shown above, there is a new filtering area where we can filter by tags. You can see below that I’ve filtered the 28 instances in our demo setup to the 2 that have the “sqlservercentral” tag.

What’s more, clicking in the tag box shows me the existing tags that are applied.

Tagging is also available on the Estate tabs.

There are a few other places, and it’s slowly making its way across the product to all areas. You’ll see it slowly appear in other places as well.

Adding Tags

You can add these in the Server Configuration, which works fine. Pick a server and then you can add tags that correspond to what you care about.

If I’m working with a server in the overview, I can also expand the right Alerts panel and in the top About section, I can adjust tags. A good way to fix these up as you work on issues.

Look for tagging to make it’s way into the PowerShell cmdlets as well.

There’s a post on the Redgate Blog about tagging as well. They are looking for feedback, so please send it along.

If you haven’t used SQL Monitor, it’s a great tool to help you keep an eye on your estate with minimal effort. You can get alerted of issues and even integrate with other tools. Download an eval and give it a try today.;

February 14, 2022
Think Marathon, not Sprint

I saw an article about automating responses to security issues being a marathon not a sprint. The articles gives a few examples of different levels of automation response to situations, noting that each of this is a different level of maturity in the organization. At early stages, the response is mostly alerting a human to take action. Later, the automation will make some changes, but still defer to a human for more actions. The final example is automation handling most of the issue itself. Note, none of this means humans are unaware of what responses are being made.

The idea is that improving security with automation is something that takes place across time, as the organization matures and becomes more comfortable and trusting of automation. It’s a marathon, where we push, but we know this will take some time to get to the end. It’s not a sprint where we make a quick fix and get a result.

Actually, I think a lot of things are marathons in the technology area. That’s if we are looking to improve how we work with automation. If we like just firefighting issues and building quick patches, then we’re constantly sprinting.

A lot of the work I do in advising clients about DevOps is to get them to think marathon. There isn’t really a finish line, but we are racing our competitors and trying to improve how we work. We just need to recognize that this is a process that takes months, not minutes. We want to mature and evolve processes, making them better over time. We also start small with our scope, hoping that we expand things to the entire organization over time, but again, that time is months.

This was my same approach as both a developer and DBA. Find something that I can automate to make better, start to improve it, learn from success and failure, and repeat. At some point, I usually found something was working well enough to move on to a new area to improve. If I needed to come back and continue to improve something, I could do that as well.

I don’t like sprinting. In real life, or in technology. I prefer to think marathon. We are pushing to achieve something, but with the further away future in mind, not the next few minutes.

Steve Jones

Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

February 2, 2022