Tag: administration

I’ve never been interested in working on large systems. I know some people relish the challenge, and certainly there is a lot to learn, but I’ve always valued my sleep and time with family. I like getting away from work, seeing my wife and kids, and I’ve found enough after hours work on (relatively) small systems to keep me occupied. To be fair, I’ve often dealt with large in terms of numbers of systems, rather than a large single system. For some reason, managing 200-300 instances that have 50GB databases is much less stressful than a 10TB single instance, at least for me.

In 1999, I was offered a job managing a 13TB database on SQL Server v6.5. I declined that job, and was glad I did. Running that system would have been a nightmare.  I think a 40TB SQL Server 2017 instance is likely easier to manage, though maybe Taryn Pratt would have taken either challenge. I was interested to see her writeup on migrating a 40TB database recently, though I’m glad I don’t manage this system..

Even if you don’t have a large multi-TB system, the challenges Taryn faced are similar to ones I’ve had on smaller systems, where I was still space constrained. In some places, a 50GB system might be limited in storage, and you might encounter some of the same issues. You also might have the same moving target problem, where the information you are moving keeps changing and your processes struggle to catch up.

This is the type of documentation and evaluation that I’d like to see more people produce about their daily (or weekly or yearly) challenges. Having examples of what worked, maybe what didn’t, and the thoughts behind solving problems helps others learn and grow their skills. Even if you only write this for internal co-workers, it’s a good learning experience.

It’s also good practice for your communication skills, which are going to be very important in the new normal of pandemic work environments.

I’d love to publish more stories like this, of how you solved the challenges you face as a developer or DBA. If you can write about things, send me a draft. If you need help anonymizing things for your employer, I’m happy to help. If you don’t want to do this publicly, at least consider documenting this type of effort internally. Others might learn, and you’ll have a nice item to present to your boss at review time.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

Many of us have worked in environments that have a number of SQL Server instances. Different versions, editions, and mostly different hardware profiles. We deal with different applications and software that places different demands and requirements on our database systems. Some of us are even dealing with multiple datastores, trying to integrate SQL Server with Oracle, PostgreSQL, Elasticsearch, Redis and more.

Keeping an inventory of instances and patches can be a challenge. I hadn’t thought this was a big problem, but I’ve been surprised how many people like the Estate Management Versions page in SQL Monitor. This gets a lot of use, as people work to keep track of their systems. With that in mind, I wonder how many people have to support the “average” SQL Server that Brent Ozar supports. He runs the SQL ConstantCare® service for his customers, and regularly reports on average data every quarter.

In his latest report, which contains data from over 3000 servers, we get a picture of what various organizations run for their instances. The version breakdown is what I expect, and I’m not surprised that 2016 is the most popular. This was a major release, with lots of changes. I think 2008 R2, 2014, 2017 were relatively minor releases. Few changes, and not good timing relative to other releases.

The data shows most people have supported versions, and I think some of the licensing rules and breaks to lead many people to think about getting Software Assurance to upgrade once in awhile. I also think it makes sense that many people manage relatively small databases, well under 125GB. If you do the math, 47% of these instances are these relatively small sizes. However, it is interesting to see nearly 15% of his clients are > 1TB. That’s quite a spread.

With data sizes like this, you see lots of smaller hardware sizes. I don’t know how this might compare with your organization, but it’s interesting to think about how you might fit into these averages. Is your organization doing a better or worse job of giving you resources for your data size? Keep in mind, there isn’t correlation here, so you don’t know if the 30GB database has 4 cores or 24 cores.

I think having data like this is interesting. I do wish Microsoft would release more specific stats, like the version counts and database sizes, with hardware averages for those data sizes. I know why this doesn’t make sense for them to release the data, but I still wish they would let us know more. As Brent says, they tend to present on really recent technology, which many of us might not use. I’m sure many of you have a variety of instances, but you’ll easily be able to see if your spread of instances looks like Brent’s client base.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

Many of you are administrators, maybe accidental ones, but you have some responsibility for ensuring your databases run smoothly. Part of ensuring this happens is monitoring resource usage, configuring security, and patching your system. However, the long term health of your database requires some proactive work to ensure things continue to run smoothly. One way of doing this is using checkdb to assess the health of your database’s internal structure.

Those of us that are full time focused DBAs likely run checkdb, though potentially not in the best way. There are implications to “offloading” this work to another machine. Those that are accidental DBAs, developers, or someone else with other duties might not think about checkdb as necessary.

Do you think about how you should run checkdb? Do you think about licensing issues? Do you think about the frequency and breadth of where you should run checkdb? I’m wondering what some of you do after I ran across a post from Brent Ozar on offloading this work. If you haven’t dug into how checkdb works, you might not realize some of the things that Brent brings up. Even if you think you know how this works, read the post.

I’ve usually been able to run checkdb in production, but I recognize that more and more environments can’t do that. Usually because of the resource contention. When I’ve had that issue, I’ve accepted a time lag to getting results. I don’t worry about finding out about database corruption a day later. I can probably deal with that. I worry about finding out a month later, when reconstructing data is much, much harder.

This isn’t to imply or recommend that you need to run checkdb on each production instance, but rather to get you to think about how checkdb works and choose a strategy that works well for your environment. Even if you have this set up, ensure your configuration still makes sense for your organization. Take a few minutes and read the post and then schedule a review with colleagues of your checkdb philosophy.

Steve Jones
Listen to the podcast at Libsyn, Stitcher or iTunes.