Voice of the DBA

Author: way0utwest

Versions of Stored Procedures
I never knew this, but stored procedures have versions.

I was browsing the CREATE PROCEDURE doc page, and stumbled upon this item. In the beginning part of a stored procedure definition, after the name, there is a section that starts with

; number

Hmmm, I read the entry and it says the number is an integer that is used to group procedures of the same name. There is a note this is a deprecated feature that may be dropped, should not be used for new work, and old work ought to be modified, but it was interesting, so I tried it.

First, create a proc:
```
CREATE PROCEDURE dbo.GetOne

AS 

SELECT 1

GO
```
Once this is done, we can execute it and it works. Now, let’s modify this. I’ll use this code:
```
CREATE PROCEDURE GetOne;2

AS 

SELECT 'One'

GO
```
You can see these will have different results. If I execute them, I do so with the name, including the optional integer.

In SSMS, there is only one object listed.

If I drop the procedure, both are gone.

I’m not completely sure where I’d use this feature, and I can see not investing in it, but I found this fascinating. All these years of writing stored procedures and I learned something new this week.
February 6, 2019
Complex Constrained Security

I was reading about Kerberos and authentication with SPNs recently. It’s a topic that seems to make sense and appears orderly, but when I’ve had issues with SPNs, it feels like voodoo and black magic sometimes might be needed to get things working. As I read through the document, trying to ensure I would learn a bit more about how impersonation and delegation work, I noticed this sentence:

“As a security best practice, Microsoft recommends constrained delegation over unconstrained delegation.”

That seems reasonable to me. We ought to limit where users can connect to specific systems to ensure good security. This makes perfect sense where we have systems like web servers or application servers and we should limit delegation to specific databases servers. This wouldn’t prevent all security breaches, but it would limit the scope of many.

The complexity comes when we start to have multiple servers that might connect to multiple back ends, especially as we grow our architectures to include additional HA nodes with Availabilty Groups. Tightly linking security complicates the configuration and requires that our sysadmins setup new machines and properly add new delegation targets as machines change. DevOps and configuration as code can help here with ensuring that we always add the required security changes to the right machines.

That still doesn’t make it easy to manage a tight security environment without lots of resources. As we rotate or retire machines, we need cleanup of the security settings that refer to these objects. If we rotate host machines, which is usually rare, we need to remember to update out configuration scripts to work with new machines and accounts. If we add nodes, we need additional lines in scripts. If we move to containers for database servers, this might require even more changes.

None of these items is complex, but when you must repeat them for many systems, many accounts, and on a semi-rare basis, they add some overhead that is both tedious and difficult to keep up with for a staff. This is especially true as staff turns over. Do you want to let the new people know that they need to make all these updates while handling their “normal work”? I could see all these details becoming a chore because we’re human, we’re flawed, and we make mistakes.

I like the idea of tighter security, but at a scale, at random times, in between all the other tasks we must complete, the tools and techniques we have don’t make this something that seems manageable. I don’t have solutions, but I think that we do need some better tools that ensure security can be both flexible and convenient, while enforcing the principle of least privilege. The management of systems at scale is helping (forcing?) companies rethink some security tools and features, but there is still work to be done to ensure our employees will correctly and consistently configure security.

Steve Jones

The Voice of the DBA Podcast

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

February 6, 2019
DR Planning

Data professionals know that protecting and ensuring our data is safe is one of our primary jobs. Many of us worry that if we were unable to recover a database, our job might be jeopardy, which makes sense. If we lose data, an organization might make the decision that we aren’t trustworthy enough to manage a database system. This leads many of us to plan and prepare for different types of disasters, with procedures and systems in place to ensure that we can quickly get things running after an issue.

Natural disasters, or other large scale disruptions of business sometimes exceed the plans we’ve put into place. Fortunately they’re rare, but I ran across an article that talks about a few items that we might not consider when making plans. Even if you can fail your database over with an Availability Group running in another location, there are still some points you might want to think about.

Perhaps the biggest one for me is that testing is not optional. I’ve seen some amazing plans put into place, but never tested because no one wanted to disrupt ongoing business activities. Testing is really critical, perhaps because of the second more important item I see cause issues: failback. This isn’t always as simple as we’d like, even with some of the amazing work that Microsoft has done with SQL Server. We want to ensure that we do know that if something happens to our primary systems and we move them, we can come back. After all, these are the primary systems for a reason.

While other items such as making DR planning something your organization cares about can matter, I think the viability of this depends on how likely these disasters are. If you’re in a seasonal hurricane path, or some other disaster, you likely need to have better plans than if you’re in a stable region. Not that you can avoid any plans, but most of the time a disaster is a rare event and it’s really IT’s job to ensure that systems are resilient.

I do think it is worth noting that regulatory compliance isn’t optional. While your auditor might have sympathy if they are likewise affected by the disaster, that sympathy dissipates over time. A disaster next month might not factor into an audit review in 20 months. More laws are on the books and more are coming than most of us have dealt with in the past. Design your system and process to be compliant, even in a disaster.

Lastly, the people side of business can’t be emphasized enough. While some of us might be expected to shoulder a greater workload during a disaster, keep in mind that we would still need support outside of work, perhaps even a replacement worker to handle some of our work tasks or even help with personal items. The longer our lives are disrupted, the less likely we are to work as hard, or remain focused. Part of any plan should be how can our organization help support those that are struggling themselves. After all, the effects of a localized disaster on business could get compounded if staff stops coming to work.

Steve Jones

The Voice of the DBA Podcast

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

February 5, 2019
Learning for Feb
By the time you read this, I’ll have decided, but I just finished the first book and need to pick another. This post is more for me than anyone else, helping me to sit down and think for a minute.

I don’t have any pressing need to work on any of the other books for work or career. It’s more that I’m interested in various topics, so I need to pick a direction. I’m also cognizant of the future and which books I want to go through.

Recap

Here are the books I purchased and plan to read this year:
The question is, what’s next?

I’m really not sure, but I do know that I’ll be relatively less busy in February, really busy in March, and April will likely be like January. As a result, I want an easier book in March.

The challenge for me is understanding what’s easy and hard. I think the Azure/Xamarin one will be hard as I’ll need to practice skills that aren’t useful or tangential to work. The Power BI stuff is likely the opposite. The Python stuff is probably in the middle.

The Plan

My thoughts right now are that I need to research for a couple days. It’s Jan 31 as I write this, and I’m on vacation for a couple days. That’s both good and bad. Bad because I want to get away, good because I can find some spare time to just read and no do.

With that in mind, I’m going to read a chapter of 3-4 books and then decide in which direction to go. By the time this publishes Monday, I should have made a choice, but I’ll be busy working on other stuff, so I won’t get to update this post.

The four to get through a chapter on are:
Wish me luck.
February 4, 2019