Author: way0utwest

  • SQL Nexus

    I was lucky enough to be accepted to speak at SQL Nexus in Copenhagen and I attended the event a few weeks ago. This is the new Nordic SQL conference that seems to be replacing the SQL Rally. I’d never been to Denmark, but the trip was easy, and I had no problem getting from the airport to the area downtown where the event was held. Surprisingly (for me) everyone I met spoke English, which was nice, considering I didn’t even know how to pronounce many words, including the train station I was trying to get to.

    Being on the water, the speaker dinner was appropriate and quite enjoyable. I’ve had some good ones, but I think this was the best of them all.

    Photo May 02, 12 16 50 PM

    The event was held in a movie theater, which I think is very interesting. The spaces were large, theater style room with big screens. Our computers were hooked to the projectors, which worked well. You can see the keynote in the IMAX room below.

    Photo May 03, 8 59 10 AM

    The keynote was interesting, from Joseph Sirosh (Microsoft) and Troels Peterson (physicist at the Neils Bohr Institute). The same keynote from Joseph was at SQL Bits, but I don’t think Dr. Peterson went over to the UK. I want to write on Joseph’s a little later, so I’ll just take a few moments and show some highlights of how data is managed at the Cern Hadron collider.

    Dr. Peterson works with the ATLAS detector. He had a few nice stats on the hardware.

    Photo May 03, 10 24 59 AM

    If you do some math here, you’ll see that when they run the detector and conduct an experiment they produce a lot of data. In fact, this was the next slide:

    Photo May 03, 10 34 21 AM

    That’s serious data. It was interesting that he said that’s an unmanageable amount of data. In fact, they need sensors to make decisions on the raw data because they can’t even use computers to analyze this level of information. However, they do have computers. In fact, they have:

    • 1127 racks
    • 10,070 servers
    • 17, 259 processors
    • 90, 948 cores
    • 75,718 disks
    • 113, 852 TiB raw disk
    • 312 TiB of memory capacity.
    • 120 tape drives
    • 52000 tape catridges
    • 75 PiB data on tape.

    In all their analysis, searching for the secrets of the universe, they’ve learned a lot and gotten better at finding anomalies and problems with data. They know all their data is flawed, so they must use algorithms to try and find the data they can rely on in the entire lake of bits that is captured and stored. They use a lot of machine learning to comb through data.

    In fact, he said their research actually showed that there was a reason certain data was altered in line with the phase of the moon. In fact, Dr. Peterson said that they determined that the length of the collider tunnel actually lengthened by 1mm because of the moon.

    There were lots of other interesting SQL Server 2016 talks, including the ones you’d expect on machine learning, R, one on IoT (a bit of a wreck of a talk) and a great one showing MitM and other attacks against a SQL Server from a Linux machine.

    The event was two days long. I spoke on encryption and security changes in SQL Server 2016 that went well. I’ll do some writing on my demos, showing more Always Encrypted, RLS, Dynamic Data Masking, and more.

    The theater was right next to the river, with a nice walkway. A few of us were able to run alongside in the morning. Plenty of people walked or biked along the river each day, and the weather was amazing.

    Photo May 03, 10 04 04 AM

    I think this was a really nice conference, at a good cost for those of you in Europe. If you can get to Copenhagen, it might be worth the two (or three days with a pre-con) to try SQL Nexus next year. I’m hoping they do the event again next year and I’d certainly like to go if I can.

  • Testing T-SQL Made Easy

    Abstract:

    Everyone tests that code, but most people run a query, execute a procedure and run another query. This ad hoc, non-repeatable testing isn’t reliable, and encourages regression bugs. In this session you will learn how to begin introducing testing into your development process using the proven tSQLt framework. You’ll run tests with a click of a button, using an ever growing test suite that improves code quality. You will see how to handle test data, exceptions, and edge cases.

    Level: 200 (I am assuming you know something about unit testing and tSQLt)

    Demos:

    • Creating exceptions to standards
    • Catching changes to large tables
    • Ensuring the join works correctly
    • Testing Getdate()
    • Isolating functions and stored procedures from other calls
    • Checking boundary conditions

    Downloads:

    Powerpoint: Testing T-SQL Made Easy.pptx

    Code: .zip file or Github repo

    Presentations

    • SQL Bits XV – May 7, 2016
  • Back Home, Despite a Scare

    I’ve spent the last 11 days traveling in Europe, returning home late yesterday. It wasn’t a holiday or even corporate boondoggle as this was 3 cities, 2 events at which I spoke, travel in planes, trains, and automobiles, a minor sinus infection, and movement across 6 hotels. All with just this luggage:

    13087787_10209272872407736_4048621762789380628_n

    Packed too full, and heavy, but I made it.

    I returned late afternoon and in between spending time with family, I booted up my desktop and was surprised to find that Dropbox gave me an error. As I dug in, one of my SSDs wasn’t visible in Windows, containing VMs, my local DropBox folders and a few other things. Not what I wanted to deal with the first night back.

    I shut down the system and rechecked connections this morning, then rebooted to find things working, but it was a good reminder to double check my backups and ensure that I’ve got copies of data in case I do lose an SSD.

  • Solving Tempdb Issues

    While reading Remus Rusanu’s piece on SQL Server 2016 development, there was an item that struck me. There’s a part of the piece where he notes that an engineer at Microsoft realized that there was a tempdb issue with Azure SQL Database. To solve it, a failover was needed, which could be problematic. The basic issue was that tempdb files were sized unequally, discovered after “months of investigation.”

    Now, on one hand this seems silly. After all, we’ve known since SQL Server 2005 that the guidance was for all files to be sized the same. Shouldn’t engineers at Microsoft be following all the practices  known for optimizing SQL Server performance? I think all Microsoft people should follow this, especially those working on other products (*cough* Sharepoint *cough*), but at the very least SQL Server engineers should have a huge list, perhaps with PBM or unit tests, that warn about non-compliance.

    On the other hand, since we’ve known this is an issue since SQL Server 2005, why does SQL Server allow this? I’d think some simple tooling and a few checks in code could eliminate this as an issue in any new install. Catch the issue during upgrades and grow (or shrink) files to be the same size, or at least warn the administrator. I know there are situations where you need to add a new file in an emergency, but shouldn’t this be an item we push administrators to correct quickly after the emergency is past? Or at least force them to consciously make an exception.

    There are plenty of limitations and restrictions in SQL Server systems that Microsoft forces on us. We have limits on where new features can be used, various historical limits on function parameters, and more. Why not also just enforce limits that prevent issues like this? I’m sure people will complain, but wouldn’t those complaints be outweighed by less issues overall from all customers?

    Steve Jones

    The Voice of the DBA Podcast

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