In November, I had the opportunity to attend Microsoft’s MVP Summit. It was a pretty awesome experience. Microsoft doesn’t like us to talk about the MVP summit much, so I’ll be scarce with details.
While I was en route from Boston to Seattle, I had tweeted that I was at the airport. That’s when I got a reply from my friend Mike Walsh (blog | twitter). It turns out that we were on the same flights, and Delta had upgraded us both. As the flight was boarding, we saw an Access MVP board. Mike and I just looked at each other without a word being needed.
Things got even more interesting when we got to Delta’s Minneapolis hub. When we got on the flight, it turns out that there were five SQL Server MVPs on the flight, with four of us in the front cabin.
If you look at the photo, you’ll see Adam Jorgensen (blog | twitter) in the top left seated next to Mike Walsh. I’m in the bottom left seated next to Jes Borland (blog | twitter). It was like a family reunion, only with people you like. We warned the in-flight crew that we all knew each other. The laughter started there and never stopped until we landed in Seattle. I’ll spare Mike from posting the picture of him falling asleep on the plane.
Sitting next to Jes on a four hour flight was an incredible amount of fun. That flight went by so fast!
That set the tone for the MVP Summit and the PASS Summit. The next seven days were a blast!
I recently had a request to build a handful of servers that would run a piece of critical infrastructure in our environment. The requester wanted SQL 2008 R2. I laughed. The earliest version I’m willing to deploy in 2015 is SQL 2012. And if the application supported SQL 2014, then that’s what we’re going to deploy. The sun is setting pretty quickly on SQL 2008 R2, and the risk of running on an old version is just too great.
The requester was my old boss, and I absolutely adore the woman. She’s also very conservative with DBMS platforms and doesn’t always trust the latest versions. Her aversion to risk with newer versions is impressive.
When it comes to running database serves for infrastructure, I will always advocate for running the most recent supported, stable version. I learned that trick very early on in my career.
In 1996, I was working for a company that provided IT services to large companies. I was onsite with a client that operated a nuclear facility. Anything that came out of a hot area had to be buried in several feet of concrete, and burying computers got to be incredibly expensive. They had a rule that everything that went into their hot areas had to be state of the art and would stay there until it was absolutely unsupportable. In fact, when they were putting new desktops in the hot area, they were literally hours off the assembly line at IBM. That’s how seriously they took this.
Today, I work for a financial services company, and the analogy isn’t too much of a stretch. We only upgrade when we have to. After all, it’s not broken, why incur the cost and risk of upgrading? Right now, we’re doing a risk analysis of our Windows 2003 servers that will soon come out of support. We still have servers running SQL 2005. That technology is ten years old! The good news is that I’ve been pretty diligent at getting rid of our SQL 2005 servers, so the number of boxes running Windows 2003 is pretty small.
For environments that we host for clients, we upgrade their DBMS when we upgrade their version of our application. For most clients, that model works well because they upgrade to the latest version of our application every few years. But there are a handful of clients that will hang onto an old version of software until we force them to upgrade or they finally understand that a critical piece of their application landscape is no longer supportable.
So when the request came in for a bunch of SQL 2008 R2 servers, I dug in my heels. When we’re supporting SQL 2022. I don’t want to still be babysitting this little group of SQL 2008 R2 servers. This particular application doesn’t yet SQL 2014, so we’ve deployed SQL 2012. I’m okay with that.
Access database. There. I sad it. And I cringe every time I say it. My friends in the SQL Server community will probably shun me for putting those two words together.
For the first time in my career, I’m not responsible for supporting anything that is related to Microsoft Access. It was one of the selling points in taking this job.
For nearly twenty years, every company I’ve worked for had some system that was business critical that ran on Microsoft Access, and as the database guy, it somehow became my responsibility to support these beasts.
At the steel company it was our change management system. At the utility company, it was our daily processing calendar. At the construction company, it was our project master schedule. And at the telecom equipment company, it was the manufacturing database. These were all monstrosities, and they all had one thing in common–none of them were built by professional application developers. That’s the brilliance behind Access. It lets accountants, business analysts, and engineers hack together build their own applications without using IT developers. These little databases become handy tools, and then a small group of people start using them. Before long, the thing blossoms and the whole company is using it. The next thing you know, Doug in Accounting is spending his day supporting a database that IT knows nothing about. It becomes a business critical application.
One day, an executive has a problem with this little tool that Doug build, so the executive calls the IT director for help. The IT a director has no clue what this thing is. An hour later, the whole IT a department is scrambling to find this thing. They become aware of a business critical application that is sitting on a desktop computer under Doug’s desk. Imagine the horror when people realize the thing has never been backed up.
That scenario is absolutely true. I’ve seen it happen more than once. And the outcome is never pretty. The application usually gets moved to a proper file server that’s backed up regularly, and the tables are upsized to SQL Server. And then the IT department gets the responsibility of maintaining something they knew nothing about a few hours earlier. The IT staff now has to figure out how to make this thing scale. And now that IT owns this beast, they’re responsibility or every little bug, glitch, problem, and performance issue. There is often talk of replacing it with some professionally developed or even off the shelf product. However, because IT never knew about it, there is rarely a budget to replace it.
Oh, and Doug? He’s not even close to happy. IT has taken away his pride and joy. He won’t be afraid to tell anybody that will listen that the system ran much better when he managed it. On a machine under his desk. That had never been backed up.
Unfortunately, the only way to prevent these situations is strong leadership with executive support. IT needs a policy that states prohibits people from building their own applications. We did that at a previous company, and we would scan the network for Access databases regularly. That allowed us to prevent future systems from cropping up like this.
On March 11, I will be speaking at the New England SQL Server User Group. My topic is Do More With Less: SQL Central Management Server and SQL Agent Multi-Server Administration.
The whole point of my talk is that we can eliminate a lot of administrative overhead by applying some of the native tools that Microsoft provides within SQL Server. I love how the Central Management Server allows you to execute a query or script against multiple targets at once. And Multi-Server Administration allows you to manage your SQL Agent jobs from a single place. When used properly, this is a one-two punch. We use these tools quite extensively in my environment.
I’m really excited and terrified at the same time. This is an exciting topic, and I’m thrilled to be in front of my own user group again. That said, speaking to this group scares the crap out of me every time. Under the leadership of Adam Machanic, this group has grown into one that is incredibly technical. These guys ask questions that are insanely detailed. They’re good people. They’re just smarter than I am.
When we organized SQL Saturday Boston 2014 Business Intelligence Edition, we found that we had purchased WAY too much food. On that day, we donated 100 lunches to Boston’s Pine Street Inn. You know what? It felt great! We did something pretty awesome for the community.
That day, I made a decision. I knew that for SQL Saturday Boston 2015, I wanted to raise the bar. And I raised it high! We’re giving to Rosie’s Place, Boston’s Sanctuary for Poor and Homeless Women. They have an incredible mission, feeding poor women and helping them get back on their feet. So for this event, I raised the sponsorship fees by $100. And I committed that this extra $100 per sponsor would go toward buying something we could raffle. It’s written right into our sponsorship plan.
Rosie’s Place is pretty amazing. Not only do they serve meals, but they provide coats and clothing, as well as education. My former employer was one of their regular sponsors, and each department would take a day to help serve lunch for these amazing women. I think it’s a great way to help us give back to the community.
With ten sponsors already, I’m committing to raffle a $1000 Amazon gift card. Yes, one thousand dollars. If we get more sponsors, we’ll add more prizes. Would you like to help us raise money for Rosie’s Place while having the chance of winning a great prize? If so, head on over to our raffle page.
To keep your data secure, we’re using rafflecreator.com, which partners with stripe.com to collect payments. I’ll never see your credit card information. If you’re really concerned about paying for raffle tickets online, we’ll be selling them on the day of the event for cash.
And putting my money where my mouth is, I bought the first $100 worth of tickets. Since our sponsors paid for the prize, every penny we raise in the raffle will go directly to Rosie’s Place.
So please, spend a few dollars to help us do some great good for our community. Go buy raffle tickets!
SQL Saturday is a great opportunity for learning more about the technology. But it’s also an incredible opportunity for networking. As I tell people in our opening statements, “If you walk into a room and sit next to someone you know, you’re doing it wrong.”
At our user group, I always start the evening with some type of speed networking event. This is often as simple getting people to stand up and greet the person on each side of them. Other times we’ll break into small groups and do some type of a quick challenge. In college, we referred to this as mandatory fun. I’m fond of saying “you’re next job may come from the person sitting right beside you.”
For SQL Saturday Boston this year, I’ve decided to take the networking up a level. We’re going to do a professional scavenger hunt. Instead of collecting things, we’re having our participants meet people.
The rules are simple. Go meet people. Get the names and email addresses of people who fit the criteria below. You may not list the same person twice. The first ten people who complete the hunt and return this page to the registration desk on the second floor will be entered in a drawing for an HP Stream 7. You must be present at the end-of-day raffles to win.
We then give our participants a list of different people to find. We have them look for MVPs, non-local speakers, people who work in diffferent environments, different technologies, and all kinds of goodies. I’ll post the list after SQL Saturday in April. We don’t want anybody cheating.