Author: way0utwest

  • DevOps–Fixing Poorly Named Constraints

    I was building some code the other day and kept getting problems in my deployment for a change. The deployment was having issues, and this came down to this statement.

    ALTER TABLE EventLogger DROP CONSTRAINT [PK__EventLog__5E548648B043C0BC]

    The problem was that this was the constraint on one developer’s workstation, but on another laptop, and in QA/Staging/Production, this constraint didn’t exist.

    When we deploy to other environments, such as QA and Production, we will always see the wrong constraint, as most deployment mechanisms look at the name of the object, not the function. Every upgrade script will typically try to run the above statement and then run an ALTER TABLE ADD CONSTRAINT later to add the PK back.

    If we have the correct name of the constraint in QA, the script will work. However, the name is likely different in each environment, so we need to fix this.

    We can find the name of the PK with this script:

    SELECT 
        A.TABLE_NAME, 
        A.CONSTRAINT_NAME, 
        B.COLUMN_NAME
    FROM 
        INFORMATION_SCHEMA.TABLE_CONSTRAINTS A, 
        INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE B
    WHERE 
           CONSTRAINT_TYPE = 'PRIMARY KEY' 
        AND A.CONSTRAINT_NAME = B.CONSTRAINT_NAME
    AND A.TABLE_NAME = ‘EventLogger’

    If we take the results of this, we can use this to produce a drop script. Here’s one way to do this. We’ll store the name of the constraint in a variable and use the EXEC() statement to execute some dynamic SQL. We then can execute the ADD CONSTRAINT with a new name later in the script.

    DECLARE @s VARCHAR(200)
    SELECT @s = A.CONSTRAINT_NAME
    FROM 
         INFORMATION_SCHEMA.TABLE_CONSTRAINTS A, 
         INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE B
    WHERE 
            CONSTRAINT_TYPE = 'PRIMARY KEY' 
         AND A.CONSTRAINT_NAME = B.CONSTRAINT_NAME
    
    AND A.TABLE_NAME = 'EventLogger'
    
    EXEC('alter table EventLogger drop constraint ' + @s)
    GO
    /*
    Other work
    */
    ALTER TABLE dbo.EventLogger ADD CONSTRAINT EventLoggerPK PRIMARY KEY (LogId)

    This is the type of DevOps change that I would release a table at a time, slowly cleaning up the constraint names. This will smooth your process and increase the reliability of your deployments.

  • SSoL: Where are my data and log files?

    I don’t think most of us need to know Linux, but if you end up managing a system, it’s good to have a little idea of how to get around. This is a short series of posts as I remember the skills I used to have back in university.

    This is easily documented, and once you start working, you’ll learn this, and it is documented, but after a few weeks when I actually go into a Linux VM, sometimes I forget. Most of the time I connect with SSMS, and it’s just another server.

    Data and log files are stored in /var/opt/data. You can see this in SSMS by selecting the properties of the server instance.

    2017-06-15 11_21_18-Server Properties - 192.168.1.210

    If you check the Files tab in a database properties, you’ll also see this:

    2017-06-15 11_22_41-Database Properties - AlwaysEncrypted

    You can also get this in Linux by starting the file manager as root. In a terminal type:

    sudo nautilus

    and enter your password. Then browse to the folder (computer/var/opt/mssql/data) as shown here:

    2017-06-15 11_19_11-Ubuntu 64-bit SQL Server .210 - VMware Workstation

  • Advancing Security

    One of the topics that is very important to many technology professionals is security. Security also might be one of the least understood aspects of our jobs. It’s an area that requires regular learning, monitoring, reactions, and vigilance. A healthy dose of paranoia makes a good security mindset, but this an easily devolve into greater stress and worry than might be appropriate, or the feeling that one should throw their hands in the air because of all the potential issues, attacks, and vulnerabilities.

    I think as individuals our part is to learn to write better code and scripts with security in mind, perhaps implementing best practices, but really the ways we will get better security is when vendors and platforms develop better ways to implement their security for us. They need people that study the issues and build fixes applicable to protect systems. This means we need good interfaces and basic contracts that ensure we can build software on top of platforms, but we will need to outsource this part of our security.

    Microsoft is one company that has been working to help us implement better security through defense in depth, through partnerships with other firms, and is making a difference. They’re not perfect, and there are still flaws in their software, but they are addressing and fixing them quicker and quicker. The world is changing, and Microsoft is a very different company than the one that build SQL Server 2008 R2, or even SQL Server 2012. They are maturing and becoming more responsive, and to me, more responsible about their place in the technology industry. They are striving to produce higher quality products, and when there are issues, they look to fix their mistakes quickly.

    Many of us that have struggled to believe in this new Microsoft and apply patches in a more timely manner. I’ll admit that I still rarely apply CUs unless I have a need for a fix, but mostly that’s because I don’t want any unexpected issues to crop up when I’m presenting and I don’t have time to test that regularly. Like you, I have multiple versions of SQL Server. I do catch up periodically, and I certainly try to apply Service Packs within a few weeks of release, if not sooner. As much as Windows updates can be annoying, this is more a matter of timing than concern over quality, and I do try to keep up with these.

    Will Microsoft and other vendors make mistakes with updates? Sure, sometimes there will be a patch that causes a problem with some, maybe many systems. However, we do need to grow and advance the security of our systems, which will always have vulnerabilities. Therefore, we need good quality updates from vendors like Microsoft, which I do think has happened. However, we also need customers to apply those patches. You can be slow and conservative, but don’t be negligent and try to avoid them completely. That makes the security situation worse for all of us.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Financial DBA

    I’ve got an Azure subscription. At least, I think I have just one. I know I have a few Microsoft accounts, across 4 (or more) different email addresses, that I use for various VSTS development purposes, but only one should have any Azure resources. When  I check each of them, I find that I do only have resources (and charges) for one. However, I also found a strange charge on my credit card statement from Microsoft Azure. It was just a couple dollars, but as I started digging through the various statements, I couldn’t determine where the charge was from, or what it was for. As of now, I’ve opened a support case with Microsoft to track down my usage.

    This has me thinking of the future of many data professionals, some of whom will certainly have a few assets in a cloud based environment. I have a small subscription, but plenty of resources, and keeping track of which items belong to which resources and what I need isn’t always easy. It’s quite the challenge, especially when billing and finance aren’t my job. In an organization like Redgate, I’d guess we have lots resources, some of which developer provision, need, and then might forget about. Who reconciles this and ensures the assets we have are those we need?

    As we move to a world where services are used as often as assets, perhaps interchangeably, I expect that many of us will need to be accountable for not only the usage, but tracking why we’ve engaged that service. Over time, we need to retire and get rid of assets, but ensuring we remember exactly what we’re using and why can be hard over time. With a little employee movement, many of us might find ourselves in charge of services that we don’t understand, and might not be sure are necessary. We also might not be sure these services can just be discarded. The last thing we want is some uptime disruption because we terminated some service contract.

    A whole new dimension to our job is likely coming, and for many of us, this will test our documentation and organizational skills. I wouldn’t be surprised to find many DBAs or lead developers having a standing monthly meeting with someone in finance to be sure we aren’t wasting money.

    Steve Jones

    The Voice of the DBA Podcast

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