Traveling to SQL in the City Austin today, and it’s a busy day. Getting ready for this event and then 3 more on the other side of the world. A republish today: No State Based Deployments.
Category: Editorial
-
What Limits Do You Want in 2019?
SQL Server 2019 is in development, and likely getting close to being released. I mean, it is named 2019, so I assume we’re down less than 6 months of time before we start deploying it. One of the decisions that Microsoft will need to make before release is what the costs for each edition will be, as well as the hardware limits involved. I assume other items like OS support and feature mix will also be decided, but those are less important to me after SQL Server 2016 SP1. Most features just work on all editions.
Recently Glenn Berry proposed some new limits. He requests that 2019 Standard edition raise it’s core limit to 64 and the RAM limit to 256GB. These would be raises from 2016, where we were limited to the lessor of 24 cores or 4 sockets and 128GB of RAM. We do get 32GB of RAM for In-Memory objects and 32GB for columnstore as well. There were no changes for SQL Server 2017.
What do you think? Are these limits that make sense in a world where hardware advances and a “small” system is much larger than anything we used at the turn of the millennium? Since data sizes continue to grow and most of us want (and need) more hardware, is 128GB of RAM crippling to a small database server? Do you think that more cores are needed to run a Standard Edition server?
I might also point out that raising limits might keep some people on Standard Edition, but it might also get more people to move from SQL Server 2008 to SQL Server 2019, Standard to Standard. At lower limits, when you might be limited to processor and not core licensing, why not stay on 2008 if you can’t get a much faster system?
Personally, I think that Microsoft ought to raise limits somewhat. I do think 256GB of RAM makes sense, even if that includes the In-Memory and Columnstore usage. For cores, 24 to 64 seems like a lot, but what about 40 cores? Who cares on sockets, let’s make this simple. Cores. These days, no one is going to get 8 sockets at 4 cores each, but if they do, what does it matter? Let them use all of them on Standard Edition.
Steve Jones
Listen to the podcast at Libsyn
-
The Other Jobs
There’s a meme of sorts going around Twitter. It asks for your non-tech jobs, and I’ve seen some good ones from Grant, Kendra, Erin Stellato, and more. There are some interesting ones, and a few that I’m glad I never had to try. My list is here:
- Ice bag packer/delivery
- Waiter/bartender
- Lawn service supervisor
- Lay water/sewer pipe
- Volleyball coach (current)
In my youth, I had a few more (newspaper delivery, painter), but I’ve had paying computer jobs since I was about 16, off and on, and I had a lot of restaurant jobs. I’ve actually been a cook, busboy, delivery person, waiter, bartender, and manager. I always enjoyed restaurant work and even had some part time jobs even as I was starting my career in tech. These days I certainly have ranch jobs, usually assigned by my wife, and I do coach competitive youth volleyball over the winter.
I know most of us have more in our lives than tech, and some of us might even have second jobs now, whether by necessity or for fun. This week I’m curious what other jobs you’ve held and which ones you enjoyed. Perhaps there were some you hated. Let us know how rounded your work history is.
As I get older, I think about other jobs. Not that I want to leave Redgate or SQLServerCentral, but I’d like to retire at some point and still have something that occupies some time. Volunteering somewhere, with a commitment as a real job, is something I hope to do at some point. Volleyball is great, but one thing I’m looking to try is holding babies at the local hospital. Many of them need companionship when they are born premature or ill and parents need a break. Seems like a good gig to me.
What interesting job would you try in retirement?
BTW, I know some of you worry about these as a security question, but I’ve never seen this listed as one of my choices. If you have, then please don’t answer.
Steve Jones
Listen to the podcast at Libsyn
-
Serverless Databases
I wrote about serverless applications recently. Not a lot of people are using serverless technology for their code, but a few have had a lot of success. It seems like a move that makes sense, though there are some challenges in managing the code when you deploy functions or snippets instead of an entire codebase. I worry a bit about tracking billing, usage, versions, and deployment pipelines with serverless, but I know things will get better over time.
Now Microsoft Azure has included a new option for databases: Azure SQL DB Serverless. This is a SQL Server database that bills you for the compute cycles used by the second. This works by essentially pausing your use of the database processing when clients are not accessing the system. You are still billed for storage all of the time, which makes sense, but storage is cheap. The system also has quite a few automatic scaling features, many of which aren’t as simple to understand as I might hope.
How many times have you purchased a server (or rented one) and found it is barely used, trundling along at 10-20% CPU? I’ve done that quite a few times, especially when I had no idea of the workload early on. Later, it’s often not been worth my time to try and consolidate the database on another machine. Often this is often a fear based response where the cost of the machine is already gone, and I don’t want to take the chance that a burst in workload will overload another system.
For sporadic use applications, serverless databases might be a good fit. I can avoid paying for compute during low periods, such as overnight. I’m essentially renting a machine at specific times and not at others, but the compute layer gets provisioned as I need it. That seems like the ideal situation for a lots of apps, assuming I can run them in the cloud. There are some restrictions in preview, such as the inability to pause the system unless there are 6+ hours of no activity, but I’m hoping that changes. Six hours seems like a long time.
The one thing I think about this database service is that it will require longer timeouts and more resilient applications that can handle a warm-up period if the computer layer has been shut down. I also worry a bit about cache and the buffer pool. If you’ve ever dealt with servers that regularly restart, there is a bit of a slow period as the buffer pool fills and code is compiled. Perhaps Microsoft has ways of saving off some of these states, perhaps capturing plans in the Query Store that can avoid excessive compilations on restart, but I do worry that slow starts will increase user complaints and tickets filed. Those costs might not be worth the savings from shutting down your database resources.
Steve Jones
Listen to the podcast at Libsyn
