This is my second post in a series which I hope will help you (and me!) prepare for the upcoming PASS Summit November 4-8, 2019 in Seattle, Washington.Continue reading “Preparing for PASS Summit – Networking and Events”
This is Part 2 of a series. Please see Part 1 for the background and more.Continue reading “Q&A: Dealing with Thousands of Databases (Part 2)”
This is part one of a three-part series.
I’ve mentioned in various places, including in blog posts on occasion, that my production SQL Server instance hosts several thousand (nearly 9000 as of this writing) databases. People are usually surprised to hear this and it often leads to interesting conversation.Continue reading “Q&A: Dealing with Thousands of Databases”
This is my fourth installment in a series responding to Steve Jones’s (b | t) #SQLCareer challenge. I jotted down most of what I did through the day, filling a page and then some in a small notebook with timestamps and short reminders of what happened. For more, check out the #SQLCareer hashtag on Twitter.Continue reading “A Day in the Life (4/?) – August 2, 2019”
Way back in August, Matt Cushing (blog|twitter) was preparing to teach and asked for a list of “what do you wish you’d known when you started” items that he could present to his students. I threw a barrage of Twitter direct messages at him and he incorporated much of it into his post, but I thought it was worth posting here as well.Continue reading “Things I Wish I Knew When I Started”
As we open 2019, I thought I’d take a moment to reflect on the past year.Continue reading “2018 Year in Review”
I wanted to get an idea of some good, bad, and surprise experiences that people had at everything from a SQL Server User Group meeting to PASS Summit. Things you found out right before, during or even after that you were glad you did or wish you did.
SQL Saturdays are similar to PASS Summit, but much smaller in scope and budget. Most SQL Saturdays have a twitter hashtag; follow it before the event so you can get an idea of who’s attending and make plans to meet some of those people.
If your SQL Saturday has an after-party, it’s usually not heavily attended as people tend to want to get home to their families (unlike Summit, where you’re already away from home). But I definitely encourage you to go if there is one! You might even find yourself invited to an after-after-party.
I can’t say I’ve had a bad experience at a SQL Saturday, although I have sat in on a session or two that didn’t really grab my interest the way I’d hoped. And unlike PASS Summit, it’s really hard to gracefully exit the smaller rooms at SQL Saturday mid-session if you decide it’s not really for you.
The biggest surprise to me after my first couple events was the inspiration that I had coming out of the event. After each event, I have new ideas for projects, changes to make at work, blog posts, and ways to give back to the community.
- Volunteer! If you don’t sign up before the event, talk to the folks at the registration/check-in desk and ask if they need any help. Every session needs a room monitor – just someone to get a headcount, help the speaker with timing (if they want), find help for A/V issues, pass out and collect session evaluations. You’re going to be in the room anyway. This is a great way to meet both organizers and speakers – folks who are active in the community.
- If there aren’t any sessions in a timeslot that grab your attention, skip it and read the next two items.
- Network with your fellow attendees. These are folks who live and work in your area. They may become your next job lead, or your next new hire.
- Talk to the sponsors! Make sure you thank them for sponsoring. If there are sponsors whose products you currently use, ask them questions about making the most of those products. Just don’t monopolize their time; they need to talk to new people as well to justify their sponsorship dollars. I’ve been known to hang out at the SentryOne booth on more than one occasion. I’m just a very satisfied customer and love talking with them about how I’m using their products.
- If you find a session particularly engaging or relevant to your interests, catch the speaker when the session is over and say “this is really interesting and I can see myself using it this way, can we talk later?” Ask if you can connect on LinkedIn; follow them on Twitter.
- Attend the after-party (if there is one)! It’s a great way to connect with organizers, speakers, and volunteers after the stress of the day has passed. It’s a smaller, quieter environment and easier to have a longer conversation.
After SQL Saturday
Remember those people you met on Saturday? Keep that conversation going. Make contact on LinkedIn or Twitter. Do they have a blog? Follow it! For example, I met Matt at PASS Summit 2017 and we haven’t seen each other since. But we talk regularly on Twitter and we follow each others’ blogs. If you’re meeting more local people (which will happen at SQL Saturday), catch up at the next user group meeting, or arrange lunch sometime.
Malathi has asked us to:
Pick one thing you want to learn that is not SQL Server. Write down ways and means to learn it and add it as another skill to your resume. If you are already learning it or know it – explain how you got there and how it has helped you. Your experience may help many others looking for guidance on this.
The timing for this works out well for me, as I’ll be working on my 2019 goals very soon and education is part of those. But right now, we’re kind of a homogenous shop, which makes stretching beyond SQL Server a bit more effort. I’m occasionally indecisive, so I’m going to throw out a few ideas of things to learn in 2019.
- Need to learn for work: Postgres on AWS. We have a pilot project starting up using this and eventually, my team will need to support it. So, we need to at least understand the basics – backup & restore, basic monitoring/troubleshooting.
- Want to learn on my own: A document database of some description. I’ll probably land on MongoDB due to convenience and cost (or lack thereof). Runner-up: DynamoDB.
- Stretch goal: I still don’t entirely get the concepts behind Docker or Kubernetes (although I’m close on Docker). I’ve tried to run SQL Server 2017 on my Mac via Docker, but Docker itself seems to make the machine unstable. Kubernetes is a complete mystery to me; I know a few people who are doing “stuff” with it, but haven’t talked with them about it yet.
But you may be asking “Andy, where’s Azure? CosmosDB is a document database on that platform. And PostGres is on Azure too, why not learn it there?” My shop is starting to do new work on AWS, so the opportunities are more available there and I can apply what I learn at work more readily. So it’ll cost me nothing out of pocket if I go with that or MongoDB. As for the learning plan:
- I’m going to have to do this one for work regardless, so step one will be setting aside time at the office to work through the AWS tutorials and documentation. Then set up a few test databases, throw some data in, and play around.
- I know we have a few MongoDB experts locally and a user group, so hopefully they can get me started in the right direction. I’ve got a Raspberry Pi 3B as well as a Pi Zero W that I can put to use here.
- Apparently one can run MongoDB on Docker with Kubernetes so maybe I can kill two birds with one stone? It could be an excuse to pick up a couple more Pis. Or maybe fire up some VMs on the rack mount server that’s been sitting in my basement for 5 years.
MongoDB & Docker/Kubernetes are completely new ground for me to cover, so just figuring out where and how to get started may be a challenge. By the time publishes, I may already be starting to read the MongoDB manual en route to PASS Summit – and I know I can talk to people about this stuff at Summit to get ideas on where to start.
This post was written published early by accident. My reading of the MongoDB manual didn’t happen last Tuesday as I was not feeling well on my flight to Seattle.
On the eve of this year’s PASS Summit, I find myself reflecting on my first Summit in 2012. My employer was generous enough to pay for not only Summit itself, but a pre-con session on Tuesday as well.
I was a developer with an interest in SQL Server and PowerShell at the time, not a DBA. Becoming a DBA wasn’t on my radar yet. Regardless, I used the opportunity to attend a full-day class on managing SQL Server with PowerShell, taught by Allen White (blog | twitter). One of the big focal points of the day was the SQL Server Management Objects, aka SMO.
What I learned that day wasn’t immediately usable in my day-to-day job. Parts of it flew way over my head at the time. But the seeds were planted. It’d be several years before I got to the point of really applying it. Initially, my application was limited to some development “DBA-lite” tasks and suggestions for our sysadmins.
After a job change to become a full-time DBA, I started using and then contributing to dbatools, which uses SMO heavily. That previous exposure to SMO proved very beneficial. dbatools provides a lot of functionality, but it doesn’t do “everything.” In my own scripts, I’ve used that knowledge of the SMO object methods and properties to extend that functionality.
As I pore over this year’s schedule, I remind myself and ask you to consider not just what’s applicable to your present work and environment. Catch some sessions just to see what else is out there, or what’s coming. It’ll open doors for you in the future. Being informed about a wider range of topics will help you guide the conversation toward better solutions in the future. You don’t have to become a master of the topic; just know that something exists, what it can be applied to (equally valuable: where it won’t apply), and where to start gathering information if the solution is worth pursuing.