Voice of the DBA

Author: way0utwest

Adding the Right Value

I caught this post about a career presentation from Kendra Little and it resonated a bit with me. The summary of the post (it’s a bit long) is that there is valuable work that supports and benefits a team of people, called glue work. However, glue work isn’t necessarily technical and it isn’t necessarily recognized as valuable by management. In fact, it might unintentionally lead you from a career in engineering to one in project management.

I haven’t been someone who has been marginalized in positions, who has been taken for granted or expected to do certain tasks. I think some people get taken advantage of, and this is especially true for women, who both volunteer more and are volunteered by others more for these tasks. While I have been quick to document decisions or actions, and sometimes help out with project work, I do that in addition to any technical work. I’ve felt that as a developer, my job is to produce code. If I can help with other things, then I’m a Developer+, but I ultimately know that code my clients can use is what matters.

I think that people sometimes mistake valuable work for the team with valuable work for the people looking at the team. They know teams fall apart because someone doesn’t do the glue work. Or they have a s*** project manager who isn’t managing the project. I think that is very common, and because many of us have an “I need to succeed” mentality, we sometimes stop coding to pick up other tasks, essentially volunteering to be the pseudo-project manager or team manager. That’s fine, but if you fill your days with non-coding tasks, you are not moving toward senior engineer status.

At the same time, I know that many of you don’t want to work long hours, nor do you want to let tasks drop that need to be handled. There’s tension there, as either the employee feels overworked and taken advantage of, or they work themselves into burnout.

Sometimes there isn’t a choice and your boss might expect you to work extra hours on tasks adjacent to or related to your work. I have seen a few people work for one of the big-name tech companies where employees had tasks outside of their normal work that they were expected to complete outside of their core 40 hours. If you have a boss like that, I’d look for a new position. That’s my advice. I’m happy to work extra hours in limited doses, but not on a regular basis.

I’d say the same thing if your fellow employees don’t step in and do their share of the load of glue work. If we’re a team, we all do those things. If we don’t, we’re not a team, and I don’t like working in places where we aren’t a team.

Whatever you decide to do, make sure that you are clear on what is expected of you to get that raise/bonus/promotion and focus most of your efforts there. It doesn’t matter what you think is important; it matters what those who make decisions about your career think is important.

Steve Jones

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

Note, podcasts are only available for a limited time online.

January 8, 2025
Using Flyway Prepare for State-Based Deployments
One of the neat enhancements made to Flyway was the addition of state-based workflows and tooling. A lot of people have loved SQL Compare or SQL Source Control for deployments. As I’ve worked with customers, they’ve asked for this, and the v11 version of Flyway includes this for the Enterprise edition.

This post will look at using these two commands to deploy a change to a database from the command line instead of Flyway Desktop.

If you want to know more about Flyway, all my posts are together in one feed.

My Current Environment

I have Flway v11.0 installed and I have two databases: FWState_1_Dev and FWState_3_QA. These two databases are in my flyway.toml file, where I see them configured as development and qa.

I also created a “deployments” folder under my project, which is where I want deployment scripts. I’ll do this manually, but in a pipeline, I’d do this in an automated fashion. As you can see, this is an empty folder.

In Flyway Desktop (FWD), you can see that I have a change made in my dev db that’s ready to deploy. I could click “deploy” and run this from FWD, but I want to experiment with automation here, so I’m practicing at the command line.

I can verify this change isn’t deployed by checking the database.

Let’s get started.

Flyway Prepare

The prepare command is designed to create the deployment script. It can use a variety of sources, but in this case, I’ll use the schema model that I’ve saved in my git repo. This is where I (in general) want to pull from, using PRs and branches to manage work. In this case, I’ll pull from main, where I’ve got that change.

To get my changes, I’ll use a few parameters with Flyway. One thing to note, each of these parameters includes a namespace. I think this will go away at some point, but it’s good to be explicit in any case as we have lots of “source” parameters in different namespaces.

Second, use a single hyphen. That somewhat offends my unix/linux’y self, as the parameter names are more than one character. I’m used to 2 hyphens, which generate an error in Flyway.

The basic parameters I’m using are:
- prepare.source – the location of my source. In this case, the schemaModel defined in my flyway.toml file as “schema-model” in the file system.
- prepare-target – the target to look at to build the script. For me this is an environment preconfigured (see above) as qa, so “env:qa”
- prepare.scriptFilename – the default is D__deployment.sql, but I want it in a subfolder, so I’ll explicitly put this in.
My CLI call is this:

flyway prepare -prepare.source=schemaModel -prepare.target=”env:qa” -prepare.scriptFilename=”deployments\FWState__deployment.sql”

When I run this in my project folder, I see these results:

If I look in my deployments folder, I see the file:

The contents of the file are here:

This looks like what I’d get in FWD if I clicked “Deploy”.

This step just created the file. I need another call to deploy this.

Flyway Deploy

The Flyway Deploy command will execute a deployment script against a target. The idea here is that one script is created from a state-based project and deployed with this command.

