Voice of the DBA

Category: Editorial

  • Highly Skilled

    The world of work has been changing quite a bit over the last few years. The pandemic appeared to be a boon to technology workers, both by allowing us to work remotely, but also taking advantage of our skills to deploy more technology throughout the world. At the same time, late 2022 and 2023 have seen many companies pull back and cut their staff, including technical staff. It seems that in mid-2023, we have both a demand for technology workers and a lot of people looking for technology jobs.

    A recent 2022 report on working in technology has some interesting insights. It is summarized at ZDNet, but you can see the original report here. The highlights from the report are that quite a few top performers left their jobs, recruitment doesn’t work well, and finding top talent is hard. These aren’t that surprising to many of us that actually write code or manage systems, but it is nice to see that founders and executives are reporting this (they were the ones surveyed in the report).

    For much of my career, I do think many executives have taken advantage of tech workers, pressing them to get more and more done with fewer resources. Even though many people were paid well (though not all), they may not have enjoyed their jobs. I’ve had a lot of great positions, but over the years, I’ve met a surprising number of people who wouldn’t recommend others follow them into their career choice.

    The pandemic made it easier for people to switch jobs since everyone was remote. That might not have benefitted lots of people, but it certainly helped top talent. If you’re one of those people, you likely got a better job, with better compensation, and hopefully, more interesting work to you.

    For others, we might still be looking for something new (or worried about the security of our current position). One of the main parts of the report talks about the problems with the traditional recruitment model. First, it takes too long, an average of 4 months to fill technical roles. There is pressure to speed that up, while also understanding that candidates will need some training and re-skilling or up-skilling to meet an organization’s particular needs. That would seem to be good for many candidates, but I think this report is biased to startups and newer organizations, not mature ones.

    I do think the impressions you make early are important. A candidate needs to ensure that they have technical skills. You should be able to solve problems but also think on your feet. Respond to the interviewer and showcase critical thinking. A developer should be able to answer general questions, like how to find duplicates in a table or sort data that is aggregated. You don’t need to solve all of Itzik’s query problems, but you ought to know some of them. I’d expect you to know the basics of this job. If you’re unsure, post a note on the forums and ask people what things they need to know to do their jobs.

    However, apart from the technical skills, you need good soft skills. A strong candidate will communicate well, display confidence, relate to the interview(ers), and build some rapport. They will look to ask questions that seek more information about what is asked, but without being confrontational or disagreeable. There’s a skill to debating a point rather than arguing with someone. The ability to get along with others and find synergy is important. When others think adding you to the team makes the entire team better, you stand a good chance of getting an offer.

    If you’re unsure of whether you present a good impression, get a few friends or co-workers to interview you and give you honest feedback. Maybe even ask a friend who hires people to mock interview for a position. Learning to present a better impression will go a long way toward increasing your chances of getting hired. Especially if firms are trying to make quicker decisions.

    Maybe the big change from the report is 80% of people surveyed say they are willing hire someone without a college degree. Whether they actually would to that, whether their HR or other policies allow this, and whether they convince existing employees to do this remains to be seen. However, many of us know that a college degree isn’t a good predictor of whether someone can do any job well. I hope future hiring trends confirm that.

    Steve Jones

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

  • Actively Choosing Compatibility

    SQL Server databases have had a compatibility level for a long time. This is a setting that enables the database to process code as if it were a particular version. The levels go from 80 (SQL Server 2000) to 160 (SQL Server 2022). Each time (almost) a new version of SQL Server has been released, there has been a new compatibility level.

    However, not all versions can support all compatibility levels. For example, my SQL 2022 instance can support levels back to 100 (SQL Server 2008). If I wanted to get a database to act like a version older than 2008, for example, 2005, I would need to install a SQL Server 2012 or older instance. There is a table of engine versions and supported compatibility levels on the ALTER DATABASE Docs page.

    When you create a new database, by default, it is at the current compatibility level. However, if you upgrade a database, the level might not change. There are some limits to which versions are supported, so an upgrade might change your database.

    An administrator might choose to keep an older level for compatibility purposes. Perhaps your code has an identifier that is now a keyword. Perhaps you expect some code to behave a certain way. However, not all changes are protected by the compatibility level. Most of the time, an administrator must manually change this, which is something that can slip through the cracks. If you don’t change this right away, likely it isn’t going to change.

    There was an interesting post from Brent Ozar recently that explained a bit about compatibility levels in a SQL Server database. I wonder how many people actually actively choose a level or they just accept the default level for that instance. Brent gives some advice in the post, and his recommendations vary a bit, depending on whether you are happy with the system or not. He also recommends measuring your system and then evaluating a change. Especially if this is a database for vendor software.

    I don’t think changing or updating this setting is a priority, but I also think that being aware of when your level doesn’t match the instance and documenting this is important. At some point, through many upgrades, you might find your level isn’t supported any longer. Then your database might have immediate issues. A good monitoring system can let you know when you have mismatches that can be evaluated when there is extra time to clean up or test changes to the system.

    Each version of SQL Server adds new features, like the changes for Intelligent Query Processing. In general, we want to take advantage of these if we can. However, not all workloads respond positively, so as Brent mentions, you need to test and evaluate your workload. Hopefully, you have a clear “things are better” or “things are worse” when changing levels. When you get some queries that perform better and some worse, then you have some choices to make. Often the default is “do nothing,” which may or may not be the best decision, but the devil you know is sometimes easier to deal with than the one you don’t know.

    That’s fine but consciously make that choice. Keep an eye on your system and don’t just accept defaults, whether those are from Microsoft or the ones you’ve left after an upgrade. Actively manage your systems to get the best performance you can for clients.

    Steve Jones

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

  • What’s Your Job?

    There are a lot of technology people looking for jobs these days, especially after all the layoffs that have occurred in 2023. At the same time, I have a number of friends and clients that are struggling to hire qualified people. They get lots of candidates, but they are dismayed at how little the candidates they interview seem to know, or at least how little candidates know in the areas that their organization has needs.

    Today, I want to help people get better at growing and managing their careers. Therefore I’m asking those of you that are employed to describe your job. Give us your title in the comments and then list 5-10 things that you’ve done lately. What types of queries have you written? What tasks did you complete with SQL Server or Azure SQL? Have you needed to research something to solve a problem? What knowledge or concepts helped you complete a task?

    The idea is to share some of the skills or concepts a person should have to grow their career. Hopefully, some people will then read descriptions and build skills from this list. They’ll try to accomplish the tasks you’ve had to finish, hopefully documenting or blogging about their work.

    As an example, I’ll give a few tech things I’ve seen lately from clients. These are practical things someone needed to finish, or something they asked someone else to do.

    I was working with a client and there was a need to find all the logins whose passwords were not set to expire. How can you do that?

    Another had a table had a lot of duplicate data, and all duplicates but the row with the latest date needed to be deleted. What does the DELETE statement look like? Caveat, what if I need to update all but the first row (newest) with a new value in some column to mark them as inactive?

    A client needed to get a list of all the servers from their central management server (CMS) and then extract that list as a CSV file. They were using this for some audit purposes.

    At another client, a developer needed to clone a git repository and then open the .sql files in Azure Data Studio. Can you show how to do this?

    A DBA wanted to decide whether you choose a clustered or non-clustered index for a table that contains sales information and is often queried for a few rows based on a date. Why would one index be better than the other?

    Don’t answer these questions, as this is homework for others. However, if you could share a list of things you would expect your new coworker to know or solve, that will help us raise the bar for what we expect from our colleagues.

    Steve Jones

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

  • How Many Days Can You Survive?

    I saw a great post from DCAC on disaster plans and using them after a fire in an LA data center. DCAC wasn’t affected, and I wouldn’t expect them to be. Denny, Joey, Monica, John, Kerry, and Meagan are all experts in running systems efficiently and effectively. They think about how to ensure that things keep working in the event of disasters and have delivered presentations all over the world helping you become better at managing your own servers.

    However, Denny brings up a great question in the post. How many days could you survive without IT systems? Days? Weeks? Have you ever been in that situation? I’m sure many of us have experienced a failure of some sort. An application crash, hardware dying, or most commonly, Internet access being cut. All of these are small disasters, which typically are fixed quickly. Hopefully, these aren’t issues you experience every week. If you do, maybe you need to call DCAC or someone else and fix more fundamental issues.

    While it’s unlikely that you lose all your systems, it could happen if you concentrate your resources in one data center, one region, one cloud provider, etc. Having a single point of failure is something we try to avoid in IT, and that is true not just for one application, but for your infrastructure design. Most of us depend on one authentication system, and a failure of our Active Directory could lock everyone out of a system. Those are rare, and hopefully, your administrators have enough redundancy (and backups) to recover from this type of disaster.

    I have experienced a few large failures at one enterprise. We had a few viruses, including the SQL Slammer worm in the early 2000s. Our network was shut down for a couple of days, when almost all systems from email to CRM to ticketing systems weren’t available. Everyone had to use whatever paper systems they could to keep business running. While we likely lost some revenue from these outages, we learned we could survive a few days without our network. We also learned that we needed better virus scanning and education for employees, as well as a few more resources for tech people. Before those events, everyone assumed an outage was bad, but had no idea how bad. I have no idea how much this cost us, but it didn’t appear in a 10-Q, so it must not have been too bad.

    I think there are lots of businesses that could find ways to continue to work if some systems were down. However, there can be costs, sometimes significant. Even if the company doesn’t go out of business, perhaps some people get terminated because of less revenue. That might not be the tech person in the short term, but how would you feel if your DR plan didn’t work (or you didn’t have one) and some co-workers were let go?

    The move to the cloud, and the move to more software-as-a-service systems, might help you better survive local disasters, but if you have too many systems concentrated in one place, it is worth preparing for some contingency. After all, even if this fire were to happen in an Azure or AWS data center, it’s possible that their process to move and restore all the systems from one data center to another could take time. Your systems might not even be their top priority as cloud vendors have some large customers. It probably won’t take months, but I wouldn’t want to bet my job on any cloud vendor getting everything moved in less than a week.

    If you’re not in the cloud, make sure you have a plan. If you don’t know how to do that, call DCAC or another consultant to help you.

    Steve Jones

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