Marshmallows

Though I attended RPI, which is generally considered an engineering school, my degree is a BS in Computer Science. I say that because I consider myself more of a scientist than an engineer at times. And honestly, we all start out as scientists, but many of us lose that along the way.

Anyone who has had a small child has observed a scientist in action. No, they’re not in a lab full of test tubes and beakers and flasks giving off noxious smells. But they are in the biggest lab there is, the world. They also don’t necessarily realize it. Nor do parents. But every time they drop a Cheerio, they’re testing gravity.  Fortunately (or unfortunately depending on your point of view) so far every time they’ve managed to prove that gravity works. This is the most obvious example, but when you stop to think about it, much of the first few years of life is all about experimenting. Most of the time it goes well, but sometimes, as a burnt hand will attest, the experiment has a less than ideal outcome.

And it’s the fear of burned hands that leads to parents to utter that common  refrain, “Don’t touch that!” or the variation “Don’t do that!”.  Soon, over time, our experimentation starts to get reined in until we do very little of it. This can be inhibiting.

Years ago I used to teach an “Introduction to Windows” adult education class. It was I believe a 6 week class and I taught several over the course of a couple of years. It didn’t take me long to realize the biggest constraint on the students ability to succeed in the class was that they had internalized “Don’t do that, you might break something.” Once I realized that, half my teaching pedagogy simply became, “Touch that, you won’t break it, and if you do, it’s not a big deal, and if it is, we’ll fix it anyway.” Seriously, more than anything else, I had to encourage most of my students to experiment with the computer.

More recently I realized I had stopped doing as many experiments in my life as I should be doing. About 1.5 weeks ago I attended a Wilderness Medicine Conference a friend of mine had told me about. At the end of the very wet, cold, rainy day, a bunch of us went outside and tried to start a fire. Starting a fire, let alone in such conditions was something most of the students had never done. I had, but not in years. With some effort, and experimentation, including using the outside box of a single serving size package of Fruit Loops, we finally managed to get the fire going.

But this got me thinking. When I go hiking, I carry a tiny ziplock back in my jacket with some firestarting materials. They’re there in case of an emergency. But, the thing is, I had never actually tried them and realized if I didn’t know how well they worked in practice, I couldn’t rely on them in emergency. So, I went outside, and started a fire. And I learned that yes, my materials ARE adequate, but the dryer lint needed to be pulled apart more than I realized. I tried again later in the week, and added the use of a toilet paper roll to form sort of a chimney so the starting fire would draft better. This, and the better pulling of the lint worked even better and a single match was sufficient this time.  This gave me more confidence that in an emergency, in less than ideal conditions I could get an actual fire going.

But, I wasn’t done! Our microwave broke this weekend. But, before I wrote it off, I wanted to make sure it wasn’t a fluke or something else. So, in this case I decided to get a bag of marshmallows and lay them out inside the microwave to see if I was getting ANY energy out of the magnatron. Turns out, nope, nada, nothing. So, today or tomorrow I will be buying a new microwave. But, it was a fun, and later tasty experiment.

Without delving deep into the scientific method here, I’ll say at a simple level, science is about having a hypothesis and testing it. The testing it is important.

To bring this back to SQL. First, you have a hypothesis that your backups will work. Have you tested that hypothesis? If not, do so immediately. Even if they do, you might learn something now that will be important when you have to do it for real. Perhaps you learn the volume your backups are on only has write access. Or perhaps you learn you need to retrieve your encryption keys and the person who controls access to them is on vacation. Or perhaps your RPO is 4 hours and the restore takes 6 hours.  So, experiment.

query plan

Capture of a random query plan

Recently for one client I’ve spent some time experimenting with various changes to help improve the performance of some queries. Not everything I tried worked, but some things did. So, again experiment.

I’m curious what recent experiments you may have done, SQL or otherwise. What were their outcomes?

 

Redemption

About a year ago I wrote this post: And so it Happened… about my first (and so far only) time I ended up with an empty room at a SQL Saturday. I’ve run into a few other speakers who have had the same experience, so that soothed the bruised ego a bit, but it still left a bit of a mark.

