Tag: syndicated

  • 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.

  • Pensacola in June–SQL Saturday #491

    One June 5, I’ll be back in Pensacola, FL for SQL Saturday #491. It’s been a few years since there was a conference in the area, and I’m excited to go back. I really like the area, and am looking forward to visiting for a few days.

    I’ll be presenting my dive into Always Encrypted in SQL Server 2016. I presented this in Phoenix recently and the session was well received. I like this feature, but there are some caveats and gotchas, as well as various items you should consider before making the decision to implement it. Hopefully I’ll see a few of you there and you’ll enjoy the talk.

    However if you’re nearby, there are pre-conference sessions on both Thursday and Friday that you can attend. Both are inexpensive training and the chance for you to quickly improve some data skills.

    There are lots of great sessions from other speakers, and Pensacola is a great place to spend a weekend. Lovely beaches, not too large, not too expensive, and a beautiful area in June. If you’re anywhere from Houston to Florida to Tennessee, consider combining a little learning with a vacation on the gulf coast.

  • Another Day, Another City

    After a few days in Copenhagen for SQL Nexus, I traveled to London late last night, and am now making my way to Liverpool for SQL Bits. A hectic schedule, leaving one city, flying to another, a few hours sleep and moving again today.

    It’s exciting to be heading back to SQL Bits again, as it’s my favorite conference, and I am looking forward to seeing people from all over the world that I’ve become friends with across the years. Plus it will be fun to see all the costumes at Friday night’s space themed party.

    I’ve got two sessions to deliver. A lunchtime session on version control Friday and then a testing talk Saturday.

    Between now and then, some final rehearsals, and hopefully an hour or two at the Beatles museum.

  • Explicitly using tempdb with ##tables

    I had someone ask me last night if this statement would create a permanent table in tempdb with a strange name or a global temp table:

    CREATE TABLE tempdb..##mytable
    ( id int
    );

    My suspicion was that this would always be a temp table, but since I usually don’t include tempdb, I decided to test things. I quickly opened up SSMS and tried it. I got this message:

    2016-04-21 13_55_14-Microsoft Solitaire Collection

    That seems to imply what I suspected. The ## override everything and determine the table type. When I look in the list of tables, I see my table there as a temporary one.

    2016-04-21 13_56_21-Start

    This is the behavior I’d expect, and it acts the same in SQL 2012, 2014, and 2016 (RC2).

    I don’t think there’s an advantage to using tempdb..##mytable, or even creating a permanent table (until restart) using tempdb.dbo.mytable, but if there is, please note something in the comments.