Where does the time go?! January was an incredibly busy month with the day job, home, a battle with the flu and the wrap up of the holidays. It went felt like it took a week to go by but some good news came in January as well. This first week in February, I hope to catch up with a post about the goals for the year, perhaps respond to a meme I was tagged on and get some technical posts queued up for the coming weeks. Until then, a bit of an update:

SQL Saturday

I presented at my first even user community event! I am still here typing after doing so, so the fear, nervousness and anxiety didn’t kill me. I was given some good feedback by people I trust after each talk on some areas to improve but it didn’t seem like I bombed in either talk. Some people sought me out after each thanking me and even had some compliments. I can definitely be more interactive, project my voice better and try and keep the presentations a little bit more dynamic (I had positive feedback with a silly phonebook game I did in one of the talks when talking about SARGability and Indexes). I also have some thoughts on tweaking the DBA talk a bit to help drive the main point home. The slide decks and some other info on the talks are in the presentations area of this site:

• You Can Tune Your Own SQL Code – The beginner level talk aimed to help show that doing some level of tuning isn’t as scary as some make it out to be.
• As a DBA, Where Do I Start? – We setup a scenario at the beginning that puts you into the position of being the only SQL Server DBA at a company. Through that we talk about prioritizing our jobs as DBA as we go through the “itties” of database administration.

Seacoast SQL Server Users Group!

I got a great e-mail from Blythe Morrow at PASS HQ (BlytheMorrow on twitter) welcoming the Seacoast SQL Server Users group to PASS. I still have some finalization with a location and primary sponsor but it looks like our first meeting will be the first or second Tuesday of April on Pease Tradeport in Portsmouth, NH. More coming on this in the coming week or two as more details are finalized. Subscribe to the blog feed to keep up with updates.

An Ultrasound and A Name!

My family and I (Today that set includes a wife, a 4 year old daughter and an almost 2 year old son) got to watch an Ultrasound (I love watching the pictures, especially the 3D… Amazing) on my wife. The Insert statement (Lord Willing) is looking like this INSERT INTO WalshFamily (Name, GoesBy,Gender, DOB, LikesToSleepFlag, CuteFlag) VALUES (‘Samuel’,'Sam’,'M’,’0528ish’,1,1)… Happy news indeed There is talk about another INSERT statement but we have plenty of time to pray and discuss that one. It will be what it will be, though.

SAPpy Love Songs

Well.. Not a lot of love, but it looks like I am now getting my hands very dirty in the area of being a DBA for an SAP implementation. Getting to know the tables (and the big tables), the processes and maintenance on our new GL. We’ll be adding more functionality but for now, I am getting to know the environment closely. Also getting to know a lot of new ETL processes and a team of dedicated ETL developers. It was a busy month but things are stabilizing and we’ll see how it looks when we go through the future phases. I’ve worked with many ERP systems, just never SAP. Great that we are doing SAP on SQL, too bad they planned it before talking to me and missed the opportunity to go 2008 at go live but we can work on that later.

But No Blogging, Tweeting, Etc.

Didn’t really touch the blog this month. I exhausted a couple saved posts early on but didn’t do any updates. I was a bit of a recluse this month. In the coming days, I’ll get a goals post (late but better than never) online. I am expecting to be perhaps speaking at another SQL Saturday or two this year and I will be doing tweaked and (hopefully anyway) improved versions of the two talks I gave in Waltham. 2010 is shaping up to be a fun, busy year.

I was recently tagged in an interesting blog post by A Misplaced New Englander, David Taylor. (dyfhid on twitter). The question sounds simple enough, “How do you use SQL Server where you work?” Of course the answer is not simple. I echo Grant Fritchey’s response in his blog post that it would be easier to post about how it’s not used. That being said we’ll see what we can do…

What’s my day job Vertical?

As a consultant part time nights/weekends I get to experience a lot of different environments and uses of SQL Server. Rather than talk about those, I’ll talk about the day job in general terms. I work for a large, global property and casualty insurer. We don’t write a ton of policies in the subsidiary I work at, but we write some very expensive and interesting policies. From oil rigs to directors and officers insurance to specialty cargo lines we insure it. That means we have to be quite adaptive to very different data sources with widely varying pertinent information about each of a multitude of lines. We don’t have huge databases but they are complex databases as a result.

