The Internet has all the T-SQL you’ll ever need. Google it!

Now, let me count that again…make sure it is 11 words!

• SQLShare.com has a nice list of SSIS videos on specific tasks. 
• SSIS Videos (and more!) at MidnightDBA.  You’ll enjoy the humor in these videos just as much as knowledge you’ll gain.  Do a search on the list to find the SSIS Videos.
• List of official Microsoft videos on SSIS.
• The BI VC for  SQLPass has an archive of their past presentations.  Again, you will have to search for the SSIS videos.
• Pragmatic Works holds monthly webinars – some on SSIS.  Once again, search through the list to find what interests you.
• Jamie Thompson (Blog | Twitter) has created several short SSIS videos – SSIS Nuggets.

I’ll add more to the list as I find them. 

So, in no particular order, are my top ten worst indexing practices:

1. Not considering the best column for the clustered index.

Too often, when building a new table, the developer will simply make the primary key the clustered index. But there are many good reasons to make another column(s) the clustered index. For example, if the table has a datetime column and that select queries will be looking for a range of dates, then that column should be part of the clustered index. Additionally, there are other columns you want to avoid putting in your clustered index, such as columns that are constantly updated or columns that are very wide. Since you can create only one clustered index per table, this decision deserves some thought before you decide on which column(s) to set as your clustered index. If you can’t think of a good reason to make another column(s) the clustered index, by all means keep the primary key the clustered index, but make sure you have a clustered index, which leads to the next worst practice…

2. No clustered index

A table without a clustered index is called a heap, which is just an unordered list of data. So, why is this bad? Well, as rows increase in size they are moved to new rows, creating what are called forward pointers. Kalen Delaney explains this very well in her blog post: Fragmentation and Forwarded Records in a Heap. So what about very small tables with static data, such as lookup tables? Well, yes, they don’t really need a clustered index, but I’d rather just put one on every table, so there is no chance of any table having this problem.

3. Incorrect fill factor for the index.

The default fill factor is 0, which means that the leaf page for the index will be full.  If your data is static, this is good, but inserts will cause page splits, which in a database with high write activity can degrade performance.  Choose a fill factor based on minimizing page splits.

4. Forgetting that foreign key constraints do not create indexes by default.

When you create a Foreign Key constraint, SQL Server does not include an index. If you need the index, you must create it. Review all Foreign Keys to determine if they will benefit from an Index.

5. Forgetting to show indexes some love.

Ok, DBA’s this one is for you. After all that coding and testing to find the best indexes, you forget to schedule the proper maintenance for them. Indexes won’t give the best performance if they are allowed to become excessively fragmented. And keep those statistics updated too, will ya! I’ll make a deal with you, Mr(s). DBA, you keep my indexes nice and tidy and I won’t be asking for SA rights on production. Deal?

6. Creating lots of indexes without a real reason why.

Once you see the performance benefits of indexes, it’s easy to fall in love with them and think the more the better. No, this is not the case. Too many indexes can drag down insert, update and delete operations and led to wasted resources and time during maintenance operations. And your DBA will be cursing you…oh yes they will.

7. Low selectivity of an Index.

If there are only a few unique values in a column, a nonclustered index will not be used. So, just how low is too low? Tibor Karaszi explains all in his post How Selective Do We Need to be for an Index to be used?

8. Use of index hints.

Yea, they do work. For a while. For an indeterminate amount of time. And the time they stop working, will be so, so inconvenient. You will be buried in work and users will be hollowing for you to fix it. Immediately. Trust me, I’ve been there, it’s ugly. Please, find some other way to fix your troubled query.

9. Non-sargable where clauses.

If you create a WHERE clause that includes search conditions such as <>, !=, NOT EXISTS, NOT IN, or math operations or functions, it will not use an index. For an deeper explanation, see Sargable Functions in SQL Server by Rob Farley or Chapter 11 in the book SQL Server 2008 Query Performance Tuning Distilled by Grant Fritchey and Sajal Dam.

10. No naming standards for your indexes.

What does “IDX_1”, “Index5, or “IX_Customers” mean? Please, put just a little bit of thought into your index naming. I like to see the table name and column(s) names in the in index name. Then I don’t have to script out the index just to see what’s in it. The next time you are tempted to put a useless name on an index, ask yourself, “Will I remember what columns are in this index 6 months from now?”

Got any other indexing worst practices you would like to share?  Leave ‘em in the comments!

P.S.:  Michael, I am team Indexes!

…or is it?  In a big company, with lots of resources (to include at least one full time DBA, usually with several years of experience), this makes perfect sense.  But for smaller companies, especially when there is a part-time, “accidental” DBA supporting the database environment, this may not be the best way.

Consider this situation:  Users are complaining that the system is slow…it appears that the database is to blame.  (Maybe not, maybe it is the application, but play along with me here, its my story and I say the database is the problem, hehe.) The DBA is an “accidental” DBA who has been a part time DBA for 1 year.  His main job is the company Lead System Administrator.  He can set up backups, do restores, grant security and migrate code to production, but that’s about it.  The Database Developer has over 10 years of full time experience with SQL Server, to include a couple of stints as a DBA, and has plenty of experience in performance tuning.

