Wear their shoes

Last night I had the pleasure of hosting our local SQL Server User Group and having Rie Irish speak. Despite it being a remote presentation, which usually draws a smaller crowd, we had one of our larger crowds in awhile; I was quite pleased.

The topic was “Well Actually… Don’t be THAT guy in IT.” I first saw her present this at the Atlanta SQL Saturday 2018 and knew I wanted her to speak again to my user group.  She had previously presented “Let Her Finish” and this was a good follow-up.

One of the points she makes during this particular talk is that men don’t know what it’s like to be in a woman’s shoes.  This triggered a memory of when I was a wee lad.

Let’s jump back into the old Time Machine and dial it back to early September 1985. It’s evening on the campus at RPI and a young college freshman is hanging out with one or two other guys trying to figure out what evening session for their student orientation they should go to. They see a session provided by the Society of Women Engineers (SWE) talking about women in engineering. One of them says, “Oh that should be fun” in a voice that probably had at least a bit of snark in it. So, this young, intrepid and naive freshman follows along, after all, at a school with a 5:1 ratio, one might as well go where there’s some women.

Now, this young freshman can’t quite remember the entire session, but he did come away with a very different impression than he thought he would. Basically it was an “Oh wow” moment. Prior to that he had no idea the sexism women might face at an engineering college where in theory one was admitted solely on merit. It was eye-opening.

Jumping back into the time machine, we can dial it forward about 18 months and set down at a house off campus where he’s talking with one of his housemates. She mentions she had started as an architecture major but changed majors, for a variety of reasons. But, one thing that stood out was her first day of class where a professor made it quite clear that he didn’t think women should be architecture majors. He was a bit shocked that such attitudes still existed, but by then wasn’t entirely surprised.

Again, jumping in the time machine, he dials things forward about 2 years later. He’s sitting in the backyard of a sorority house talking with his girlfriend and a mutual friend. The mutual friend is a geology major. She mentions how she has gotten into the habit of submitting her homework and papers with simply her first initial and last name. This less naive man doesn’t quite get the reason why at first until she points out that this way, her professor can’t as easily identify her gender, and it makes her life easier and she tends to get better grades that way. He doesn’t want to believe it, but he does, because he figures she has no reason to lie.  It angers him though that she has to do it.

Let’s jump forward now about two decades. Due to his then current work situation, he’s actually staying with the now former girlfriend from college. In the years since they graduated and broke up, she had gone on to become a VP of engineer at a medical devices company before eventually quitting and going into consulting. He’s making dinner when she comes home from a meeting she had with a client. She’s visibly upset.

He asks why. After all, she was simply going there to give her final report on an item she had been asked to review and to get paid for that report.  The client had accepted the paper, and then asked her for a date. What had been a professional setting now became an awkward setting where she was placed in a position of having to say no to something she never expected to come up and to still make sure she got paid.

Jumping into the time machine one last time, we return to the modern day where Rie is still speaking. This no longer young man has to agree.

He’s had glimpses into what close friends have gone through, but, that’s exactly what they are. Glimpses. He didn’t experience them. He has never, as another friend has had happen, been told if he gave a blow job, he would get the job.  He’s never had a door close behind him and a manager awkwardly try to make a move on him.  He hasn’t woken up most mornings wondering, “who will question my credentials today because I have large breasts.”

Today’s takeaway for a number of my readers is: listen to your colleagues and believe their experiences, but don’t for a minute claim to fully understand them. Many of us never can and never will.

Oh, and one more comment: this author is far from perfect when it comes to handling gender and other similar issues. It’s an ongoing process.  I’m still trying to learn and grow.

 

Followers and CPR/First Aid

Yesterday, I performed a little social experiment and was pleased to find it worked. I’ve got to say, sometimes it’s the small things that make me happy.

Despite the below zero (Fahrenheit, so really cold, not that warm-cold of 0°C) temperatures, my son and I decided to head up to a local state park and do a hike.  Surprisingly, OK, maybe not, when we arrived, the parking lot was completely empty.  It had been plowed, but there was still a layer of snow over the entire thing, so it was impossible to see where the parking lines were. Now in the summer, this parking lot can be completely full, but I wasn’t too worried about that occurring when the temp was about -4°F.

So, which way to park? Well, there was some sun, so I figured I’d park so that the windshield would get the most sun and hopefully warm up the car just a bit while we hiked. I was sure at the time and later confirmed, this was at a 90° angle to the way the parking lines run. Ironically it was also about 90° colder than the summer temps!