Our primary claims system is built on DB2 and it feeds several systems that utilize SQL Server as a back end.

How Is SQL Server Used?

Some key uses:

• SharePoint - We use a global SharePoint (MOSS 2007) release to share information between regional teams and business functions. A few hundred GB of content databases so far in a relatively young implementation. As DBA I work closely with the SharePoint team in making sure performance is right, maintenance is right and things are working smoothly. SQL 2005 back-end but currently in the process of migrating to a SQL Server 2008 cluster on Windows 2008 we are building out in the coming weeks.
• Data Warehouses - There are several key data warehouses in SQL Server 2005. These warehouses track information about past claims, customers, financials, etc. These warehouses feed reports (in Reporting Services 2005 currently) and Cubes (analysis services 2005) which also feed those reports. As DBA I work closely with the warehouse teams in analyzing performance concerns, suggesting architecture and query improvements for performance and help with troubleshooting, availability and reliability decisions.
• Enterprise Service Bus - We have several applications built either on SharePoint web parts or .net web services. Lots of work with Biz Talk as our service bus. Data flows through to SQL Server and a lot of xml passing into and out of SharePoint. As DBA, I work closely with the dev teams in getting deployments done, performing code reviews and helping them write better performing code.
• Various ISV Provided apps – SAP is the financial suite we are in the middle of deploying (on SQL 2005) to replace Great Plains. We also support several ISV applications that perform various business back office functions or IT functions.

What do I do?

I am the sole production DBA. There are roughly 20 production SQL instances I manage and at least double that number of dev/test/uat instances I manage. Following the philosophy that the DBA is the data advocate at a company, I perform normal DBA duties but also spend a lot of time working with developers in understanding impacts of coding and design decisions. I also spend a lot of time in meetings discussing future plans, time lobbying the infrastructure team for improved hardware needs and helping to change the way folks access environment for deploys and development support.

