Category Archives: SQL Server

First impressions: SQL Server 2017 Administration Inside Out

I recently had the pleasure of reading SQL Server 2017 Administration Inside Out by William Assaf, Randolph West, Sven Aelterman, and Mindy Curnutt. I love this book. While I haven’t finished reading it yet, I wanted to post my first impressions. I’ll update this post once I’ve finished the book.

I recommend this book for accidental DBAs, junior DBAs, and senior DBA’s with a sense of impostor syndrome. I would NOT recommend it for people with no experience with SQL Server or for senior DBAs looking for a deep dive. This books aims at breadth not depth.

To emphasize that point, take a look at the table of contents below:

  1. Getting started with SQL Server tools
  2. Introducing database server components
  3. Designing and implementing a database infrastructure
  4. Provisioning databases
  5. Provisioning Azure SQL Database
  6. Administering security and permissions
  7. Securing the server and it’s data
  8. Understanding and designing tables
  9. Performance tuning SQL Server
  10. Understanding and designing indexes
  11. Developing, deploying and managing data recovery
  12. Implementing high availability and disaster recovery
  13. Managing and monitoring SQL Server
  14. Automating SQL Server administration

That is, without a doubt, a lot to get through. Each chapter could easily be its own book. Instead, I see this as a book to fill in the gaps. The text is perfectly suited for that middle level of complexity, where you have heard of a concept, but it doesn’t click yet. This book made things click for me.

As an example, let’s take look at chapter 2. In this chapter they run through the core components of a computer: memory, CPU, storage and networking. They are fundamental concepts for any IT worker. How easy would it be to say “Everyone should know this.” Despite how basic these concepts are, the authors neither condescend nor assume prior knowledge.

For example, when there are complex concepts such as RAID or NUMA, they take the time to explain what these things mean, why they are important and why are DBA would care. Reading these sections, I felt a sense of gratitude because use when people talk about these concepts, I never quite get it. Reading this book, I felt like I “got it”.

So, you may be wondering why I wouldn’t recommend this book for people without SQL Server experience. First, It’s big. It’s over 704 pages long. Second, the book is very good at filling in the gaps of an existing mental model. It would need more detail and information if you were starting out with almost no mental model, such as a college student.

Regarding tone, the book is quite technical and detailed at times. For example, it explains each and every column in components of the Activity Monitor. That being said, the authors do try to inject a bit of humor here and there. They also aren’t afraid to call out worst practices, such as running Database Tuning Advisor in production. I appreciate a book that a little bit opinionated.

One last comment on the book: I appreciate that it is a book about modern database administration. It acknowledges the realities of Azure and PowerShell, two tools required for any dba moving forward.

So, is this book worth buying? I would say yes, with some conditions. First, there is no question regarding the quality of the content. It is well written and the authors are experts in their field. The first condition is to make sure you are actually going to read it. It’s a long book and adds more value as a whole, not as individual chapters.

Second is a matter of your skill level. If you are looking to fill in gaps in your knowledge of SQL Server overall, you will fall in love with this book. If you are either very junior or very senior, you will feel quite frustrated. This is very much a “Goldilocks” book: not too deep, not too light, just right.

TSQL Tuesday: Who is on my server?

tsqltuesday

Here is my entry for this month’s T-SQL Tuesday.

I once had to some auditing for a customer and it was a complicated, multi-stage process. We had to be able to demonstrate who had admin access and what kind of activity was going on, on the server. But before we could do any of that, we first had to identify who was actually logging on.

Triggers to the rescue

So what are the different options for telling who is logging on to a a SQL server? 5 options come to mind:

  1. Configure login auditing.
  2. Login Trace
  3. Login Extended Event Session
  4. SQL Audit
  5. Server Trigger

So going through each one of them:

Configuring login auditing really isn’t a good solution. What you are doing is changing the base settings to log successful logins in addition to failed logins. The problem is that these events are written to the SQL Server event log, which isn’t convenient to parse.

Well what about using a trace? Well I’ve always been told that traces are expensive in terms of performance so I shied away from using one of those. In retrospect, I doubt it would have been too expensive since it’s only tracing logins. If anyone knows, let me know!

The next option is to use Extended Events, which often have better performance. Unfortunately, this server was SQL Server 2008 R2 and there was no GUI support for extended events. So that wasn’t ideal.

What about SQL Audit? Underneath the hood, SQL Audit is just Extended Events. That being said, there is at least some GUI component to it. For 2008R2, it required Extended Edition. while that wasn’t an issue for us, it seemed like overkill.

So what’s the last option? Creating a server level trigger. This was simple to implement and easy to dump the data into a SQL table for reporting purposes.

Proceed with caution

So, what’s the downside. Wellllllll. What happens if you have an error in your code? If you hit an error, then you can’t login. At all. Anyone.

There are ways to resolve this issue, but it requires shutting down the SQL Server and taking an outage to fix it. Suffice it to say, I spent a looooot of time testing before I pushed this out to production.

Overall, triggers provided a simple solution to a simple problem. But the solution required a good dose of caution.