Even when we started hiking, no one else had shown up. But, I have to admit, in the back of my mind I had to wonder if I would start a trend.

Sure enough, 1.5 hours later, when we arrived back at the car there were 3 other cars.  Not only were they parked in the same orientation, they were all parked right next to my car.  This parking lot probably covers 3 acres. They could have parked pretty much any place they wanted in any direction they wanted. But, because I had randomly picked a spot (and not so randomly a direction) 1 car was parked next to me in the same orientation and the other 2 parked facing us.

So what does this little experiment have to do with First Aid or CPR? Have you ever been at an event when someone has a medical event and at first no one reacts? It’s actually fairly common.  Everyone is standing around waiting for someone else to react. But once someone reacts, others tend to follow.  Be that person that others follow.  Learn CPR and learn First Aid so that when something happens, you can be the first to react. Sometimes people just need a leader to follow; and often they don’t necessarily realize it.

There’s no good reason anyone else parked just like I did, and yet they did. But there is a good reason for people to follow you if you can be the first to react in an emergency.  And you don’t have to be an expert. Obviously it didn’t take “expertise” to park yesterday, but people followed anyway. You don’t have to be an EMT or paramedic to react at a medical emergency. You can be the person that simply shouts, “Call 911” and gets people reacting.

That said, I still highly recommend taking a CPR and First Aid course. Not only do you learn very useful medical response skills, it will help you be that person that reacts first.

And stay warm!

Barriers

Years ago, I had my team building out our racks at our new datacenter. I was quite proud of it. It was going to be our first planned from the start build-out of 6 racks, as opposed to the hodge-podge build-out we had done of 5 cabinets we had previously rented. Instead of just cramming in equipment where it would fit, we could plan where every piece would go and where we’d leave room for future expansion. This was in 2001, so it was still during a big Internet boom.

One of the things I had decided on doing early on was color coding cables. Red was for anything in front of the firewall for example.  On the backside, every server had two network cards, one for outgoing traffic (the “front-net”) and the second for traffic between the servers (the “back-net”).  To help distinguish between the two, I had ordered a bunch of green cables for the front-net, since that data was “safe” and green is “safe”, and blue cables for the back-net, both start with “b”. Sure, somewhat silly mnemonics, but they worked.

Until, about a week after we finally completed our datacenter move, not one, but two members of my five person team commented, “oh, they were different colors? I couldn’t tell, I’m colorblind.”

“Doh!”  So much for my nice color-coded system.  It can be fairly easy to overlook barriers when you don’t see them. Sometimes it takes more thought and action on your part. Sometimes it takes asking questions, or observation.

Lately I’ve been trying to look for more barriers that I might not have seen before and looking into what I can do to remove them. I’ll be the first to admit, I’m not always successful and I’m still learning. But hopefully we call can.

One area I’ve been focusing on this is in my work for the Capital Area SQL Server User Group. Right now I’m looking at two possible barriers. I say possible because I honestly don’t know if they’re issues or not:

First, I’m trying to find someone who can provide ASL interpretation.  Here’s the thing: we have never had, as far as I know, a deaf person attend one of our events, or even express an interest. Is that because there are no deaf DBAs in the area or because they know if they do attend, they probably will face barriers an person with hearing won’t face?

But, that actually begs the question: if there are no deaf DBAs in the area, why? Perhaps there are deaf people who WANT to become a DBA, but can’t because the barriers that exist well before they even attempt to attend one of our events.  I don’t know, but I hope to explore this issue a bit more.

Another item I’ve started to look into, is whether some sort of child-care services at our SQL Saturday event would help encourage more people to attend. My initial thought is, “it’s Saturday, so ideally a spouse can watch kids” or a similar solution. But, that’s assuming every attendee has a spouse or the extra money to hire a babysitter for an entire day. In other words, it’s making a lot of assumptions.  There’s definitely some major logistical concerns that I have to continue to explore before we can even think about offering it. But I’m also simply trying to figure out if it would make a difference.  Unfortunately, currently for our user group meetings itself, it would not be practical. But even then it may be worth looking into.

