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.

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!

 

 

 

Merry Christmas

It’s Tuesday, which means normally I’d try to write something insightful about caving, or computers, or technology, or our human experience.

Instead, I can only say, “Merry Christmas” to all my fans and readers.

I was hoping to get to 2000 page views this year, looks like I’ll be about 50-100 short, but that’s ok. I’ve enjoyed writing my weekly missives and I hope you’ve enjoyed reading them.

Now get off the computer and spend time with your family!

Social Deconstruction II

In a previous post, Social Deconstruction I reflected on a barrier that had been put up on a Thursday, and by Sunday, completely bypassed. I had recent cause to revisit that area again recently and

Barrier bypassed

Barrier bypassed

as you can see, an actual, real gate has been put into the fence. The power of the crowd basically overruled the original intent of the landowner.

Of course, this could have been done from day one.

This is true in the IT world. How often has the security department come and said, “we’re implementing this new security policy” with little input from actual users and are surprised when users get frustrated and try to bypass the new security feature.  I had this happen at a client of mine. In the case of the fence above, people bypassed the security the fence builders wanted (presumably to reduce liability), and by doing so, increased their chance of getting hurt (and ironically, presumably increasing liability).

One of the security features that I think annoys most of us are passwords, or more accurately arcane password requirements. For example, some systems require a certain amount of complexity, but don’t necessarily tell you what the rules for complexity actually are! Yes, I’ve had that happen. Turns out they required special characters, but, only a specific subset of special characters and the ones I tried weren’t on that subset.

Now a minimum password length, makes sense. A one character password can be cracked by anyone. But, what about short maximum password lengths? Yes, perhaps that was a good idea when memory and storage were scarce (ok even then, not a great idea) but not so much these days. Yet, I know at least one system where your password has to be between 8 and 14 characters.

Another annoyance is the “must change every N days” where often N is something like 90 (though I’ve seen even lower). What does this mean? Folks end up with passwords like: Secur3Passwrd$1, Secur3Passwrd$2, Secur3Passwrd$3, etc.

Truth is, many of the so called password rules, actually encourage us to create lousy password, and so we repeat stuff, or write it down or take other steps that make it easier for to use them, but also as a byproduct weaken passwords.

The National Institute of Standards and Technology recently released an updated set of guidelines: NIST 800-63B that discuss good password requirements (note I have NOT read the entire document, just large portions of it).  Spycloud has a decent review here: New NIST Guidelines Acknowledge We’re Only Human. I’m not going to recap the recap here, but I will add what I generally do:

  1. I use a password manager. You can read reviews for finding one that best meets your needs. Personally, I use one that does NOT have storage on the cloud. While in theory they’re encrypted and secure, I get paranoid. (Yes, I do recognize if someone compromises my desktop, they can get access to my local password manager. But on the other hand, if they get access to my desktop, they can probably just install a keyboard logger and I’m hosed anyway.)
  2. I use a different password, automatically created by the above password manager for nearly every site of system I log into.  This ends up meeting most (but not all) of the NIST suggestions (they’re certainly NOT easy to remember, but they don’t have dictionary words, can be as long as I need, most likely are NOT in a previous breech, etc.)

Note, I said most, not all. There’s a few places I used passwords I can remember. These are systems I interact with on a daily or near daily basis, such as my desktop, AND the password manager itself. There would be no point to have a password manager if I couldn’t log into it, or if the password were so simple anyone could guess it.

So, I make sure these passwords are easy to remember, but extremely hard to guess. (For example, they do NOT include the name of my first dog, my mother’s maiden name, etc.)

In conclusion, if you’re in charge of security, make it usable, or else people WILL try to bypass it, simply to get the job done. And, remember, you’re always in charge of your own security, so make it usable, but secure.