Working From Home

I have been working 100% from home for almost four months now,  and one of my former coworkers recently hit me with "How's it going working from home - I expected to see a blog post about it by now."

HASHTAG GuiltTrip HASHTAG Sigh

He's right - I had intended to blog about this before now, and as the three people who read my blog have noticed by now,  I have produced a whopping *one* blog post since starting at Ntirety.


HASHTAG ReadyOrNotHereWeGo

 

I have noticed some of the benefits that many people report about Telecommuting:

More time with my wife and our three little boys - when I drove into the office every day (or at least most days,  since my last job did allow me to occasionally work from home) the only meal I usually had with my family was the evening meal (we call it dinner).  I was almost always out of the house before everyone else was up and around, so I didn't have breakfast with my family (and often didn't really have breakfast at all,  or at least not a good breakfast - more on that in a bit).  Lunch was never at home - maybe once a month I would come home at lunchtime and bring home takeout.  Now I have all three meals at home with my family every day.  

Another benefit in this area is the lost commute. Driving to my office at my last job was a 30-45 minute commute depending on what time of day I was driving.  Combined with the time spent preparing to leave and the time spent setting up in my cube every day (bonus benefit - no cube now) I was spending about two hours a day going back and forth.  Now that time is spent helping my wife gets the kids ready in the morning and either cooking dinner or distracting the kids so my wife can cook.  :)

One final benefit in this area is the reduced/non-existent travel.  My last position was supposed to be about 50% remote managed services (from our local office) and 50% on-site consulting, and they were definitely honest and up-front about that.  To be fair they did a good job of allowing me to work more like 80/20, but it still meant one week every couple months I was away from home at a client site.  The other downside was that while it averaged out to a week every other month, it was more streaky than that, with two weeks coming in one month and then no travel for three months straight.  The trade-off for my lighter travel was that some of my colleagues willingly traveled much more frequently, to the tune of 3 weeks or more every month.  It quickly became clear that there was no real advancement available within the company unless you were willing to travel more than I would be comfortable doing.

At Ntirety, all of my work is WFH - in my four months I have been away from home for one week, when I visited Boston (the home base of Ntirety) during my first week on the job.  The company line is that we will do a week at the mother-ship 2-3 times per year, always with significant notice (as opposed to my last job, where you would often find out on Thursday or Friday that you were flying out to a client on Sunday afternoon.)

Decreased expenses - aside from what is usually the most obvious upside to most people - less gas consumed and fewer miles on our little Chevy Malibu - I have found I spend less discretionary money in other ways as well.


When I went to the office, I ate out for breakfast and/or lunch - takeout or in restaurants - at least three or four times a week and often even more.  Now I never eat out by myself,  and combined with a new effort in our family to eat at home more often, we find ourselves only eating out about once a week (some weeks not at all), and more importantly, we don't find ourselves missing it much!
 

The other expense that has come down is our grocery bill.  While that may seem counter-intuitive since we are eating at home more,  I have realized that before I would stop at a store on the way home 2-3 times a week to grab something,  which often resulted in picking up something extra as well.   Now that I don't go out every day, those more expensive "quick trips into the store" have virtually disappeared.

Increased flexibility - my previous job did a good job of allowing me flexibility to go to doctor's appointments, etc., even as we went through the multitude of appointments that make up the pregnancy and birth of our third child last year, but I was still in the office every day, basically 7-4 or 8-5.


Now when I take a break to go to the restroom or get a drink,  I can spend a minute to talk to my wife,  or to throw the clothes from the washer into the dryer (our laundry closet is upstairs near my home office).

--

Of course as with everything,  there have been some minor downsides to the new situation as well:


Less social media and blogging presence - this is another item that may seem counter-intuitive,  since most articles and blogs about Telecommuting talk about the importance of the "virtual water cooler" to stay connected to the outside world.


At Ntirety we use Skype as an instant messaging tool,  and I work with two MCMs (although one of them did recently leave to from his own consultancy).  I have found that the interaction I was missing at work in the past that was driving me heavily onto Twitter is more present now in my work relationships and therefore has decreased my Twitter presence.