My primary duty is to keep the lights on and make sure I am invisible to the end end users (the customers of IT as a whole.. I try to be very visible to developers as needed, but not to the end users clicking on reports, using the Operational Data Store through the ESB. Not invisible in a “not gonna help you” point of view. Invisible in the sense of, you shouldnt’ experience any issues that are database related so you shouldn’t have to know there is a such role as DBA, in a way. Does that make sense?

I help analyze new technology with the architecture teams and try to have a say in balancing technology to solve real business problems or technology for technology’s sake (tough line to tow sometimes at most places with geeky architecture teams… who doesn’t love new stuff?)

I give impromptu courses to developers on performance tuning their own code, spend time hand holding some folks through indexing and design considerations and try to share my knowledge wherever and whenever possible.

What Technologies do I use?

Besides the normal SQL Server tools and other free tools I’ve blogged about (Microsoft Assessment and Planning tool to enumerate all SQL instances on our network or Performance Analysis for Logs for performing benchmarks and tuning) I use several tools day to day…

• Monitoring Tools – We use Systems Center and Operations Manager (SCOM) for a large portion of our monitoring needs.  I also use a few vendor provided SQL Server specific tools to keep track on my environment.
• Development/Comparison/Etc Tools
  
• Word – Documentation is important, I blogged about my thoughts there. I try to use this when possible to at least do screenshots of installation processes but hopefully create more detailed documentation.
• E-Mail - A lot of folks wish I didn’t use it so much. I wish I didn’t. Something to work on in 2010 is improving conciseness and taking things out of e-mail (where it’s too easy to be misunderstood or escalate needlessly) and into in person/on phone meetings.
• Change Data Capture – We are playing with a really neat tool from a vendor (found out about them at a User Group meeting they sponsored.) This tool captures data changes from our source claims system in real time rather than through triggers and offers a huge performance improvement over DB2 OLEDB open queries across a Linked Server.

What are some Challenges I face?

Query performance. A lot of room for improvement and working with developers there. SQL Sprawl – Not multiple servers but “over instancing”, fewer servers  (saves on licensing) but many instances leading to some performance issues. We are going through a process of separating what should be separated and bulking up with either multiple instances (or single instance used for multiple purposes) for the applications that can handle it.

Reporting performance and a “self service” MS Excel culture in the end user community. A lot of the warehouse reports are high row count reports as a result. Lots of rows returned simply to be exported into, and massaged by, Excel. This creates some performance issues with the way that SQL Server 2005 Reporting Services renders reports. There is a plan to investigate SSRS 2008 as some key changes will provide some relief. It’s just tough to find the time with a single DBA Q1 2010 at this point. In the meantime, the self service aspect seems to really bode well for Power Pivot. I hope to create some demos in my spare time (I really want to learn Power Pivot and really feel it will be a huge win for my company) to show how cutting out the “middle man” of Reporting Services and giving richer tools for pivoting, formatting and massaging data will improve performance, reduce server load and make our users happier.

Rolling out new policies/procedures. Before me there was no official DBA, just reluctant DBAs from the team of sysadmins. As a result some of the best practices I enjoy seeing with SQL Security and deployment processes aren’t rolled out everywhere. It’s a slow process to go through proper channels but we are getting there. For instance, most environments have finally had their [Full Recovery Model, No Log Backup, Nightly Shrink Job] pattern fixed now.

The Final Verdict?

SQL is working well for our needs. Where there are challenges, I would imagine we would face them regardless of our DBMS. Most problems faced by most companies don’t seem to be specific technology related issues but rather timeline or process related issues blamed on technology. Here we have some good processes, are always working on improvements and our business processes and timelines work well for the most part resulting in a largely positive experience.

I look forward to getting more 2008 implementations out there (using it myself right now for Policy Based Management of other instances and the new SQL 2008 SharePoint cluster will be live soon. Hopefully the RS/AS 2008 for the warehouse reports in production by Q1/Q2). It’s fun watching developers increase their knowledge and watch the improved code over time. Sure there are some long days and weeks. Sure there are some tough weekends but all in all, this is fun. Every day of working with SQL Server as a DBA, “Performance Geek” or self proclaimed Data Architect is a fun time and I still treat the job with excitement most of the time.

Tag – You’re it

Rather than tag anyone specifically as quite a few have been tagged in posts already, what about you? Consider this an open tag (pretend I sneezed in a crowded movie theater and each invisible spore that left my nose is a mini hand reaching out to tag you… Sorry.. “outbreak” was on in the background while writing this post). How do you use SQL? What are some challenges you face? Add a comment, write a post and link back to the original thread Dave started or reference this post so I can see your response.

Seriously? A Blog post about SP_CONFIGURE?

I was in a Kalen Delaney’s SQL Internals class (Blog) last week. It was a great class and I learned a lot of great stuff. One thing I learned was very simple yet it was really big to me… A tip about sp_configure that she didn’t even teach as a tip, just used it and thought it was common knowledge (was to a lot of people in the room but not me).

That got me thinking about writing a post about SP_CONFIGURE. What it is, what it does and what that tip is. So… Read on if you ever find yourself wondering, “How do I use sp_configure?”

Like what you are reading? Subscribe to my RSS feed to get updated with content like this in the future.

What is SP_CONFIGURE?

Simply put – it’s a tool to display and change SQL Server settings. It seems to me that a lot of reluctant and newer DBAs are well versed in the GUI based configuration options but not always changing them through a query (or even viewing them). Not all options are changed through a GUI, some are only changeable through sp_configure.

How do I use SP_CONFIGURE?

Well it depends on what you are trying to do….

View Settings

Take a look at your SQL Settings? Open a query window and just type and run sp_configure; you’ll likely get a partial list of settings. To see them all you have to enable an option called ‘Show Advanced Options’

Change Settings

Be careful.. Changing settings affects your instance, a lack of understanding of a result could dramatically affect your instance, performance, availability, etc. Look up a setting in books online and understand it first! This post is not about the settings, it is about the tool used to change the settings. Books Online is a great, free, resource when you have SQL Server installed, you can also get Books Online on the web (2005,2008). No excuses here about making a setting change without understanding it and testing it (Remember, I like to see empirical evidence before trying something)

Alright, now that my conscience is clear. You use sp_configure to change settings as well. You simply type sp_configure ‘setting name’ (*) followed by the value. Execute that and you either have to restart the instance (if the option is not dynamic – able to be changed on the fly while the instance is running) or execute the statement “RECONFIGURE” if the setting is dynamic.

For example – if you wanted to show advanced options you would have to type: sp_configure ‘show advanced options’, 1 GO reconfigure GO

Then when you run sp_configure again, you will see all of the available options.

* The Tip I learned from Kalen

You don’t have to type the entire option text in! At least in SQL Server 2005 and above. I never knew this. It’s right there in books online but I never went there for sp_configure because I’ve been using it all this time. So maybe this isn’t as exciting to you as it is me. I mean you can copy and paste the value. Perhaps you don’t mix up your L’s when typing Parallelism (see…  I had to pause while typing it…) but I do. You just have to type in an unambiguous portion of the text.. Try it.. Don’t make a change but run: sp_configure ‘degree’ and you will see the setting for max degree of parallelism. This is great! (Update: While spell checking my post, I realized that even though I typed parallelism slowly each time I spelled it, I got it wrong still… I’m a fool.)

Output Columns of SP_CONFIGURE

Pretty self explanatory but:

name – The name of the value to be changed, again you can look up the definition for these values in books online.

minimum – The minimum value setting that is allowed

maximum – Yea, the maximum value that is allowed

config_value – What value is currently configured?

run_value – What value is currently running?

Difference Between Config_Value and Run_Value

The difference may already be clear but it’s important to take note. When you first make a change by running exec SP_CONFIGURE (‘parameter’),newvalue the Config_Value has changed only. It is not until you either run reconfigure (if the setting is dynamic – that is no restart of SQL or reboot required) or restart your SQL Server instance (if the setting is not dynamic) that the run_value changes.

SYS.CONFIGURATIONS

The view only twin of sp_configure. You can select from this catalog view to see configuration options. No changing of settings necessary to see all options here since you can’t change them, it is a way to view your options and you can filter with a where clause.

This catalog view has several columns, the ones that are an exact match to a column in sp_configure will be ignored but the rest:

configuration_id – Just an internal ID of the configuration setting. Good for trivia? I don’t use it for anything…

value – same as config_value above

value_in_use – the twin of run_value above.

description – nice. A little less cryptic then the name column here or in sp_configure. I was going to say it might save you a trip to books online but if you didn’t know what it meant before reading a couple more words, you should still visit books online and understand the setting.

is_dynamic - This very helpful tells you if a value is dynamic or not. 1 = Dynamic, just run reconfigure after changing and it changes “on the fly”. 0 = not dynamic – need to stop and start SQL Server service.

is_advanced – Like the above, ever wonder if you have to change the show advanced option to display a value? Well you can find out here. It’s a flag, 1 is yes, 0 is no, like the is_dynamic flag.

Does This Change Require A Restart?

Just running SP_CONFIGURE, you can’t tell, can you? That’s why it’s important to pay attention above to SYS.CONFIGURATIONS (SELECT * FROM sys.Configurations). That is_dynamic value will come in handy. The Next time your manager asks you, “Does changing the max memory in SQL Server require a reboot?” you can look here and see the dynamic flag of 1 meaning, yes it’s dynamic so “no boss, we can change it on the fly.” Or see a value of 0 meaning, “Sorry boss, need to have an outage while we restart SQL Server).

