Voice of the DBA

Tag: syndicated

What is the DLM Maturity Model?
I’ve written a few posts on the Redgate Software blog to try and show how I see the DLM model, and how we see things at Redgate. We have a lot of developers that work in a similar way when building application software in C#, Java, Python, or other languages, and much of the company is trying to bring more engineering to database development.

Part of what the DLM maturity model aims to do is help us classify how we progress to a more engineered, repeatable, and reliable way of managing database development. You can read my overview, and then dive into each of the various levels we’ve built. The levels are:
Some of this is based on the CMMI model from the SEI, and some is based on what application developers are doing with their own continuous delivery mode. Simple Talk has written a What is DLM? article as well, and includes a different view of a maturity mode.

I think this process becomes more important over time as we depend more on software and the databases behind them, with fewer and fewer tolerances for downtime or human mistakes in the deployment process.

I’d like to get feedback from people on what they think of this model, and of the idea of engineering better database development. I know many people have built their own process, but far too many of the processes rely on custom scripts that are built and edited for each deployment, sometimes in the middle of the deployment. I think we could actually make database development better if we applied some better structure to our deployment.

Redgate is working on tools to support this, in a few ways, but this isn’t about Redgate. Rather, it’s about building better software for everyone, whether you use Redgate tools, another vendor’s tools, or build your own. Follow a better engineering process.

If you’d like to know more about the CMMI model, Alex Nordeen built a fools guide to the framework. It’s easier to read and understand than the CMMI site.
November 9, 2015
Rebooting SQLNewBlogger in November

I ran into Ed Leighton-Dick last week at the PASS Summit and we were chatting about the SQLNewBlogger challenge he started in April. I enjoyed it and while a number of people started, it seemed like most waned away. I tried to keep the challenge going with my own posts, adding notes to the posts on how much time I spent to give you confidence you could successfully blog yourself.

Ed wanted to kick off the challenge again, and he did earlier this week. There’s a November SQLNewBlogger challenge, asking you to get four posts done this month. One is due each Tuesday, which means the first was four days ago, on Nov 4.

Don’t let this discourage you if you didn’t write a post.

Start now. Write a post today. Look through the ones I’ve written. Heck, write about the same topic I wrote about. Have you written about defining a FK at table create time? If not, write that post now, reference mine, and show how to do it. Give us a sentence or two on why you would do this.

Write about using the DAC. Write about PowerBI. that one’s still on my list. Ed has ideas as well, and feel free to use one.

The idea is to just write. Take some time this weekend, reflect on something you did this week, jot some notes, and write a short piece to showcase your knowledge.

This is your chance to showcase your knowledge for your next employer, or even your review at the end of the year.

I know I’ve been inspired, knocking out 5 posts this week, which I’ve scheduled each Thursday. I’ll be late to Ed’s challenge, but that’s OK. I’m continuing to write short pieces about my knowledge. In fact, a few changes to a PoSh script today gave me two posts, looking to specific skills I worked on.

You can do the same. I look forward to you blogging, and seeing your posts appear in the #SQLNewBlogger hashtag on Twitter.

November 6, 2015
The SQL Source Control Frequent Updates Channel
One of the things we do at Redgate is release software often. It’s not just that we want you to release your software often (and develop better), but we do it ourselves. Different teams release at different cadences, which is both cool, and hard to keep track of. The SQL Prompt team is really amazing, releasing hundreds of times in the last year. A pace of almost 4 times a week!

SQL Source Control is a product I’ve been using fairly often lately. There is a team working on updating the code regularly, and I recently found out that they had two different streams of software releases. This is so the development team can get early feedback on some new features, but also so you can get access to the new features, performance improvements, and bug fixes as soon as they’re available.

As a result, we have a normal, mainstream channel for releases, and a frequent release channel. The frequent channel offers new updates every Wednesday whereas the normal channel releases are less regular. The releases tend to be every few months, depending on the feature set being worked on. The regular channel also rolls multiple frequent releases into one larger update.

