Voice of the DBA

Tag: Friday Poll

  • 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.

  • What’s the Cost of an Hour?

    In 2017, we had a number of high profile downtime outages from companies. The British Airways fiasco, United airlines being grounded, Starbucks, Amazon, and more. There was a survey that noted 98% of respondents said an hour of downtime cost their organization over US$100,000. A third put that figure over $1mm.

    This week, I’m wondering if you have any idea what downtime costs your company. If you do, and can let us know, drop a figure in the comments. Maybe you can give us a range, or maybe you can say it’s a large amount. If you don’t know, maybe let us know if it’s not important to your business.

    I haven’t often calculated this, but when most companies look at lost revenue from customers, lost ability to conduct business, and potential losses from employees sitting around, it’s probably a large number. Then again, many companies might just force employees to work extra to make up the work, so perhaps some companies don’t care.

    This certainly isn’t a simple answer. Modern systems are often distributed, with many moving parts, and complex network connections. With modern software development using caching, micro-services, and feature flags, it’s entirely that an application is down for some clients and not for others. Or perhaps, a portion of the application is broken while other parts work.

    Downtime can be disruptive and expensive, and it is something most system administrators plan for and work to avoid. If you know what it cost for either the loss of a system or in your preparations, it would be interesting to know today.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The Developer Arguments for Stored Procedures

    In all of the decades that I’ve been working with SQL Server, many people have been preaching the benefits of using stored procedures, In all of that time, the vast majority of developers that I’ve worked with have not wanted to actually write, or even call them. In one job, I offered to write all procedures within a day of being asked for them for one development team, and they still didn’t really want to use them. I made them do this by revoking permissions on many tables, but they still grumbled about the overhead of using procedures.

    I was having a discussion with a friend recently about using procedure, and he was having a similar battle. There was a group of developers that wanted to embed SQL  or use LINQ->SQL in their applications instead of calling stored procedures. It was frustrating, but he managed to secure a meeting to discuss the concerns with the developers.

    As we talked, we tried to frame the problem from the perspective of a developer. Why would or wouldn’t you want to use stored procedures? We had a few ideas, but really, I’m curious what you think today. Do you have any debate points that make sense from a developer point of view?

    I certainly do understand the ease of just writing SQL in whatever IDE you use for C#, ASP.NET, Java, etc. I get not wanting to open up SSMS, which can be slow. I also get that it’s nice to see all the code in one place, and not have some split between the application and the database.

    On the other hand, the idea of encapsulating code in the database feels a lot like the reason developers refactor code into new classes and methods to provide a clean interface between different types of functionality. Many times developers work with applications and code split among different components. On top of this, when you use procedures you push a lot of the performance work down to the database and on the DBAs.

    If you think stored procedures do or don’t make sense from a developer point of view, let me know today. Leave a comment in the discussion and explain your position.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Favorite Cars

    Ars Technica recently wrote about their favorite cars of 2019, which is an interesting list. They get to test a lot and I read their reviews to see what they glean. I love cars, and enjoy driving different vehicles, and I’ve owned a lot in my life. I think I’ve probably owned and regularly driven 30 cars since I started driving at 16. There was even a period of a few years in my life where I traded in my car for another used one every 11 months.

    I do get to drive or ride in a decent number of cars as I travel regularly and do rent cars at times. In the past year, I managed to rent eight or nine cars last year, all different, though not very exotic ones. Still, it’s always interesting to see how manufacturers change their designs and add technology. I’ve been surprised how much I enjoyed driving around a few cars, such as the Kia Soul.

    This week, I’m wondering what you fellow data professionals out there like to drive. Are there any cars or trucks that you have look forward to getting behind the wheel of and puttering around? I’ve got a long break coming up and perhaps I’ll take a few hours and go drive something around. Give me some ideas of what you like, new or old.

    In my car history, I’ve had quite a few cars I really enjoyed. I’ve had 3 Isuzu Troopers over the years, all of which I liked. The two Suburbans (1988, 2001) I owned were both some of the vehicles I liked taking on trips. An old VW Scirocco in college was a great beach vehicle for me. My 914 and 911s are two I slightly regret letting go, but it was a good decision at the time. I enjoyed our first Prius, mostly because of the MPG when gas was US$4/gal, but it’s not a car I look forward to driving. I would like to get behind the wheel of hybrid Toyota CH-R and see what that’s like. That’s not in the US, but I could try the ICE version.

    My wife likes the Tesla, and I’ve ridden in a few. Not sure it’s the car I want, but it’s very interesting to drive. The idea of electric vehicles makes sense to me, and I expect to see more and more over time. Not sure if we’re ready for one, but we will likely look to get another vehicle in the next 2-3 years, so maybe that will be on the short list. Let me know if you think that’s a good idea.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.