Thursday, July 10, 2014

How to be an amazing DBA

When you ask what makes a great DBA, what answers do you get?

-Get lots of certs!

-Oh you have to have a blog!

-Become a speaker at SQL Saturday! (or any of the other respected trade conferences)

-Mentor juniors!

....etc


While all of these are good answers, and will definitely help your intellectual credibility, none of this is worth a job if you're not customer-focused, result driven, and generally easy to work with.

A story. I tried for many years to break into the DBA world. I had quite a few jobs where I got to touch the database server occasionally: troubleshooting connectivity, doing backups, giving users permissions...simple, very junior administration. But I didn't have the experience to get a job as an actual database administrator, and where I worked doing application support there was absolutely no room (nor need) for a DBA. So I decided that getting my certifications was a good way to break into the business.

I went ahead and studied (and received) my MCDBA. I went to a small technical training firm to do this as I was able to pay for the materials and test in one lump sum, and had access to live help if I had additional questions. After receiving my certifications, the training company asked me if I wanted to work for them! They were so impressed with the fact that, when I was at the center in the evenings, I would help other students and was generally friendly and outgoing.

I worked there for three months as a trainer while trying to find that elusive DBA job. I saw an ad online for a Jr DBA position and applied. I was asked some fairly simple questions (like the difference between a user and an login) and then was invited to come in for a team interview. They asked me many more questions, most of which I knew from my training, and a few where I had no idea if they were even speaking English! Overall I thought the interview went well, I liked the team and we all seemed to mesh.

I got the job. My first REAL Database Administration job. I was so happy! I did very well, moving from Jr DBA to Sr and Team Lead within a few years of putting in a LOT of hours, studying my butt off, and working like a dog.

After I left that company, I had a conversation with my old boss. Got the news that after my interview the team didn't actually recommend that I be hired, they didn't think that I had the technical skills to be a good addition to the team. I was crushed! But luckily, my boss overrode their advice and hired me. Why? Because of one thing I said in the interview when asked about how I approach my job. I said "We're all on the same team, trying to get the same problems solved. While it may be frustrating at times, you have to put yourself in other people's shoes and see things from their point of view. In the end my job is to make their job easier."

Think about that. How much more smoothly would your company run if everyone had this attitude? You'd never hear "It's not my problem" "It can't be done" or just flat out "No". Instead you'd hear things like "Hmm, well I can't help you, but I think I know someone who might be able to...let me send them an email and I'll CC you" or "Well, it can't be done that way, what result are you trying to achieve and why? Maybe we can go about it a different way." or "Why do you need this? What's the end result you want to see?" (which brings me to something I will blog about in the future, always ask one more question, because the user may SAY they need a mauve database, when actually they might just need a report emailed to them or to be taught how to do something. Get to the root need before throwing solutions at something that may not even be an issue).

Overall what I'm saying is: to be not just a good but an amazing DBA you need both the technical chops AND the empathy to put yourself into the end-users situation. Having both of these skills will make you a very valuable employee, well-liked and respected, and never wanting for work (or friends)!






Wednesday, July 2, 2014

"Attempted to read or write protected memory" error

At my current workplace we have actual desktop computers, but are issued laptops in case we have to work remotely. If we want to access any of our installed programs etc we RDP into our desktop. This works out fairly well as my connection is quick enough for me to be able to do most everyday tasks when working remotely.

Then I got to thinking...

What happens if my workplace becomes a smoking hole? What if I'm unable to RDP to my desktop? I have SQL set up with my registered servers, RDCMan set up with all of the SQL instances I may need to connect to, all of my miscellaneous text files and screenshots that I haven't gotten around to archiving on the network...basically I'd be hurting.

So I decided to knuckle down and install all of my tools onto my laptop and then use a dock to connect to my monitors when I'm in the office, a fairly straight-forward process.

Until I installed SQL 2014 and tried to import my registered servers.

BAM


"Attempted to read or write protected memory" error. SQL crashes and restarts. Repeatedly. Whenever I try to log into an instance. When I try to add a registered server. Basically when I try to do anything.

What fresh hell is this??

So I did what any other good DBA would do and Googled the error. I found all sorts of links telling me to do everything from reboot my computer to replace my disk drives to give up and go home (I liked that one best!). I tried a few fixes and got a whole lot of nowhere.

Then I decided to look at what was different between my two computers. I looked at what was recently updated and saw that on my laptop that .NET had been updated to 4.5.1, Hmm I thought...I remember seeing something about this. I started digging through my emails and found one mentioning that this update 'breaks things' (yeah, real specific) and to run this to see if it helps:




netsh winsock reset

Well I ran it and BINGO, everything is running smoothly again, I'm able to log into instances using SSMS, can add my registered servers, and everything is as peachy as it can be when you're stuck in an office on a beautiful summer day.

I'm sure there are other reasons the protected memory error comes up, but this seems to be rather obscure and I wasn't able to find a fix easily so hopefully this post can help someone else!