Two other things contribute to my decreased presence,  one of which relates to my new position and one of which relates to the changes in my family (read: having three kids in a little over three years).
My new WFH situation and it's benefit of spending more time with my family has decreased my time spent working on my blog.  I used to spend a little time at the start and end of each day in the office compiling ideas and nibbling away at blog posts, especially at the end of the day if I knew traffic for the commute was going to be bad.  Now with my 20-30 *second* commute at the end of the day (down the stairs to the first floor), usually with little traffic other than dodging a cat on the way down, I find myself in more of a hurry to get out the door and "home" to my family.  While I can apply a little self-discipline and overcome this to blog more frequently (as I do hope to do), it still takes additional effort.

The other thing - the family thing - that keeps me off Twitter as much as I used to is my decreased attendance at SQLSaturdays and other events. Having a growing family with multiple small children (now 4, 2.5, and 1 years old) has made it harder to justify to myself spending extra time away, and this makes me less interested in what's going on on Twitter - both because I don't need the event information, but also because there's a tiny little piece of me that is jealous that I'm not traveling to remote SQLSaturdays, etc.  Maybe this will fade over time, and I know I need to be more present to take part in my #sqlfamily, so I plan to work on this as well on the coming months.

--

All in all, the WFH experience has been a very positive one, and I greatly recommend it to anyone who meets the following criteria:

• You are self-directed, able to work without constant direction from your supervisor.
• You can handle not seeing your co-workers and boss every day.
• Most importantly, you have a door to close when needed - I don't always work with the door to my office shut, but there is definitely time every day when I close it.

The items I need to work on in the next six months:

• Re-invigorated online presence on Twitter, both for my own benefit and for that of the #sqlfamily
• Increased blogging - my blogging decreased even while I was at House of Brick, but as mentioned above has been almost non-existent in the last three months - my goal is to get to a post a week, even if it is a one page "micro-post."

Further Bulletins as Events Warrant!

T-SQL Tuesday #051: Always Hedge Your Bets

  
It's time for T-SQL Tuesday again and this month's host is my former co-worker, the @SQLRNNR himself, Jason Brimhall.  Jason's chosen theme is Poker Face, asking us to describe situations where someone took a bet that was just a little too risky for our liking.

When I think about users doing risky (AKA boneheaded) things, it almost always comes back to backups - or more accurately, the *lack* of backups.

"We are running a major migration *and* upgrade of our credit card processing system this weekend, but we only have a four hour window, so we won't take backups - we can just revert to last night's Windows backups, right?"

"We don't backup our system databases because they aren't important (even though they have hundreds of SSIS packages in msdb)."

"We backup our databases to the local X: drive, but we don't sweep them off to the network or an appliance - taking the backup is good enough, right?"

"We take full backups every single day and log backups every hour - but we don't have time or storage to test them."

To me, this last one is the most dangerous "risky thing" of all, because by my experience it is easily the most pervasive problem related to backups.  Almost all DBAs take regular backups of most or all of their databases, but very few seem to have regular test restores.

