Voice of the DBA

Author: way0utwest

Shutting Off PowerShell Warnings–#SQLNewBlogger

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

Not really a SQL Server post, but I ran into this minor issue. While running a script, I saw this:

The warnings aren’t a big deal, and in fact, have no bearing on my script. At least, not on this script. Since I needed to give this to a customer as a PoC item, I didn’t want any weird warnings. As a result, I needed to suppress these. A little intellisense in VS Code gave me a hint, but what value to use for the parameter?

A quick search brought me to Server Fault, where I saw the value. I added the SilentlyContinue to my script and messages suppressed.

SQLNewBlogger

This is a helpful tip for me, and I think I showed you how I found an issue, researched, and solved it. It’s good to give a potential employer some confidence that you can work through issues and find answers.

This took me less than 10 minutes. I bet you could do the same thing in the same time. Write about how you solve a small issue and drop it on your blog.

October 2, 2019
Searching for Answers Inside

How easy is it for you to search your codebase, especially across projects, and find out if there are dependencies, similar code solutions, or even other incidents of similar problems? Do you feel comfortable that you can find out what you need to know across and throughout your organization?

Or is it cumbersome for you and others?

In the 2019 State of DevOps report, one of the important areas that designated high and elite performers was their likelihood to easily find internal information. Those users were more productive when using internal sources of information to find knowledge related to their work. They also know how to, and are able to use external sources as well. I certainly know that if I needed to write T-SQL everyday, having access to the SQLServerCentral forums would be invaluable for me, and I’m sure it is for many of you as well.

I think one of the very hard things for inexperienced people in any organization to do is find information. So often knowledge is gained over time by employees that have spent significant amounts of time working on systems. No matter how much we might preach and mandate documenting things, many items won’t be written down. Over time, many of us internalize lots of information that might seem obvious and unimportant to us, but is necessary for more inexperienced people to succeed at different tasks. If you doubt this, just look at any DR test where someone tries to follow the directions written by experienced pros. They’ll fail almost every time because we don’t document every step.

I’m not sure we should even try. I think the idea of trying to help others more easily find information is a better solution. Having tools to enable this can certainly help new people get up to speed quickly, as can group programming (or administration) efforts like pairing or mob style work. We might not easily ensure someone could pick up the pieces if no staff were around, we can make it easier for those that want to learn and succeed to seek out the knowledge they need.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

October 2, 2019
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.

October 1, 2019
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.

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.

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

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.

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.

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.

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.

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.

September 30, 2019