Voice of the DBA

Category: Editorial

  • The Need for 256GB

    I have seen a few people call for raising the RAM limit in the Standard Edition of SQL Server. In 2016, Aaron Bertrand voiced this, and for 2019, Glenn Berry asked that the limit be raised to 256GB. In the last newsletter of the year, Brent Ozar asked Santa for a 256GB limit.

    I wonder how many of you would really take advantage of that. In the Azure SQL Database pricing table, to get beyond 128GB of RAM, you need to go to 32 cores. For Azure VMs, you need to purchase even more cores.  AWS EC2 VMs require 32 cores to get to 256GB.

    How many of you use this many cores for your SQL Server Standard Edition instances? I’m sure some of you do, but is it many instances that require this many cores and RAM without Enterprise Edition? If you do run EE, then is it because you need more resources or because you need some other EE feature?

    Certainly, the use of lots of resources is likely something Microsoft considers to be a feature. They want more for licensing when you have a large workload. I don’t know if I think this is morally fair, after all the bits are really the same and there’s an artificial limit that doesn’t allow the use of them with more underlying resources.

    As a side note, this has made it into other areas. My Tesla offers me the option for more acceleration if I pay them US$2000. The hardware will already support this, but it’s a software unlock for a price. That feels strange.

    Across all the instances you have, how many of them have the need for more RAM? Perhaps a better question is whether your organization would allocate more RAM given the cost involved. I still see too many organizations that underspend for hardware when it would make a difference for customers. Of course, many of you might also get better performance if you learned to write better code that efficiently solves query problems.

    Steve Jones

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

  • Most of Us Are Vulnerable

    I saw this study recently, where most people think they are better-than-average drivers in the US. I thought about it myself afterward, and I think I’m maybe average. I do pay attention most of the time, I try to be more careful when it’s wet or snowy and give myself more time to slow down. I  try to be aware of the other cars and obstacles on the road. I also usually have a drink (coffee, soda, water) with me, and I certainly mess with the music player. The Tesla reminds me constantly when I’ve strayed near a line, so a few months of driving seems to tell me I’m not great. Certainly not above average.

    I would expect that most of us think we’ve done a good job with security for our systems.  We don’t expect to get hacked or deal with ransomware. I don’t know how realistic that is, as a recent set of penetrations tests shows the vast majority of networks are vulnerable.

    It sounds bad, and it is. It also is not likely to change as the complexity of many networks is high. There are so many devices, constant additions and changes to services and applications, and regular requests to grant access to a new group. It’s amazing there is any security at all, given how quickly people want to access systems and how impatient they are when they can’t connect.

    The data doesn’t show that every system is wide open, but there are ways in which every network can be disrupted. Whether this is significant or not is hard to assess, but given the reports I see in media, as well as private notes from friends, I suspect that most companies have plenty of work to do.

    It’s not all had work, however. I think many people that configure networks are careful and are wary of opening firewalls. The bigger problem, which continues to exist, is likely simple passwords from far too many people. That, combined with a lack of multi-factor authentication being rolled out, means that there a lot of simple changes that could make a big difference. I know my company rolled out a corporate password manager recently to all employees. This, combined with our MFA app on mobile devices means that we should have strong passwords and better verification of legitimate access for most systems.

    At least, I hope we do.

    Steve Jones

     

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

  • It Isn’t Worth Automating

    Every year I’m responsible for a portion of the Database Weekly newsletters. I used to do half, but right now Kathi, Grant, and I are on a rotation. Our boss puts out a schedule each year, which tells me the weeks for which I am responsible. Each January I then set up a recurring appointment for Mon/Wed/Fri on my weeks to remind me to curate articles and write an editorial.

    Each year I also think about whether or not I can automate this. Last year I spent a few hours looking into the Exchange APIs for creating appointments, at the C# code, and PoSh (which is a nightmare). I spent a few hours, got frustrated, and gave up, just manually creating appointments.

    This year I took a slightly better approach and tried to figure out how long it takes to create an appointment. I got a stopwatch and went through the process. Each recurring appointment takes about 30 sec to create and (a repetitive) 15 clicks. I have 17 weeks, so this is about 9 minutes (rounding) to get this done.

    That doesn’t seem worth automating. In a decade, I’d spent 90 minutes doing this. I’m not sure I could automate it in 90 minutes. I might learn a new skill, but I don’t do much calendaring, and honestly, I’m not sure I could do something I’d think would be reliable, portable to others, or even useful in other ways.

    Throughout my career I’ve had a lot of tasks like this as a DBA or developer. They are often short tasks, things I do fairly rarely, and are not tightly defined. Often I just do a little manual work rather than spend too much time trying to automate things. In my life, I’ve found similar tasks, where I’m not sure the time spent building automation or the maintenance requirements over time, would be worth the effort.

    I am, however, a big proponent of automation, and I think there are many places where the time spent is worth the effort. Periodically cleaning log files from servers, running data loads of know files, DevOps CI and CD processes, and more are worth the effort. Many people need these processes running often, and the work to get automation running becomes a time saver.

    Not everything needs to be automated, or even should be. Certainly, when the manual time or effort requirements are small, it pays to do a little analysis. If you disrupt the way humans do their work, then be sure your solution saves time or effort. As technologists, we often reach for the scripting/programming tools to solve problems, but be sure that you include a little thought before you start coding to be sure the process is worth automating.

    Steve Jones

     

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

  • A New Language

    In my life, I’ve mostly dealt with people that speak English. I tried Latin in high school and Japanese in university, but I wouldn’t say I learned a lot. This past year I’ve been working on Japanese (konichi wa) and French (Bonjour) on a regular basis, but I’m still fairly uni-lingual. At least compared to many of the people I’ve met in my travels that speak multiple languages. I’m mostly just trying to read a bit, and that’s quite hard.

    In my career, I haven’t met many technologists that only know one programming language. Even the SQL professionals know a little C# or a scripting language. Quite a few people know a bit about many languages, and some are very competent. I used to think it would be good to master one language before moving on, but I find that trying different languages can give you an appreciation for others, or even an appreciation for your primary one. Comparing and contrasting code might even help you learn faster.

    These days many of us are being asked to handle more tasks, and we may be required to support or work with code that others have written. As a result, I think it makes some sense to have a basic knowledge of other languages that you might encounter. I can often look at code in different languages and get an idea of what’s happening. I might even think about fixing simple bugs if needed.

    I saw a Data Exposed edition recently with Hamish Watson that was titled KQL: The Next Query Language You Need to Learn. I had heard of it, but never used it. After watching the episode I played with it a little. While I don’t know how important it is, I do appreciate I may run into it and will likely spend a small amount of time writing some queries and familiarizing myself with some of the common aggregates and other types of structures.

    Today I’m curious, which do you think you would learn as a next language? Not that you’d give up your current work in T-SQL or something else, but what else might be good for your career, or perhaps be exciting to you personally?

    I’ve enjoyed doing some work in Python and PowerShell over the last year, and time spent in R before that helped me appreciate those languages. There are places I’d choose to work in those over T-SQL, especially for data not already in a SQL Server.

    Take a moment and leave a comment: what new language would you like to learn and why?

    Steve Jones

     

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