Voice of the DBA

Author: way0utwest

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.
October 19, 2016
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:

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

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.

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

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:

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

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.

October 18, 2016
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.

October 18, 2016
Webinar: Database Deployment with Git, Jenkins, and Octopus Deploy

I’ve got a webinar later today that looks at how Redgate Software’s DLM Automation and other SQL Toolbelt tools can be used to smoothly move development changes from one database to another.

Sign up and spend an hour with me this morning.

This is part of a monthly series that Redgate is running, where we’re changing the platform out every month. In this case, I’m going to use a git as my VCS, storing changes in there as I make them to a database.

From there, I will push the changes to a remote git repo and have Jenkins automatically pick up the changes and build, test, and deploy the changes to another database. I’ll make table changes, data changes, proc changes, anything you want. Just ask.

However, that’s not all. From there, we’ll see Octopus Deploy take a package of changes and deploy them out to other environments, letting my manage and track the process with the click of a button.

I’ve been doing this demos for a few years, across multiple platforms, but never on Jenkins. However, I’m amazed that things work as smoothly here as they do with TeamCity or VSTS.

Building software is building software, including database software.

If you’ve got some time today, join me and see how easy this can be.

Sign up and see database changes made live.

October 18, 2016