Voice of the DBA

Category: Editorial

  • The War Room

    I remember the first time I worked in a large, 10,000+ employee company, and we had a crisis with our systems. A number of us crowded into the cold computer room, gathering around a few workstations and trying to solve the issues. We worked furiously to restore service, with various managers and executives periodically knocking on the locked door wanting status updates, unaware they were slowing us down. Eventually we stabilized things, but it was a chaotic and inefficient environment with too many people involved and more time spent talking and discussing problems than solving them.

    Later I worked in a similarly sized, but more mature company. We had various virus issues, including SQL Slammer. When we realized there was a crisis, we’d contact a director who would convene a crisis team. There were designated individuals from various groups (network, security, database, etc.), each of which had a backup, but only one representative from each area was a part of the team. Those were the only people that participated in the meetings, giving status updates, or taking actions to be distributed to their team. Each was responsible for coordinating the activities of their area with others. Status updates were scheduled regularly with a specific individual posting them. The director leading the crisis would update executives.

    I thought back on these experiences (I was the main person in the database area) when I read about the Amazon war room experiences around launching one of their products. While our crisis management wasn’t quite like this, it was fairly well scripted. There were times that the process didn’t proceed smoothly, but it worked well overall for problem situations. I wish that we had handled deployments a little more formally, though not as strictly as Amazon did. Our deployments didn’t have a large an impact as a product launch, but we certainly could have used more coordination between different groups. I remember no shortage of networking/firewall issues, security mismatches, or missed communications with customers from deployments.

    I’d like to see software deployment to be an easier and simpler process. My hope is that more people learn to code better, and they implement unit tests to ensure they meet requirements and prevent regressions. I want to see automated deployments into staging environments to catch potential issues, and eventually, smooth execution from the client perspective. I want these things to happen for both database and application software.

    A better development, test, and deployment process doesn’t mean that there isn’t a need for strong coordination among everyone involved, and certainly doesn’t mean a crisis team isn’t prepared to respond if there are issues. Thinking ahead to potential issues and ensuring everyone is on the same page helps to smooth any of the bumps that will occasionally crop up. At least, I expect they are only occasional if you follow a good CI/CD process.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Purpose of a Database

    A great quote from a blog on machine learning in SQL Server: “…nobody buys a DBMS for the sake of DBMS. People buy it for what it enables you to do”. The post is from Rimma Nehme, who has given a few keynotes at the PASS Summit. While the focus of the post is how you can implement deep neural network learning with R Services in SQL Server, I thought that quote stands out for any database, relational or NoSQL, from Microsoft, another vendor, or open source.

    I think it’s easy to get caught up in the debate over which features are better than others, or which database might perform better for the money spent. Pehaps we want to debate how easy or difficult it can be to build an application with the platform. We can look at the ROI, the ability to easily implement HA, DR, or some particular subsystem that we need. Those are all good questions, and certainly part of the decision to use a particular platform.

    At the end of the day, it doesn’t often matter which database platform you choose. Whether a JSON file, a relational platform like SQL Server, or the Neo4J graph database. The people that will use the database to query information, make decisions, or just store information need the system to work for them. The system needs to do something that helps their organization in some way. Often that’s based on the capabilities of the software that connects with the database, the capabilities and performance of the platform, and certainly the abilities and execution of the staff that work on the system.

    There’s plenty to debate about using SQL Server with the R language. We can make some determination about whether or not there’s value in spending licensing dollars on expensive SQL Server licenses and using those cores for analytics rather than some other, cheaper hardware. Microsoft R Server (another some other service) might be a better choice. Ultimately, the value to the end user is in getting the data processed and returned to them, whether this is through a query, a report or some recommendation from a machine learning algorithms.

    My view is that more complex processing, whether through machine learning or other types of data analysis, are going to be more important for data professionals in the future. As we build new applications, or even seek to keep older ones viable for a long time, we need to keep in mind that the DBMS isn’t the reason we have a project or job. It’s because we can somehow extract information from the DBMS and process it in a way that adds value to an organization. Whether we do this in a database or application is up for discussion and debate for each individual situation, but we need to ensure we are providing value for our customers.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Legacy Limits

    We are seeing changes to the SQL Server platform every month in Azure. Since that’s the same codebase used to product SQL Server on premise, that means the enhancements are not only being tested in the cloud, but they are available for release on a regular basis. SQL Server has been on a two year release cycle for major versions, but things are speeding up and I expect a new version (SQL Server 2017?) around a year after the last version (SQL Server 2016) was released.

    My thoughts are that this cadence will mean that many of us with more than a dozen servers will end up supporting more versions of SQL Server in the future. New applications will want newer versions, as do the employees, but there isn’t always a business case to upgrade all the older instances. If we were to see new versions every 18 months, given a 5-7 year life cycle (the standard support time frame) for database servers, I would expect that many of us would be always supporting the last 4-5 versions of SQL Server. If we go to a ten year life cycle (may be more realistic to me), then we would be looking at 6-8 versions.

    If you think ten years is too long, SQL Server 2005 is just over 11 years old. How many of those instances do you support? SQL Server 2008 is almost 9 years old and I bet a few of you have those instances around. Certainly if you have a support agreement and you have applications that use fairly core SQL Server features you can upgrade, but certainly keyword and language behavior changes might limit your flexibility.

    I read a piece recently noting that many organizations still use Windows XP for various systems. A number of the reasons given are to support legacy hardware or software. Some don’t have replacement versions of the hardware/software, or can’t find any value in managing an upgrade. The same issues hold true for SQL Server. I did some work for a company in 2008 that was still running a SQL Server 6.5 instance to support their keycard system. The database was virtualized, worked fine with Internet connectivity, and essentially cost a few hundred dollars a year for consulting fees. An upgrade to newer software, which would support SQL Server 2005+ would have cost over $50,000. Plus support.

    For no new useful features. No wonder they didn’t want to upgrade.

    This week I’m wondering how many of you are tied to older versions of SQL Server because of compatibility issues with software (or hardware). Are there reasons you maintain old database platforms? Any plans to upgrade, or is the cost not worth the benefits?

    I find legacy software and hardware to be a problem with the technology paradigm. While vendors want to move to new versions and reduce their support burden, many people feel that the cost of regular upgrades every few years is too high. Perhaps we could move to renting software, and getting constant development, but developers seem to be loathe to just constantly develop one version of the software for decades, preferring to fundamentally change the architecture at some point. Certainly that may make sense for some customers, but others who don’t need new features might wish for software to just work.

    I don’t have a great solution, but I would like to see options for software like we have with many other products. An example might be autos, where there are companies manufacturing parts that repair or upgrade older models, without the need to purchase a new vehicle. Maybe older software can be licensed in some way to allow independent developers to produce patches, security or otherwise. The vendor could continue to sell new versions, but a licensee could support old ones. I know there are times I’d prefer to have an older version of software work well, and continue to work for the foreseeable future.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The (Former) Complexity of PowerShell

    When I first looked at PowerShell, it was v1.0, and I was in a TechEd presentation. The language seemed a mile past the VBScript I was using when T-SQL didn’t function well. The ability to access the .NET namespace, work with objects, and program with error handling was exciting. I played with the language a little, but didn’t find that many places to use it at the time.

    Certainly file operations were much easier with PowerShell, and I built scripts to copy backup files around the network. AD operations were easy in PoSh. However, when I tried accessing SQL Server, I thought the code was complex. In fact, whether I was running a stored procedure, or performing a restore, the PowerShell code required was cumbersome. A good example is shown at the beginning of Aaron Nelson’s recently updated post on querying with PoSh. The complexity shown to just make a connection to PoSh made me think I should just write that kind of code in C#, with all the debugging and other software support available in Visual Studio. Building quick utilities with PoSh was something I’d like to avoid.

    When I heard that SQL Server Powershell was being updated, I wasn’t too excited. I had visions of there being newer versions of cmdlets, but a similar level of effort to work with SQL Server. However, as I’ve played with the new cmdlets, along with the dbatools module, I see PoSh becoming easier to use than T-SQL in some cases. In fact, I’ve started to keep a command line window open (with ConEmu) and access that to perform lots of quick tasks that aren’t based on simple queries of data. Even a backup with Backup-SqlDatabase seems as simple as it might be in T-SQL, perhaps more so if I don’t have an SSMS connection open.

    I know there can be a debate over whether you need PoSh as a DBA or you can get by with just T-SQL. I don’t want to take a side here, and no matter how you feel, if you can get work done, then you are successful. Your job depends on you being able to reliably write code to perform some task over and over. The language doesn’t matter.

    My view is that I think there are cases where PoSh seems a better fit and places where T-SQL works really well. I want to improve my skills in both so that I can decide what works best in any particular situation, and feel comfortable in building a solution either way.

    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.