The Team You Want

Brent wrote about what a good DBA looks like and challenged people to write a testimonial for them. There are some great comments on the post, and some funny ones. It’s worth a read when you need a break from other work. I especially chuckled at the picture Brent used. I think ours was better.

That got me thinking: what do I want in a team? Or maybe, who do I want in a team?

I have a great team now, but we are fairly distributed and work independently. I have great co-workers at Redgate, though I don’t often work that closely with any of them. I work often with some of them, for specific things, but usually it’s coordination rather than the tight, back and forth I’ve often had with technical teams.

I realized at some point in my career that I was often being asked to do the same work. I needed to manage systems. I needed to write and tune queries (or rewrite those for others). I needed to manage security. Most importantly, I needed to find solutions to the constant set of questions, problems, and demands from others in my organization. I learned how to teach myself things, how to research, how to test, and how to talk to others. I became good at clarifying what people needed and then finding a way to meet those needs. I think I turned into part of the Incredible DBA Team, even though often it was a team of just me.

The characteristics Brent talked about were important to me.

A little. I have always felt that I could work with others if they want to learn from me and teach me things. They have to want to collaborate and get things done as a team. That led me to worry more about who I worked with than what the job was. If the compensation was good, then the decision to take a job often came down to who would I work with. After all, the work was often very similar.

Think about your situation. What do you want to see in your coworkers? I’m sure you want people that you get along with and carry their weight. Maybe you want to learn from them. Maybe you want to be able to teach them. Maybe you have specific skills you wish were stronger on your team.

Leave a comment and let us know what your ideal team looks like. As always, if you want to leave an anonymous comment, send me a PM on the site with what you’d like posted in the discussion.

Steve Jones

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

Posted in Editorial | Tagged | Comments Off on The Team You Want

Future Data Driven is Coming Sept 27 for FREE

The Future Data Driven 2023 virtual conference is coming on September 27. Register today and save a note in your calendar.

I have been honored to speak at this event in the past. I’m not speaking this year as I’ve been buried with work and travel and need a break. However, I see a great schedule (scroll down) with some sessions that I will try to watch. A few on my mind:

I can get information in other ways, but a conference is a good chance to hear what someone else has learned and shares with me. Even if I listen in the background, I’m learning some new things.

There are lots of other great sessions, so register today.

Posted in Blog | Tagged , , | Comments Off on Future Data Driven is Coming Sept 27 for FREE

Running Flyway from PowerShell–A Gotcha

I ran across an interesting gotcha while trying to run a Flyway command from PowerShell. Specifically, the snapshot command and providing a parameter that is the snapshot.filename parameter.

Someone reported an issue with Snapshot, so I tried it from a command line. It worked fine for me, but a sharp Redgate developer noted that the person was running something like this from PowerShell:

flyway snapshot -snapshot.filename="deployed1.snapshot" -url="jdbc:sqlserver://localhost;databaseName=FWSimpleTalk_1_Dev;encrypt=true;integratedSecurity=true;trustServerCertificate=true"

As you can see below, this caused an error.

2023-08-28 11_52_27-Window

I checked my version. Surely “flyway snapshot” was valid, and it was.

However, there is an issue here with PowerShell and the parameter. In this case, the PoSh will try to interpret this as

The issue is lightly explained in this SO question, though I can’t quite figure out where this is documented. However, using quotes around the parameter name fixes this. Note, I switched the parameter value to single quotes.

flyway snapshot "-snapshot.filename='deployed1.snapshot'" -url="jdbc:sqlserver://localhost;databaseName=FWSimpleTalk_1_Dev;encrypt=true;integratedSecurity=true;trustServerCertificate=true"

As you can see, this works.

2023-08-28 08_25_29-Window

PowerShell is closed to command shell, but not the same. Keep that in mind as you build automation. Be wary of how your parameter values might be interpreted and test lots of values.

Posted in Blog | Tagged , , | 3 Comments

Rogue Colleagues

The economy might be good or bad for you right now. Some of that depends on where you live, what your employment situation is like, what your habits dictate about how you live life, and more. No matter what your situation, likely there are people around you that complain about the world and others who think things are fine. There are likely more of the former than the latter, but that’s because humans tend to complain out loud more than they praise.

When people think there is an economic downtown for themselves, they may be more likely to engage in malicious activities. While I don’t think most data professionals will start to hack other systems, or even their own employer’s systems, there is evidence to support the idea that some might be susceptible to recruitment by bad actors. This piece references some research and warns security groups to be wary.

There is no shortage of books, or television and movie scripts that might show creative ways to access information, but how can you tell if a colleague makes a simple mistake or they are a bad actor? Clicking on a phishing email could be either one. Not removing anonymous access to an S3 bucket could be either. Losing their credentials through social engineering is something that happens every day. Who’s to say that this happened purposefully?

I don’t want to second guess the people I work with making mistakes, but I also think these possibilities are why we want to use our computer systems with strong auditing and multiple groups reviewing logs. We might not necessarily stop all activity, but we can often detect it quickly and mitigate the issues. It’s also why DevOps and automated deployments with logging are a good idea. They can limit the problems from both accidents and malicious actors.

My employer has started to do more education around security and how individuals can avoid accidentally causing issues. We use a lot of automation, and more all the time, that ensures once we know how we ought to patch and update systems, we can do it regularly and confidently. Repeatable, reliable deployments of changes are what we aim for.

We know they’ll be some mistakes, but we also know that we can quickly identify issues (MTTD) and fix them (MTTR). Even if we get a bad patch from a vendor, we can quickly deploy a “fix” if we get one, or even reinstall and re-patch to lower levels, if needed.

DevOps, GitOps, and other xxOps aren’t just about getting new features out quickly. They also include the ability to fix problems when the need arises. They don’t prevent rogue actors from causing issues, but they should help you detect and recover quicker than you might expect.

Steve Jones

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

Posted in Editorial | Tagged , | 1 Comment