But SP_CONFIGURE flushes the procedure cache!

No, it doesn’t. At least not in SQL 2005 and above. I don’t have access to SQL 2000 to verify that, but I believe it doesn’t there either. Something some people still say that used to be true in 6.5 and below (maybe 7.0 also, and possibly 2000 but I am pretty sure not.. test and see.. test and see..)

There, I gave you a few other basic knowledge items around sp_configure all to justify my shock, awe and desire to tell everyone that you don’t have to type the entire configuration name into sp_configure! Whoever said it’s the simple things in life had me in mind…

Lesson learned: Visit books online on occassion. Even if you think you know it all and it is a simple feature. Always something new to learn.

Also Check Out

I have posted some other tips and tricks of items I wish I knew when starting out or earlier in my career. Some are technical how-to’s, some are DBA career related.

• Advice to beginning DBAs wondering, “Where do I start?!?!”
• Shrinking – several posts on the topic.
• Troubleshooting Methodology Woes (I also wrote an article for SQL Server Central on this topic)
• Empirical Evidence
• Documentation (or how I learned to stop procrastinating and love tolerate a chore necessary task)
• A little Paranoia and Control Freak attitude can help a DBA
• Checklists, Recipes and Algorithms – Learning about these great tools from other professions (Pilots, Chefs and Doctors)
• How do I find all of my SQL Servers? – Maybe after listening to us you’ll want to spend more time with the instances at your network. Check this link out to learn about a tool that I use to find all the SQL Servers in my network.
• Questions to ask a software vendor – Working with a new vendor with their own database? Here are some questions I ask them.
• Benchmarking… Who needs it? – The answer, I hope you will agree, is everyone. Here I talk about how easy it is to do with tools you already have and a tool you can download free from codeplex.

