Tag: T-SQL

  • Enable Transparent Data Encryption

    This is one of the things in my Encryption Primer presentation that I don’t demo. It’s really easy to do, and it’s rather mechanical, so I just show the image that has the steps from MSDN and leave it at that.

    However there are a few things I wanted to change, and test, so I thought I’d show my procedure on a local database. I roughly follow the MSDN article, but a few slight items.

    First, use master and create your keys and certificates.

    CREATE DATABASE TDETest
    ;
    GO
    USE master
    ;
    GO
    CREATE MASTER KEY
     ENCRYPTION BY PASSWORD = 'AReallyStr0ngP@ssword'
    ;
    go
    CREATE CERTIFICATE SteveCert
     WITH SUBJECT = 'My DEK Certificate'
    ;
    go
    USE TDETest
    ;
    GO
    CREATE DATABASE ENCRYPTION KEY
     WITH ALGORITHM = AES_128
     ENCRYPTION BY SERVER CERTIFICATE SteveCert
    ;
    GO

    I created a test database here for another process, and this is roughly the setup. However before I enable the encryption, here’s what I recommend you do:

    USE master
    ;
    go
    BACKUP CERTIFICATE SteveCert
    TO FILE = 'c:\SQLBackup\SteveCert'
    WITH PRIVATE KEY 
    (
        FILE = 'c:\SQLBackup\SteveCertPrivateKeyFile',
        ENCRYPTION BY PASSWORD = 'R@ndomP3ssW0rd'
    );
    go

    Encryption is serious stuff. If you lose this certificate from a server crash, you are definitely not going to be able to open your database or recover your data. Gone is gone, and data loss means data loss here.

    Back up your certificate.

    Quick question: do you know where your backup of the certificate is?

    Once this is done, you can continue on:

    USE TDETest
    ;
    go
    ALTER DATABASE TDETest
    SET ENCRYPTION ON;
    GO
    

    The encryption is quick on this new, small database.

    Now let’s see if this worked. We’ll add data and make a backup.

    CREATE TABLE MyTable( LogData VARCHAR(MAX))
    ;
    INSERT MyTable SELECT 'This is an encrypted database'
    ;
    GO
    BACKUP DATABASE TDETest
     TO DISK='tdetest.bak'
    ;

    If I go to my backup location and look for this backup, I can open it in an editor.

    encrypt2

    It’s random gibberish. If I run a search for data in my table:

    encrypt1

    I get no results

    encrypt3

    Don’t think this is valid? Run this below and re-search this backup for the string. You’ll find it. This is one thing encryption protects you from.

    CREATE DATABASE NoTDE
    ;
    GO
    USE NoTDE
    ;
    GO
    CREATE TABLE MyTable( LogData VARCHAR(MAX))
    ;
    INSERT MyTable SELECT 'This is an encrypted database'
    ;
    GO
    BACKUP DATABASE NoTDE
     TO DISK='notde.bak'
    ;

    The database is encrypted, but anything I do with the database doesn’t require code changes, hence the “transparent” nomenclature.

    The value of this is debatable, but I think it’s not a bad feature to implement if you have Enterprise Edition and you need this protection for PCI, HIPAA, or some other regulation.

  • Disabling DDL Triggers

    Suppose you want to stop using a DDL trigger for a short period of time, such as the login trigger I created recently. If you want to disable an index, you use

    ALTER INDEX xxx DISABLE

    That doesn’t work for triggers. The ALTER TRIGGER syntax is used for changing code.

    You could use ALTER TABLE on DML triggers, but not for DDL triggers. The DISABLE TRIGGER DDL can be used.

    To stop tracking user logins, I can use:

    DISABLE TRIGGER CatchLogins ON ALL Server
    ;
    

    There is an ENABLE TRIGGER syntax as well to turn the triggers back on. These two commands allow you to save the trigger code, but have it enabled or disabled as needed.

  • Removing a DDL Trigger

    In a recent post I talked about how to create a DDL trigger. You’d think to drop that trigger, I’d run this:

    DROP trigger CatchLogins

    That returns me this nice message:

    Msg 3701, Level 11, State 5, Line 1

    Cannot drop the trigger ‘CatchLogins’, because it does not exist or you do not have permission.

    I was logged in as a sysadmin, and I’d created the trigger in the same session, so it doesn’t make sense.

    Instead you need to add a little phrase:

    DROP trigger CatchLogins
     ON ALL SERVER
    ;
    

    Then you get the wonderful

    Command(s) completed successfully.

  • Identity Insert and Table Variables – CONNECT issue

    I was running some code the other day and was surprised by the result.

    DECLARE @tmp TABLE (myID INT IDENTITY,MyChar VARCHAR(200))
    
    INSERT INTO @tmp(MyChar) Values('Apple')
    INSERT INTO @tmp(MyChar) Values('Peach')
    INSERT INTO @tmp(MyChar) Values('Pear')
    
    DELETE FROM @tmp WHERE myID = 2
    
    SET IDENTITY_INSERT @tmp ON
    
    INSERT INTO @tmp(MyID, MyChar) Values(2,'Banana')
    
    SELECT * FROM @tmp

    My result?

    Msg 102, Level 15, State 1, Line 9

    Incorrect syntax near
    ‘@tmp’.

    Line 9 is the SET IDENTITY_INSERT statement.

    I can understand why this is an issue. If you set this on a table variable, you could cause problems in other parts of the DB, since this can only be set on one table, but perhaps that’s not a huge issue? I don’t know, but either the functionality or documentation is wrong.

    I submitted this on Connect. Vote if you agree.