As with prepare, I’ll use a few parameters here. The ones I need are:
- scriptFilename – the file to deploy. I’ll use the same one as above.
- environment – the name of the environment where I am deploying, in this case, no need for the prefix.
- executeInTransaction – this should default to true, but I’ll be explicit as I might change this in different platforms (postgreSQL, Oracle, etc.) and so if someone copies this pipeline, I want this to be clear.
This gives me this command:

flyway deploy -scriptFilename=”deployments\FWState__deployment.sql” -environment=qa -executeInTransaction=true

When I run this, it works.

I can verify this in SSMS.

I’ve deployed changes, and if I look at the FWD deploy tab, I see no changes.

I could put these two commands in a pipeline and have them work in an automated fashion.

If you do that, use variables in your pipeline, or ensure people commit (and merge) changes to the flyway.toml file that is used for the various options.

Summary

This post showed a quick way to start automated state-based deployments in Flyway, using the new prepare and deploy commands. A few options were used to control these deployments from a command line.

There are more options that you can include to control deployments and I’ll look at some other ways of doing this in the future. For now, this gets my deployments working easily.

Flyway is an incredible way of deploying changes from one database to another, and now includes both migration-based and state-based deployments. You get the flexibility you need to control database changes in your environment. If you’ve never used it, give it a try today.
January 8, 2025
Monday Monitor Tips: Lots of Postgres Options

Redgate Monitor is growing to include more than just Microsoft SQL Server monitoring. We added PostgreSQL support in 2023 and that continues to grow. This post looks at a few changes we’ve added.

This is part of a series of posts on Redgate Monitor. Click to see the other posts

PostgreSQL Monitoring

When we added PostgreSQL support to Redgate Monitor, I assumed that we could monitor most types of PostgreSQL installs. I was very wrong. Apparently everyone that’s forked or used PostgreSQL in different ways has changed how a DBA might need to monitor the system. At first we monitored on-premises installs only, but that’s grown.

AWS

We now support RDS. If you search for bluebox, you’ll see a PostgreSQL RDS instance. If you click in the card, you can see the workload, and more specifics on this RDS database.

We also support Aurora, if you use that version. Search for pizza and these cards appear, the right one being Aurora. This is an AWS Aurora database, based on PostgreSQL.

Azure

We also support Azure Flex PostgreSQL database. Search for the pgtips database and you’ll see this card.

If you’re in the cloud with AWS or Azure, we have some PostgreSQL monitoring available for you, with more coming all the time.

Give Redgate Monitor a Try

Redgate Monitor continues to change and grow. Look at our demo system at monitor.red-gate.com and click the What’s New in the upper right, where you’ll see all the new features, like the PostgreSQL support changes.

You can also see the release timeline for more specific features in each version.

Redgate Monitor is a world class monitoring solution for your database estate. Download a trial today and see how it can help you manage your estate more efficiently.

January 6, 2025
The Rise of Data Centers

For the last few years, we’ve seen no shortage of cloud migration stories and felt pressure from management who wanted to migrate our systems to the cloud. It seems that almost everyone I speak to has a story of having to move a system out of their owned or leased data center into a public cloud from some vendor. A lot of this is the movement of VMs from one place to another, which has me scratching my head. If we’re just running VMs, surely we can do this cheaper in our own data center.

Perhaps, though there are a lot of costs to setting up or running a data center, and it’s not easy getting a system in place that allows a bit of self-service for our customers. Especially while ensuring that images used are properly patched and secured, while ensuring lots of easy connectivity to storage that can be reconfigured easily. It might not be worth the effort for a few dozen VMs, but if you have hundreds of systems, maybe it is.

Maybe it’s happening. I keep seeing stories about repatriation from the cloud. I also caught the global data center trend report, which shows a lot of growth in the data center world. Vacancy rates are low and there is continued demand for building more data centers. Some of this is due to public cloud providers, some is from AI companies who need lots of power and GPUs, and some is from private companies looking to collocate their systems.

The world is becoming more and more dependent lots of servers in data centers. I expect that we will continue to see more data centers built, but I expect fewer and fewer private, corporate data centers. More than likely all of us will use someone else’s data center, even if we choose to own the computing systems. Even Basecamp, which left the cloud, is using a collocation facility for machines, which means they are using a facility owned by another organization and shared with other clients. However, they own the servers they use, which are just located in someone else’s data center.

If any of you have private data centers, my guess is most of those will slowly fade away over time. The cost of running them privately will exceed that of what vendors will charge. Data center vendors can spread the cost of buildings, power, networking, cooling, etc. across multiple clients, often hundreds or thousands. While you might not be in the cloud, and you may still own your own computers, you’ll likely store and connect them in someone else’s data center.

That means that most of us will need to be comfortable with limits on the hardware deployed and amount of upgrades available. In the cloud you’re limited to what vendors provide. In our own collation spaces, it might be what our core IT group makes available. I still expect database servers to be among the largest machines available, but there will still be limits to what most of us can provision. After all, most IT groups still want some standard configurations shared by most of their servers. That might be an interesting trade-off for some of us as the cloud might be more or less preferable in certain situations.

Steve Jones

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

Note, podcasts are only available for a limited time online.

January 6, 2025