[Video] Office Hours 2016/10/19 (With Transcriptions)

This week, Brent (and only Brent) answers your questions about table partitioning, best practices for VMware configuration, rebuilding indexes, transitioning from physical SQL failover cluster to VMware or Hyper-V, database backups, security issues with cross-database chaining, and why you should never use vague adjectives when describing database sizes.

Here’s the video on YouTube:

You can register to attendnextweek’s Office Hours , or subscribe to our podcast to listen on the go.

If you prefer to listen to the audio:

Podcast: Play in new window | Download

Enjoy the Podcast?

Don’t miss an episode, subscribe via iTunes , Stitcher or RSS .

Leave us a review in iTunes

Office Hours Webcast 2016-10-19

Brent Ozar: All right. We might as well go ahead and get started. It’s eight minutes after the hour. Now, we’ll start going to the questions, folks. Don’t forget, get your questions in now because we may end up coming fast and furious and I just go first come, first served, so if you get them in later, you probably won’t get caught.

First question is, “We have done the table partitioning, but we did not get the performance. Why?” Yeah. That’s actually really common. Most of the times, when we see partitioning implemented, it makes queries slower rather than faster.

In order for partitioning to make your queries faster, one of two things has to happen. You either have to be loading and deleting your data at the whole partition level. Meaning, like you delete a whole partition at once, you load a whole partition at once, and you don’t have any overlap between the other partitions. If you do that, you can utilize a technique called ‘Sliding window loads’ that you let you load a separate table, and then swap in just one partition. That only makes your loads and deletes faster though. It has nothing to do with SELECT Queries.

That’s the first scenario where partitioning goes faster. The second scenario where partitioning goes faster is when your WHERE Clause in your SELECT Queries, when the WHERE Clause specifies the exact couple of partitioning keys that you use or the one partitioning key that you use so the SQL Server can narrow down your SELECT to just one partition. If SQL Server can’t do partition elimination, then you’re still scanning all of the partitions. It’s not going to be any faster. If you go to ‘Brentozar.com/go/partitioning’, we’ve got a whole series of posts explaining how you can tell whether or not your database makes sense for partitioning or not.

The big clue is if you’re doing OLTP type work, if you’re doing inserts, updates, and deletes of individual rows and your SELECTs, the WHERE clause doesn’t have your partitioning key in it, partitioning is going to make things worse instead of better.

Next up, we have a question that says, “Is there a document that outlines the best practices for VMware configuration for SQL Server?” VMware actually has several, so if you search for ‘VMware SQL Server best practices’ or ‘VMware SQL Server performance tuning’, VMware has put together several documents. The thing is you’ve got to read them with a critical eye because they’re not perfect. For example, VMwares, the last time I looked at their best practices for SQL Server, it advised you to start with single processor VMs and they mean one core. There’s a couple of big problems with this.

The first problem is if you’re licensing by VM, the smallest license you can get is four cores. Sure, you can go buy a two core pack of licenses, but the minimum you’re allowed to buy for installation is four cores, so if you’re licensing by the guest, you’re just leaving performance on the floor. The second part to that is I don’t know about you, but I like doing backups. I like doing check DB, and if I’ve only got one core, that can make it very easy for the SQL Server to feel unresponsive or overloaded when I’m trying to do say a transaction log backup which I hope to God is happening on a fairly regular basis. You have to read through these guidelines with a little bit of a critical eye and start asking questions, but they’re a great place to start, so search that just for that on VMware.

Next up, Heather says, “I have a replication question. I’m getting an error about the length of lob data to be replicated exceeds the maximum of 64K, but I’ve already configured max text replication size to negative one. Where else can I look? I’m on 2008 R2.” I actually don’t do any replication work myself at all, so I would hit good, old Books Online.

Then, if you don’t find it in Books Online, watch the slides that are rotating through on the screen. Those of you who are only listening to the podcast, you don’t have this luxury, but there’s a link on there for Stack Exchange. If you go to ‘DBA.Stackexchange.com’, there are several people on there who are great with replication. Tara Kizer, even our own Tara Kizer who’s now on the screen does a lot of replication works or has done a lot of replication work in the past. She can answer questions on there as well.

It’s funny and there are certain black holes in my knowledge area. Replication is a big one. SSIS is a big one as well. CLR is another big one.

Next question, “We have databases created from various master databases”.

Not exactly. They say “We’re looking to move to Amazon RDS. Databases that have the same family GUID isn’t allowed in RDS. Is there any way to change the family GUID?” I’ve never seen that.

I’m not exactly sure what you mean by that and I’ve never seen that restriction before. Do me a favor because I’m personally curious about that because I do a lot of RDS work. Email us and email us with a couple of different things. I want you to include the exact error that you get when you go to restore it over in Amazon RDS, and I’m assuming that you’re doing in a restore because that’s the only way that I would see a problem with family GUID, so yeah. Just give us the exact error. If it does turn out to be something that RDS truly doesn’t allow, the crappy way that you’d have to do it is to do an insert into the brand new database using something like SSIS or BCP.

Those are horrible options. I would much rather have you be able to do just a restore, so email us the exact error message. Don’t put it in here in the Q&A panel because I won’t be able to dig deep enough, quickly enough.

Our next question, “I rebuilt my INDEX, but it’s still fragmented”. There’s a few possible different reasons for this.

The most common one is it’s a really small object. It has less than say a hundred AK pages in it or in cases like that, SQL Server may not just be able to cram those pages absolutely full because you can’t fill up all the pages. You just don’t have that much data. It can also have to do with the s