Database Corruption Challenge Week 3 Results


It is my pleasure to announce the winners in the Week 3 Database Corruption Challenge. But first how about a rundown of challenge.

The challenge was issued at 10:00pm (pacific time) on Friday night. Yes, this was a difficult time for those on the East coast of the US, and if you are from EST, next week I promise the time will be better for you. Trying to switch up the times to give everyone across the planet a fair advantage. Those who had signed up for my Newsletter received early notification of when the corruption challenge would occur, but not details on what the challenge would be.

Once the challenge was issued, I received a couple of partial submissions, one contained the correct steps, but no results. The second one contained the right results, but was missing the steps to do it. The first correct submission that contained the steps, and proof that it was done correctly came in 37 minutes after the contest had started.  It was almost an hour later before the next winning solution was sent in.

Read more of this post

MySQL JOIN Types for LinuxFest Northwest

Today I had the opportunity to present at LinuxFest Northwest on MySQL Join Types, using the MySQL JOIN Types poster in the presentation.

It was a good session, about 30 people in attendance. Lots of great questions were asked.

Here is the download material.




Week 3 of the Database Corruption Challenge

Welcome to week 3 of the database corruption challenge.

Hi, I am Steve Stedman and I have created this challenge to help the best and brightest SQL Server DBAs on the planet test their skills and to show expertise to the world.

The winner last week was Rob Farley, I would just like to congratulate him again on winning the second Database Corruption Challenge (DBCC). Nice job Rob!


On to the week 3 challenge:

You might notice the “Recovery Pending” message in the following image, hmmm, what is it going to be?


Click to find out about the Week 3 Challenge

Database Corruption Challenge Week 3 Approaching

After two great weeks of the database corruption challenge, week 3 is approaching. I have a few things to announce as we go into week 3.

The database corruption challenge will run over 10 weeks at which point another challenge will begin, and everyone will start out with a fresh score, sort of like bowling. This post I am going to cover scoring and prizes, just to keep it interesting.

Scoring the Challenge

I realized that I had never finalized the scoring of the competition. Here are the scoring criteria that I have come up with.

Read more of this post

Deadlock and Trace Flags 1204 and 1222

When you are looking for deadlocks there are, like most things in SQL Server, more than one way to find the deadlocks. This article is specifically focused on using the SQL Server ERRORLOG file located in the LOG directory for the SQL instance. If you used the defaults on SQL Server 2012, this log would be at this location:

C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Log\ERRORLOG

For SQL Server 2014 it would be here:

C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Log\ERRORLOG

and in similar locations for other versions of SQL Server.


What is a Deadlock?


A deadlock is a specific case in SQL Server and other databases where, in the simple case of two transactions, the first transaction gets stuck waiting on blocking from the second transaction, and the second transaction gets stuck waiting on blocking for the first transaction.

Imagine traffic so jammed up that one lane of travel is blocking another lane of travel, and vice versa. The deadlock in SQL Server is similar to this, but instead of traffic being blocked, it is queries and transactions being blocked.

Eventually in traffic when cars are blocking, one will give up and back out, and the other will be allowed to drive through. The one that backs out is known as the deadlock victim.

When one query is chosen as the deadlock victim, it looks something like this:

Read more of this post