On a personal note, I have a friend who had a service dog. She was interested in joining me on a caving trip.  So we actually discussed the logistics of it and determined that it was in fact possible to take her caving with her service dog.  There was some logistics we had to work out and I did have to get permission from the cave owner.  Unfortunately, our scheduling never quite synched up and we had to forego the trip. But the point is, barriers CAN be overcome if one works at them and is willing to be a bit flexible.

Today’s takeaway: What barriers have you looked for and tried to remove? They’re out there, even if you can’t see them.

 

Moving the Needle – Hard

One of the things I enjoy is problem solving or “debugging”.  I don’t necessarily mean debugging code, though I’ve done plenty of that.  One particular class of problems I like solving is when something isn’t working “right”.  I’m currently involved on one such issue.

Just before the holidays, the lead developer at one my of my clients put me in touch with a team in another division to help them solve some performance issues they were having with their SQL Server. This is the sort of issue I generally like to sink my teeth into.

I started poking around and asking questions. I was a bit crushed when in the initial review they listed all the things they had tried and I had to nod my head sagely (which, being a remote worker went unnoticed by them) because they had tried all the basic things. They had, fortunately for them, ruled out a lot of the easy fixes.

So now it came down to some digging. I won’t go into too many details, but will cover some of the things uncovered and tried. For one thing, they have 44 SQL jobs that run every 20 seconds and basically do a poll of a database to see if there’s any work to be done. So, every 20 seconds 44 SQL jobs would fire up, do a quick select and then go back to sleep.  On their new server, they were on average taking 6 seconds a piece.  In addition, the CPU would spike to 100% for about 5-6 seconds and then drop back down. We are also seeing a lot of wait states of the MSQL_XP variety (accounting for about 1/2 the time the system is waiting and averaging about 61.1 ms each time. [Thanks to Brent Ozar’s script here!])

We tried three things, two helped, one didn’t.

First, I asked them to spread the jobs out. So now, basically 2-3 jobs are started every second. This means over a 20 second period all 44 jobs are run, but not all at once.  This had an immediate impact, the jobs now were taking about 2-3 seconds. A small victory.

Secondly, we changed the MAXDOP settings from 0 to 4.  This appeared to have no impact on the jobs. In retrospect makes a lot of sense. Each job is a separate task and basically single-threaded, so SQL Agent won’t care about the MAXDOP.

For those who aren’t familiar with SQL Server, MAXDOP is short for “Maximum Degree of Parallelism” This controls how much SQL Server will try to spread out a task among its CPUs. So for example you had 100 tests to grade and sort into alphabetical order and you had 1 person to grade them. That one person would have to do all the work. You might decide that having 100 people is 100 times faster since every person can grade a test at the same time. But then you have to hand out the 100 tests and then collect the tests and resort them back into alphabetical order, and this takes longer than you think.  So by playing around, you realize it’s actually faster to only have 10 people grade them and sort them.  In other words, sometimes, the effort of spreading out the work itself takes longer than the time saved by spreading it out.)

But, one thing that didn’t change was the CPU spike. But, since the poll jobs were twice as fast, we were happy with that improvement.

However, the real goal of the poll jobs was to wake up ETL jobs to handle large amounts of data. These were running about 1/2 as fast as they’d like or expected.

Here, MAXDOP does seem to have changed things.  In most cases, the ETL jobs are running close to twice as fast.

But, here’s the funny thing. I didn’t really care. Yes, that was our goal, but I’d have been content if they had run twice as slow. Why? Because at the point we changed the MAXDOP settings, my goal wasn’t to improve performance, it was simply to move the needle, hard.  What I meant by that was, by changing the MAXDOP from 0 (use all 32 CPUs) to 4 I was fairly confident, for a variety of reasons, I’d impact performance.  And I did in fact expect performance to improve.  But, there were really 3 possible outcomes:

  1. It improved. Great, we know we’re on the right track, let’s tweak it some more.
  2. It got worse. Great, this is probably NOT the solution, but let’s try it the other way and instead of 4 CPUs, try say 16 or even a larger value. At least we know that the MAXDOP is having an impact.
  3. Nothing change. In this case, we can pretty much rule out parallelization being a factor at all.

In other words by forcing SQL Server to use only 4 CPUs instead of all 32, I expected a change. If I didn’t see a change, one way or the other, I could mostly rule out parallelization.

Finally, once we saw that a MAXDOP of 4, we started to play with the threshold of parallelization. In this case we ended up with option 3 above. We tried a fairly small value (5) and a fairly large value (100) and haven’t seen much of a difference. So the cost threshold doesn’t seem to have much of an impact.