I just got back from a New England SQL Server Users Group meeting. Andy Leonard (twitter: @AndyLeonard, blog) gave a great presentation on Change Data Capture and SSIS 2008.

At the beginning of this week, I posted about things I wish I knew when I started. I tagged a couple people asking them the question and they tagged others. It is interesting to read through and see the lessons folks have learned along their careers. Some commonality between them, some new lessons for me from them.

While the meme thing can be a bit annoying (ala chain letter), it was actually a way to find some interesting blogs to add to my feed reader. I am probably missing some but at the end of this post I will list the links to those that I had compiled at the time of writing.

Some of the common themes and items that stuck out for me:

It’s all about the community – Nearly every person who posted mentioned something about getting involved. Be it user groups, newsgroups, forums, PASS, etc. Get involved, network and learn. The relationship may start out parasitic(and that is fine, we all started that way) but it grows to be mutualistic really quickly.

Learn - This came in different forms: Be passionate about a product, read the manual, don’t be afraid to ask a question. The point is –> Commit yourself to learning about the skill set(s) you are planning your future with. Sure things may change but never stop learning or you might as well throw in the towel.

Reuse isn’t evil - David Stein of made2mentor.com wrote”Before starting a new project, check if a solution already exists…” in his response. He went on to qualify this and I agree. Don’t reinvent the wheel. Of course give due regard to the solution and test it out first (pet peeve of mine )

Learn the other pieces - Jason Massie (twitter: @Statisticsio, blog) reminds us that our world (especially as a DBA) has moving pieces that we don’t always control. Learn the hardware that you rely on. Know it cold so you can ask the right questions and get the right support.

And from the humor department (though there is truth in jest), your superhero tights can become dysfunctional with an extra 30 lbs. (Thanks, @SQLBatman). This response has humor but it brings up a good point: take care of yourself. This is a job, be passionate about it, engage in learning but don’t make it your life. Enjoy your family, take care of your body, get some fresh air and make a fool of yourself on occasion.

Links to some of the responses that I found (they are all great reading and have other interesting blog posts to discover while visiting). In no particular order:

