Voice of the DBA

Tag: sql server

  • The New SQL Server 2016 Edition Limits

    I was thrilled with SQL Server 2016 SP1. I’ve been asking for all features to be in all editions for a long time, and now we have most of the features available. There are still a few enterprise only items, but these are based on speed and scale, and not programming, and I can live with those. While I’d still like some “in between” edition that had higher limits than Standard, or even some sort of core/RAM add-ons, I recognize there’s a complexity in doing this that might not be worth undertaking.

    That changes in SP1 that allow features like snapshots, CDC, Columnstore indexes, and more mean there are some other changes that are important to understand. The SQL Server Tiger Team recently posted a note about some of the limit changes in SQL Server, showing how some of the memory limits have been raised with the new Service Pack.

    In the last few versions, SQL Server Standard Edition (SE) has been limited to 128GB of RAM in a server. While that might not be a lot to some of you, I’ve rarely had servers with more memory, so that’s been a good edition for me. However, when considering using Columnstore or Memory-Optimized tables, I could see why there could be some concern over memory shortages. After all, SQL Server really, really likes lots of memory.

    There still is a 128GB limit for the buffer pool cache in SE, but this is separate from the Columnstore cache and memory-optimized data stores. For Columnstore cache, you get an additional 32GB of RAM that can be used per instance. That means that if I use Columnstore indexes, I could use 160GB for caching data (128 + 32). What’s more, if I decide I need to use In-Memory OLTP tables, I get an additional 32GB per database to use here. If I have a single database with both features, that means I can use 192GB of RAM for data. If I have two databases, I could get 224GB of data in RAM. Of course, things aren’t quite this simple, and certainly, running out of RAM with In-Memory OLTP tables is bad.

    While these changes might not mean much for some people, I bet lots of customers will appreciate the chance to use these features, and not take any existing RAM away from their SE server. Of course, if you only bought a server with 128GB, you might want to get a little more before you start playing with Columnstore or In-Memory OLTP tables. And if you really need lots of RAM, Enterprise Edition now supports 24TB of RAM. I can’t wait to read a post when someone publishes their experiences on that system.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 6.9MB) 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.

  • What is a Database Master Key?

    The encryption mechanisms in SQL Server are interesting, and they work well, but they are somewhat poorly named. I ran across a few people struggling to understand, so I decided to cover the concepts in a series of posts. This one looks at the Database Master Key (DMK).

    Not the Master Database Master Key

    This is one of the more poorly named objects in the SQL Server platform. Or perhaps the “master” database is the one that is not named well. In any case, the DMK has nothing to do with the master database. Instead, the DMK is the base encryption key inside of a database. This is the key that secures all other keys

    There can be a DMK in each database that you have, including master. For some features, such as TDE, you must create a DMK in the master database. For others, you would create a DMK inside of the user database.

    Protecting a DMK

    By default the DMK is encrypted and protected by the Service Master Key (SMK), which is the key that protects the instance. This means when a database is opened and used, the service account can decrypt the SMK and use that key to decrypt the DMK. You can optionally also protect the DMK with a password.

    Even more optionally, you can break the encryption link between the SMK and DMK. In this way, you could need a password on the DMK, which would have to be entered each time a user wanted to use a key protected by the DMK.

    You need to ensure the password for the DMK is protected and available, as you will need it if you restore the database to another instance.

    To use the DMK, an account needs the CONTROL permission on the database.

    The DMK is a symmetric key. It is uses the AES_256 algorithm in SQL 2012+. Prior to that it was with Triple DES.

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