As Paul Randal (blog/@PaulRandal) noted in his excellent blog post (I don't know who said it first, because it is credited to too many different SQL Server professionals to count):

"You need to design a restore strategy, not a backup strategy."

One of the most important parts of a restore strategy is testing your backups.  Unfortunately in my 13+ years as a SQL Server DBA (including 4+ years as a Managed Services DBA/Consultant), I can count on one hand the businesses/clients that had a regular restore test environment and schedule, and even those businesses only did it for several "critical" databases.

Why does this happen?  I can think of a couple "reasons" (excuses) I have heard over the years:

Excuse #1 - "We can't afford the servers/time/licenses/whatever to test our backups."

BZZZZZ - False!  In reality you can't afford *not* to test your backups.  Especially in today's ever-increasingly virtualized world, it is becoming easier and easier to throw up more servers, and this often problematic fact (which can lead to server sprawl and other manageability issues for the DBA) can be leveraged in a positive way to create a backup/restore test environment that can be taken up and down or cloned as quickly as a mouse click. 

As Brent Ozar (blog/@BrentO) notes in his post "Dev, Test and Production SQL Server environments" the ideal situation is to perform nightly restores of your PROD environment into QA (with limitations related to sensitive data, etc. as Brent describes) which not only gives you the benefit of current data in your QA environment, but also tests your backup/restore process as well.

Paul Randal ("Mr. DBCC") notes in his thorough blog series on "CHECKDB From Every Angle" that an additional benefit of performing this type of backup/restore testing is the ability to run your regular CHECKDB - BTW - you do run regular CHECKDB's on all of your databases, user and system, right?  That's another poor DBA practice for another blog post - many DBAs only run CHECKDB once in a while or only when something goes wrong (which is usually too late).  You need to run CHECKDB as often as your system can handle it - daily is great but weekly is definitely better than many DBAs do.  As Paul succinctly puts it in SQLskills's great Immersion Event classes, your data is only as clean as of the time of your last successful CHECKDB. </rant>

As I was saying, with a regular backup/restore strategy, you can run your DBCC CHECKDB against that restored copy and a clean result will show you that your PROD database is clean *as of the time of the backup*.  This last part is especially relevant - if your PROD backup runs at 10pm and you restore it to QA at 4am and get a clean CHECKDB against QA, but then find out later that morning that there was a problem at 1am, your clean CHECKDB doesn't mean anything other than helping put a box around the problem - the corruption occurred sometime between the 10pm backup that resulted in the clean CHECKDB and 1am when the problem was discovered.

Excuse #2 - "We only need to test restores on our critical databases, right?  The other databases don't mean as much."

BZZZZZ - False!  At the risk of another rant, this leads me to another common misconception many DBAs/managers/carbon-based lifeforms have - "It's just DEV, so it doesn't matter."

It took me a few years to get it, but for some time my take on this scenario is:

"Every system is PROD to somebody."

What about a DEV system?  It's PROD for the development team - and heaven help you when the DEV databases that haven't been backed up for six months (you know, the bi-annual DEV backup scheme) goes down and loses all of the code for the latest release that was supposed to be checked into Source Control, but you know, they didn't have time and it shouldn't matter because the DBA backs up the databases, RIGHT?  To management and other IT teams, it is always the Default Blame Acceptor's fault - and you are kidding yourself if you think otherwise.

What about a QA system?  It's PROD to the QA team and their testers - and unless you have the nightly backup/restore to QA cycle described above in place, do you know how long it will take to refresh QA from PROD?  Especially if you have to scrub out the sensitive data - a restore of an already-scrubbed backup of QA will almost certainly be significantly faster than a "scrub & refresh" from PROD. How many hours of lost QA work will there be, possibly impacting an upcoming release date, before QA is back online?

I know that these comments are mostly written from a development shop point of view, but even if you don't build your systems - you just buy third-party software for everything - you still probably (should) have at least one layer of DEV/TEST/QA system to test regular patches and new vendor code releases on, and the same statements made above apply to those systems as well.  Consider this comment that could easily cost you your job: "Sorry, Mr. CIO, but the SharePoint upgrade for tomorrow can't happen because the QA team hasn't finished their work yet and QA is down with no database backups."

--

Too make a long story short (I know - too late) - without regular test restores, your backups do not provide much of a guarantee of recoverability.  (Even successful test restores don't 100% guarantee recoverability, but it's much closer to 100%).

WHATEVER YOU DO - DON'T STOP TAKING BACKUPS JUST BECAUSE YOU CAN'T REGULARLY TEST THEM - THIS WOULD BE WRONG-WRONG-WRONG.

Instead, use this a reminder that backups are good, but backups with test restores are much, much better!

The Next Phase of My Career

For anyone who hasn't seen an update somewhere else in the social media universe, I recently started a new job as a Senior SQL Server DBA for Ntirety on their remote DBA team.  Ntirety is a top Remote DBA services firm that works in MSSQL, Oracle, and mySQL support.

Why would you do that, Andy?

I made this move for several reasons:

• Ntirety has a larger Microsoft SQL Server business than my previous employer - sure Ntirety also handles Oracle and mySQL, but MSSQL is the largest portion of the business.  My previous employer was heavily Oracle (and VMware) focused.
• The ability to work from home - at my previous job, I had the opportunity to intermittently work from home when I had an appointment, etc. (and they were very easy to work with from this point-of-view), but the expectation was clearly that we should be in the office whenever possible (and this expectation has grown over the two years I was there).  My new job is 100% WFH with occasional trips to the mother ship in Boston.  I have never worked 100% from home, but am looking forward to the opportunity to not have a 30-40 minute commute each way every day.
• Decreased travel - at my previous job we were 50/50 (maybe 60/40) consulting/remote managed services, and almost all of the consulting was traveling to client sites all over the United States.  While I traveled less than some of my colleagues, it was still significantly more travel than I would like.  I came into the company after an interview process discussion about how the company did both types of work and that people could choose a path, but it became readily apparent that the model was designed around starting in managed services and then "graduating" (for lack of a better analogy) into becoming a traveling consultant, and this model is not for me.
• The opportunity to work with other senior personnel - two of the staff at Ntirety are MCMs and I know just working with them will help me enhance my skillset. (HASHTAG MCMsAreCool HASHTAG Fanboy HASHTAG TotallyStealingThisFromJimmyAndJT)  As many readers of my blog already know, the star MSSQL employee (and hopefully soon-to-be MCM) from my former company recently left to form his own practice, leaving a void that has not been filled.

Sure there is a little more money (plus some savings in gas, etc. from no commute) but that isn't the reason I moved - if I had just needed a little more cash I would have worked with my employer to find out what I needed to do to make that happen. This is 100% about quality of life, the opportunity for technical growth and (most importantly) the opportunity to be more present with my family and our boys.

So what's next?

As you may (or may not) have noticed, my blogging has been very slack over the last year,  and I hope my new role will re-energize me to increase my focus on this important aspect of technical development.  As mentioned above, I have never worked from home full-time, so expect to see posts in the coming weeks on my experiences with this new job style.  There are already multiple blogs describing tips and tricks and personal experiences on working from home (listed in no particular order):

• Merrill Aldrich (blog/@onupdatecascade) and his post "Five Things I’ve Learned About Surviving the Telecommute"
• Brent Ozar (blog/@BrentO) and his series on tips for Telecommuters
• K. Brian Kelley (blog/@kbriankelley) and his cautionary post "Why I Don't Look for a Telecommuting Job"
• Thomas LaRock (blog/@SQLRockstar) and his post "Eight Things I have Learned While Telecommuting"
• Erin Stellato (blog/@erinstellato) and her description of "What I Know For Sure…After One Year at SQLskills"

While I greatly value all of these fellow #sqlfamily members' opinions, I also know that everyone's experience is different and I look forward to documenting my personal journey with telecommuting.

I also know that every job brings a new set of technological experiences, and hope to blog about those as well. 

Wish me luck!

Hung SQL Server Restores from Tivoli Storage Manager/Tivoli Data Protection

I ran into this with a client last night when trying to restore their SQL Server data warehouse database from TSM.

We went through several iterations of the restore failing without any meaningful error other than a cryptic “TCP/IP Connection Refused” even though we could ping and telnet from the database server to the AIX server hosting TSM.  The TSM technician at the client could see multiple tapes loading and then just sitting, with only a little data transferred to the database server at the beginning of the process but no large scale data transfer.  From my end on SQL Server I could see several connections from the TSM client (Tivoli Data Protection/TDP) that appeared to be waiting as well for BACKUPIO with little CPU or I/O traffic, but the wait time was cycling up and down rather than continuously increasing, as if the thread was doing a little work rather than completely blocked.  Perfmon showed no I/O on the disk to which we were going to restore.

The first several tries at the restore ran for about 20 minutes and then failed with the TCP/IP error.  When this occurred, a database was created on the SQL Server in “restoring” mode immediately before the failure and empty files were created on the disk at this same time.  For each subsequent attempt I deleted the restoring database and the empty files.

I found an article that talks about the length of time required to zero-initialize large database files and the potential need to increase the timeout on the TSM server (COMMTIMEOUT) to allow the SQL Server time to zero-initialize the files.  We tried this, but realized after 25 minutes of no change that with no traffic on the disk (in PerfMon) that it couldn’t be just waiting for SQL to zero-init the files.

The TSM technician found a IBM article about Tivoli Data Protection that talked about hung restores being related to striped backups.  In this client’s case, they stripe their TSM/TDP backups with four stripes to increase performance (fine) but they do it to media pools (not fine).  As a result in this case, there were four backup stripes written to only three tapes.  By default, the TSM/TDP client restores with the same number of stripes as the backup, but when it tried to queue up all four stripes at once it couldn’t with two of them on one tape. 

The answer was to modify the restore request to run as a single striped restore, which succeeded.  It still took about two hours for the restore of the 214GB database, but when we kicked off the single striped restore we immediately saw a difference on both the TSM server and the SQL Server.  It took the TSM server a couple minutes to load the first tape and then progress was visible in the TSM/TDP client window, data was being transferred from the TSM server, and the connections in SQL Server showed I/O.

This is potentially an issue with any enterprise backup system that backs up using multiple stripes to tapes in media pools unless that system is internally intelligent enough to prevent the “two stripes on one tape” issue described.

New Page - "How to Get Involved With the SQL Server Community"

I recently composed an email (on the side) for a client DBA looking for info on getting involved with the community, looking for training, etc - and now I have turned it into a web page here on my blog - please check it out and please let me know anything I should add or fix - I want this to be as accurate and helpful as possible - thanks!

http://nebraskasql.blogspot.com/p/how-to-get-started-with-sql-server.html

SQLPerformance.com

I have had the opportunity to go through the first three SQLSkills Immersion Events, and one of the side benefits of that is getting to meet and interact with their team.  One of their team that I never really even knew of before he joined SQLskills was Joe Sack, and (like everyone at SQLskills) he is just too smart (It isnt fair!) :)

