I recently read an article which stating that since the GDPR came in force, there has been 59,000 data breaches reported in the EU. I must admit, that while I did anticipate that we’d see a surge in these numbers, due to reporting requirements in the legislation. I really did not expect the numbers to look that terrifying.
From the point of view of a SQL Server DBA, there is a number of different ways to protect your data. Some of them are even quite easy to setup, such as Transparent Data Encryption (TDE). So let’s have a look at how to set that up!
Note: This post is not a technical one, but one focusing on a professional (and maybe personal) growth. As we’re already well on our way to 2019, I figured that now is as good time as any to look back, all the way to the year 2018! As I mentioned in passing in a previous post, I did end up leaving the company I had worked for 20 years, and while being a small step to mankind it was quite a huge leap to me.
It also taught me few things, which I figured are worth sharing.
About two months back I ended up moving to another job, which has unfortunately kept me to be bit too occupied to find the time to blog, until now. Due to this previously mentioned career change, I have been working quite a bit with monitoring, and it gave me a spark to write this post about my favorite PerfMon counters.
Like most DBAs I rely quite a lot on monitoring, and like most DBAs I too have my own set of PerfMon counters that I rely on to provide me an accurate view of what’s happening in the environment I am administering. In this post, I’ll describe what are my favorite PerfMon counters.
Over the last two years I have been working lot on improving the tooling and processes related to database development at where I work. One concept born out of this work is what we have started calling a “Database-as-a-Code” model. Originally the idea was to introduce some of the good practices, such as version control, build automation and unit testing to database development. Over the time it has evolved to include even more, in an effort to break down traditional silos between software developers, database developers and the operations people.
In this post I’ll describe some of the decisions we made and the steps we have taken in our Database DevOps journey.
Dedicated Admin Connection is one of the easy-to-forget features in SQL Server that can really save your day. DAC (no relation to Data-Tier Applications, just shares the acronym), as it’s often called, is the way you can try to access a SQL Server instance that is in such a bad shape, that no normal connection is available. This can be due to resource exhaustion or if you happened to create a slightly wonky logon trigger. In this post we’ll look at how you enable Dedicated Admin Connection (for remote users) and how you connect to SQL Server using the DAC.
I recently had a discussion about the ability to offload DBCC CHECKDBs to a secondary database using Active Secondaries in SQL Server Availability Groups. While it is fully possible to run database consistency checks against secondary database (and there’s plenty of recommendations floating around for doing this), it needs to be pointed out that using Availability Groups for this does not equal of running checks on the primary database.
In my previous post about logical joins I wrote about the most common type of SQL Server join, the INNER JOIN. Naturally the logical follow-up is to look at the OUTER JOIN. Syntax for OUTER JOIN is bit different from the INNER JOIN, as you need to define either LEFT, RIGHT or FULL keyword (more about FULL in another post). Unlike the INNER JOIN which only returns rows from the tables if there are equal values in join column, OUTER JOIN will return all the rows from either LEFT or RIGHT even if there is no matching value in the table you are joining.