Recently I was talking with some DBAs at a SQL Saturday event and one of them asked me if I thought that installing SQL Server on Server Core would be complicated. I didn't think it was, and told them that I wasn't sure how much of a beneift your SQL Server would get from being installed on Server Core. I thought it would be more secure, and there definitely was less overhead from the OS, but in these days of quad core processors and tens of GB of RAM it didn't seem like a big deal.

However I wasn't sure and thought I should do an installation on Server Core since it will be supported in SQL 11 and see. This week I found a handy guide from Andrew Fryer at Microsoft that starts looking at what's involved with this process. He points out that there's less of an attach surface, less patching required, and a tiny footprint. When RAM matters in SQL Server, it really matters, so I might be rethinking my opinion on Server Core. Perhaps this will be more common in the future than I previously thought.

There are all sorts of basic skills that it seems many DBAs are expected to know. From the definitions of terms to skills needed to properly administer a SQL Server instance. However becoming a DBA, even a great DBA, isn't a progression that we can map out. All of us seem to come to the profession in a different way, and builds skills almost randomly as the need to learn something comes up. I know DBAs that started with T-SQL and then learned to perform backups. There are developers that first installed SQL Server, learned to connect, and never learned to reindex. There are an infinite ways in which someone can learn to work with SQL Server, and as a result our knowledge progression doesn't look like the chart above. Instead, I think they look more like the chart below:

I think that we all can map our skills on some surface, with peaks where our strengths lie and much lower bumps and ridges in those areas that we have less experience. I suspect the mapping of skills is different for everyone as I've seen senior DBAs with years of experience in some areas have almost no experience in others. People I have thought were gurus on tuning T-SQL or configuring instances have asked basic questions on replication, not because they couldn't understand the subsystem, but because they had never needed to learn about it.

Most people that visit SQLServerCentral or subscribe to this Database Weekly newsletter are making an attempt to improve their skills, and raise their "skills map" in some area, which I think it great. However I have found that sometimes people forget that all of their skills, even those learned in the past, will atrophy over time if they aren't used. This week I wanted to remind people that they shouldn't forget to brush up on those older skills if they haven't been used in awhile.

Do you remember what ACID stands for in SQL Server and the implications of adhereing to its principles? If not, Michael Swart continues his series with part 3 looking at isolation. Many people haven't done much I/O subsystem benchmarking, but even if you have, you might need a refresher, and Glenn Berry starts a new series this week on that topic. There are also some great posts on execution plans, from Grant Fritchey and Gail Shaw, explaining some of the things you should know while giving you a preview of their full day seminar on the topic this fall at the PASS Summit.

Learning about SQL Server is something everyprofessional ought to engage in regularly, but as you do, don't forget the basics you've learned, and as you branch out into new areas, tackle the basics there first. Build a strong foundation and you'll be surprised how much quicker you learn in the future.