Enabling Frequent Release

If you’re interested in getting frequent releases, then open SQL Source Control (SOC) and then click the help item. The “Check for updates” item is there, which is what you want to select.

The update screen appears, and you may or may not have updates available. I don’t, as I updated this morning. However in the upper right corner is a “Configure visible updates” button. Click that.

Once you do that, you’ll get a dialog that tells you that you might get more updates, every few weeks and get new versions. If you check the box, as I have, you get updates quicker.

One note. This isn’t for beta versions. This is for code we are sure is ready, but we’re hoping to refine how it works and this gives us a chance to essentially have a additional test audience view the code and let us know. This is over and above the automated CI process we use and rigorous testing already completed by the development team.

My experience is that I turned this on in early September to get the new Git support. I got the release with push/pull about three weeks before others (this has since been released to the regular channel). Since then, I’ve gotten two other releases that changed minor items, the same ones available to everyone else on the frequent release channel. The next regular channel release isn’t due until early 2016.

If you want to see more frequent changes, enable the updates. If not, you’ll get updates on the normal schedule you do now. If you’re trying to understand what version you’re on, or what the features are, we have release notes:
- Frequent Release Channel – https://documentation.red-gate.com/display/SOC4/SQL+Source+Control+4.1+Frequent+Updates+release+notes
- Regular Channel – http://documentation.red-gate.com/display/SOC4/Release+notes+and+other+versions
And if you want to shape the product, please vote on UserVoice for the things that you’d like to see in the future.
November 5, 2015
Adding Extended Properties
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 I needed to do recently was add some extended properties to objects. I got the idea of using them from John McClusky at SQL Bits. He had a great presentation on tSQLt that’s worth watching.

In any case, I wanted to add, and update, extended properties. I had used SSMS to do this, but it’s cumbersome. I decided to experiment and see how the T-SQL code works. My browsing of Books Online showed me there are a few procedures used, one each for adding, updating, and deleting properties. I decided to start with sp_addextendedproperty.

This procedure takes some interesting, rather unintuitive arguments. Name and value are easy to understand. These are the name of the property and it’s assigned value. One thing to note is that value is a sql_variant, which should work fine for most situations, but CASTing may be required.

However the next arguments are level 0, 1, and 2, with a type and name for each. Those didn’t make much sense at first. In fact, as I wrote a few scripts, I had to keep looking up the meanings. Essentially we have three classifications of objects. The outer containers, the objects, and the dependent objects. I’ll explain them below.

The level0 type is essentially the class of object. Is this an Assembly, a Contract, a Schema, etc. For my purposes, this has always been a schema, but certainly you could add properties to the other classes if you needed them.

The level1 is the object type that we usually work with: table, view, function, procedure. For me this is pretty much been table, view or procedure, but certainly function is something I’d use as well.

The level2 is the dependent object: the trigger, the column, the parameter, the constraint. These I haven’t really used, but I certainly think that adding in properties for indexes, triggers, etc are valuable.

Adding a property is easy. For example, one of the items I add is a PK exception for heap tables. To do that (for the SalesHeader_Staging table), I’d run this.
```
EXEC sys.sp_addextendedproperty 
  @name = 'PKException',
  @value = 1, -- sql_variant
  @level0type = 'schema', -- varchar(128)
  @level0name = 'dbo', -- sysname
  @level1type = 'table', -- varchar(128)
  @level1name = 'SalesHeader_Staging' -- sysname
  ;
GO
```
I can see this easily in SSMS.

Properties are great ways to add additional information to an object in SQL Server, though I certainly wish they were more visible in objects.

SQLNewBlogger

I knew there was a procedure to do this, and a quick search on extended properties got me to the BOL reference. I was experimenting with adding the properties while working on this, and I had to research the meanings of the parameters a bit, so this took about 20 minutes to get ready for publication.

Reference

A few items from BOL

sp_addextendedproperty – https://msdn.microsoft.com/en-us/library/ms180047.aspx
November 4, 2015