Voice of the DBA

Author: way0utwest

  • Manual v Automation

    I’ve got my work cut out for me. This week is SQL in the City 2017. One of the sessions I need to present is a Manual DBA database deployment against an automated CI/CD process with the Redgate tools.

    To give our automated DBA a chance, I’ll be playing the role of the manual DBA, which means I’ll need all my typing skills and experience to try and quickly get code moved from one instance to the next.

    I don’t have a lot of confidence I’ll be faster, but I do know I can do the deployment. Or at least, I know I have done plenty of manual deployments in my career that have worked. I know how to script out changes, check them, and be sure they get executed in the right order on the next instance.

    However.

    I’ve also made plenty of mistakes, even with simple changes. I’ve learned that while I know what to do, I don’t always do what I should. Fortunately I know how to fix things quickly. Patching live in production. Always a good idea, right?

    We’ll see.

    We’re broadcasting a virtual SQL in the City this year, on December 14/15. The same content is both days, spread out to cover different time zones on each day. I hope you’ll join us and see what Redgate has in store for 2017.

  • The Five Year Plan

    This editorial was originally published on June 13, 2013. It is being re-run today as Steve is traveling.

    IT departments won’t exist in five years. A bold prediction from the CITE conference last week. It’s not so much a prediction of an increase in cloud services, but more the idea that the centralized IT department is struggling with the consumerization of technology, the increasing demands of the business for faster turnaround on projects and prototypes, and the flexibility being demanded by an increasingly technology savvy workforce.

    Like most predictions, I take this one with a grain of salt. I don’t think five years is enough time to change the face of the enterprise IT groups. Five years ago the first iPhone had been out for a year and was being demanded by users to replace their Blackberries. These days many corporations support iPhones, along with other smartphones, and Blackberries have disappeared from many organizations. However IT has adapted, released some of their control, and even integrated some of their policies into new technologies. When I enabled corporate mail on my smartphone recently, I had to allow some remote management features to get mail, which was fine with me.

    I do agree that we will start to see some of our IT functions, especially small projects and POC (proof of concepts) increasingly being driven in departments. There are too many projects, too many different technologies, and too little time to work on them for central IT departments to tackle all these projects. Departmental management won’t wait for IT that is stretched too thin, especially if they have existing staff that have some technology skills. That latter factor is something becoming more and more common all the time.

    However I can’t see central IT disappearing. There are often quite a few systems that are complex, that are too large, too important to let someone manage part time. There are projects that cross departments, or even the entire company, and coordinating tasks and resources between departments is complex. Add to all of this the problems and hassles of hiring good technology people, and I can see projects rising in departments, but being turned over at times to IT to manage.

    I do think that central IT groups need to be more flexible, and reduce some of their rules, or adapt them to new technologies and platforms. I expect people working in central staff to be “lent” to departments for projects, perhaps even multiple departments at the same time to help get projects completed, while also gaining some training on the various systems in order to provide support when other staff isn’t available. Such as weekends.

    Steve Jones

     

  • SQLBits 2017 In April

    I’m getting excited, with the announcement that SQL Bits 2017 is scheduled. The conference goes back to Telford, which I enjoyed and takes place April 5-8, 2017. 

    I’m getting my presentations ready for submission, and I really hope I get the chance to speak again. This is a fun event, and one I try not to ever miss.

    Registration opens soon, and the schedule should be out early in 2017, so start planning your trip today. 

  • Faster Versions and More Support

    When I started working with SQL Server, the versions came a strange paces. Three years between v4.2 and v6.0, but less than 1 before v6.5. Then two years to v7, one more to SQL Server 2000, but five until SQL Server 2005. After SQL Server 2008, we’ve moved to a 2-3 year cycle, but I can see that accelerating a bit more as SQL Server vNext looks like it might come in 2017, a year after SQL Server 2016. Since much of the code is released to Azure first and exercised there, I could see us getting on premise releases coming every 1-2 years in the future.
    Overall, I like this pace. We can see changes coming to the product on a regular basis and enhancements that I can choose to implement or not. We no longer have to wait years to get an enhancement or evolution of a feature. We always have the choice to upgrade. Many of us won’t, but that’s OK. Perhaps we’ll use new features in new applications, and learn how they might make the case to, or not to, upgrade existing instances.
    There’s a flip side to the rapid releases and enhancements to the platform. Many of our organizations expect a database server to last for years. We invest plenty of resources in building these database servers, and I think many managers and organizations expect they will be in service for at least five, and maybe ten, years or more before they are decommissioned or perhaps upgraded. I know there are still plenty of SQL Server 2005 and 2008 instances (probably not 2000) that are being used on a daily basis with no plans to replace them.
    This means that as the developers and DBAs that work with SQL Server, we will likely be supporting a wide range of versions in the future than ever before. Even if you started a company two years ago with a SQL Server 2014 instance, I’d guess you might have a few more now, perhaps some SQL Server 2016 instances. In two years you might have 2014, 2016, and 2017 (assuming vNext becomes SQL Server 2017). In five years, perhaps you’ll have five versions to support. I know there are people in that situation today with 2014/2012/2008R2/2008/2005 instances in production.
    There was an announcement this week from Microsoft. They are now offering SQL Server Premium Assurance, which will give you 6 years of support after the 10 you ca now get with Extended support. Certainly there are restrictions and costs, but I expect that there will be some large organization that think it’s worth paying this to continue to use older versions as long as possible. After all, this is a platform, which implies some level of stability.
    That doesn’t solve the knowledge issue and need to keep staff around that understand the platform, but with all the education and knowledge available from places like SQLServerCentral, perhaps supporting multiple versions isn’t a bit deal.
    Steve Jones