I really can't stress the importance of doing your own legwork when it comes to doing server discovery. And in this case I'm not talking about discovering the servers themselves, but discovering the setup of the resources of the server.
I've had several instances where I've been lied to by either other in-house support personnel, or vendor support about the layout of the server, a certain setting in the DB, or even how the disks are configured. And every time I've found out the hard way that what I was told was incorrect and we had been troubleshooting for a long time with false information.
Having had this happen so much has left me pretty untrusting of anything anyone tells me and it can really rub people the wrong way sometimes. Just last week I had a situation where a DBA from a vendor told me that the DB was setup a certain way and I went and verified it right then. He got a little upset because he had just told me that and what do I think he is, stupid? Hey, it's not that at all. You really have no idea what's on the server. Someone could have come in behind you and changed the setting for any myriad of reasons.
So now I find that I can't even begin troubleshooting an issue until I verify my own disk layouts, memory, SQL settings, etc. It just makes things so much easier when I personally know exactly what the server looks like. I also impose that on my Jr. DBAs. I will often give them slightly wrong info when asking them to do something just to get them used to verifying their own info. And it's really best. I know I've accidentally lied to someone before when they asked me something about a server and I boldly gave an answer only to find that someone had changed it a couple weeks ago because something happened that made it an unviable setting.
The bottomline here is never trust what anyone tells you about a server. They may not mean to, but people lie all the time. It's even happened to me before. And if you can, don't even take their word on what the issue is either. Again, people lie. It's not entirely their fault, but everyone colors their report on issues through their past experiences, or what they feel. It's very difficult not to. So if you get a call from a user telling you they can't get through the firewall to get to the DB, politely ask to see a screenshot of the error message. Because the problem here is they didn't report a problem to you, they reported a diagnosis and users are notoriously bad at diagnosing technical issues... that doesn't keep them from doing it though.
So unless they're reading the exact message to you, or pasting the exact message into an email, or sending you a screenshot, then assume they're lying and insist on one of those.
And don't trust yourself either. The more servers you manage the harder it is for you to remember specifics on each one. So trusting your own memory is often times just as bad as trusting someone else's.
Sean McCown holds a double MCITP in SQL Server 2008 for both Administration and Development. He is also a SQL Server MVP with over 15 years experience in databases. Sean is a contributing editor with InfoWorld and a frequent contributor to many community sites and forums.
Sean has also created content for TrainingSpot.com, TrainSignal, and moderates the Petri IT Knowledgebase SQL forums. Sean also speaks a various SQLSaturday events and is a board member of his local user group, the North Texas SQL Server User Group (NTSSUG).
What's with the blog name, SQL Marklar?
The word marklar stems from an alien race named the Marklars, which appeared in an episode of South Park. The Marklars use the word marklar as a generic word, similar to a pronoun, that can refer with specificity to anything, place, person, idea, concept, or otherwise represent the meaning of any noun, including proper nouns. Ex: This marklar has been marklared by a marklar and now I can’t marklar with it anymore.