Part of the MemeMonday blog series, started by Thomas LaRock:

"The idea is for you to list out the things that can go wrong with SQL that are NOT a result of disk issues. No, you don't need to do 99, try to think of nine (9) things that come to mind. For example, your list could include things like linked servers, or NULLs, or whatever you would consider to be an issue in your shop."

So here are my 9, for the moment, who knows, I might get to the office tomorrow and get all upset over something completely different...

9) - 3rd party applications that come with database 'baggage'.
When a system is purchased and it requires (unnecessarily) elevated privileges for some or all users. Or it forces the database to have certain settings or employs sub-optimal code, such as Cursors etc. Hopefully the vendors are open to suggestions on how to get their product to improve otherwise you are going to have to resign yourself to a server that will always underachieve.

8) - Forums.
Not the forums themselves but some of the etiquette displayed by some users. It's not usually the people that are answering it's the people that dive in, ask a question that is usually vague like "How to make my server faster?" or "I have to move Master database. Reply now. Its URGENT" and then seemingly never visit the post again. Regular users of the forum bust-a-gut to make what sense they can from the question and provide real quality answers but there is never an edit from the poster to give more information let alone a follow-up "Thank you". Poor manners and an absence of courtesy annoy me.

7) - CURSORS.
Why do people STILL use cursors*? I can't see any reason that people would employ this sort of TSQL - I find the syntax harder to understand than other, better performing, options.
* - I see on various posts on forums where some people say there are times when you can only use a cursor to get a solution and anyone using either sp_msforeachdb or sp_msforeachtable are using cursors in those procedures.

6) - XML.
The problem here is simply my capability to understand it thoroughly, and therefore use it successfully and appropriately. I always have to stop and think and it's difficult to pick my way through. I just don't 'get it'.

5) - SELECT *. G'ah! Laziness. OK, if you want to get a quick list of the columns in a table and a sample of the data but then it should take the form of SELECT TOP 5 * and should never happen on live. We recently had a purge in the code on a report server and one of our MI team located and replace SELECT * with a specified column set in over 200 reports. What an amazing project to have completed. Something you may be interested in - users have mentioned that reports are noticeably faster loading now.

4) - Old Versions.
From the point of view that they are a pain to administer as you get more servers on new versions but cannot move legacy systems and also their lack of integration with management tools and so on. I am supporting SQL from 2000 onwards so might count myself lucky. I know some people that are still on SQL 7.

3) - SSRS on the OLTP database.
This is pretty specific to my environment, there is a strong drive to have all reports based on live data so there is very little implementation of report snapshots or subscriptions. When the end of a reporting period comes along the SSRS demand on the database(s) rockets and I see performance dip. It passes and is something that system managers accept as their choice. Still grinds my gears though

2) - Users.
I appreciate their situation and that they have a specific job to do but I have seen reports being run sometimes only minutes apart so that it provides a work list with one item moved from 'outstanding' to 'resolved'. Did that REALLY need a re-run of the report? Surely a daily report like this could be saved into Excel and updated locally or even printed and amended? Sometimes it seems the servers is dying a death of a thousand cuts.

1) - COLLATION.
Especially the situation where you have databases that are on different collation from the system databases. Things get awkward in so many aggravating ways. By accident or design you may suffer from this and you have my sympathy.

* - Mr Flibble appears in this blog courtesy of Dominick Reed (Twitter | Facebook )

Please visit http://sqlinthecity.red-gate.com and register to attend a great, FREE, day of training and talks from MVPs and get some demo's of Red Gate tools