Comments on: Knowing the Relative Value of Databases

By: Kmescha

Kmescha — Wed, 09 Dec 2009 14:33:34 +0000

Boy this reminded me of this post, where even within MSDB there is a lack of good indexing strategy.I have read many posts similar to this suggesting adding indexes to the backup tables. Always shows up on my missing index reports and is very distracting.

http://weblogs.sqlteam.com/geoffh/archive/2008/01/21/MSDB-Performance-Tuning.aspx

By: BradC

BradC — Mon, 07 Dec 2009 20:55:46 +0000

I’ll certainly agree that it isn’t ideal, but sometimes its necessary.

One specific vendor I have a lot of experience with (*cough*SageSoftware*cough*) seemed to provide barely-adequate indexes in their out-of-the-box product anyway, plus their software was so customizable that any larger install would need some production DBAs to look at all the custom tables/joins/fields and make sure they weren’t going to cause problems.

More of a combination DBA/application support role than a pure DBA, actually.

By: Fatherjack

Fatherjack — Mon, 07 Dec 2009 20:32:19 +0000

Brad, I havent dismissed any options. What I was surprised at was the appearance of TempDB on a server that I thought was doing OK in terms of performance and I wondered if its the case in general or if I really do have a problem. What I have dismissed is moving TempDB to another server(!).

We have plenty of systems on that server so I think any performance issue is a “death from a 100 cuts” issue rather than one single culprit. This will make it harder for me to locate the quickest win(s).

I am still interested to know what % of activity on the files stored on a server would be the TempDB files – < 20% | 20-40 | 40 – 60 | more ? … ?

Some vendors have said for me to get in there and let them know what indexes work for their application, others have said the polar opposite and we lose support if we change anything. Others are in the middle.

By: Brent Ozar

Brent Ozar — Mon, 07 Dec 2009 20:30:55 +0000

Ouch – I disagree strongly with the suggestions of index tuning and plan guides.

For index tuning, the problem I’ve seen (disturbingly often) is that 3rd party apps will come out with an upgrade, and that upgrade script will include several database tweaks. The tweaks assume that the database is exactly as the vendor installed it, down to index names. If you change an existing index, or add one with a name that the vendor later decides to add, the vendor’s upgrade package can explode. Guess who gets the blame? The DBA. I’ve also seen vendors flat-out refuse to support databases when they’ve noticed schema changes done by the client’s DBA.

For plan guides, this is a great idea – but only when you can focus on the database often. Every single time the vendor comes out with a new version with better indexes or changed queries, you have to devote DBA attention to your plan guides. I have a motto that I never want to put something into place that requires me to come back to it regularly. If I put in more than one solution like that, I’m basically backing myself into a corner, allocating my future time every time I implement a solution like that. I’ll only implement solutions that work without my intervention.

You’re completely right that these solutions work – but you have to make sure that you’re willing to marry yourself to your fixes and babysit what you’ve produced.