Voice of the DBA

Author: way0utwest

  • More than 25 Years for me

    I was surprised to see a 25 year celebration for SQL Server at Ignite recently. It was also a 25 year celebration for Bob Ward. If you haven’t met Bob or seen him speak, make an effort to do so. He does an amazing job and can likely answer most any question you pose about SQL Server. I didn’t know Bob had been at Microsoft for 25 years, but that’s an impressive milestone and I’ll congratulate him when I see him in person later this month at the SQL in the City Chicago summit (register now:code Steve).

    The surprise for me was that I installed SQL Server in 1991, which by my calculations, was 27 years ago. It was in the fall of 1991 that a corporate development department came down to our remote site and had us install a SQL Server in preparation for a new application that we’d install on Dec 31, 1991.

    However, if you read the celebration post from Amit Banerjee, you will see that he notes in 1993 SQL Server released on Windows NT. That’s true, and I remember getting a wide box of NT 3.1 Advanced Server manuals that I dutifully read since I hadn’t been thrilled with the performance and stability of SQL Server to this point.

    You see, in 1991, we installed SQL Server on OS/2 1.3, which was horribly unstable and unable to handle the load of our application. I’m not sure if the SQL Server port from Sybase was the issue or OS/2 wasn’t stable, or the hardware wasn’t sufficient. Suffice it to say that I was thrilled when we migrated in 1992 to OS/2 20 and later 2.1, which were more stable. Then I could stop working 100 hour weeks.

    Despite a poor first impression from me, I grew to really enjoy SQL Server and switched from networking and infrastructure to database work. The rest, as they say, is history.

  • Give Up on Natural Primary Keys

    There is plenty of debate over how to design your database. At SQLServerCentral we have a Stairway Series as well as a few articles that cover design topics. I think it’s important for anyone that builds tables to spend some time learning what others have done and understand the pros and cons of making different choices. It does often become hard to change designs once they are in use, so trying to choose a good entity design early is important.

    One of the things I think is important in modeling your particular entity is including a primary key (PK). In my DevOps talk I stress this, as I’d rather most attendees come away thinking a PK is important as their first takeaway from the session. There are exceptions, but they are rare, and I would prefer that most tables just have some PK included from the beginning.

    A PK ought to be stable as well, and there are plenty of written words about how to pick the PK for your particular problem domain. Often I have received the advice that natural keys are preferred over surrogate keys, and it is worth the effort to try and identify a suitable column (or set of columns) that will guarantee uniqueness. I think that’s good advice, and it’s also advice I tend to ignore.

    There’s an interesting article about keys and the GDPR. The first part is a rather basic description of what PKs are, but the second part talks about keys and some of the rights that data subjects have under the GDPR. I think these are worth considering, especially as it’s likely similar legislation will make its way into other jurisdictions, as already seen in California. The short part of the argument is that the right to be forgotten or to have your data deleted is incompatible with the use of natural keys.

    It’s an argument, though I’m not completely sure if I think it would be solid. There are valid reasons to keep some information about a user, and I suspect keeping a list of emails to delete from a database restore as a separate list would be a valid use. Even if the user asked that their information was removed. It would be, but there would also be a need to ensure that the correct data was removed,  hence a list of emails.

    The bigger problem for me is that if I needed to redact or alter this key data, which I would likely do in order to keep some integrity in my database, I’d need to alter this data in lots of tables. That makes for a much more complex set of scripts, including ensuring that I am correctly building a map of the new values I would use for a key. It’s much easier to have a surrogate key that doesn’t change and just redact the other information.

    I’m sure there are arguments both ways, but as we move towards the era of not only seeing data as valuable, but also as an asset we can’t completely control, I think surrogate keys make more sense now than ever. Let me know if you agree.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Redgate Releases Sept 2018–Practicing DevOps

    At Redgate, we build tools to help you build software in the entire DevOps cycle. In fact, I love this new graphic that shows the areas that we focus on in the entire software development cycle.

    We don’t just preach DevOps, we live it. As an example, here are the releases for September:

    SQL Monitor (Sept 11, 20) – New viewing and reporting options

    SQL Clone (Sept 11, 24, 25) – Added reset, new notifications and an EAP of the  next version!!!!

    Data Masker/Figleaf – Sept 5, 14, 25, 26 – Bug fixes for Data Masker and enhancements to Figleaf

    SQL Change Automation – Sept 19 – cmdlet updates and bug fixes

    SQL Backup – Sept 6 – import registered servers

    SQL Compare/Data Compare – Sept 3, 17, 24 – bug fixes in frequent updates releases

    SQL Prompt – Sept 12, 25 – refactor insert into updates, bug fixes

    SQL Source Control – Sept 24 – bug fixes

    SQL Test – Sept 4 – bug fixes

    SQL Index Manager – Sept 3 – bug fixes

  • The Ever Expanding Data Platform

    This past week was the 2018 Ignite conference from Microsoft, where we had a number of announcements about the data platform. You can rewatch some of the sessions from the event, and I might recommend the keynotes to see some of the demos and positioning of the data platform. That’s the direction that Microsoft is moving their database products, as a complete platform that not only includes SQL Server, but CosmosDB, Managed Instances, Data Lakes, and  more.

    If you’re a SQL Server DBA, it’s time to stop thinking yourself as a SQL Server DBA or developer. Instead, you need to be a data professional, especially on the Microsoft stack. While you might concentrate on SQL Server and live in SSMS, you ought to be aware of the growing options for working on the Microsoft stack. Azure Data Studio, which Grant wrote about this week, ought to be a tool you investigate. You also ought to be looking at the latest version of SSMS, which had it’s v18 move into a public preview this week. With these tools being free, companies ought to be moving away from the older versions that shipped with SQL Server 2014 and earlier. Instead you should at least be on a v17 version of SSMS. Talk to your IT group and give it a try today. It works fine with all your SQL Server versions, from 2005 through 2017.

    Microsoft is certainly hoping you’ll run more workloads in Azure, and that’s where the data platform is growing. CosmosDB, which I think has a lot of promise for various types problem domains, or even as a companion to SQL Server for certain types of data. There is an increase in their SLA to 5 9s, which is both impressive and ambitious. I know very few on-premises instances that get by with 5 9s across multiple years, leaving aside the ability to get 10ms write performance in the SLA. The is also multi master replication and support for the Cassandra API. While I haven’t done much with CosmosDB, it is on my radar to experiment with as a data store option.

    Managed Instances will be generally available on Oct 1, just a couple days away. While I wasn’t sure that this product would catch on, I’m not surprised that some companies would like to get away from managing most of the stuff around the database and stick with the data. To me, this, more than anything else, can mean that DBAs at larger companies need to be managing data, security, and more, without worrying too much about the basics of backups and HA. Even threat detection, something few of us are good at, is handled by Azure. The restore demo in the keynote is truly impressive. I’m not sure many of us would want to, or be able to, architect those speeds. At least not as easy as provisioning an Azure Managed Instance.

    There are lots of other announcements, which you can read. The one really interesting thing for me was the Data Box announcement. I’ve had more than a few people be concerned about the initial loads of data into an Azure database or data lake. I’ve had that concern, and actually been part of a company that FedEx shipped a rack of disks as part of a SAN to a DR site because of bandwidth constraints. The Data Box is a device that you can order and fill, shipping this back to Azure for loading. It comes in 40TB, 100TB, abd 1PB sizes. That is truly stunning to me. Drop ship 1PB if you have the need. You can even see a picture of it from Argenis Fernandez for some idea of size.

    It’s an exciting time to be a data professional, and Microsoft’s data platform continues to grow. I don’t know that any of us will know more than a tiny bit about most of the platform, but I certainly plan on increasing my knowledge in a few areas to become better aware of how they work and what they are capable of. I might not be able to use them well, but I can at least have enough knowledge to have a conversation about the technology and have an idea of whether it might solve a problem that I run into at work.

    Steve Jones