SQL

OK, so everyone wants to know how Microsoft did it…how they got SQL Server running on Linux. In this article, I’m going to try to figure out how.

Update: Since the publication of this post, Microsoft has published a blog post detailing the implementation here.

There’s a couple of approaches they could take…a direct port or some abstraction layer…A direct port would have been hard, basically any OS interaction would have had to been looked at and that would have been time consuming and risk prone. Who comes along to save the day? Abstraction. The word you hear about a million times when you take Operating Systems classes in undergrad and grad computer science courses.:)

The SQLMonitor team at Redgate has been releasing updates at a much more rapid rate…what’s this mean to you? More fixes and more features. In this latest release, they certainly added something special…Graphical Query Plans! Yes, right inside of SQLMonitor’s user interface. Why is this important?  Well for me, when I’m troubleshooting a performance issue…I usually start with identifying what system resource is being taxed and try to zoom in from there on the root cause. Now lets say the root cause is a poorly performing query, SQLMonitor let’s you find that query pretty easily, but stopped short when it came to diagnosing that actual performance issue in the query.

SQL 2014 Service Pack 2 was recently released by Microsoft and there is a ton of great new features and enhancements in this release.This isn’t just a collection of bug fixes…there’s some serious value in this Service Pack. Check out the full list here. One of the key things added in this Service Pack is an enhancement of the Extended Events for AlwaysOn Availability Group replication.

Why are the new Availability Group Extended Event interesting?

If you’ve used Availability Groups in production systems with high transaction volumes you know that replication latency can impact your availability. If you want to brush up on that check out our blog posts on AG Replication Latency, Monitoring for replication latency, and issues with the DMVs when monitoring. These new extended events add insight at nearly every point inside your Availability Group’s replication. More importantly they also include duration. So using these Extended Events we can pinpoint latency inside our Availability Group replication.

Paradigm Shift!

What do I mean by that? Every once in a while a technology comes along and changes the way things are done, moves the bar…well last week Microsoft released a Channel 9 video on persistent memory using NVDIMMs and DAX on Windows 2016…then combining it with SQL Server! This is one of those technologies that moves the bar! Check it out here.

Why is this important?

Relational databases like SQL Server use a transaction log to ensure the durability of the transactional operations to the database. This is so it can ensure its data is consistent in the event of a system failure. SQL Server uses a logging protocol called write ahead logging (WAL). This means that the data change operations must be written to stable, persistent storage before the process can change data in the database file…so this means our database throughput is at the mercy of the performance of the device the changes (log records) are written to.

I’m proud to announce that I will be speaking at IT/Dev Connections on October 11th 2016 in Las Vegas! I can’t begin to tell you how excited I am to be able to speak at this conference! I look forward to seeing you there!

Here’s the information on the talk!

Designing High Availability Database Systems using AlwaysOn Availability Groups

**Track: **Development Platform Tools and Devops

Abstract:

Are you looking for a high availability solution for your business critical application? You’re heard about AlwaysOn Availability Groups and they seem like a good solution, but you don’t know where to start. It all starts with a solid design. In this session we introduce the core concepts needed to design a Availability Group based system. Covering topics such as recovery objectives, replica placement, failover requirements, synchronization models, quorum, backup and recovery and monitoring. This session is modeled after real world client engagements conducted by Centino Systems that have lead to many successful Availability Groups based systems supporting tier 1 business critical applications.

I’m proud to announce that I will be speaking at SQL Saturday Baton Rouge on August 6th 2016! This will be my forth SQLSaturday event this year and I’m really excited that I get to do it as a speaker. I look forward to seeing you there!

If you don’t know what SQL Saturday is, it’s a whole day of free SQL Server training available to you at no cost!

If you haven’t been to a SQL Saturday, what are you waiting for! Sign up now!

I’m proud to announce that I will be speaking at SQL Saturday Sacramento on July 23th 2016! This will be my third SQLSaturday event this year and I’m really excited that I get to do it as a speaker. I look forward to seeing you there!

If you don’t know what SQL Saturday is, it’s a whole day of free SQL Server training available to you at no cost!

If you haven’t been to a SQL Saturday, what are you waiting for! Sign up now!

In this post we’re going to introduce the basics of CPU scheduling.

In a computer system, only one thing can happen at a time. More specifically, only one task can be on a processor at a point in time. This can expand to several tasks if the system has multiple processors or a processor with multiple cores, which most modern systems have. For example, a four core system can potentially execute four tasks concurrently.

I’m proud to announce that I will be speaking at SQLSaturday Pensacola on June 4th 2016! This will be my second SQLSaturday event and I’m really excited that I get to do it as a speaker. I look forward to seeing you there!

If you don’t know what SQL Saturday is, it’s a whole day of free SQL Server training available to you at no cost!

If you haven’t been to a SQL Saturday, what are you waiting for! Sign up now!

In my opinion one of the key features of SQL Server 2016 is the rebuilt and optimized log redo mechanism for AlwaysOn Availability Groups. Check out the many new AG features here. Check out my posts here and here to learn about how Availability Groups move data.

Early last week I was conducting a load test using SQL Server 2016 and wanted to compare the performance of the log redo thread with that of SQL Server 2014. To establish baseline the performance of 2014, I constructed a load test using a heavy insert workload on the primary. To measure that workload I used the following script to pull database replication performance data from sys.dm_hadr_database_replica_states