Category: Editorial

  • The End of Support

    With the accelerating pace of development and more frequent releases, we are seeing a bunching up of SQL Server support milestones. From 2008 through 2016, we had a new version every two years. Last year we saw another version, which means 5 versions in a ten year span. With 5 years of main support and 5 of security patches + extended support, Microsoft has quite a few active branches of code.

    We now see SQL Server 2008 and R2 coming to the end of support on July 8, 2019. There are plenty of options for customers, including doing nothing. After all, if you’ve been running SQL Server 2005 or even 2000, you’ve been without support for some time. That might not be a policy of your organization, particularly if you adhere to any standards or are bound by regulation. In those cases, you may need to have active support under contract.

    There is a good argument to be made that you should have active support for your core systems, such as the OS or your database platform. If a bug or security issue is discovered, would you want to upgrade on a very short timeline or apply a patch to your existing version? Think about running SQL Server 2008 today and a critical security problem is discovered in October. Do you want to upgrade to SQL Server 201x this year? Or would you wish that you would have planned and executed an upgrade in June and have to apply a GDR patch in October?

    I tend to view patches as much lower risk than an upgrade, mostly because the number of changes is smaller, and an upgrade reduces my options, not to mention often increases my costs. That might change over time, as I upgrade other instances and gain experience with a new version. SQL Server 2017 still feels new to me, but SQL Server 2014 and SQL Server 2016 feel older. If I had to perform an emergency upgrade to an instance, I’d be more comfortable moving from 2008 to 2016 than 2017 right now.

    I wonder how many of you view the upgrades as more risky? These days the migration tools analyze for keyword issues, and many of those can be alleviated with compatibility levels. Perhaps some of you aren’t worried and will run your SQL Server 2008 instances until they die, only upgrading if forced. If so, let us know.

    If you’ve got R2 instances, however, please get rid of them. The sooner we get rid of this horribly confusing version name, the better.

    One late note, after this was written, Microsoft offer to add additional extended support if you migrate to Azure.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Age of Multiple Databases

    I can still remember learning to store data in files, reading one record at a time, testing for end of lines and end of files. It was slow and cumbersome, but for a teenager, it was amazing. We built applications that could help run Dungeon and Dragons games, and the ability to store information about our games was amazing. I even adapted some of these routines to store data about various chemistry experiments in school, making my report writing (and data fudging) must easier.

    In time I stumbled upon the basic database structure of dBase, thinking this was vastly superior. I could control the structure of each table, but have the power of quick access and indexes. Of course, I learned to make sure I opened all the indexes with the data file, otherwise I might “lose” some data over time.

    Those first database structures felt great, and even superior to SQL Server when it was just one person. Initial queries were much quicker under dBase type applications (Clipper, FoxPro, etc) than under SQL Server, though that quickly changed as the number of users grew. For the last two decades, I’ve been entranced and thrilled with the power of relational systems. They solve many problems well, and I find them fairly easy to develop against.

    Not everyone feels the same, and there have been many different types of data stores built in the last decade, each designed to solve different types of problems. I ran across a post about the different specialty databases available in AWS from Werner Vogels, Amazon’s CTO. The piece is interesting as he notes that one type of database can’t meet all the needs of modern applications, at least, it can’t meet the needs of very large scale systems like Amazon’s eCommerce site. Instead, there are situations and problems better solved by specialty systems.

    Amazon built a key-value, extremely fast database to back a system that mostly needed those types of simple lookups. Over the years, in response to their needs or those of their customers, they’ve added other types of databases in their AWS cloud. Mr. Vogels lists six databases in AWS, including relational stores. He talks a bit about where each can be used. He also cites some customers that have had success in different applications with different data stores.

    Microsoft has done similar things in Azure and their data platform. Most of us know SQL Server as the relational engine, but we have an in-memory component and with 2017, we also get graph capabilities, albeit rudimentary ones. In Azure, they have CosmosDB, which include a number of different types of data stores (key-value, document, graph, etc.). I know Google has multiple databases available as well.

    As we build larger systems that reach out to more people, I wonder sometimes if we ought to be architecting to use multiple data stores from the beginning, choosing the type that works best for the problem and not choosing to just use one database for all parts of an application. I already have some customers that supplement their SQL Server with Redis, Elastisearch, AWS or Azure queues, cloud storage buckets/containers, and more.

    I’m a practical person, who likes to pick the solution that works well for the problem I need to solve. I have no issue with using multiple technologies, and as my career as advanced, I think it’s easier than ever to do so. If you haven’t considered other data stores, perhaps you want to learn a bit about them and see if they could help improve your system. Keeping an open mind and considering alternatives is good, and I recommend it. What I don’t think you should do is choose another technology because you like it or are interested in learning more about it. Pick the solution that works best.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The MVP Award Looks Backward

    I was awarded the Microsoft Data Platform MVP designation in July 2018. I’ve been honored to receive this designation since 2008, though the award doesn’t drive my work. I started writing articles to help others get better with their work, just as I got help from others before me. That was the goal of SQLServerCentral, and I’m proud whenever I hear that I’ve been able to help someone solve a problem, learn a new skill, or improve their career in some way.

    Microsoft has an MVP site, and they describe the people they recognize in this way: “Microsoft Most Valuable Professionals, or MVPs, are technology experts who passionately share their knowledge with the community.” The award is for those that make efforts to help others “ranging from speaking engagements, to social media posts, to writing books, to helping others in online communities …” In other words, for those that help others, Microsoft chooses to designate some of them as MVPs for their efforts.

    Their past efforts.

    That’s the key. If you are awarded the MVP designation, then you’ve spent quite a bit of time during the previous year helping others and sharing knowledge. You could stop all your writing, speaking, etc., and you’d still be an MVP for the next year. You might not be renewed after that, but you could use the logo, attend the MVP Summit, and more during this year.

    There are budget constraints to the MVP program, just like other corporate initiatives. As a result, not every speaker, blogger, open source MS stack developer, etc. gets awarded. People get nominated, or if they’re already MVPs, they’re automatically considered for the next award period. This leads to an evaluation process where every nominee for some period is ranked in some order. I have no idea what method is used, but it’s a combination of speaking, blogging, organizing events, writing free/open source software, and likely more. There is a budget that says only xx people will be awarded, and the top xx people get picked. I really have no idea how this works, but since I’ve been a recipient of the award, this is what I’ve observed.

    Most people appreciate the award and continue to contribute to the community. Some really want to earn the award and make special efforts to ensure they make plenty of contributions. If you want to get recognized, it takes a lot of work. This is a competitive environment, with many people regularly making contributions to the community. You have to make enough to rank above the cutoff, regardless of accomplishments in prior years.

    I’m always appreciative of the award, but as I mentioned, it doesn’t drive me. I have a set of things that I do for work, and a set that I volunteer for as a part of the community. If that earns me a high enough ranking, that’s great. If it doesn’t, I’m fine with that. Ultimately my goal is to help others, and I’ll continue to do that, regardless of recognition.

    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.

  • AI Regulators

    With the GDPR now being enforced in the European Union, there are plenty of companies that are getting concerned about the potential fines from regulatory authorities if they aren’t complying with the law, or at least, making an attempt. There certainly is leeway for regulators to adjust fines or give warnings if a company is making efforts to comply. This has likely contributed to the work inside many organizations to move towards compliance.

    There are likely some companies that might not worry, since there are relatively few regulatory employees and many companies. There are lots of complaints coming in, which could easily overwhelms the relatively small staff in each EU country. Complaints might not be investigated in a timely manner or even lost because of the workload. The problem will likely get worse as more consumers complain about data processing practices. I don’t expect regulatory authority staffing to increase, so I’m sure only the most aggregious or complained about companies will get caught.

    There is one way to help amplify the capabilities of the relatively small staffs reviewing complaints. There are researchers in the EU Institute in Florence that are are working with consumer organizations to create AI programs that can help by performing some of the work. The initial thrust is to evaluate privacy policies of companies. If there are issues, the software doesn’t assess a fine, but it does alert a human to perform additional checks.

    In one sense, this is exactly what computers can do well. They amplify the capabilities of humans by doing a piece of the work. We can build systems, whether traditional programmed ones or AI based applications, that handle a piece of the work that requires lots of human labor. Once initial evaluations are made, a human can review the work and make more refined judgments.

    The danger, to me, is that humans will be lazy. They’ll start to trust the AI systems as authorities and use less of their own judgment, mostly because it’s just easier. I could see these systems evolve over time to actually train humans involuntarily. New employees would initially trust the AI results, learning from the AI rather than teaching it and constantly evaluating its effectiveness.

    I think AI can really help improve the way that we accomplish work in many ways, but it should be regularly audited and approached with some skepticism. There certainly needs to be some sort of supervisory group overseeing the program that isn’t involved in the outcome. We should be sure that the goals and results from any AI system continue to be focused on what we want to achieve, and that we transparently define those goals for anyone impacted. Otherwise we might end up having AIs evolve in ways that are counter to the original purpose.

    Steve Jones

    The Voice of the DBA Podcast

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