• http://rickdoes.net/post/2009/02/10/Thing-you-now-know.aspx
• http://scarydba.wordpress.com/2009/02/10/things-you-know-now/
• http://sqlbatman.com/2009/02/what-i-wish-i-had-known-when-i-started/
• http://facility9.com/2009/02/09/things-you-now-know/
• http://www.brentozar.com/archive/2009/02/things-you-know-now/
• http://benchmarkitconsulting.com/colin-stasiuk/2009/02/09/things-you-know-now-mrdenny-peschkaj-raosolage/
• http://www.deputyfamily.net/MichaelDeputy/archive/2009/02/things-you-know-now/
• http://www.made2mentor.com/?p=1271
• http://itknowledgeexchange.techtarget.com/sql-server/things-you-know-now%E2%80%A6/
• http://sqlfool.com/2009/02/things-you-know-now/
• http://statisticsio.com/Home/tabid/36/articleType/ArticleView/articleId/334/Things-you-Know-Nowhellip.aspx
• http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/02/10/things-you-know-now.aspx
• http://www.sqlservercentral.com/blogs/tim_mitchell/archive/2009/02/11/things-i-wish-i-had-known.aspx
• http://www.sqlservercentral.com/blogs/steve_jones/archive/2009/02/12/things-you-know-now.aspx
• http://sqlblog.com/blogs/adam_machanic/archive/2009/03/16/things-i-know-now.aspx
• http://blogs.technet.com/wardpond/archive/2009/03/15/what-i-know-now-ward-s-epistle-to-the-n00bs.aspx
• http://blogs.msdn.com/jimmymay/archive/2009/03/13/things-you-know-now.aspx
• http://sqlblog.com/blogs/kevin_kline/archive/2009/03/10/things-you-know-now.aspx
• http://www.simple-talk.com/community/blogs/johnm/archive/2009/02/18/72064.aspx
• http://chrisshaw.wordpress.com/2009/02/17/things-you-know-now/
• http://weblogs.sqlteam.com/joew/archive/2009/03/16/60874.aspx
• http://www.sqlskills.com/BLOGS/KIMBERLY/post/Things-I-know-now.aspx
• http://www.sqlskills.com/BLOGS/PAUL/post/Things-you-know-now.aspx
• http://blogs.msdn.com/joesack/archive/2009/03/16/what-i-know-now.aspx
• http://sqlblog.com/blogs/andy_leonard/archive/2009/03/17/things-i-know-now.aspx
• http://sqlinthewild.co.za/index.php/2009/02/22/things-you-know-now/
• http://msmvps.com/blogs/robfarley/archive/2009/03/18/things-you-know-now.aspx
• http://rusanu.com/2009/03/20/things-i-know-now-blogging-can-get-you-into-a-email-ponzi-scheme/
• http://blogs.sqlserver.org.au/blogs/greg_linwood/archive/2009/03/16/1488.aspx
• http://blogs.digineer.com/blogs/jasons/archive/2009/02/16/things-you-know-now.aspx

If I didn’t catch yours, I am sorry. Post a comment so I can read it or send me a tweet

When I wrote about empirical evidence and learning through trying (instead of asking only), I got thinking about things I wish I knew when I was a Junior DBA that I know now.

Rather than just keep those thoughts to myself, I figured I would write about them here and tag a couple folks to do the same. So I am tagging Brent Ozar (@BrentO on twitter) and Michelle Ufford (@SQLFool on twitter). It doesn’t have to be DBA skills, but what do you wish you knew when you were starting?

Here are some of my quick hits. My posts on empirical evidence, troubleshooting methodology and questions to ask vendors also all contain tidbits I wish I knew then.

• The World is Not Enough is a great name for a movie but not a great goal in a career – Being young, eager and wanting to please everyone I have always been the type to grow my “fiefdom” as rapidly as possible. I would say “Yes” always, try to interject a helping hand everywhere and end up with far too much on my plate. No time for family, growth and no time to focus. I am still working on this one but much better at it (though coworkers and wife may not always agree)

• Rolling your own is fun but not always practical – As a young, eager DBA/DB Developer/”SQL Guy” wherever I was, I wanted to create my own full monitoring regimen. I borrowed some scripts, created my own and made some nifty (but ugly.. I’m not a web guy) asp and HTML pages. They gave me quick insight into the environment but not the greatest. They took time to develop, it was a good learning experience but I could have learned in other ways. The vendors of the various monitoring products (upcoming blog post in Feb or March… I am comparing four DB monitoring vendors and will write about it) all spend countless hours developing their products. They usually have world-class support teams (some even have “domain experts” available to them ). If the budget allows, buy a product that works for you! It will be far more reliable, cover more alerts and allow you to focus where your efforts are truly needed.

• Learn through teaching and helping - Early on, I received help on the newsgroups (I will ignore a recent tweet asking what a newsgroup is, that and my hairline made me feel older than 30 for a minute). In the process of using the newsgroups, I saw questions I could answer or wanted to investigate and answer. I was shy, felt myself too new to help and too busy shooting for the world not being enough. Had I given the time to those questions, I know I would have offered assistance to a community that was helping me, built contacts but I also would have learned through researching questions I wasn’t 100% sure on.