As a result, I set a goal of redeeming myself this year again at the Colorado Springs SQL Saturday. I figured it wouldn’t be that hard to exceed my turnout from last year.  So, I submitted several topics for them to select from and waited. Finally the day came, and I found that I had been selected to speak. There was only one problem. The topic in question was one that while I had submitted, and had a good outline for, I had not actually fully developed into a presentation and was a bit nervous about:
The very Model of a Modern Day Database. I thought it would be a good topic, I just had to develop it.  And of course like any good procrastinator I kept putting off the work. I mean I was making progress, but, well it was slow.

Fortunately, by Friday the 5th, I had run through a complete form of it and had worked out pretty much all the tweaks I wanted and had practiced it a few times to an empty room, you know, just in case of a repeat of last year. Seriously though, I do several run-throughs to make sure I get the timing right and I pretty much know what I was going to say. I’ll let readers in on a little secret, some of the parts of my presentations that look like they’re improvised or impromptu comments or replies, are often rehearsed.

So I felt pretty good going into Saturday.  Then, looking at the schedule, it struck me that my topic was on the System Databases, one of which is known as the TempDB (to my non-SQL readers, that’s a fairly critical database SQL Server uses as sort of a scratch pad) and that a session before lunch (mine was scheduled after lunch) was by Kalen Delany and was an entire hour on just the TempDB. I first heard Kalen speak at SQL Connections conference back in 2005 or so in Orlando and had read a few of her books. To say that she’s well known in the SQL Community and highly respected might be an understatement. Now the impostor syndrome was really starting to kick in! What could little ol’ me say about the TempDB in 15 minutes that would interest people after listening to her?

But then I realized, our topics had a slightly different focus, and while some of our advice was similar (put your TempDB on FAST drives), I covered things in a different way and there would still be something of interest to my attendees. And, it is not a competition after all. Honestly, my goal whenever I teach any topic is to reach at least one student or attendee. If I can get one person to walk away and say, “I learned something” or “That was worth it” I feel like I’ve won. This happened during a week-long cave rescue training course once. On the first day in the field I showed a student a fairly simple but not entirely obvious way to rig a rope. After explaining it to her she looked at me and said, “that’s worth the price of the course right there!”.  I glowed and joked I could now take the rest of the week off; I had achieved my goal.

Anyway, after lunch I was prepared. Lunch was scheduled for 12:30-1:45 and I was in the classroom by 1:40, all setup waiting for folks to show up. And sure enough two people showed up. I was happy. Perhaps not ecstatic, but at least happy I had an audience.  And then two more people showed up, put down their stuff and asked, “mind if we leave this here, we’ll be back.”  I said it was fine, but was a bit confused since the clock was saying 1:44 and I was wondering where they’d be going just before my session started.

But hey, four people, that was four more than last year, even if two weren’t in the room and one of the others admitted they weren’t really a DBA and wasn’t sure if the class was applicable to what they wanted to learn.

At that point, one of the original pair started to shuffle her papers and looked up and said, “you know, it’s weird, the schedule has a 15 minute break between lunch and the first afternoon session. This is supposed to start at 2:00 PM”  I looked and she was right.  As far as I can tell, when the organizers laid out the sessions, they put a 15 minute break between them, and simply did the same for after lunch. This explained why the second pair of people had left with the intent to come back. They wanted good seats for the 2:00 PM start.

Sure enough, by 2:00 PM the room was fairly full and I was off and running. I was in a smaller room than Kalen’s presentation, where she had 40 or more, I had perhaps a dozen. But I was happy and content. And, once it was over, both the room monitor and myself reminded folks to give feedback and this audience was great at that.

A word on feedback. The forms at SQL Saturdays tend to be fairly standard and I think I speak for most presenters when I say, that while it can be gratifying to get all 5s on the top of the form, it’s also kind of useless. But, when folks actually take time at the bottom of the form to give actual written feedback, that’s quite gratifying. This audience gave great written feedback.

I also appreciate feedback in person. At least one person came up afterwards to say, “That was really great, I bet you could do an hour on each System Database.”  So perhaps, I will do an hour presentation on the TempDB someday!

So, I feel redeemed. Due to a variety of reasons it’s unlikely I’ll bid to speak at Colorado Springs next  year, but I’d highly recommend it for anyone in the area. And, if you’re afraid that some other presenter might overshadow you because they’re better known or their topic is similar to yours, don’t despair. Seriously, there’s enough knowledge to go around and enough interest.

 

