Voice of the DBA

Tag: syndicated

  • Dreaming of SQL Saturday

    I’m truly stunned at the responses I received to my post asking how far people have traveled for a SQL Saturday. I posted here, and at SQLServerCentral. In addition, I got plenty of emails from people, detailing their travels.

    Early warning, this gets a little long.

    I am truly stunned. In fact, when I read some of the notes and comments, I got tears in my eyes.

    Tears of joy. I’m touched by the way people feel about SQL Saturday. A few random things that stood out:

    “This was my first time attending and I would gladly attend again.  The distance is about 3000 km.  I elected to attend the SQL Saturday in Orlando and to include it as part of my vacation plans. ” 

    I asked, and this person moved their vacation plans to get to the event. That’s amazing. Someone changed vacation plans (slightly) to attend a SQL Saturday.

    (paraphrased) “As an attendee and volunteer I’’ve been to 14 SQL Saturdays, from 7miles to 266miles from my home” – This person moved, and has been to multiple events, each in the state of residence.

    Another person had gone to 2 events, both over 100mi. away. their quote: “Why? bc I love hearing the discussions and learning. Also since they are on weekends I make mini vacations out of them and do other fun activities. That may be something you may find others do as well. I have asked my company for Friday off since I am spending all my own time and money which makes it a 3 day weekend.”

    This one is sad to me: “We (3 of us) traveled 160 km twice. Two of our colleagues, from our remote site, traveled 300 km once. It is just too much, so we stopped attending.” I understand, especially in less populous areas that it can be hard to get to events like this. I have a dream, see (way) below

    This is great: “Pursuant to your article on  SQL Saturday, the controlling issue is “information and not “distance” – if the information is extremely valuable,  I would travel one thousand miles!” 

    While it’s quite exciting, I’d hope that no one would have to travel 1000 miles.

    This next response stuns me. I’ll describe it because it’s a mix of things. A person has lived in the middle of the country. There is a SQL Saturday in their city. In fact, they’ve been to that event 4 times. In total, this person has been to 19 SQL Saturdays with distances of: [21, 21, 450, 516, 251, 21, 511, 516, 319, 21, 450, 319, 378, 203, 6, 595 516, 319, 378]. Of those, they were an attendee at 16 of those events.

    Now, you might say, “see, people will go over 400 miles for an event.” Absolutely, and I don’t argue that. However, what I’d do is flip this around.

    How many events would this person attend if there were more within 100mi of their house? How many more people would get training if there were more SQL Saturday events, more often, in more locations? 

    Dreaming of 500

    I’d like to see 500 events a year in the US. I’d like to see three or four events in many cities a year. I’d like to see a thousand more speakers, just average DBAs and developers that are willing to share some knowledge. I want more, many more, many more slim, easy events. Have big ones if you like, but let’s get more training out there.

    I want more chances to speak, and learn, with the challenge of picking and choosing. I want to think of what we can do, not what holds us back.

    There’s a great scene in Apollo 13, which I bet a few of you remember. The engineers need to get the power usage to 12A from 60A. They have to find a  way to get the spacecraft back to Earth from the projected point in between the Earth and Moon where the astronauts might die.

    They are challenged to do so, with a famous quote that you may remember.

    I challenge you. I want you to think about how we make that leap to 500 events a year. I want every organizer to think about how they can create more events, not just their one big event a year. I want the events to fit a budget, not the other way around. Find a way to 500 events a year.

    I want every speaker to think about how you can inspire, prod, cajole, convince, and support another person or two in your area to speak. I challenge you to staff 500 events a year.

    I want everyone at PASS, from the Board of Directors to the staff at HQ to the volunteers that help PASS to think about growing SQL Saturdays, and finding ways to provide support. Maybe more support for some events and people than others, but take the challenge. Don’t tell why you can’t, dream of why you can. I promise you, more events will create more SQL Saturdays, and more changes to make larger, paid for events work for PASS.

    I want every attendee to share SQL Saturdays with your friends, and help grow to more events in your area, or a new area closer to you. Fifty people can make an event, if you just give back a little.

    Failure is not an option.

    It shouldn’t be. Let’s dream big. After all, who would have thought we’d get this far? Andy and I certainly used to wonder if we could actually have 12  year.

    500 events in the US in a year is crazy. It’s silly. Maybe it’s not possible, but I’d like to think we can get to 500 if you challenge yourself and just dream a little.

  • Did My Dev Changes Get to Production?

    One of the things that people don’t think about often is whether the changes made in development actually get to production. Usually this is because most changes go, and unless it’s a big change that causes a problem for a large number of customers (or a large customer), we often just deal with mistakes as we can.

    That’s not ideal, and certainly not what I’d like to see as a developer. I’d like to get changes to customers quickly enough that I get feedback. In this post I want to look at how DLM Dashboard can help here.

    Tracking Changes

    There’s a disconnect in traditional software development. Developers write code to meet some spec, and often drop that into some storage spot, hopefully a Version Control System (VCS) and eventually that code gets deployed to production. Whether a web site, client local app, mobile, database, etc., that code tends to move in batches.

    Developers typically haven’t been concerned about the overall packaging of all the code, mostly because code gets pulled from multiple people, so it’s hard to track this. We depend on project manager or some deployment person to ensure all changes get deployed.

    For the database, because people often manually build, or at least edit, scripts, I find there are more changes for a particular line of code to get left out. That can be bad, and maybe really bad if you deploy the database in advance, such as a day or week before other code.

    How do we track changes?

    How can we track changes? In a VCS things are easy to see. However, we really need to see a bundle of changes. Having a version of the database, not just the latest version, becomes important. Let’s look at an example.

    I’ve made some changes in development, and my CI process pushed them to my integration environment. This shows my current database pipeline like the image below:

    2016-07-30 17_03_38-SalesDemo-2015-12-01-1745-export-i-fgod4b6h - VMware Workstation

    In this case, I’ll get a close-up of the details, but I’ve moved my Integration environment from a database v of 4.2.70 to 4.2.71. This is from a new stored procedure, as you can see below.

    2016-07-30 17_04_05-SalesDemo-2015-12-01-1745-export-i-fgod4b6h - VMware Workstation

    I can see the details of the procedure, as I’ve shown here.

    2016-07-30 17_05_30-SalesDemo-2015-12-01-1745-export-i-fgod4b6h - VMware Workstation

    I typically might not look at each CI build, though perhaps as a DBA I’d go through a series of changes across some period of time. That’s a post for another day. In this case, I usually would approve all the changes occurring in Integration environments. Eventually I’ll end up with quite a few changes. I’ll make a few more, with a few more commits and up the version a few numbers after marking this version as reviewed.

    I’ve made four separate commits, and now see this in my dashboard.

    2016-07-30 17_13_23-SalesDemo-2015-12-01-1745-export-i-fgod4b6h - VMware Workstation

    As you can see, the CI process has updated the integration database to 4.2.74 from 4.2.70. However, as I dig in, I can see details. The “Review” button only gets me the changes from the most recent commit.

    2016-07-30 17_14_22-SalesDemo-2015-12-01-1745-export-i-fgod4b6h - VMware Workstation

    However, I can click “See Schema History” at the top and then click the particular version to see all the changes. Here are the first two.

    2016-07-30 17_16_13-SalesDemo-2015-12-01-1745-export-i-fgod4b6h - VMware Workstation

    I don’t care about these changes by themselves. However, I do want to be sure that the appropriate changes have made it through to other environments, especially production. Let’s deploy some changes to the Test environment. Easy for me in Octopus Deploy. Let’s deploy 4.3.74.

    2016-07-30 17_17_31-SalesDemo-2015-12-01-1745-export-i-fgod4b6h - VMware Workstation

    Once Octopus Deploy does it’s thing, I should see the same changes in the Testing environment. However, when I look at the SimpleTalk_Test database, how can I tell the changes are correct? It’s not easy.

    2016-07-30 17_32_20-SalesDemo-2015-12-01-1745-export-i-fgod4b6h - VMware Workstation

    There are a lot of objects in here, and comparing them piece by piece is a pain. Certainly I could use something like SQL Compare, but do you really want to have to double check your deployments by running another tool? Will you remember to do this?  What if development has moved on, as shown below?

    2016-07-30 17_34_52-SalesDemo-2015-12-01-1745-export-i-fgod4b6h - VMware Workstation

    To run a comparison, I’d now need to track back versions in my VCS.

    However, if you look at the image above, you’ll see that I know what the state of every object in my test environment is. It’s at version 4.2.74. That’s the versions I had in Integration above, and the version I deployed to Test.

    Verification

    If a developer isn’t sure why something doesn’t work in production, or test, or anywhere else, they can look at the changes that were actually deployed, and reference back to the state they worked with in development. In fact, they could even create a new database, and trace back the exact version of all changes in the VCS or CI server, and actually try to reproduce the issues.

    Above all, a developer can tell quickly that if version 73 of the database is deployed, but the code expects version 74, there’s one thing that might need to be checked first: the changes made to the database in v74.

    Hopefully you’ll see there is value in using DLM Dashboard as a developer to ensure the work you complete gets deployed correctly to later environments. If you don’t have an automated pipeline like I do, and DBAs or developers create manual scripts, it’s even more likely DLM Dashboard can help ensure all the correct code is deployed.

    DLM Dashboard is free, and each instance works for up to 50 databases, so download it to day and give it a try.

    Download DLM Dashboard

  • Quick Scalar Tables–#SQLNewBlogger

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    This actually comes from Itzik Ben-Gan, by way of Kevin Feasel.  Kevin’s post is about CROSS APPLY, which is something I need to play with more because I hadn’t thought about this.

    However, the one thing I did see as interesting is the use of VALUES to get a quick table. Here’s an example. Suppose I want to get a list of the last four years in a table for some reason, I can do this:

    WITH    cteYears ( Yr )

          AS ( SELECT   2015

               UNION
               SELECT   2014
               UNION
               SELECT   2013
               UNION
               SELECT   2012
             )
    SELECT  Yr
    FROM    cteYears;

    Or I could be more compact and do this:

    WITH    cteYears ( Yr )
          AS ( SELECT  Yr = y
               FROM ( VALUES (2016), (2015), (2014), (2013) ) a(y)
             )
    SELECT  Yr
    FROM    cteYears;

    Is one arguably easier? Certainly some might like the UNION, but it’s a lot more typing, and I think it can be easier to make some mistake in editing. The VALUES clause can easily simulate a table, and you can quickly see groups of rows as well.

    WITH    cteYears ( Yr, champ )
          AS ( SELECT   y
                      , c
               FROM     ( VALUES ( 2016, 'Broncos')
                           , ( 2015, 'Patriots')
                           , ( 2014, 'Seahawks')
                           , ( 2013, 'Ravens') ) a ( y, c )
             )
    SELECT  Yr, Champ
    FROM    cteYears;

    SQLNewBlogger

    This is a quick item I noted, and one I’ve started to use more and more to build quick tables. It seems much easier for me to visualize and create the virtual table. I have started to use this to mock data, or run quick tests.

  • Slimmer SQL Saturdays

    I’ve had this idea for some time. It’s been bugging me, but I haven’t really been pressured to write, nor inspired. That changed a bit with the announcement of the rules change for SQL Saturdays, as well as a few discussions I had with people.

    I dislike the announcement for a few reasons, which you can read if you like.

    Of What does a SQL Saturday Consist?

    Like my grammar? I was desperate to avoid the preposition at the end. However, I’m wandering away from what I want to write about.

    What does a SQL Saturday consist of each week? I think this is a high level view of the tasks that have taken place at many of the events I’ve attended in the last few years.

    • Get a venue
    • Sell sponsors some advertising/exhibition package
    • Perhaps put together pre-con events (get more space and manage logistics)
    • Get speakers to come speak
    • Market the event
    • Put together a speaker dinner
    • Have some sort of speaker gift
    • Order shirts for speakers and/or volunteers
    • Contract for some sort of lunch
    • Get volunteers to help with logistics
    • Buy some prizes
    • Teach people in sessions
    • Have a closing and give stuff away.
    • Get people to come to an after party, often providing some food and drinks.

    Now, what do we need to have a SQL Saturday?

    • Get a venue
    • Get a few speakers
    • Market the event
    • Teach people in sessions

    The core of this event is teaching people. It’s about touching many people that may never go to the PASS Summit, or DevConnections, or SQL Intersection. It’s about helping people get inspired in this business, learn something, meet colleagues. It’s about building a community.

    Everything else is gravy.

    Let’s be clear. I have no issue with events that can put on a fancy dinner for speakers, or give nice gifts, or cater lunch, or give away XBOXs to an attendee. I have no issue with any of that, and if you can, do it. However, please don’t feel you have to. Please don’t compete and build an event based on the budget you want, or have seen elsewhere. Please don’t make this event about stuff.

    Remember the attendees.

    Money is Tight

    Money is tight with product vendors, and it’s tight with recruiters, and it’s tight with venue sponsors. I have been worried about this for a few years now, as I think vendors have gotten caught up in the SQL Saturday excitement as much as organizers, speakers, and attendees. There has been lots of easy money, and as a result, I’ve seen competition and effort put into making a SQL Saturday more like a mini-Summit than a free, grassroots, one-day event.

    I am not complaining about anyone’s efforts. Many of you have done amazing jobs putting on events, and I’ve been impressed, and also quite humbled by your efforts. You really care and do a great job.

    However.

    The easy money isn’t sustainable, and I want many of you to be cognizant of that. I want you to ensure that you run another event next year, based on the budget you have, not the budget you want.

    Most of all, I want you to feel successful with your event because attendees came and learned something. Attendees don’t care about the extras that much, at least not overall. Someone will always complain. Extras are nice, but people come to learn and interact. They come because they’re hungry to be better at their jobs.

    Please don’t expect that you need to raise, or spend, $10,000, or even $5,000. Raise what you need, but build the event that suits you. I won’t think any less of you if I need to buy my own breakfast, coffee (yes, that’s a separate meal), dinner, and drinks.

    I promise you, the attendees won’t think less of you either if there’s a room, a speaker, and a slice of pizza for lunch.