Voice of the DBA

Author: way0utwest

  • Fun and Contests at Summit 2016

    I’ll be attending the 2016 Pass Summit as a part of the Redgate Software crew. I’m not speaking this year, so most of my time will be at the Redgate booth, showing you a few tricks and tips with products and maybe convincing you that we can help your company produce software just a little bit better.

    As a part of the Redgate experience this year, we have a few fun contests for you, an amazing new product, and a party as well. First, the contests.

    Win Coffee

    Many of us like coffee. Even if you don’t, I bet someone in your life does. Redgate is giving you that chance to win Death Wish Coffee. In fact, you can win a year’s supply. Just the thing to help you get through those longs weeks at work.

    Come by the Redgate booth and learn the answers to a few questions. Then enter online.

    Oh year, you’ll also win a SQL Toolbelt + support.

    Win a GoPro Hero 5 Session

    We have a difference flyer that you can fill out and return to win a GoPro Hero 5 Session. That’s a neat little camera that looks like a lot of fun. In fact, maybe I need to get one of these for some mini movies in my life.

    SQL Clone

    I’m excited about SQL Clone. In fact, I saw a demo, using mocked up basic PoSh over a year ago and I knew this was a great idea. It’s finally coming to fruition, with a beta release next month (Nov 2016).

    However, Grant is presenting a session SQL Clone on Thursday, Oct 27, at 3:15pm. Come see this talk and learn why I think this will really help with database development (and other tasks).

    Redgate Rocks

    Thursday night, Oct 27,  Redgate Software is hosting a party. This will be from 7:30-10:30 at 1927 Events on 3rd Ave. With drinks and snacks, this will be a fun time and  a good chance to unwind and chat with colleagues.

    You’ll need a wristband to attend, so be sure to stop by the Redgate booth and pick one up.

    Follow @redgate

    We’re on twitter as @redgate, and we’ll be posting updates during the week, so keep in touch with us and hope to see you next week.

  • One Million

    Is a million writes/sec a large number? I guess it’s all relative, but I’d consider it a fairly large number. Our peak transfers for SQLServerCentral are in the hundreds/sec, though we’re not really a busy database server. Some of you might have much higher numbers, and if you’re in the 100,000/sec and can let us know, I’m sure others would be interested in hearing about your experiences.

    I ran across a piece on the Uber database infrastructure that I found impressive. No, Uber doesn’t use SQL Server (they use Cassandra), but they have worked to build a large scale infrastructure. Their goals:

    • 1 in 100,000 requests can fail
    • 1,000,000 writes/sec
    • > 100,000 reads/sec

    Those are quite impressive. While I’m not sure they’ve ever achieved these levels in production, I’m glad they’re testing at these points. I think far too many people forget to test the limits of where there systems might grow and only stick with where they are today. Or where they were a month ago when they refreshed a test environment from production. Test at larger than production levels, at least once in awhile.

    There’s something impressive with one million. Getting to a MB, roughly 1mm bytes, was impressive to me. Not such a big deal now (with pictures requiring > 1MB), but 1mm MB is a terabyte, and while I carry that in my pocket, it’s still an impressive size. Crossing one million members at SQLServerCentral was impressive. I think $1mm is a lot of money. One in a million still seems like a very small chance of an event. At the recent Data Science Summit, we see SQL Server scoring over 1mm fraud predictions/sec.

    Achieving 1mm of anything in a database system is still a large number. I know many people have tables with over a billion rows, but I’d still say a million is large. Perhaps you disagree, but I’m still a little awed at seeing SQL Server process a query of 1mm rows in less than a second.

    Steve Jones

    The Voice of the DBA Podcast

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

  • DB CI: Getting Test Results in VSTS

    One of the things I struggled with a bit was getting test results to appear in VSTS from my builds.

    Here’s my original Build flow:

    2016-10-07 10_50_32-Microsoft Visual Studio Team Services

    However, when I’d run a build, I got this in the Build summary:

    2016-10-07 10_51_43-Microsoft Visual Studio Team Services

    That’s not great, and I knew this could work better, so I started to look at where my test results were. Here’s what I did to get the results to appear.

    I added a Publish Test Results task to the end. This is in the “Test” section of the Task catalog.

    2016-10-07 10_39_11-Microsoft Visual Studio Team Services

    When I looked in the output of the build tasks, I found these files:

    2016-10-07 10_31_41-s

    I kept thinking I needed to get the .trx file to load, but that wasn’t correct. I really wanted the “*reports.junit.xml” file. After a little experimenting, I configured the task like this:

    2016-10-07 10_40_33-Microsoft Visual Studio Team Services

    Once I saved this (with a comment), and ran a new build, I could see test results.

    2016-10-07 10_31_50-Microsoft Visual Studio Team Services

    I could have just read the XML file in my build result folder, but that’s a pain. Typically we don’t care unless there is a failed test, but when there is, it’s nice to see what actually failed.

    Plus, having the results in the console means I can show the other developers and management that tests are being run and are checking code.

  • Archaic Commands

    I was watching the San Diego Technology Immersion Group meeting in September, and found myself transported back into the past. This month was the first meeting of the Linux chapter, spending a few months working through The Linux Command Line.

    Watching from home, I watched the hosts walking through the command line in Linux, showcasing various basic file comments. Seeing them explain and execute commands like ls, rm, alias, cat, tail, less, and other commands in a text session reminded me of learning Unix at university on SunOS. Slowly various bits of knowledge came back to me from my own experiments learning how to work with files, full of text data, interspaced with my regular visits to the “man” pages when something didn’t work. In fact, seeing the man pages come up on the YouTube session made me smile.

    It’s funny to think how much the world has changed. Even now, I have an Ubuntu VM that I run at times, but it’s mostly a GUI shell, and my interactions with the command line are fairly minimal. That’s completely the opposite of my time at university and my first job where I pretty much lived in the command line. My code editors were vi and emacs that I ran across a dozen X Windows sessions open on various machines in the college computer lab. My interactions were really working with text and text commands. Even now, I might use SSMS and Visual Studio, but I’ll pop into a command line to check my git repo or spend time playing with PowerShell and executing commands in text sessions. While working with Python I’m as likely to use the REPL from a command window as I am to use an editor like VS or PyCharm. I really just like the interaction of the command line.

    Not everyone feels that way, and that’s fine. I agree that GUI based systems are more convenient at times. In fact, I often use various GUI items in SSMS build up a task, such as an Extended Events session, and then script the result to give me code that I can execute. GUIs do some things extremely well, but allowing for repeatability is not one of them. They can also easily hide the actual commands and defaults being executed.

    I think everyone working in technology needs to have some skill in working with a command line. Even if you want to use T-SQL to script all your tasks, you should be familiar enough with something like SQLCMD to execute a script in case you run into a situation where SSMS might not work. This might be especially true as you learn to automate more of the work your systems require and perhaps execute these scripts through other tools, like an Enterprise scheduler.

    If nothing else, the command line teaches you how to work in a methodical, step by step process. However, I’d argue it develops new skills that might lead you to do solve a problem in more creative ways. Perhaps you’ll even grow to use a command line language like PowerShell to accomplish some repeatable task. You might find it works better than the old way you used to work.

    Steve Jones

    The Voice of the DBA Podcast

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