Too Many Tabs Open

It’s been one of those “busy-slow” weeks. I get these sometimes when I’m consulting. On one hand I’m busy, but work is slow. What do I mean? Well Monday I was on a train all day (literally other than a 1.5 hours layover in NYC) coming back from Atlanta. That’s another story but suffice to say, I wasn’t much in the mood to get work done. Tuesday, when I generally write this blog, I had a couple of customer meetings and was busy, and then the rest of the day busy with non-client work. Same with Wednesday and Thursday.

Finally today, I had a few minutes to catch up on some stuff. I FINALLY took the time to look at one of the tabs I had open in my browser. Admit it, you do it too. “Oh look, that’s cool I want to read/watch/listen to that, but not now, I’ll just keep that tab open.” And then weeks later you’re like, “what is this tab?”

In this case it was a video post by Grant Fritchey on “Why friends don’t let friends upgrade to SQL 2014.”  I was curious about this because at a client I had to recently upgrade two servers to SQL Server 2014. I had preferred SQL Server 2016 or 2017, but the 3rd party software vendor said “no”.  Fortunately nothing bad has happened, but, it’s posts like Grant’s that I appreciate because it helps broaden my knowledge base.

One thing that makes humans incredible is our ability of language and ultimately our ability to create forms of communication that transcend time.  None of us can learn EVERYTHING. But what we can learn is who knows more than we do, or how to access that information. If I want information on query tuning, I’m going to ask Grant or pick up one of his books. If I have a question on Power BI, I might reach out to Kellyn Pot’Vin-Gorman or Cathrine Wilhelmsen. In other words, I don’t need to be an expert on everything, though I’d like to be! I just need to know who to reach out to.

Similarly with my cave rescue world. I’m proud to say I work with some of the greatest people in the world, people who literally have written the book on cave rescue. And yet, at our recent meeting (the reason I was down South), two of my colleagues, Roger Mortimer and Eddy Cartaya reported back on their trip to Europe where they attended the ICARS conference and brought back some great information on how the Europeans are doing some things differently when it comes to cave rescue. This has prompted some discussion between Roger and myself on some medical topics.  Again, none of us are the complete expert on the field, but we know enough to know what we know and don’t know and how to learn more.

So, keep those tabs open and keep adding to them. I know I’ve got at least one video on air plane accidents I need to listen to when I get 30+ minutes. What tabs do you have open?

 

SSMS 2017 RegEx

A short technical post on one thing I’ve found annoying.

Anyone who has worked with computers in the last decade has probably used regular expressions in some form or another, or “regexs” as they’re known as. First (as far as I know) popularized in Perl (though their history stretches back to the 1950s), they’ve become standard fair in most languages and tools and are very useful for complex matching and find and replaces.  And for anyone who has worked with computers for over two decades they often look like line noise when someone would pick up the phone in the house when you were dialed in via an actual modem.

