Author: way0utwest

  • The High Availability Poll

    Always On Diagram
    Is it worth it to you to build a highly available database?

    The cost of building highly available databases dropped with the introduction of Database Mirroring in 2005. Without the need to purchase identical hardware for a spare system, it became much easier and less expensive to set up extra systems that could handle a workload in the event of a disaster. This technology was improved in SQL Server 2008, and in SQL Server 2012 we have a new option: Always On.

    When I first heard about the changes coming in SQL Server 2012, I thought for sure that many people might upgrade to take advantage of the HA enhancements and provide more stability for their systems. However as I see the actual changes in detail, and talk to more and more data professionals, I’m not so sure. Many of us have spent years building systems that tolerate most issues meet the majority of our needs. With that in mind, I had a question for the DBAs out there.

    How important is a highly available database with automatic failover to your employer?

    Having a spare system that automatically picked up the load when a database server failed would seem to be on the wish list of every user, but plenty of environments don’t implement one. Many companies desire such a configuration, but when they see the cost or complexity, many forego an implementation.

    This Friday I’m wondering if your business sees this as critical and has implemented such a system, or are you more tolerant of minor issues, and willing to accept some downtime in a simpler environment.

    Steve Jones


    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Password Help

    Keepass Logo
    Use Keepass, Password Safe, or some other password manager.

    In case you haven’t heard, LinkedIn passwords were hacked and posted online. If you haven’t changed your LinkedIn password since the attack, please stop reading and go do it now.

    In reading about the attack, I sent a few friends a note as well to remind them that not only should they change their passwords, but that they should not be using the same password in multiple places. With more and more services intertwined, and more logins needed, it’s no stretch to think that someone that manages to crack your password, or steal it, from one service might use it on another service. Especially banking services.

    As data professionals, it’s easy for us to preach to non-technical people the value of strong passwords, but it can be hard to get them to use them. Strong passwords are problematic for many people to remember and type, and we find that most people prefer the path of least resistance: one short password that’s easy to remember.

    This article talks about a few things that IT people can do to help educate others and make it easier for them to consider strong passwords. Inside of a company, we can try to implement more services and products that secure our systems, but if people continue to use the same password for their personal mail or favorite website, much of that might not matter.

    Ultimately I think the best thing we can do is set a good example, and choose strong passwords stored in a password manager. Once people see that it’s relatively easy to secure passwords with something like KeePass or Password Safe, they may give it a try. That may help keep our data just a little more secure.

    Steve Jones


    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • The Redmond Agenda

     

    TechEd 2012
    TechEd 2012 had a lot of cloud focus.

    TechEd was recently held in Orlando, and I watched a few highlights of the event remotely from the ranch in Colorado. One thing was quite apparent from the coverage is that the cloud is very important to Microsoft. They’ve backed off the “everything in Azure” message that we have been seeing for a few years, and I saw quite a few talks and demos about hybrid applications and the private cloud. One that’s located in your data center.

    However the cloud is still important, and I wonder if this piece is true. It talks about five things Redmond doesn’t want you to know, and the first item is that the cloud is first. New releases of products will likely come in the cloud first, and in a version you can buy second. The article mentions Sharepoint, but many other Microsoft products live in the cloud, including SQL Server.

    Is that a bad thing? Many of us complain about the quick release cycles of SQL Server, so having new releases take longer in the box may be preferable. It’s already a challenge supporting two or three versions of SQL Server. If releases continue to come every two years, I suspect many DBAs will be supporting five or six versions in their companies very soon. That will be challenging, especially as many of the monitoring and troubleshooting skills we will build or buy may not work with all those versions.

    I don’t know if the rest of the items listed in the article are true or even important us data professionals. However I do think that if SQL Server moves toward a cloud-first development model, I think it might be something that many DBAs appreciate.

    Steve Jones


    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Using a Symmetric Key

    In my Encryption Primer talk, I do demo on symmetric key use, and wanted to document it here. Encryption is a serious subject, and please do your research and education, as well as testing, before you implement it.

    This post will look at some simple encryption and decryption using symmetric keys. I showed how to create a symmetric key before, so I won’t talk about that here, but I’ll just show the code.

    Let’s set up a test table. In this case, I’m showing salary in a table, which isn’t something you want to do, but you might have this in an existing application: data you need to encrypt, but it’s stored unencrypted.

    -- create a table 
    create table Employees ( 
     id int identity(1,1)
     , firstname varchar(200)
     ,lastname varchar(200)
     ,title varchar(200)
     ,salary numeric(10, 4) );
    go
    insert Employees 
    values
      ('Steve','Jones','CEO', 5000)
     , ('Delaney','Jones','Manure Shoveler', 10)
     , ('Kendall','Jones','Window Washer', 5)
    ;
    go 

    Here I have three employees and salaries. Now I want to encrypt the salary. However I cannot just encrypt this value. Encryption creates a binary representation of the data, and that won’t fit in a varchar field. So I need to add a column.

    alter table Employees 
     add EnryptedSalary varbinary(max);
    go 

    Now I have a placeholder, so let’s create a key and then update the new binary column with the encrypted value.

    -- create a symmetric key
    create symmetric key MySalaryProtector
     WITH ALGORITHM=AES_256
     , IDENTITY_VALUE = 'Salary Protection Key'
     , Key_SOURCE = N'Keep this phrase a secr#t' 
     ENCRYPTION BY PASSWORD = 'Us#aStrongP2ssword'
    ;
    go 
    -- open the key 
    open symmetric key MySalaryProtector
     decryption by password='Us#aStrongP2ssword'
    ;
    
    -- encrypt the data 
    update Employees 
     set EnryptedSalary = ENCRYPTBYKEY(key_guid('MySalaryProtector'),cast(salary as nvarchar))
    ; 
    go 
    -- remove the old data 
    update employees
     set salary = 0
    ; 
    go 

    Note that I open the key, which is needed. I can close it at the end, or it will close when my session ends. I don’t close it here as I usually run this demo in the course of one session.

    The encryption takes place with the ENCRYPTBYKEY function, which requires the GUID of the key. Why the GUID and not the name I don’t know, but it seems like a PIA, halfway implementation. In any case, the KEY_GUID function is used as the first parameter.

    The number needs to be cast as a character, so I do that first, and then it’s the next parameter in the function. If I look at the data, it looks like this:

    select id , firstname , lastname , title , salary , EnryptedSalary
     from Employees; go 

    encryptsymm

    If you use the same identity_value and key_source, you should get the same encryption.

    To decrypt it, I do this:

    -- decrypt the data, with the casting  select id  , firstname  , lastname  , title  , Salary = cast(cast(DecryptByKey(EnryptedSalary) as nvarchar) as numeric(10,4))  , EnryptedSalary  from Employees go 

    The encrypted value has a header that tells it what key is used, so as long as it’s open, this works.