• Have all of your facts before barging in and making a proclamation – I see the old me in some folks I have worked with over the past years. I both admire it and shudder at the thought . I am still very direct and blunt, I don’t hold back the truth but I try to present it diplomatically. Early on, I would do half of an investigation find one thing and quickly attempt to impress folks with my findings. More than once I was hit in the gut by the rest of the research revealing that I was wrong and way wrong.

• Have your own world in order before raining on someone else’s – I missed this simple lesson from the Bible early on: Take care of the plank in your own eye before helping someone else with the speck in theirs.(Mat 7:3-5). Related to the above, try and get your proactive checklist done and be sure that you aren’t the cause (through omission or commission) before assigning blame and insult. Folks are under the same deadlines as you often.

• Humility is a good thing – Not the false humility (“Please, don’t call me a hero, I was simply doing what anyone would have done”, said in a narcissistic tone) but know your limitations. Be willing to learn from anyone no matter where in their career and walk of life they are in. Learning and asking questions is not something that will have you thought less of. Being an arrogant jerk who “knows it all” and won’t learn from anyone you feel is “lower” than you on some magical scale is going to get you nowhere.

• What they say about assumptions; it’s really true. – This is related to the above two and I think it speaks for itself.

There are volumes of “teachable moments” I could write about but these ones combined with the previous posts cover the ones that come to mind most often. I am still working on some of the lessons and perhaps they had to come through experience but I sure wish I had them innately instead

How about you?

[Update 3/16/09] – This is still going around with more folks responding and tagging each other. I have the list of responses summed up on this post. I will try and update that with some of the more recent responses.

Or how I learned to stop asking so much and start trying…

Empirical, as defined by Webster: 1.) originating in or based on observation or experience 2.) relying on experience or observation alone often without due regard for system and theory 3.)capable of being verified or disproved by observation or experiment.

I think empirical thought and evidence are far too often ignored or bypassed in technology. With quick answers available through newsgroups, forums, points based answer exchanges and blogs running rampant (present company included ) folks are fine with a quick answer and are often quick to apply that answer… Even in a production environment.

I spoke about the pet peeve of rushed troubleshooting in my first blog post. Not using empirical evidence is definitely not a great troubleshooting strategy, unless all options have been exhausted and time is of the essence.. Even then, it’s a tough argument but I can see the “it’s broken no matter what, the problem looks like this and it is our only hope”approach and have even taken it a couple times in the past. This can be minimized by having good test environments (that mimic as best as possible the production environment) and rigid controls on releases.

Empirical Evidence in Development

I am sure you have also found code that was compliments of an internet search. That’s not all bad if it gives you a pattern to solve a problem. It is entirely bad if it was just thrown in without even understanding why you used it, how it helps you but the results seemed right. You do yourself a disservice, you do your users a disservice if you just grab and apply.

Instead, try to understand the issue. Treat each opportunity where you are working with something new as a chance to gain a deeper understanding of the product you work with and experiment with a couple ways and see the effects yourself. If most developers tried this approach and tested their methods, looked at query plans with different syntax, etc. there would be less performance tuning work needed in the SQL world.

Empirical Evidence vs. Tips From The Internet

I often see questions on the newsgroups or forums where people just want an answer, they don’t want to know why or how something works, they don’t want to know how to arrive at an answer; they want the answer. I can see the rationale when something is down or it is a question without a lot of grey area. Even still, how do they know that is the best advice if they don’t test it? How do they know that person knew what they were talking about? How can they explain it to their manager and users? How can they understand why they had a problem?

For example, a lot of search engine traffic to my blog (it’s still new to me so I still enjoy looking at those stats) have been with questions like “How do I shrink my database” or “SQL Server Shrink Transaction Log”. This is because I posted about not using shrink. Now had I posted instructions on shrinking a database they would have grabbed the info, taken it back and done it. I have seen answerers on newsgroups suggest tactics that break a log chain and mess up recoverability. I am sure they are well intending but the folks getting the answers and applying them without thought, understanding and testing are losing in the end.

So what are you saying we do?

