Voice of the DBA

Author: way0utwest

  • Staging Deployments

    This editorial was originally published on Nov 30, 2011. It is being republished as Steve is out of the office.

    Software development can be a complicated dance. Most of us do not work for a software vendor and don’t have the strict requirements for our deployments when we control the client systems. That doesn’t mean it’s easier for us, especially as our environments grow more complex and the availability of our systems becomes more important. Application changes can become disconnected from the database changes, especially when the scope or scale of the change is large, which can present problems.

    Making database changes can be challenging since we must ensure that our data is not lost as objects are altered. We have to ensure that any application functions that depend on a certain schema receive the data they need, without unnecessary errors. The timing of changes becomes more important in the database than in applications in many situations. This Friday I am curious how many of you decide to stage these changes in your environment. If you have dependent changes, I’m wondering if you might alter the database first and change the application in a later deployment.

    How many of you deploy database changes before code changes?

    By “before” I mean you deploy the database changes, possibly making some application changes, but there are other code changes deferred for a separate deployment at a later time. The use of views, defaults, optional parameters and more allow database changes to proceed without accompanying application changes. It may require a bit more work, but the database can potentially be changed during a less busy time, even if development or testing for the all the application changes is not complete.

    The future will require more availability and stability from our systems as they become more essential to our organizations. Learning to update software, and databases, with minimal disruption is a skill that will set you apart in the future.

    Steve Jones

  • Speaking at SQL Saturday #621–Silicon Valley

    Once again I’m heading back to the Valley. I was accepted to speak at SQL Saturday #621 – Silicon Valley on April 22, 2017. This is one of the larger SQL Saturday events in the US and I enjoy visiting California, so I’m looking forward to the event.

    I’ll be talking DevOps again, trying to convince some of you to start testing database code, others that database development and deployment can move quickly. This is a similar talk to the one I’ve delivered a few times and hopefully I’ll get a few people to think about changing their development practices.

    If you’re anywhere near Mountain View on Apr 22, consider signing up and coming by the Microsoft Technology Center in the area. It’s a neat building and there will be some great speakers. A good chance to learn more about the SQL Server platform.

  • Dealing with Supervision

    This editorial was originally released on Feb 4, 2013. It is being republished as Steve is out of the office.

    I’ve been working at home for a decade, first for my own company and now for Red Gate Software. In that time, I’ve learned to manage myself, motivate myself, find work to do, and meet deadlines, all of which I’ve done without having anyone manage me. Over the last five years I’ve worked at Red Gate, I’d like to think that I was one of the easier people to manage since I work well on my own. I’m not sure if my various managers would agree, since I know that I can be particular about how I work and not necessarily work closely with others, but at least I haven’t required much of their time.

    A short while back I was talking with a friend that was under pressure to complete a deployment that was proceeding poorly and their manager stood next to their desk, watching, commenting, and asking how long each process would take. I’ve had to deal with that situation in the past, and it was  maddening to me. It’s hard enough to focus and work on a task when there are problems with the technology. Having someone that can’t contribute but is in a supervisory role nearby usually makes things worse.

    Ultimately I think micro-management says more about the manager than the employee. There are trust issues or control issues, or perhaps pressure from the manager’s boss. It can be hard to deal with micro-management, but if you plan to continue your employment, you need to find some way to deal with it.

    There is no shortage of ideas. You can search for “dealing with micro-management” and you will get a wide variety of advice. I’ve tried different techniques in the past and some have worked, some haven’t. The best way to handle micro-management seems to vary with the situation, but it’s good to have a few things to try.

    Steve Jones

  • Laptop Cattle

    I traveled to Cambridge recently for some meetings at Redgate Software and to attend SQL Bits. I arrived on Tuesday, worked a bit, and then came back to the office Wednesday for the SQL Clone launch (a success, by the way. Watch it. Now. Well, not now, but after this post).

    After the first two SQL Clone broadcasts, I walked back to my desk and tried to get some work done. I was updating the release pipeline for a demo and kept getting an error during the restore from production step. It was strange as I hadn’t changed anything, and had actually demo’d this step the previous week. I tried a few things before I read the error message and then realized I had a corrupt .dll. Not great, but sometimes a restart will clear things if this is some bad bits in memory.

    I closed Windows and then clicked “restart” and got this.

    IMG_1385

    Not the end of the world, and I assumed this was some transient. I let this go and went to get coffee. I returned to see this screen, but I could swear the percentage was different.

    It was. The machine was rebooting, crashing, and getting back here. I powered down, waited the customary 5 seconds and 5 more, and booted back up. I got to the Windows recovery screen. There were a few options, System Restore Point, System Image, etc., but nothing was working. After about 20-30 minutes, and another 10 considering whether I should walk down the road and buy a new machine, I decided to reset and reinstall Windows. Not my favorite option, but I didn’t think I had another one.

    C8F5sILXwAAHil6

    I clicked the button and started watching Windows reset itself.

    IMG_1390

    And watching, but fortunately I had another broadcast to do for SQL Clone, and I had my phone.

    IMG_1392

    Eventually the install finished, and Windows configured itself. I’d done this a few times for other machines (desktop and laptop) in the last year, but by choice, after I’d made backups. This time I was forced, and was hoping that I didn’t lose too much stuff.

    IMG_1393

    When I was able to log in, I saw there were still a few things, including some configuration that Windows restored as a side effect of using a Live login, or whatever Microsoft calls it now. When I first logged in, I was greeted by my new install.

    IMG_1394

    From there, I needed to get going. I had some Windows config, and more of the stuff in the Documents, Pictures, etc, libraries were there (Actually all of it), but anything in\ Program Files, \Windows, etc. was gone. Not fun.

    Fortunately I have rebuilt some machines recently and have found Chocolatey to be invaluable. I first got Chrome going, then added Dropbox and kept other installs going in the background as I got ready for broadcast 3.

    IMG_1395

    Throughout the evening, I manually added back my O365, SSMS, and SQL installs, and kept thinking of the stuff I needed for demos. git, Github and VSTS got my code back down, and I had to re-authorize some apps with new passwords, but I was 90% running before I went to the hotel that night.

    Reinstall Windows to running SSMS demos with SQL Server in about 4 hours, minus about an hour in the SQL Clone launch.

    The next day I had pretty much everything running again by noon, minus a few sample database backups. I’ve learned that the default SQL backup path is no bueno on a laptop. I’ll have to rebuild some sample data sets and I’ve already moved things to a new path that will exist if this happens again.

    I was productive and working, writing some code and testing demos the next morning. It really was about a 4-5 hour process to have a laptop back working, with code, that I could use on an airplane with the data I expect.

    My laptops are (mostly) cattle now. I’ve got a few things to square up (like SQL backups), but overall, I think I’ve improved my DR process.

    And I’ve learned to git push before I power down this machine.