So, we’re not fully there yet, there’s a number of other factors we need to consider.  But sometimes when you’re approaching the problem, don’t be afraid to move the needle, in any direction, hard, can tell you if you should continue to try that approach. In this case with MAXDOP it indicated we were on the right track, but with the cost threshold, we’re probably not.

We’ve got a lot more to do, including seeing if we can eliminate or speed up the MSQL_XP wait states, but we’re on our way. (For the record, I don’t expect much change on this one, it’s really SQL Server saying, “hey, I called out to an external procedure and am waiting to hear back” so we can’t tweak the query or do other things that would make much of a difference.”

 

 

 

 

 

Janus 2 – 2019

“All my life’s a circle” – Harry Chapin

The New Year is now upon us. It’s now January around the world.  For those who don’t know where the name of the month comes from, or why my previous blog post and today’s are named as they are, it comes from the Roman God Janus.  Janus looked backwards and forwards. I thought it was appropriate for posts bracketing the New Year. In addition, the name of the month January is often believed to come from the name of the god, but that appears to be a false etymology.

Yesterday I looked back. Today, I’ll look forward.  I’m not necessarily a fan of New Year’s Resolutions (other than resolving to live one more year, which I’ve been successful at so far every time) so call these goals:

  • Continue to blog at least once a week. Last year I think I missed a week while on vacation, but otherwise I pretty much succeeded.
  • Hit 2000 page views. Last year I hit 1907.  I think I can exceed that this year. Of course I’ll need your help!
  • Continue speaking at SQL Saturdays. I haven’t set my schedule, but I already have 3-5 in mind. I’m not sure I’ll do 6 again, but we’ll see.
    • Expand my “SQL Server for under $200” session
    • Expand my “SQL Server Backups” (perhaps into a full precon)
    • Add one more topic to my list of sessions (see current ones here)
    • Shoot for at least one overseas engagement
  • Shoot for speaking at SQL Summit!
  • Figure out how to get an MVP!
  • Publish at least 3 more articles for Redgate’s Simple Talk
  • Continue to promote and support Women in Tech as well as other minority groups
  • Continue to learn PowerShell
  • Continue to learn about SQL Server on Linux
  • Play with containers, just a bit. This is really a minor goal given all the others I have, but I figure I should learn a little.
  • Pick up at least 1-2 more decent sized customers
  • Continue teaching cave rescue
  • Cave more!
  • Hike more!
  • Bike more!
  • Travel
  • Have fun!

That last goal is important to me. If I’m not enjoying what I’m doing, why do it? Life is too short to hate what you do with life. If you can find a way to enjoy life, do it!

Most of the goals above are SQL related, but that doesn’t mean that’s the major focus of my life. It’s just the place this blog touches upon the most these days.

I have a number of personal goals, but that’s for me and I won’t be sharing here.

In any event, I wish everyone in my biological family, #SQLFamily, Caving family, and other chosen families a wonderful and amazing New Year and hope that the new year brings you peace and happiness.

Janus 1 – 2018

As the year draws to a close, I thought I’d look back on the year a bit.

The goal of this blog has been to give me a place to reflect on the purpose of this blog.  I claim in My Goal Here to want to reflect on how we think and what drives certain decisions. And I suppose at times that’s true. At times it’s to give actual SQL or IT related advice.  But at times, it’s simply an exercise in my ability to put fingers to the keyboard and words on the screen and to be a bit self-indulgent if I’m honest.

My most popular page this  year was a mixture of things: The Streisand Effect. It was a bit of an activism piece about events at my alma mater and a chance to broaden my blog to more readers. But, it did also serve to actually reach one of my primary goals; to reflect on how we think and make decisions; primarily sometimes by trying to tamp down an issue, we only serve to draw more attention to it and to inflame things further.

My second most viewed piece this year was one of several on sexism, especially in the IT industry: Math is hard, Let’s Go Shopping. I still haven’t finished the book mentioned in the post, but it’s on my list to finish. The issue of sexism in my primary industry is one that has grown in importance to me and I expect to write more about it in the coming year and to try to do more about it.

Reviewing my SQL Saturday’s in 2018, I had the honor of speaking at Colorado Springs, or at least trying to, which I wrote about here; SQL Saturday Philadelphia, SQL Saturday Atlanta, SQL Saturday Manchester UK (my first overseas SQL Saturday, where I had a blast!), SQL Saturday Albany, and finally SQL Saturday DC. I also presented at the DC SQL User Group in September.  All great times and I had learned a lot and had a great time meeting new people and reconnecting with old friends.

I put in to speak at SQL Pass Summit, but again didn’t make it. But I still attended and had a great time.

I also was pleased to be asked to write for Redgate’s Simple Talk where I know have two articles published on using PowerShell for SQL: My first and second. I’ll be submitting my third article in coming weeks.

But not everything I did or wrote about was SQL related or even IT related. In late June, 13 people became trapped in the Tham Luang Nang Non cave in Thailand. This became a world-wide media event that a few weeks later I found myself part of. Besides at least four blog posts of my own that touched upon it, in my role as a regional coordinator of the National Cave Rescue Commission I did close to a half-dozen media engagements, including one for The Takeaway NPR program.

Oh, one more interview I did this past year was with Carlos Chacon and Steve Stedman of SQL Data Partners: it was a podcast I did with them. You can read about my thoughts here and listen to the podcast here. And definitely go to Amazon and buy my book!

Anyway, it’s been a great, and eventful year and I appreciate everyone who has read my blog and even more so to those who have commented on it, shared it, or somehow given me feedback.

I’m looking forward to 2019. I hope you are too.

Change your password!

This year saw a new form of greenmail: emails sent to you containing a password of yours stolen from a compromised site.  I saw the first one of these literally an hour or two before boarding a flight to Manchester UK to speak at the SQL Saturday there. My wife received it.

They often take a form similar to:

As you may have noticed, I sent you an email from your account.
This means that I have full access to your account: On moment of hack your account has password: Tel3phone!

You say: this is the old password!
Or: I will change my password at any time!

Yes! You’re right!
But the fact is that when you change the password, my trojan always saves a new one!

I’ve been watching you for a few months now.
The fact is that you were infected with malware through an adult site that you visited.

If you are not familiar with this, I will explain.
Trojan Virus gives me full access and control over a computer or other device.
This means that I can see everything on your screen, turn on the camera and microphone, but you do not know about it.

I also have access to all your contacts and all your correspondence.

Why your antivirus did not detect malware?
Answer: My malware uses the driver, I update its signatures every 4 hours so that your antivirus is silent.

I made a video showing how you satisfy yourself in the left half of the screen, and in the right half you see the video that you watched.
With one click of the mouse, I can send this video to all your emails and contacts on social networks. I can also post access to all your e-mail correspondence and messengers that you use.

If you want to prevent this, transfer the amount of $745 to my bitcoin address (if you do not know how to do this, write to Google: “Buy Bitcoin”).

My bitcoin address (BTC Wallet) is: 19Q4HZtCznuBGcuWng7cacwqZV13gNpZas

After receiving the payment, I will delete the video and you will never hear me again.
I give you 48 hours to pay.
I have a notice reading this letter, and the timer will work when you see this letter.

Filing a complaint somewhere does not make sense because this email cannot be tracked like my bitcoin address.
I do not make any mistakes.

If I find that you have shared this message with someone else, the video will be immediately distributed.

Best wishes!

I actually LOVE this form of greenmail because I suspect it’s highly effective.  I’m also amused because the above (edited) email came with the subject: Security Alert. You account has been hacked. Password must be need changed. It then goes on to tell you that even if you do change your password, the hacker can read it.  I’m also amused because the faux hacker’s concept of my time at the computer sounds FAR more exciting than what I actually do at the computer (and of course the fact I don’t keep my webcam plugged in!)

When confronted with a password that the user recognizes, I’m sure folks pay up.  But, don’t. Yeah, it’s probably a password of yours, but it’s almost certainly from a site that was hacked months previously and has nothing to do with your email, current account, etc.  You can easily find lists of email addresses and passwords online, especially if you’re willing to pay.

In the case of the above password (changed to be extra safe, but even if I hadn’t it most likely wouldn’t matter in this case) I know what service was hacked. Fortunately I only used that password on that one site and it had no financial data associated with it.

That said, again don’t use obvious passwords. In fact effective password systems would incorporate a list such as the one here: Worst 25 passwords of 2018. If you’re using a password on this list: SHAME on your.

The takeaway: If you haven’t, for 2019 make a New Years Resolution to use UNIQUE passwords for every site you use, use a password manager to remember them, and do NOT make them obvious or easy!