Given the general state of the economy...many companies are looking to cut back. Going back over what we've done and "optimizing" things -> budgets, expenses, etc. is the norm right now. And, scaling back is not always a bad thing - unless the wrong things are cut. Unless the wrong things are used to motivate you. Prioritizing and/or really assessing what gives you the biggest gains for your dollars is hard. In fact, one of the things that always seems to be first on the cutting block is training. Training is hard to quantify. And, the results of good training are also hard to quantify. Instead of fixing a problem (which you can often see the exact improvement) you might instead avoid a problem. Avoid downtime. Avoid data loss. Process more rows - with the same hardware. But, how do you know the cost of what could have happened. Ugh. To be honest, if I could do that - Paul and I would be on a beach. ;)

But, I do have a reason for this post... what should you be thinking? Where should you focus your attention? What can you cut - safely, temporarily, permanently and what might you help to prioritize?

Should you upgrade software?

• Is there a feature that makes something easier? Some new features are really powerful "big" features. For example, Policy-Based Management (PBM) might help you to better centralize certain rules (in PBM-speak "policies") and then enforce them on many servers - even 2005 servers... so, you might be able to upgrade a smaller number of servers and still get some of the benefits. Many of the tools work against multiple versions so you might be able to minimize (and/or prioritize) which servers you upgrade and slowly migrate others. Potentially following an every-other-version upgrade strategy... upgrading some servers from 2000 to 2008 and leaving some of your 2005 servers to wait to upgrade until SQL11 (the next version after SQL10 - which is SQL Sever 2008).
• Are you starting a new project - architecting a new database? Wouldn't it be easier to start on the newer version and get better longevity (maybe?!)? For example, sparse columns might make a major difference in your base table's architecture...and be easier than if you were to architect (and write all of the code) for 2005 but then later need to do a major architectural change to move to 2008 (well, to *really* benefit from things like sparse columns). There are some really good features in 2008 and some *might* warrant upgrading... upgrading now. But, if you don't have a direct need then I'd argue that you could probably stay with 2005 (or even 2000) and then push this out a bit until you absolutely need to move forward.

Should you upgrade hardware?

• Again, are there features that will directly impact: performance, availability, manageability?
• Can you wait? I can't really answer this and - for everyone - the answer is going to be "it depends". There might be something that significantly reduces costs and/or minimizes downtime and as a result, you'll just have to do cost-benefit analysis. This is a tough one... but, maybe you can do rolling upgrades and let some of the lesser servers take the hand-me-downs. :)
• Can you do rolling upgrades moving the most critical to a new server and then a less critical server to the one freed up by the last upgrade...

Is there anything you can do to get more out of what you already have??

In my opinion, this is probably even more important than the two above. Upgrading hardware and software is something you will ALWAYS need to consider but if you could get better performance, scalability and availability out of the hardware/software you have now, then you'll benefit *now* without additional funds spent (actual outgoing funds) and you still be able to leverage what you do today when you do upgrade. So, what this really translates to (IMO) is tweaking and tweaking a bit more - what you already have? How? What can you look for? What can you do to help??