That said, I first learned about their value in SQL Server Management Studio due to a great talk by Sean McCown. (note the post’s byline is Jen’s, but trust me, I saw Sean give the talk. 😉

One of the powerful features is the ability to “tag” part of an expression so you can use it in your replace statement (see the above link for more details.)

But, here’s the thing, somewhere along the line (I think it was post SSMS 2014) Microsoft changed the rules of the game and it can be hard to find the new rules!  They have a post on using regexp in SSMS 2017. But as far as I can tell, it’s the old 2014 info, simply rebranded. Some of it, especially the tagging part does not appear to work for me. If anyone CAN make it work in 2017, please let me know how.

Let me give you an example. Just today I was given a script that had a lot of statements similar to:

DROP TABLE If Exists ##TempAttribute

Let me say I LOVE the new “If Exists” option for DROP Table, but, I needed to run this on SQL Server 2008R2 (I know, don’t ask!) and that syntax won’t work.

I needed to replace it with something like:

IF OBJECT_ID('##TempAttribute', 'U') IS NOT NULL
  DROP TABLE ##TempAttribute; 

Now, I’m naturally lazy and didn’t want to have to find and replace all 100 or so instances of this by hand. So, I reached for regexes… and… well it didn’t go well.

Based on the old syntax my find should look something like for the find:

DROP Table if exists {\#\#[A-z_0-9]+}

And for the replace

if object_ID('\1', 'U') is not null drop table \1;

Except, for the life of me, that wasn’t working. Every time I tried to tag the table name using the braces {} my regex would fall apart.  So of course I searched and got the link from Microsoft above that still suggests tagging with braces.  From previous experience I knew it was wrong, but that IS the official Microsoft page after all, so I kept doubting myself.

But, I was right in remembering things had changed.

The proper syntax is:

Drop table if exists (\#\#[A-z_0-9]+)

and

if object_ID('$1', 'U') is not null drop table $1;

The change to the search expression is subtle, changes braces to curved parenthesis .

The change to the replace is about the same, changing a \ to a $ but I suspect (I have not confirmed) that you’re no longer limited to just 9 tagged expressions.

And before anyone chimes in, I do realize there are some other ways of writing the search expression (such as I could have used :w+ instead in SSMS 2014 that would have worked in my particular case, since there were no temp tables with numbers, but this would not have worked in SSMS 2017), but this worked for me and wasn’t the point of this post. My goal was to focus on the change in tagging expressions.

Regular Expressions are still one of those things that don’t come very easily to me so I often struggle with the syntax and it doesn’t help when Microsoft changes the syntax rules between versions of SSMS (my understand they did so to make SSMS functionality better match Visual Studio, so I’m ok with this), but overall, I find them EXTREMELY useful and if you haven’t played with them, I highly recommend you start learning. There can be a bit of a learning curve for anything too complex, but it’s worth it.

My advice, start with learning how to “grab” the beginning and the “end” of a line and then go from there. This is the most useful thing to me at times when I want to add or remove something at the start or end of every line.

Happy expressing!

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.

 

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.

“So, why are you sitting here?”

I had been anticipating the question and it was a fair question, after all, I was one of two men sitting at the Women in Technology Birds of a Feather table at PASS Summit.  But let me back up a bit.

Last week was the PASS Summit in Seattle, an annual event that I mentioned two weeks ago that I was headed to. There are several thousand people that attend and in order to promote networking, in the massive lunch hall, they have a number of tables set aside for particular topics, i.e. “birds of a feather”. So if there’s a particular topic or interest group you are associated with you, you can sit at such a table and know you’re among like minded friends. For example on Day One I had set at the “Virtual and Local User Group” table.  But today, I found myself at the Women in Technology table.

So why?

Let’s back up even further. I grew up in a small town in the northwest corner of Connecticut. I can’t say my parents were poor, but we probably lived below what many would consider a middle-class lifestyle. However, I was very fortunate to have hard-working parents and grandparents who helped, and more than a bit of privilege.  What do I mean by this? One example comes to mind. A couple of years after college when I was first consulting, I needed a small business loan to cover a project for a client. I literally walked into the local bank and on my word got the loan I needed. Even then I realized I had a bit of privilege going on there.

As I’ve grown older, I’ve listened to more and more testimonies from women and persons of color and continued to realize how for granted I’ve taken many aspects of my life. As a result, I’ve worked to listen to others and try to increase their access to opportunities and gain the same privilege I was simply born with by being a white male.

So why was I there?

The question was not a surprise, since the table host, Kathi Kellenberger had said she wanted to go around the table and ask folks why they were there. fortunately she hadn’t started with me first! This gave me time to think about my answer.

To listen. To listen to two women of color talk about their struggles and efforts to make it into the world of being SQL DBAs. To listen to other women talk about their experiences and to learn from them.

So I gave that and a bit more as my answer and then shut up and listened. It was a great lunch and a great experience.  As my friend, and WIT Virtual Group co-leader (along Kathi) Rie Irish is wont to say, “if women could solve these problems we’d have done so by now. We need your help”.

So to my fellow men out there, I would say, be an ally. Attend the WIT Luncheon (which was the day before) at Pass Summit.  Encourage women to speak at your User Group and at SQL Saturdays, stop others from interrupting them during meetings, amplify their ideas. And sometimes, just shut up and listen. And if you’re involved with SQL Server and PASS and want more information reach out to Rie and Kathi and contact the Virtual Group the manage, Women in Technology.  Trust me, men are welcome as allies.