So, who should troubleshoot this problem?

Unless there is some regulatory, legal, or company policy  reason to keep the DB Developer completely out of production (in which case the company **really** needs a full time DBA!, one with plenty of experience!) , the DB Developer is the better choice.  The “accidental” DBA doesn’t have the knowledge or experience to find the problem.

…ok, so the DB Developer will investigate the problem.  But what permissions do we give him?   Just enough to get the job done, that’s what.  So, lets go over what he might need to troubleshoot a performance issue in one database:

GRANT db_datareader – this is usually the first one that comes to mind.  This permission is set at the database level and allows the user to select from any table in the database.  A good place to start.

GRANT VIEW DEFINITION – This permission is set at the database level and allows the user to view the database metadata such as stored procedures, functions and views.

GRANT VIEW SERVER STATE – This permission will allow the user to run Dynamic Management Views and Functions.  Lots of yummy troubleshooting data in those babies.  This must be run in master database and this permission is server wide.

GRANT ALTER TRACE – If SQL Profiler is needed for troubleshooting, then this permission needs to be set. It also will allow the user to see SHOWPLAN data for an individual query. This permission is also needed for replaying a trace as well.  This must be run in master database and this permission is server wide.

Now these permissions are only available on SQL Server 2005/2008, so if you have SQL 2000, sorry, these permissions don’t exist on that version.

Of course, none of these permissions will give the user any ability to make any permanent changes on the production server, so that job is still left to the DBA.

1. Define Success. Before you do anything, decide what the goal is?  A 50% reduction in time needed.  75%?  What??  And once you have met the goal stated for success, stop!  I’m sure you have other tasks on your to-do list.  Nobody in your company is going to care if you make it faster then needed. When the customer/end user is happy, move on.
2. Do no harm.  Whatever you do, don’t make the problem worst then it is.  For example don’t throw a bunch of indexes into your database in an attempt to fix one procedure, without understanding the rest of the queries in your system.  It is better to start off with a review of the code first.  Changing the code will only affect that procedure where as creating or dropping indexes will surely affect other queries on your system.  And please fully test all changes you do make! The last thing you want to do is introduce logical errors into your code.
3. Document your changes.  Oh yes, the dreaded need for documentation.  I know all of the excuses for not documenting a code change…you’re too busy…nobody will read it…nobody will care.  Trust me, the new developer who comes in behind you will be so grateful if you do this.  And if you need to work with the same code again, you’ll be happy if you document your changes, because you will probably forget what you did 6 months later!  So, write down what you changed before you forget!

So what does this have to do with documenting our databases?  Well, in my experience the worst databases I’ve come across have the least amount of documentation, in some cases, none.  If you are throwing hacks into your database, you just want to purge the whole event from your mind, not write it down.  We don’t want to remember the hack we had to put into the database or the fact we really don’t like the all the other “junk” that the last developer/DBA put into the poor database either.

But like your diet, the worse the database is, the more it needs documentation.   Like the improvements in our bodily health, improvements in our SQL Servers will be much easier to come by if we take the time to document what we’ve got, as junky as it might be.  But don’t try to document the whole thing at once.  My food journal only asks for what you ate at your last meal or snack, not your food choices for the past month.  A little bit at time makes it more likely that you will actually do it.  So document your databases as you go, a small portion at a time.  That way it won’t feel like such a chore.

Just 78 days until we depart.  I can’t wait!

Do a search on “SqlStudio.bin”.  It will be under …\Application Data\Microsoft\Microsoft SQL Server\100\Tools\Shell\SqlStudio.bin.  Close down SSMS, rename the file and start up SSMS again.  Now those boxes are nice and clean for you!

For SQL Server 2005 directions, go here

Chapter 6 – This chapter focuses on using graphics such as charts and images in reports.  This chapter provided a nice overview of graphics, and like the previous chapter, the directions were easy to follow.  I’m not sure if I will use graphics to build reports in my current job, none of the reports we have in production include charts and we have very little use of images.

Chapter 7 – This chapter is called “Kicking it Up a Notch:  Intermediate Reporting” and that is a perfect title for it.  The chapter starts with showing how to create a template to use in future reports.  Much time is spent on improving the presentation of reports and the chapter introduces concepts like totals in reports, grouping, sorting, parameters, and using stored procedures instead of SQL queries.  Lots of meat here and it took me a bit of time to build all the reports in this chapter.

And I can’t remember any typos, not a one!  The only criticism I have is this:  stored procedures should be introduced earlier, maybe even in chapter 5.  Embedded SQL in reports (or applications) is not a good thing.

So far, a very good book, well worth my money.

Ten years ago, when I started my first job in the database world, working with SQL Server 6.5, I could not have imagined the volume of information dedicated to SQL Server.  Back then, a whole book on the product was only 400-500 pages.  The product has grown so much that no one person could know it all.  Even the people considered the most knowledgeable about SQL Server typically specialize in just a part of it.  That’s probably why I have over 25 different SQL Server blogs in my RSS reader.  No one blog covers it all.

I have to remind myself to focus my self study efforts.  I have to partition out all the things I would like to know about SQL Server into two buckets:  stuff I need in my head and stuff I should just know to how to look up.   It’s less stressful that way.