It was not long ago that I though DevOps to be one of those things that happened to other people, and honestly, I did not give it that much thought. That was a time when I was a DBA in the part of the company that does deployments and support for our products, the Ops.
After working in the Ops for almost 20 years, at the beginning of the 2017, I transferred from the Ops to the Dev to lead a small team of database developers on a grand quest to save the world. For me this has been an eye-opening experience in many ways and it has also made me realize the value and possibilities of the DevOps culture.
Let me tell you a story on what happened and brought on this change of heart.
While I normally blog about SQL Server or topics that closely relate to it in some way, I decided to make a small exception this time. Today, I will be writing about blockchain. Granted it’s not a huge jump outside my usual themes, as we’re still talking about database technology. So why I am writing about the blockchain, is it because it’s new and cool technology that everyone else is talking about? Admittedly that is part of, but I also wanted to have some of my thoughts and questions about the blockchain in an easy to find place.
SQL Server has had the Data Compression feature for a while, ever since the version 2008, so it is hardly a new thing. However as it has been Enterprise Edition feature until SQL Server 2016 Service Pack 1, it is not something you see employed very often. Technically speaking, you could also compress data before 2008 by using NTFS file level compression on a read only data. However with the implementation of SQL Server Data Compression you could now do it inside the database on a page or a row level.
It took me a while to write the first post for 2017, but it has been rather hectic at the office since I moved inside the organization to quite a different role. However I noticed this story a while back and it has been haunting me ever since. Now if you are a DBA then you probably already understand just how important it is to have, not just backups, but valid backups. But what is the difference of a backup and a valid backup?
For the last blog post of the year 2016 I chose something that has been bothering me a bit as of late. Over the past couple months I have come across a number of cases where, after migrating databases to a new server, the end users are reporting increasingly bad performance. What has been common to these situations is that the new server has more and faster CPU cores, more memory, faster disks and should offer better performance, not worse.
Now the first thing I usually do when troubleshooting performance issues, is to check what kind of hardware we have and how the SQL Server has been configured. This is a really simple step to start with: Run msinfo32 to get the hardware details and then query sys.configurations to see how the SQL Server is configured. In these cases, all of the SQL Server configurations were left to their default settings. The result: Systems running to dangerously low levels of available memory which leads to extensive paging of the memory to the disk, and some really wild-looking query parallelization issues.
This year I didn’t write my usual daily blog posts during the PASS Summit 2016 as I felt it to be bit too much work with the long days and bit of a jet lag with the 10 hour time difference. Instead I decided to write a post summarizing my experience of the event. Every year, when deciding on what pre-con sessions to take and what regular sessions to attend to I try to think of a theme. This year I decided to go with Big Data and Analytics, as that’s an area of Microsoft Data Platform I’m not terribly familiar with. It was also a good choice because with SQL Server 2016 we’re seeing a huge number of improvements on technologies involved with these topics and there were quite a few sessions regarding these.
One of the new interesting features in SQL Server 2016 is the system-versioning with a catchy name, Temporal Tables. The name of the feature offers a hint to its purpose, to collect and to keep historical information about the data changes inside the database over a period of time. Instead of having just the latest data, we now have a way to know what it has been in any previous point in time. The most obvious use case for Temporal Tables is auditing, or at least it is to me, but they can be used for other purposes as well. Some examples are going back in time in case you need to perform a data recovery from an error or a data change operation gone bad, or you might want to use it for reporting purposes.
There are few things about the Temporal Tables that are good to know. First of all the work needed to keep track of the changes is done by the database engine when the system-versioning feature is enabled. Another thing some of you might appreciate is that the feature is available also in Standard Edition. And finally my favorite, it’s actually rather easy to start using the system-versioning as we will discover shortly.