Voice of the DBA

Category: Editorial

  • Expanding into Print

    This is part of a few memories from the founders of SQL Server Central, celebrating 25 years of operation this month.

    When we started SQL Server Central, our goal was to build a great resource that helped other people advance in their careers and also made some money. Our decisions in building the site were based around the digital world and treating the community as we would want to be treated. Over time, however, we realized that continuing to grow this business was hard in a digital-only world. We experimented and proposed helping others build similar sites, like ReportingServicesCentral (which would have been great) or NotificationServicesCentral (which would not), but ultimately, we weren’t experts enough in those areas and couldn’t find people willing to partner.

    Everyone thought they could do it themselves and that the knowledge was the hard part, and execution was easy. The truth is that the reverse is the way it works.

    In any case, there was a point in time when we were sending 6 newsletters a week (Monday through Saturday) and we didn’t think there was much room for growth there. Andy suggested that we compile all our articles into a Best of SQLServerCentral book. I didn’t think they would sell well (they didn’t), but we did enjoy giving them away at our annual SQL Server Central Party at PASS. We even added a second series where we compiled the Question of the Day series into books, based on the Two Minute Mysteries I read as a child. We called them SQL Server Stumpers. Those were hard to manage, and were multi-month long projects that I had to toil away at almost every week.

    Then came the magazine: SQL Server Standard.

    In the early 2000s, the Professional Organization for SQL Server was trying to grow as well. We knew magazines were popular and profitable back then, so we proposed helping them produce a magazine every other month (6 times a year). They were charging an annual membership fee and needed to give members more value, so we agreed to produce, publish, and ship a magazine to all their members. It was both a source of tremendous stress for me to manage, as well as a proud item I could point to every month.

    I wish I had some online links, but this was intended to be a real-world, analog item. We hoped it would grow to be a substantial revenue item, but it never did and PASS shut it down after around a year of publication.

    I was glad because these projects were a never-ending source of stress. Managing book projects that were 4-6 months, along with the every-other-month magazine, and a daily newsletter was overwhelming at times.

    Our forays into the print world provided me with a lot of education about how books and magazines work, and gave me a few mementos.

    Steve Jones

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

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

  • The Power of Data and Privacy

    I tend to be fairly careful with data, especially data on this site. When we started the site, we were worried about potential issues and worked hard to ensure we kept our systems safe and limited the attack surface area for personal information. We also declined the various offers we had to sell our list of subscribers to marketing firms. We know that some places add value for marketing, but some abuse the trust of their users and our approach was always to be careful.

    When we sold the site to Redgate, we emphasized the need for this trust, and to date, Redgate has been a great steward of your personal information. I regularly field requests for uses of data from other marketing people, and almost all get declined. I’ve had a number of great managers who have supported me on this because we value your privacy.

    Recently I saw a piece from Troy Hunt, asking who deserves privacy. He runs HaveIBeenPwned, which tracks data breaches. There have been some sensitive breaches, like the Ashley Madison breach, and he has decided to handle some of those differently. I appreciate that, even though I don’t visit any of those sites, I do think there can be unintentional consequences from revealing too much data.

    We certainly have plenty of problems with public data, which was never intended to be accessed at scale. Once someone can query lots of data from one place, they can correlate and use it in ways we never imagined.

    In the piece Troy notes that he has been attacked by some people because he has chosen to redact certain information. This is censorship of a sort, but a) this is a private site, and b) there are good intentions. This service was never intended to be a weapon, and I agree with that. I have rarely censored anyone at SQL Server Central, but it has happened when someone becomes harassing and unprofessional. Our forums are great for civil debate and disagreement, but not for personal attacks.

    I am glad for the restrictions that the GDPR and similar legislation has placed on how companies used data. It has made many individuals and organizations more responsible with how they handle data internally. It hasn’t necessarily helped with data breaches, but at least there are less intentional abuses.

    Data has tremendous power at scale and my view is similar to Troy’s: we all deserve some level of privacy.

    Steve Jones

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

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

  • The DBA is Dead; Long Live the DBA

    I remember getting a job at a startup in the Denver Tech Center. This was shortly after SQL Server 7 was released, with a marketing campaign that the platform was auto-tuning and wouldn’t require a DBA. My colleague asked me if I wanted to learn Cold Fusion and have a longer career. I declined and stuck with this SQL Server thing, which has seemed to work out pretty well over the years.

    I was reminded of this when I saw a “Death of the DBA Again” post, this time from an Oracle DBA. There are plenty of links in there from Larry Ellison and Oracle about how some version of Oracle won’t require a DBA. I’ve seen questions on Reddit (and elsewhere ) about this topic where people seem to think DBAs can be replaced.

    Or maybe they want them replaced.

    There are no shortage of posts on why this isn’t the case (Grant, Kellyn, Brent, William, Boris). These all look slightly different, but the main thrust is that there is still data management-type work and people are needed to do it. Or maybe to direct the AIs to do it.

    An interesting post from Kendra last year that we will see less DBA jobs because good DBAs can leverage AI to replace a few less-good DBAs. I like her approach, and the key reason why AI agent usage will grow is that they can potentially just make less mistakes than a human.

    If that human making mistakes is you, then you might not have a job.

    I do think that the DBA as a gatekeeper or a single point of managing systems and ensuring backups/security/patches are made is dwindling. However, there are still lots of places for database-related work. High Availability setups are needed; someone has to work with InfoSec and auditors and implement their requirements. That might be especially important as those requirements might not be clear and clean enough for all your systems. While ETL might be a thing of the past with the various “links”, without a doubt, people will link too many tables to analytics systems, leading to overloaded systems, too many resources being used, and costs being too high.

    That might be a reason we will still need some type of DBA. They need to field the complaints from budget holders and work on resolutions to reduce costs.

    The DBA will continue to exist in many organizations, but the job will change, and you need to evolve. There might be other organizations that don’t want a “DBA” as a title, but they will need a data engineer, a full-stack developer spending more of their time on the database stack, an InfoSec person that mostly works on database security, or some other job that absorbs all the data-related chores.

    There is a lot of opportunity still out there, but the bar is being raised, and one end of that bar rests on AI. Improve your skills, show your value, and become someone who delivers results and doesn’t just say “No.”

    Steve Jones

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

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

  • When SQL Server Central Went Down

    This is part of a few memories from the founders of SQL Server Central, celebrating 25 years of operation this month.

    “The site is down.”

    I got a phone call from one of the other founders around 9 am in Denver one day. At the time, I was working at a small startup, in a semi-private office with one other person. Most of the company knew I had a site on the side, and alternately cheered me on or celebrated hiccups, depending on the person.

    I checked, and things were down. I had a side channel to telnet into the server, but couldn’t access things. At this time, the site was hosted on a single server, running IIS and SQL Server, in a friend’s basement. This was in 2002 or 2003, and broadband was a lot different then. No cable internet, and most other solutions were in the kbps range. I had ISDN at my house, but a friend had gotten into a trial from Sprint, giving him 3Mbps over a microwave link.

    My office-mate was listening and watching. I said I was taking an early, and long, lunch. She chuckled and went back to her own tasks. I let my boss know and started driving, stressed out. After all, the site was growing, popular, and downtime could be a killer.

    We’ve had a few outages over the years, but not many. This was one of the more stressful ones as I fought traffic on I-25, trying to get from the Denver Tech Center up to Westminster. I can’t remember the weather, but I was sweating when I got to my friend’s house. This was the before-times, when remote work was a rarity. Luckily, my friend had left me a key to get into his house, where I ran into the basement. Unable to get the server to respond, I rebooted it and crossed my fingers.

    I’m sure a few of you have had the stressed-out feeling of waiting for a database server to restart, hoping that it comes back up cleanly. It did this time, and I don’t remember what went wrong, but things were back up and running with no major issues. I was probably in the basement for less than 30 minutes, and I left, dreading the long drive back to the office. Almost two hours driving for a 30-minute fix.

    I do remember thinking if this was going to be a regular occurrence, I might need a new job. Or a new place to host the server.

    We weren’t in the basement for too long. Revenues were increasing enough that I started to look at co-location facilities. My current employer had investigated quite a few when we set up our systems, and I reached out to a few contacts. I negotiated a half-rack at some point, moving our servers to a real facility. By that time, my employer had failed, and I got an F5 firewall as part of my severance, which fronted SQL Server Central for quite a few years.

    Those were the days, with lots of CLI access to remote systems and a power strip where I could cycle them off and on. Those were skills I had to learn to avoid more drives at inconvenient times.

    Steve Jones

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

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