• Upgrade to the latest service packs/hotfixes (at least upgrade to the free stuff - you might see some gains and in some cases (like SQL Server 2005 SP2+) you might get some new features. (important note: test this on a non-production server FIRST!!)
• Update your hardware's firmware? You might have missed an update that improves performance (important note: test this on a non-production server FIRST!!)
• Bottleneck Analysis - Some good resources for this are: Performance Tuning Using Waits and Queues and the SQLCAT team.
• Workload Analysis - Some good resources for this are: Troubleshooting Performance Problems in SQL Server 2005, Working with Tempdb in SQL Server 2005, Batch Compilation, Recompilation, and Plan Caching Issues in SQL Server 2005...well, there are lots of good whitepapers that are specific to certain types of workloads and/or perf problems...check out our whitepapers page here: http://www.sqlskills.com/whitepapers.asp and the CAT team's whitepapers pages here: http://sqlcat.com/whitepapers/default.aspx and the general SQL Server on microsoft.com pages here: http://www.microsoft.com/sqlserver/2008/en/us/white-papers.aspx and for 2005 here: http://www.microsoft.com/sqlserver/2005/en/us/white-papers.aspx
• Maintenance - often overlooked and incredibly important. A database that has solid maintenance practices (fragmentation analysis and cleanup, VLF analysis and cleanup, transaction log management, finding corruption in its early stages through automated CHECKDB executions...) performs better, is easier to recover, might naturally stay smaller (more compact) and therefore require less hardware. In fact, analyzing indexes - to get rid of unused indexes and to consolidate redundant indexes can end up saving disk space, backup space, cache, maintenance costs, etc. Both Paul and I have blogged quite a bit about many of these!
• Other tips and tricks
  • Blogs... which is why you're here and there are so many out there! Here's a link I recently found that lists a bunch of SQL-related blogs: http://technet.microsoft.com/en-us/sqlserver/bb671052.aspx and, of course, Paul's post on "So many blogs" and the PASS list of blogs here: http://www.sqlpass.org/Community/BlogDirectory.aspx.
  • Webcasts... there are lots out there and we now have a page which has most of ours listed on it (thanks to Paul for creating this!!) here: http://www.sqlskills.com/webcasts.asp and there are LOTS more on TechNet, MSDN, etc.
  • Conferences... OK, maybe a shameless plug for conferences like SQLConnections *but* in having put together the agenda (with Paul) where we specifically focused on best practices topics and performance tuning - I can tell you that some of the tips and tricks that we recommend can significantly improve performance, may minimize needed disk space (by creating more optimal and often fewer indexes), may improve availability with better design practices and/or maintenance and much more than that! And, in getting away from the office for a few days and focusing just on learning you might do two things. First, you might learn some tips and tricks that you never would have (or it would have taken *a lot* more time and/or been harder to really understand?). Second, you might come back with a whole new and renewed enthusiam for doing things - and with an ordered/prioritized list of things to try. And, this might even help to motivate you because it also shows that your company really is committed to you/your job (having spent money specifically on your learning) - and you to them.

So, I do think that there are SMARTER ways to save. A well trained employee is worth a lot more than a cheaper one. And, there are smarter things to cut. I hope this might help you think of things to do and/or places to look to get better performance with what you have! I think blanket "no training" or "no upgrades" statements are never good for anything - even the budget (the longer term effects can be much worse - but also much harder to quantify).

Really, the answer is always different. It depends............

kt

Well, I had wanted to come up with a clever reply to my husband's oh-so-romantic blog post (here). And, well, in all honesty, that *is* the best present for me... but, probably not what most would say is romantic ;-). We've both had quite an effect on each other's presentation styles. We constantly remind each other of what works and what doesn't work. In fact, we even take notes when we watch each other's sessions so that we can very clearly and concisely state what we think works and/or doesn't work in a session. So, that got me thinking that I'd like to add a few things - mostly about how to get started in presenting - as his list for tips/tricks in presenting was extremely thorough!

Presenting tips:

• Demos: OK, everyone says this - yes, your demo should work. A demo that fails is easily the most frustrating thing to happen on stage. Not only is it frustrating for you (as the presenter) but the attendees feel like their time is wasted. And, in all honesty, this should never happen. When it does it usually happens because of one of the following: the demo wasn't prepared, the demo was overly complicated or something changed recently (and you hadn't recently tested it). And, all of these are preventable.
• Passion: Paul mentioned that you need to find a topic for which you have a passion - and I completely agree. This is probably the most important part for me. I've often been asked to talk about X or Y and if I can't find something really compelling to focus on, then it's definitely not my best session. In fact, less and less am I presenting other people's content and/or other people's abstracts. I really want to construct the session, the content and the message (in general). Having said that, what I want to add is passion/excitement/fun. The more fun you have with a session (and, I don't mean jokes - I just mean good content that makes sense and that is interesting), the more fun it will be to present. If you're having fun and presenting something with passion (that you have specifically for that topic), then it's contagious. People will remember more and take more away with them.
• Mentor: Paul mentioned this in his post, Greg Low mentions this in his series Presenting at Large Events, and large conferences such as TechEd have people like Richard Klees on-site to help with this as well. But, if you can find a colleague or other presenter to really watch your actual session (and you watch theirs), then you will get the best feedback. The actual session - in front of real attendees - is the only place where everything counts (unfortunately, all of your presentation gotchas don't always show in a "test run"). So, it's here where you can get the best feedback and where you can really learn.
• Don't stop learning: I've presented in one way, shape or form since 1987 when I gave "short-courses" on WordPerfect for the local students and staff at my University computer center (where I worked). And, in over 22 years, I still read evaluations, still look for books on presenting, still read blogs, watch webcasts, etc. A session can *always* be better. A presenter *always* has things they can work on.

Getting Started (which can also translate into improving your own skills/knowledge and even your own position within the company):

• Create a work/study group: Something that can help to "find the right tool" for the job is to divide and conquer. In our technical fields, no one can ever know everything. And, sometimes we get stuck in a rut - solving problem after problem with the same solution. I always use the "tool" analogy because I think it works well. If you have a problem in your house you don't always grab the hammer, right? But, I don't know how to use every tool either - if I don't know exactly what tool to use, sometimes I'll ask someone else to look at something. Sometimes a second set of eyes is exactly the thing to do. They might see an easier and/or a quicker solution. So, since you can't know everything - know a lot about a lot of things. Have a small work/study group that meets weekly or bi-monthly where each of you tackles a topic, a feature, something. Or, maybe you all read different blogs or newsgroups - then come back together and each do a 10 minute presentation on what you found. This can keep you better informed about other tools you might need to use someday AND can help you to start presenting (on a small scale)

NOTE: Before you do any of the following, you might want to check to see what your company policies are with regard to blogs, user groups, conferences, etc. With an appropriate disclaimer and/or no direct references to the company, you might be fine. Just check to make sure! 

• Present at a local user group and/or consider creating one if one doesn't exist: these a typically 10-50 people who meet at least once a month. Some user groups are much larger... But, this is a great way to learn more AND present what you know to a bigger group but, with (usually) a bit less pressure. The PASS website has a large list of chapters: http://www.sqlpass.org/Chapters.aspx. Consider even working with the local user group to have a side group that meets solely for improving presenting skills - you can present to each other in the same way that the work/study group would but this is a group outside of your company.
• Create a blog: there are lots of sites you can join to blog on and my personal opinion is to see if you can write consistent posts for a month or so (without them being published publicly) and then slowly publish the ones you've written so that you can stay ahead of the game. Blogging is hard. I have a hard time keeping up with it but if you have a good message - that's useful to others - then it's worth it.
• Create podcasts to post on your blog: This can be another way to present but without the stress of an audience.
• Write for magazines (TechNet, MSDN, SQL Server Magazine): This is a bit harder but if it's a good article then it's likely to be published either in print and/or on their associated websites. This can give you more exposure and in turn, help you to hone your message and your presentation skills.
• Submit sessions for larger conferences: This is the hardest and will take the most time. It's really nothing personal if you're not chosen the first or second time around (and these days the large conferences are even more competitive so it's *really* hard - don't get discouraged!!). Most large conferences want people who have a name that attendees can recognize. So, this takes time. The previous bullets *will* get you to a point where submitting to a larger conference makes sense - but, even then it's still not a guarantee that you'll be accepted. The more you blog, write, present at user groups, etc. the more people will get to know your name and your presentation skills. This is what the larger conferences are looking for - people that can give a good, technical session and make those 75 minutes the attendee spends with you worthwhile. Consider getting into a speaker competition like Speaker Idol which is usually at conferences such as TechEd but I've also been seeing this in local areas as well (with local user groups).

Key point: Clear and Concise "Presentation" for every aspect of life...

So, in re-reading Paul's post, I also read the comments and followed the links (which is what got me to Greg Low's 4 part series on presenting for large conferences - which is a really good series btw). In his presentation he mentioned a flight attendant... which, then made me surf/read a few things there. And, somehow I go sidetracked and ended up:

here: Galley Gossip: Flight Attendant Pet Peeve #1: Answer please!
and here: A woman missed her flight at the boarding gate HKIA
and even here: An open letter to unsatisfied users on the newsgroups

And, the combination made me think of a few things that really can go back to presenting but also just in general about comments, criticisms, and everything in life. If you want something then you need to ask for it precisely. If you want to get somewhere or do something or improve your position (in life, in work, whatever), then you need to be specific, concise, and clear. It's all about the presentation. Paul says this occassionally to the girls: Stop, Think, Speak. It's somewhat frustrating when he says this to me but it's usually after I've had a couple of glasses of wine ;) but, I think it's really interesting in the context of user groups, forums, presenting, life... You need to *present* something clearly and concisely for people to understand.

If you're posting a question on a forum and/or newsgroup - take time to research it first. Take time to present it clearly (what version, what's the EXACT syntax (can you provide a repro script?), what exactly are you doing, what is it doing that's wrong, what do you think it should be doing?). The better your question (i.e. the presentation), the easier it is to get people to understand. And, in the case of a forum/newsgroup, the easier it is to get a [useful] reply. Remember Tom Cruise/Cuba Gooding, Jr. in Jerry Maquire - "Help me, help you."

If you're presenting a session - present the problem (or idea), present the solution (code/demo/etc) and summarize why it works. Clear, concise and then follow through. And, this also reminds me of the most important presentation skills that everyone says but that I'm going to repeat one more time... your demo should WORK. Keep is simple. Straightforward (concise) and simple demos are really the most effective!

So, on that note, I'll remind you to look at one of the links I already posted above. This woman is very clearly stating the problem and reasonably coming up with a solution (to her missed flight): A woman missed her flight at the boarding gate HKIA. Yep, that's going to get someone to help you. Hmm. Clearly, she did not see Jerry Maguire.

Thanks for reading!
kt