Voice of the DBA

Author: way0utwest

  • It’s Natural to Avoid Problems

    The hardest part of transforming to a lean, efficient process is the culture change necessary to get a team to work together. It doesn’t matter if the team builds software or vehicles, the change to working in a new way, into disclosing problems, admitting issues, working without blame to fix them, these are very, very difficult changes to make.

    Dr. Edward Deming and his work with the Japanese have been the source of many ideas on how to improve a manufacturing process and increase quality. The ideas and principles are incorporated into The Goal, a novel that inspired The Phoenix Project. I recommend both those books for people interested in DevOps because building software is very similar to the manufacturing process used for other goods.

    Toyota has been one of the leaders of quality manufacturing and the Toyota Production System has been used as a model and adapted by many industries, including software. One of the ideas used in manufacturing is the ability of anyone to highlight potential problems. In car plants, this has been implemented with an andon cord, a way to stop production and have others help diagnose and solve a problem early in the process.

    Some have thought this is a culture issue where the Japanese might be more willing to highlight problems and work as a team, something that many Westerners have struggled to do. At the lean blog, they talk about how this isn’t the case. In fact, the Japanese, in general, seek harmony and might be less likely to raise potential issues. In fact, I think most workers are hesitant to raise potential issues, for a variety of reasons. Often anything that slows down work is frowned upon by management, which often leads to issues lingering on, or substandard products being produced. This also happens in software.

    I might argue that changing culture for developers is hard, but even harder for managers. We often don’t train managers well, and certainly we don’t often have good systems for coordinating work between and among knowledge workers. The systems that help with manufacturing give us a base, but they don’t apply quite the same way when your “machinery” is another human. Culture change for DevOps must include management and that means less oversight and interruptions, blameless reviews, and embracing mistakes and small failures. Those are often very hard for managers but necessary if you want to improve your software.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Using SQL Dependency Tracker as a Picklist

    This is part of a demo series I did for a customer workshop. I’m adding a little more detail and explanation of the demos of products I gave.

    A long time ago Andy and I were chatting with the founder of Redgate. At the time SQL Compare use was growing and it was becoming one of the “must have” tools for any DBA. I suggested that having a separate way to getting just the dependencies for an object listed was a good idea. Redgate agreed and at some point SQL Dependency Tracker was released.

    This post looks at one of the main uses I’ve found for Dependency Tracker: a picklist of things to examine.

    Altering a Table

    One of the common things a developer might do is change a table. In my case, I’ll add a column to a table.

    2019-09-13 17_10_12-Window

    Once I do this, I might think I’ve fixed something, but what if there are dependencies? Could there be a view of other item I want to ensure gets changed? There might be. While I could run a query against sys.depends, that might not get me everything that I need.

    Dependency  Tracker fulfills a need here and can make this process smoother. I’ll flip over to my SQL Source Control tab and click the icon in the upper left. I can use this integrated menu to launch Dependency Tracker with context, in this case, the database in which I’m working.

    2019-09-13 17_11_27-Window

    When Dependency Tracker launches, it will build a project out from my database, including a diagram. While this looks great, I find the diagram hard to use and navigate, especially when I’m in an unfamiliar database.

    Maybe if Redgate bought me a 42” monitor for home, I’d feel differently (hint, hint).

    In any case, this is the basic Dependency Tracker view

    2019-09-13 18_03_05-Window

    To me, the best part of the tool is on the right side. Specifically, the middle and lower panes. If I click in the middle pane, I can see my objects listed.

    If I now start to type a table, say my “Articles” table, I can see the list of objects sorts down to matching items.

    2019-09-13 18_03_41-Window

    Nothing special here, but when I click on the object in the middle pane, the bottom pane fills. In this case, I see what items depend on my object.

    2019-09-13 18_03_45-Window

    This bottom pane is where I find value. This is my picklist of things to examine. I can click on one of the items, and then go back to SSMS and find that item in SQL Search. I can see if I need to do work.

    2019-09-13 18_03_52-Window

    When I’m done, I ALT+TAB back to the Dependency Tracker screen and down arrow to the next item. In this way, I can walk down a picklist and try to ensure I don’t miss any dependencies. If I change any object, I can double click on it in the “Dependencies” window in Dependency Tracker and see if there are lower dependencies on that object.

    2019-09-13 18_03_57-Window

    Keeping track of work and ensuring I catch everything that might be affected by a change is an area that many developers struggle to do well.

    Dependency Tracker is a great way of ensuring that you catch all the dependencies that might be affected by your database change.


  • Unreliable Data Sensors

    I like data, and I like cars. I think there have been some really creative and useful integrations between the two. I also think there have been a lot of gimmicks and poorly architect-ed systems, including those that insecurely allow access to vehicular systems. I even worry (very slightly) about the integrations of networks in airplanes.

    The US NTSA has said no to cameras and displays in place of side view mirrors. These are on the new Audi e-tron SUV, and would use a camera and a display on the door to show the rear view. While this certainly might help mileage, and it could allow for technology to perhaps sharpen or identify something in the display, I also worry about a couple issues. If you want to know what this looks like, here’s a review that shows this.

    First, there is the safety issue. I find backup cameras, even very new clear ones, to be harder to look at than a rear view mirror. Granted, these do show a view the mirror can’t show, but I wouldn’t want to use these when I was moving at anything above a slow 5mph backup speed. The ability to gauge distance is much harder. I would worry that I’ve both look in the wrong place, and also struggle to see the display in some weather conditions. Not to mention potential dirt, water, etc. on the camera lens. Already my backup camera is often too dirty to use.

    The second issue, and this is the bigger one for me, is that this technology isn’t anywhere near reliable enough to use in this situation. While it might work well at any point in time, I find too many issues with advanced electronics in cars that fail more often and with a much higher cost. At just over 4 years, when the warranty in my current car expired, one of the cameras in the side mirror failed. While it doesn’t appear to be hard to fix this, it’s a an expensive part (US$400). And an annoying, albeit unimportant, error on the display.

    I’m all for new technology, and I think things like the lane change warning and other tools are fantastic. ABS and traction control are lifesavers. Backup cameras have saved me or others a few times. Adjusting mirrors and other responsive improvements are fantastic, though I certainly want to ensure these devices let me know if there is any failure. Others have been less exciting, like locks that don’t operate without power.

    We know there are issues with lots of data, and we know that sensor data also needs to be checked and verified, as well as occasionally discarded. Vehicles have dramatically opened up our world and given billions abilities to access goods and services they might never otherwise see. However, there are safety issues that should override any new technology that hasn’t proven itself not only to operate at a very high reliability level, but also in a way that operators can easily adapt to using.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Pre-Con in Denver

    As prep for our pre-con at the PASS Summit, Kendra and I are presenting a pre-con at the Denver SQL Saturday#908, on Friday, October 11, 2019. We’ll be talking about How to Architect Successful Database Changes: Source Control and Release Patterns for Performance and Availability.

    This is a look at development patterns that we’ve found to help handle more complex changes, both with state and migration patterns.

    The pre-con is $150, which is a bargain compared to the cost at large conferences. If you want to discuss development patterns that keep your database up and usable, come join us.

    Register today and we’ll see you in a couple weeks.