He has a great new article up on SQLPerformance.com about "Troubleshooting SQL Server CPU Performance Issues" and while it may seem like basic stuff it isn't - CPU issues are not something every DBA deals with every day (Memory and IO issues yes, but CPU not so much) and he describes a good framework for where to look for information and how to get started.

I don't think for a minute that there is anybody reading my little blog that doesn't already read the SQLskills blogs, but I wanted to draw attention to this because it isn't a SQLskills blog.  SQLPerformance.com is a dual effort between SQLskills and SQL Sentry, and their blogroll is crazy-talented:



Make sure to check it out - a new article comes out every week or two, and the content is top of the line.  You won't regret it!

T-SQL Tuesday #42 - The Long and Winding Road

It's T-SQL Tuesday again (Thanks go to Adam Machanic (B/T)) and this month the host is Wendy Pastrick (B/T).  Wendy's excellent subject is "the long and winding road" - changes in our work lives and how they impact us.

I am luckier than most in that many of the changes in my work life over the years have been self-induced - I have never been fired, laid off, downsized, or any of those other HR terms.  I started as a help desk support admin who got the opportunity to learn Microsoft SQL Server when our group at the University went to a Microsoft development model (Visual Basic 6.0 on SQL Server 7.0 at the time - yes, I'm old).  Since then I have changed jobs from working for a major public University to a large regional bank to a regional healthcare system then back to that bank and then on to my current consulting gig, and all along I have changed positions on my terms - not always exactly when I would have preferred, but at least on my say-so.

Most of the direct changes in my work life over the years have been changes of technology and role - learning MSSQL 2000-2012, gaining experience in different industries and interacting with different side technologies such as VMware, becoming a senior/lead DBA and then a consultant, building amazing relationships with my #sqlfamily, and meeting some of the most brilliant (and nicest) people on the planet.

All of that aside, the biggest change in my 13+ year DBA work life is an indirect change that has nothing to do with any of the above.  Six years ago I married my best friend, and over the last three-and-a-half years we have had three amazing boys (Noah 3 years, Jonah 20 months, and Micah 3 months).

Wow - this really all I can say - Wow.

I am lucky enough that what I do is sufficiently lucrative that my wife can stay home with our boys, but an unfortunate side effect of what I do is that I have to go on the road for my job - both to consult and for training - sometimes for days, and sometimes for weeks in a row.  I am writing this in a hotel room in Chicago while they are 500 miles away at home.  My growing desire to be involved with SQL Saturdays and the community (my #sqlfamily) just infringes on my real family even more.  It has become an amazing balancing act and many days I don't feel like I do one side or the other justice, but I keep trying.

...and trying.
 
I am at the point in my career life where nothing is more important than my wife and kids, and getting further ahead in my job is less important than getting a raise/promotion/whatever at work.  My job is merely a means to an end to allow me to support my family - it is not my reason for being.  This is a double-edged sword as it can be difficult to even keep up in our field without excessive time off-clock keeping our knowledge updated, and it also makes me painfully aware of the times I bring work frustrations home and how that impacts my wife and sons (even as little as they are).  I begrudge every minute I am on-call or have to work an after-hours release because I know I am missing some first in my boys' little lives, but that's the job, and I know that.

No matter what, I will always keep trying - they are my everything and they are definitely worth it.

Announcing SQL Saturday 197 Omaha Pre-Cons!

Here is a flyer produced by someone on the team - he says it all very well:

--

Friday, April 5, 2013
Get Warmed Up For SQL Saturday By Attending The Preconference!  
Three Great Speakers, Three Great Topics!

--

Scaling SQL Server 2012 (Glenn Berry - @GlennAlanBerry)

How can you scale SQL Server 2012? Scaling up is relatively easy (but can be expensive), while scaling out requires significant engineering time and effort. If you suggest hardware upgrades you may be accused of simply “throwing hardware at the problem”, and if you try to scale out, you may be thwarted by a lack of development resources or 3rd party software restrictions. As your database server nears its load capacity, what can you do? This session gives you concrete, practical advice on how to deal with this situation. Starting with your present workload, configuration and hardware, we will explore how to find and alleviate bottlenecks, whether they are workload related, configuration related, or hardware related. Next, we will cover how you can decide whether you should scale up or scale out your data tier. Once that decision is made, you will learn how to scale up properly, with nearly zero down-time. If you decide to scale out, you will learn about practical, production-ready techniques such as vertical partitioning, horizontal partitioning, and data dependent routing. We will also cover how to use middle-tier caching and other application techniques to increase your overall scalability.


Practical Self-Service BI with PowerPivot 2012 for Excel (Bill Pearson - @Bill_Pearson)

SQL Server MVP and Business Intelligence Architect Bill Pearson leads this full-day, hands-on introduction to using PowerPivot 2012 for Excel to deliver self-service business intelligence.  The focus of the course is to help those new to PowerPivot to become familiar with the assembly of data from diverse sources into models that deliver business intelligence upon demand.  Participants will gain exposure to accessing and relating data, and to employing the Data Analysis Expressions (DAX) language, to construct and share PowerPivot applications that support analysis and reporting throughout the enterprise.  The intended audience is information workers (business- or IT-based) involved in analysis and reporting of data,  intermediate - to - advanced Excel users,  practitioners that want to gain familiarity with PowerPivot to build compelling analysis and reporting applications to deliver self-service BI.

 

Prof. PowerShell: Or How I Learned to Stop Worrying and Love PowerShell (Jeff Hicks - @JeffHicks)

Windows PowerShell has a special talent for simultaneously exciting and terrifying IT Pros. Many see it as just another scripting language or passing fad. Other's see it as an essential technology for managing today's Windows-based environments. Some IT Pros feel overwhelmed and don't know where to start and others dive right into the deep end, sometimes with mixed results. In this one day session, PowerShell MVP, author and Prof. PowerShell will dispel fears, myths and misconceptions surrounding this must-know management tool. If you've been dabbling in PowerShell, wondering what all the fuss is about, or simply want to get a jump start, this is the session for you. After this crash course on PowerShell 3.0 you'll realize you had nothing to worry about begin to feel the PowerShell love.
This isn't a formal training course, but bring your laptop with PowerShell 3.0 and feel free to follow along.


Get Tickets Now: http://SQLSaturdayOmahaPrecon.eventbrite.com/

Pricing:
Early Bird Special = $100
After March 22nd = $115

--

Register now!

The Value of Certifications

A former co-worker recently sent me an email asking about Microsoft certifications, and if I pursued them, and what I thought about them.  I started to write a response and it sounded like a good blog post {-: so here it is:

--

I am certified through the gills in SQL 2000 (MCDBA) and 2005 (MCITP), but when it came time to upgrade to 2008 I got distracted by life and let it slide.  I finally tried the upgrade exam once right before it retired and just missed passing it.

My experience with certs is that many people don't value Microsoft certs because they are seen as just paper - the only cert that really is valued in the community is the MCM (now the MCSM) - the Master certification.  The catch in the MCM/MCSM is that it requires most of the lower level certs as prerequisites - you have to be an MCITP Admin *and* an MCITP Developer as prereq's for Master.  (The developer requirement is why I sincerely doubt I will ever pursue MCM/MCSM.)

Unless you are interested in going for Master (or are looking at a specific job listing that requires you to be an MCITP) I would not spend your effort (and $$) on it - you will not see much real reward out of it other than whatever intrinsic feeling of accomplishment you get from passing tests - there are no raises or better jobs or anything else just from being certified *if* you already have experience.  For a brand-new DBA there may be some benefit if you are competing for jobs against other new DBA's - the guy with the no experience and the cert may have an edge over the guy with no experience and no cert.

Having said that, the certification blueprints (topic lists) are good sources of study material if you just want to know what there is to learn for learning's sake - but you can do that without shelling out a few hundred dollars per test for multiple tests.  Most of my SQL 2000 and 2005 certs were achieved while I was working for a boss who saw great value in certification and education and therefore funded everything.

Someone told me back when I worked at the University of Nebraska - a certification just tells a potential employer one thing - that you know how to take tests.  For Microsoft certs lower than Master, I completely agree.  The Master is a two-part written and lab exam and is supposed to be the best exam MS has ever created.  One of the guys in our office recently took (and passed) the Knowledge (written) half of the exam and it blew his mind compared to all of the MCITP tests.

So....if you are thinking of becoming a certified Master (I think there are ~75 of them in the world) then you *have* to take the lower tests and you should get on it.  If you are not thinking of that, then I wouldn't worry about it.

--

...and that's my $.02

Why is My New Server Under CPU Pressure?

Signal waits frequently translate to the amount of time that SQLOS is under pressure for CPU resources, as outlined in this TechNet article (http://technet.microsoft.com/en-us/magazine/hh781189.aspx). While a lower number is almost always better, it is a useful metric is to start paying attention to when the number rises over 10%. Your system will usually start presenting issues at the hard line of 25%.  This something that we check on every server that we touch as part of our regular health check.

Today I tripped over a conundrum - I was given a new server with a fresh install of SQL Server 2008R2 and Reporting Services, and on this system the Signal Waits were measured at 25.19% on our scan, which shows that this system appeared to be under some CPU pressure.  All wait statistics are reset each time the SQL Server service restarts, so this number (25.19%) is only since the last service restart.

This system in question is a physical box and has two sockets with six cores each with hyperthreading (so 24 logical CPU’s), and that made me pause – why does a new server with two small databases (from Reporting Services) and 24 logical CPU’s show high Signal Waits, which usually indicates CPU pressure?

The answer is that in this case, this new server is *too* quiet, and as such the numbers are skewed.  Here are the specific wait stats, measured after clearing the total wait statistics using the DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR) command.

 

As can be seen in this shot, almost all of the Signal Wait time is in two categories, XE_TIMER_EVENT and REQUEST_FOR_DEADLOCK_SEARCH, both of which are basically system background processes (waiting for XEVENT processing and deadlock processing, respectively) and neither of which are therefore relevant to measuring the busyness of the server.  On a regularly busy server, all of the other wait categories (over 400 in total) greatly outweigh these two background processes and the normal query we use that compare signal wait time to total wait time is useful.  In this case if we exclude these two categories:

  

We now see that the server has zero Signal Waits and no CPU pressure, as expected.  For a good description of the different types of waits and what they mean, look at http://blogs.msdn.com/b/psssql/archive/2009/11/03/the-sql-server-wait-type-repository.aspx from the Microsoft Customer Service and Support (CSS) team.

Linchi Shea has written several great articles on Signal Waits and what they mean in SQL Server.  They are here and here - check them out as well.