• Try it yourself – Want to know what SELECT statement methodologies perform better? Try them and see. Look at the query plans of each. If you don’t understand the operators, learn about them from books online or some of the Inside SQL Server 2005 series (itzik’s 2 books really go in depth here).
• Seek to understand a solution even just one level deeper than you want – if you get an answer, ask a follow-up of yourself, of your resources try to understand the how and the why and the mechanics.
• Learn a bit more about the internals – For me, seeking to break things down to the basic level with everything meant I wanted to learn about the internals of SQL Server. I have learned a lot but still have TONS to learn. The point is, I rarely make a wild stab at something, I seek to understand the problem, understand the parts of the solution and end up learning a lot of extra information in the process.

It really comes down to what you want to be and where you want to go. If you want to be growing and learning constantly then experimenting and learning deeper is a great approach.

Just balance it For me, I can often go off the deep end learning How’s and Why’s to exponential levels. You know you have that same problem if a visit to wikipedia with a simple question ends up in 30 browser tabs open and 3 hours of your life erased.

Adam Mechanic over on his blog has announced a code camp offered by Microsoft, and the New England and New Hampshire SQL Server User Groups. Looks like a great time of learning and the price is right

What is a troubleshooting methodology?

A lot of the technical problems I encounter with clients or in various roles are not really the fault of the technology at hand. They are either the result of rushed work, apathetic work or botched troubleshooting.

Before talking about what troubleshooting is, let’s talk about what it is not. It is not:

• Hail mary attempts at solving an issue hoping for that final connection
• Hitting your favorite search engine and trying everything you find without understanding it
• Trying something you knew worked in some completely unrelated situation
• Taking a hammer and crowbar into the server room

Far too often, I find some of the above approaches being attempted. Sometimes they even work to solve the issue but a lot of time is wasted, a lot of risk was taken and no one involved seems to understand the how or why behind the solution. Especially in the production database world, hacking is not a first resort and is only possibly even a true last resort.

When I am interviewing someone for a role (developer or DBA, it doesn’t matter) I like to ask questions that gauge one’s troubleshooting skills. I would happily take a person who is methodical, applies common sense and lacks extensive certifications or years of experience over someone who is experienced but lacks common sense and the ability to troubleshoot. You can teach someone the necessary skills but it’s tough to teach common sense.

So what are some common traits among true troubleshooters?

• Calm under pressure… They understand the importance of a date but will not rush in a half-thought solution to look busy.
• Uses available tools wisely… Nothing wrong with searching the web for an answer but is it the right answer? Is it vetted? Do you understand why it might work, what the risks are, how it works and how to undo it if it goes south quickly? If possible, did you test the process first?
• Knows when to ask for assistance… Your company probably pays for a support agreement. What’s wrong with using it? Especially if you can’t figure it out simply, don’t understand solutions and don’t feel comfortable with the issue. No one will think less of you if you ask for help and solve it. They will if you blow away a production database and revert back to an old backup.
• Looks for the simple first… If a printer isn’t printing what will you do first? You probably won’t go looking for a screwdriver and soldering iron. Well, apply that same logic when troubleshooting anything. Look for the simple solutions and increase scope and complexity as needed.
• Follows up when complete!!! If there is one step I often see missed, it’s this one. So the issue is resolved… Game on, right? Wrong. We all make fun of the “lessons learned” or “post mortem” process but it works. Understand why the issue happened, how it can be prevented, what solved it, what you learned about your disaster recovery strategy, what you learned about your response plan, where you can make immediate improvements, when you will make the longer term improvements.

These same troubleshooting skills can be applied everywhere in most any line of work. Understand what you are doing, learn from your mistakes and apply a consistent and calm methodology to escaping trouble wherever it hits you and vow to never repeat that category of mistake again.

Hello,

 This is the first post on the new site. I am hoping to make this blog a useful one. I hope to post here regularly and am promising myself I will only post something if it meets some of the following criteria:

• It is something I spent time researching/investigating to discover the tidbit
• I haven’t bumped into a lot of posts about the same topic
• I would have found this to be a useful blog post
• This is knowledge that I will probably want to find in the future
• It is a trackback to someone else’s blog that provided benefit to me

Hopefully I will catch myself missing these objectives and will be quick to stop the madness for your sake and mine.

Most topics will be SQL Server related but I can’t guarantee no off topic posts