Author: way0utwest

  • Informing the Internal IT Team

    Somehow across the course of my career, I’ve morphed from a strictly technical guy to a publisher and teacher that also gets to do some technical work. I never expected this, though perhaps I should have. Despite my disdain for writing in formal schooling, I learned early on to always document and log what I did. In fact, a few times my notes and tracking ended up ensuring that we weren’t chastised too harshly for our actions. Perhaps if even kept some people from being fired. I’m not sure, as I think it’s hard to get fired, but having some reasoning and documentation can provide some insurance against the boss getting too upset.

    In my career, I’ve had to send out status items at different times, with various purposes. As with many of you, I’ve often had to document my time and efforts for my manager. I’ve been a part of teams that adopted the stand-up practice of sharing your workload with others. I’ve had to summarize the work of my team for a director or VP above me. Some of those efforts felt valuable, but often it seemed I was going through the motions and wasting valuable time on something that was more of a cover sheet on a TPS report than anything else.

    There was a post on publishing an engineering weekly newsletter that reminded me of the various status reports I’ve built. While I haven’t had a weekly engineering letter, I have been in companies where a weekly or monthly newsletter was sent out. In fact, at one of my first jobs, we got a physical copy of monthly company newsletter delivered to our mail cubbies (anyone remember those?). While people would grumble about the contents or disbelieve them, I also noticed that many of them actually read the newsletter. I think it’s natural for people to want to be informed about the company, even if they are skeptical about the data.

    The idea of publishing a weekly newsletter for your staff makes sense. It’s a good way to keep people on the same page, especially as your organization grows larger than a single team. I wouldn’t expect everyone to read every part of each issue, but that’s OK. They’ll get something out of it. This is also a good way for someone to fill time during a short break, see who’s out of the office, having a birthday, or changed positions. I think it’s also a good reminder for items like on-call or project releases. Even if I don’t have time to read it right away, finding information in a central place can be a hassle, and a quick search of email would let me check the person to call this week after hours.

    Including technical content is always good, and allowing someone to peruse articles or new concepts on their own time, maybe even encouraging more learning subtlely, could improve the quality and morale of your staff. Of course, if you are an open, exciting company that employees enjoy, this works well. If management is oppressive and overbearing, then publishing a newsletter isn’t going to fix your culture. You’ve got other problems to fix first.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.1MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Create a BACPAC–#SQLNewBlogger

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

    One of the things that you might encounter at some point is the need to create a BACPAC. This is essentially a DACPAC with data included. There are times you might find a BACPAC more convenient than a full backup, especially if you work with Azure.

    This post shows how you can create a BACPPAC file (with the extension .bacpac) from SSMS.

    I have a small database, the PartsUnlimited database, from the Microsoft PartsUnlimited demo application. I want to create a BACPAC from this, however, when I right click and select Tasks, there is no “Create BACPAC” option.

    2017-02-21 14_08_41-SQLQuery1.sql - dkranchlabdemo.database.windows.net.master (sjones (113)) - Micr

    That’s fine, because the “Data Tier Application” is the DAC, and an export includes the data, which creates the BAC part of the process. Let’s choose “Export Data-tier Application”. Once we do that, we get the expected summary wizard screen to start.

    2017-02-21 14_10_05-Export Data-tier Application 'PartsUnlimited'

    I click next and immediately get prompted for a location in which to save the file. The will include all your data, so choose a location that has sufficient disk space. You have the option to also store this in Azure if needed.

    2017-02-21 14_10_43-SQLQuery1.sql - dkranchlabdemo.database.windows.net.master (sjones (113)) - Micr

    Note the filename above is already filled out by default, but you can change this in the edit box. If you click the “Advanced” tab, you’ll get the chance to select only certain tables if that is required. You can see this dialog below.

    2017-02-21 14_10_50-Export Data-tier Application 'PartsUnlimited'

    Once you’ve chosen a location, you click next and get a summary page.

    2017-02-21 14_13_31-Export Data-tier Application 'PartsUnlimited'

    Click finish, and the process starts. This runs very quickly, extracting the schema and then all the data, noting the results of each object.

    2017-02-21 14_13_38-Export Data-tier Application 'PartsUnlimited'

    That’s it. If I look in the location, I’ll see my BACPAC file.

    2017-02-21 14_15_11-DAC Packages

    I can copy this to another machine and import it to recreate a database. We’ll do that in another post.

    SQLNewBlogger

    A short, quick post. I’ve done this before, but I had to do this for a quick process and took 5 extra minutes to take screen shots, spending 5 minutes later writing this up.

  • The Livestream Product Launch

    SQL in the City Streamed in 2016 was a success, with lots of feedback that people enjoyed the sessions and format. With the release of SQL Clone, we’ve decided to do it again.

    The SQL Clone Product Launch Live Stream is coming in a couple weeks, on Mar 29, live from Cambridge, UK. I’ll be traveling there, along with Grant Fritchey, and we’ll both be helping broadcast all day, repeating sessions across many time zones.

    Join us and see if SQL Clone is right for you. Or download an eval and give it a try.

  • DevOps Isn’t Perfect

    I saw a post recently from Grant Fritchey, Help Me, Help You, Deliver DevOps. In it, Grant shows that DevOps isn’t making developers do everything, it isn’t just giving developers more responsibility, and it isn’t developers handling some of the operational staff responsibilities. It’s about getting development and operations to work together. Hence, DevOps, not DEVops, or Dev    ops.

    In the post, Grant also links to some fundamental failures from companies that supposedly have adopted DevOps processes. Companies like Gitlab and Amazon. There are plenty more examples, which certainly make some people question whether DevOps is better than other methods of building and deploying software.  How are the VSTS issues different from the Knight Capital debacle?

    In some sense, they aren’t. In many cases, we’ve had a software issue that affected customers. People were upset, services weren’t delivered, and it’s entirely possible that revenue was lost. However, one of the things that I think differentiates DevOps is that developers and operational staff can troubleshoot and determine a root cause much quicker. Since the entire commit, build, test, release pipeline is instrumented and documented, your staff can quickly determine what new items might have caused an issue. If it’s not a new item, they can also quickly determine if that’s the case.

    However, once you’ve placed your system in production, DevOps doesn’t ensure that your HA (High Availability) or DR (Disaster Recovery) preparations are adequate. Those are still the responsibility of your Ops staff, but by using DevOps, and storing configuration as code and provisioning your systems in all environments the same, hopefully you’ve taken advantage of this to actually ensure you have tested some HA or DR features in an environment outside of production.

    However, DevOps isn’t prescriptive advice. DevOps isn’t a particular process or a tool that you use or install. DevOps is about learning and improving over time. For different companies, this means you’ll be at a different stage in your DevOps maturity than other companies. Some have complete deployment processes, but limited instrumentation and monitoring in production. Some have tons of data and deploy code perfectly, but no HA. Some have great HA, but poor deployment processes.

    DevOps is about constant improvement and advancement to make your software development (Dev) and deployment (Dev and Ops) and monitoring/management (Ops) better over time. This might not prevent human error, or even code bugs, but DevOps should mean you make fewer mistakes, less often, and learn from them to avoid repeating those issues.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.7MB) podcast or subscribe to the feed at iTunes and Libsyn.