Author: way0utwest

  • Restore to a point in time–#SQLNewBlogger

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers. This is also a part of a basic series on git and how to use it.

    One of the things I had to show recently was a restore to a point in time, and I needed to actually lookup syntax. That’s a good excuse for a #SQLNewBlogger post, so here we go.

    When you restore, the default is to restore to the end of the backup file, whether full, diff, or log. In the latter, you have the option to stop early, and only restore part of the log. In doing this, you have two choices:

    • restore to a time
    • restore to a marked transaction

    Relatively few of us use marked transactions, but they can be useful. However, this post looks at time.

    Let’s do a few things and show how this works.

    Setup

    The first thing I need to do is get a database, with some data. I’ll create a database, add a table with a row, and then back up the database.

    CREATE DATABASE RestoreTime;
    GO
    USE RestoreTime
    GO
    CREATE TABLE BackupLog
    ( logdate DATETIME2 DEFAULT SYSDATETIME()
    , logmessage VARCHAR(200)
    )
    -- add a message
    INSERT dbo.BackupLog
            ( logdate, logmessage )
        VALUES ( SYSDATETIME(), '1st Log, before a backup' )
    GO
    BACKUP DATABASE RestoreTime TO disk = 'RestoreTime.bak'
    GO

    Next we want to add some data to the table and get some log records. In this case, I’ll use a simple loop to add a new row to the table every second. This gives me some points in time to look for and use to show I  am restoring to a point in time.

    DECLARE @seconds INT = 10,
            @starttime DATETIME2 = SYSDATETIME();
    
    WHILE (SYSDATETIME() < DATEADD( SECOND, @seconds, @starttime))
     BEGIN
      INSERT dbo.BackupLog
            ( logdate, logmessage )
        VALUES ( SYSDATETIME(), 'Log record entered at ' + CAST(SYSDATETIME() AS VARCHAR(30)) )
      WAITFOR DELAY '00:00:01'
     END
    
    GO
    BACKUP LOG RestoreTime TO DISK = 'RestoreTime.trn'
    GO

    I’ve added data, and my table looks like this:

    2017-05-23 15_23_12-SQLQuery8.sql - (local)_SQL2016.RestoreTime (PLATO_Steve (57))_ - Microsoft SQL

    My log backup contains all these records. If I restore the full backup and log now, by default I’ll end up in this state, with all these rows in my table. However, what if I want to only get the first 5?

    I can use the STOPAT syntax in my restore. I start by restoring the full with NORECOVERY and then the log. However, in the log, I’ll choose a time that is after row 5, but before 6. In this case, that’s 2017-05-23T15:22:57. Here’s the code:

    USE master
    GO
    RESTORE DATABASE RestoreTime FROM DISK = 'RestoreTime.bak' WITH NORECOVERY, replace
    GO
    RESTORE LOG RestoreTime FROM DISK = 'RestoreTime.trn' WITH RECOVERY, STOPAT = '2017-05-23T15:22:57'
    GO
    USE RestoreTime
    GO
    SELECT 
     *
     FROM dbo.BackupLog

    I have my results below

    2017-05-23 15_31_10-SQLQuery8.sql - (local)_SQL2016.RestoreTime (PLATO_Steve (57))_ - Microsoft SQL

    Only the log activity before this time is restored.

    SQLNewBlogger

    After I’d looked up the syntax, I spent only about 10 minutes setting up the demo and getting this ready. Practice skills and write about it. Show your next employer you are always learning and working.

  • Audio Attacks

    There are running jokes about how Amazon Alexa and Google Home are susceptible to visitors in your home. It’s become a bit of test from some geeks who will walk in your house and call “Hey, Alexa” out loud to see if you have a device that’s available. I even had an accidental Siri activation while recording some content recently. I said something that started Siri listening on my phone and then a few people nearby kept trying to duplicate the effort. Fortunately Siri wouldn’t come on, so no one was able to cause too much trouble. I suspect that the speakers in the recording room weren’t positioned well enough to allow the control room based hacking.

    I know that will change. In fact, even if Apple and other companies manage to get digital assistants to recognize specific people’s voices (as rumored), technology marches on. People are already starting to fake audio data. The fidelity of digital recording and capabilities of speakers improve constantly. This is going to be a greater and greater issue over time, and I have no idea what security technique will prevent things. Maybe we need two factor authentication for audio commands? Won’t that defeat the purpose?

    As data professionals, we are going to be dealing with more and more types of data, and trying to process, analyze, and act on information. This is one reason that I think understanding data lakes and being able to import and combine many types and formats of data will be a valuable skill for all data professionals. Whether you use something like Azure Data Lake or another platform, I expect to be combining data in all sorts of ways and providing information to users.

    While speech recognition might not be something many of us worry about, will we want to extract information from audio or video and use it? Do we expect that audio files have more integrity than other sources? I worry that we give some types of data more veracity than others, when all types are subject to hacking. Some of us may get audio files as data, and it’s only a matter of time before we get hacked, perhaps with fake audio.

    One of the issues we have with some data is determining the source of record. If I record my voice as a sample, and you compare all future audio of me to that sample, you can verify my identity, right? What if someone can fake my voice with simple software? It sounds crazy, but those days are coming, especially if our systems are susceptible to a person stitching together words from different captures, such as some of Baracksdubs. What might be worse is when we find someone hacking a database and replacing the samples. What’s the source of record then?

    As I spend more time in this business, I become more convinced that auditing and monitoring are more important that security. We want them all, but I’d rather know I have an issue than assume my systems are protected because the security doesn’t appear to be broken.

    Steve Jones

     

  • Looking Back at Build–CosmosDB

    Part of a series looking back at Build 2017, going over the 20+ pages of notes I took.

    One of the big announcements at Build 2017 was the release of CosmosDB. This is a rebranding of DocumentDB, the document store in Azure, with some additional capabilities. You can also choose to store as

    • Column-family (columnar)
    • Key-Value
    • Graph

    The service is interesting in that it supports the MondoDB and Gremlin protocols for querying, which should allow some people to consider Azure instead of those platforms. The announcement was interesting from the data perspective. Microsoft focused a decent amount of time on this platform, and certainly people at the conference were very interested in the offering. Quite a few developers were thinking this would replace SQL Server, since it has some nice capabilities.

    One of the big ones is that CosmosDB offers < 10ms latency for reads and < 15ms for writes. They scale up to millions of transactions/sec, and also grow to PBs in size. There are some good guarantees for the database.

    They call it infinite, but that’s a marketing term. There’s a limit, and there certainly may be a limit you’re willing to store in the service. Jet.com was the featured customer and they talked about how much data they used and how they can scale the platform. I’m sure they went with DocumentDB and moved over, but they have their story in the keynote, if you want to watch. They get over 100 trillion, yes trillion, CosmosDB transactions/day. No matter what you do, a trillion of anything is a lot.

    Perhaps the more interesting thing is that Azure is offering five different consistency models in CosmosDB. They are

    • Strong
    • Bound Staleness
    • Session
    • Consistent Prefix
    • Eventual

    I don’t know how well these are supported in other platforms, but I like to see that developers have a choice. I’m not sure how many will understand the trade-offs and implications, and how many will get burned by choosing one over the others, but I’m glad the choice exists.

    They are also saying a money back guarantee. What that means, or how you get money back, is going to be something to see. I haven’t always been thrilled with the disclosure in billing for new parts of Azure services, but perhaps there is going to be some way to request credit, though I would hope that any telemetry that shows issues results in some credit.

    The other good thing is that the SLA is guaranteed across multiple dimensions: latency, throughput, availability, and consistency.

    Rimme Nehme, who demo’d the product, had an interesting quote. It was something like “developers can concentrate on the app, not the database.” Forgive me if I’ve slightly misquoted as I’m going from notes. While I cringe a bit as a data person, I do know that most developers don’t want to really work deep in the database, especially for many simple apps. If I were building some simple mobile app, I’d seriously look at CosmosDB, and I plan to learn a bit about it.

  • The History of the World, I Guess

    The lighter side. From my kids, and since there’s some science and it reminded me of the Big Bang Theory.

    Have fun.