Capturing and Analyzing deadlocks in SQL Server

No matter how perfect your code and how optimized the way you have written is, facing a situation of getting a deadlock is inevitable. And it would make the situation even more complex when you know that a deadlock had occurred but you have no clue which the victim and perpetrator was.

There are few ways to capture and analyze a deadlock. I will explain two ways in this post.

1. Enabling trace flags to capture/log deadlock information into SQL Log
2. Use SQL Profiler to capture a deadlock.

Enabling trace flags to capture/log deadlock information into SQL Log

This method will make sure that the deadlock details are logged in the SQL log file (not the transaction log). Even though the details which are captured via this method is textual  it gives you the option of inspecting the details at a later time.

First you need to enable the trace flags using the following syntax:

DBCC TRACEON (1222, 1204, -1)

 

Afterwards we will simulate a deadlock : (in reality you don’t need to do this if you are facing such issue)

First create two sample tables and insert few records which we will use to produce a deadlock.

-- Create a Sample Tables --

CREATE TABLE SampleDeadLock_1(
    Item_Code    INT
    ,Item_Desc    VARCHAR(100)
    ,Qty        INT
)

CREATE TABLE SampleDeadLock_2(
    Item_Code    INT
    ,Item_Desc    VARCHAR(100)
    ,Qty        INT
)

-- Insert couple of records to each table --

INSERT INTO dbo.SampleDeadLock_1(
    Item_Code
    ,Item_Desc
    ,Qty
)
VALUES
    (1,'CPU', 10)
    ,(2, '20 GB - Hard Disk', 20)

INSERT INTO dbo.SampleDeadLock_2(
    Item_Code
    ,Item_Desc
    ,Qty
)
VALUES
    (3,'Monitor', 15)
    ,(4, 'Keyboard & MOuse', 25)

Now open two query windows in SQL Server Management Studio (Window 1 & Window 2) and paste the following code to ‘Window 1’

BEGIN TRAN

UPDATE dbo.SampleDeadLock_1 SET Qty = 100 WHERE Item_Code = 1

WAITFOR DELAY '00:00:30'

UPDATE dbo.SampleDeadLock_2 SET Qty = 200 WHERE Item_Code = 3

And paste the following code to ‘Window 2’

BEGIN TRAN

WAITFOR DELAY '00:00:10'

UPDATE dbo.SampleDeadLock_2 SET Qty = 300 WHERE Item_Code = 3
UPDATE dbo.SampleDeadLock_1 SET Qty = 400 WHERE Item_Code = 1

Afterwards execute the code in Window 1 and immediately execute the code in Window 2. After few seconds (30+) you will see a deadlock error message in Window 1.

And when you checked on the ERRORLOG file, you will be able to find out the relevant details which relates to the deadlock. (I have highlighted the deadlock victim details in Red and the perpetrator details in blue)

Using SQL Profiler to capture a deadlock (Deadlock Graph)

One of the issues we have in the aforementioned method is that we need to look into lots of textual information in order to extract the details which is relevant for the deadlock. In this example it’s somewhat easier since we had chosen a simple situation. But things could get real hard during an actual situation where the processes are bit complex.

In such case (any case), we can use the SQL Profiler to detect the deadlock in a more user friendly manner.

** Please Note: Down-side of this method is you need to have the profiler running during the time that the deadlock had occurred. And this isn’t the best way if you need to troubleshoot in a Production Environment.

How ever for the sake of understanding we will see how we can achieve this.

Open the SQL Profiler and connect to the relevant SQL Server. And in the ‘Trace Properties’ window choose ‘TSQL_Locks’ as the template.

And in the ‘Event Selection’ tab, please choose the following options.

• Deadlock graph 
• Lock:Deadlock 
• Lock:Deadlock Chain

Before click on running the profiler, Rollback the transaction which is running from the first example (The one which didn’t become the Deadlock Victim)

Start the profiler by clicking the ‘Run’ button. And once the profiler is running, execute the code on Query Window 1 and afterwards execute the code in Query Window 2.

Once the deadlock occurs the Profiler will display the relevant information in a graphical manner. This will contain all the relevant details which is required in order to troubleshoot the deadlock. And if you hover the cursor over the processes in the graph (shown in ellipses) a tooltip will be displayed along with the statement which has been executed, which caused the deadlock to occur.

I hope this will help you in order to troubleshoot a deadlock situation.

Introduction to SSDT (SQL Server Data Tools)

WHAT IS SSDT ?

SQL Server Data Tools (SSDT) is a toolset which provides an integrated environment for database developers to carry out all their database design work for any SQL Server platform (both on and off premise) within Visual Studio. Database developers can use the SQL Server Object Explorer in VS to easily create or edit database objects and data, or execute queries.

In a previous blog entry I have described on how to install SSDT into the VS environment. During this I will briefly describe few of it’s features.

SSDT’s intention is not to replace the SQL Server Management Studio, but provide a developer a complete development environment, which the developer need not required to leave Visual Studio IDE to do any database related development. The tool does not contain all the features which you find in SSMS, yet it’ll provide sufficient functionality which will required to most of the developers during their development tasks.

I find following features, pretty  much interesting and helps to increase the productivity of the developer/team.

1. DESIGN & CODE VIEW IN A SINGLE SCREEN.

Ability to see the design view and the code view in a single screen is a wonderful thing. You do not have to move across screens. And the changes you do to the design view will be affected to the code immediately and vice versa.

 

2. ABILITY TO ADD CONSTRAINTS, INDEXES, FOREIGN KEYS & TRIGGERS WITHOUT CHANGING THE SCREEN

Adding constraints, indexes, etc.. are much easier. You can add those by right clicking and choosing the ‘add <object>’ menu like shown below.

 

3. IT USES ‘DECLARATIVE – MODEL BASED DEVELOPMENT’

What this means is that there is always an in-memory representation of what a database looks like—an SSDT database model— and all the SSDT tools (designers, validations, IntelliSense, schema compare, and so on) operate on that model. This model can be populated by a live connected database (on-premise or SQL Azure), an offline database project under source control, or a point-in-time snapshot taken of an offline database project (you will work with snapshots in the upcoming exercises). But to reiterate, the tools are agnostic to the model’s backing; they work exclusively against the model itself. Thus, you enjoy a rich, consistent experience in any scenario—regardless of whether you’re working with on-premise or cloud databases, offline projects, or versioned snapshots.

4. CONNECTED DEVELOPMENT

Although SSDT places great emphasis on the declarative model, it in no way prevents you from working imperatively against live databases when you want or need to. You can open query windows to compose and execute T-SQL statements directly against a connected database, with the assistance of a debugger if desired, just as you can in SSMS.

5. DISCONNECTED DEVELOPMENT

The new SQL Server Object Explorer lets you connect to and interact with any database right from inside Visual Studio. But SSDT offers a great deal more than a mere replacement for the connected SSMS experience. It also delivers a rich offline experience with the new SQL Server Database Project type and local database runtime (LocalDB).

Actually this is one great feature it has. Because due to many reasons, most of the time we are requested to work offline, or to do our development locally and later on merged. So this feature allows us to maintain a local database and do all the development using that. And later on merged/published to other database. And by doing a schema comparison, it’s possible to find out the changes we have done.

6. SCHEMA COMPARISON

This is a very valuable feature. This allows us to do a schema comparison between our development environment and the physical database (or vice versa) and find out the changes very quickly.

7. SAVING SNAPSHOTS OF THE DATABASE

Sometimes it’s required to keep snapshots of your database at different stages of the development. And the best thing is, it even allows you to compare between two database snapshots. So it’s easy to see the changes you have done compared to the previous stages.

8. ABILITY TO FIND ANY ERRORS OR REFERENCE ISSUES IN DESIGN TIME

When SSDT is used it’s easy to identify any syntax issue or any reference issue before deploying it to the database. E.g. assume we have one view which is referring to few columns of a table. Usually if someone change or remove any columns from the table which this view is referring, there is no way of identify that, till the view is used in our application. But when SSDT is used, it will show you these issues, when building the project. So these can be eliminated before we apply these to the deployment server.

These are some features which I have find very interesting and most developers expect. But having said that I am not saying it’s the complete set of features. There are few missing functionalities which I felt that it would have been even nicer, if those were there.

And you can find a good article in here (http://www.codeproject.com/Articles/357905/Evaluating-SQL-Server-Data-Tools) regarding the SSDT. You can find things in more depth.

Deployment model in SSIS 2012

Aim :- To Learn a New way of deployment model in MS SQL Server Integration Services i.e. SSIS 2012.

Description :-  In this article we are going to learn a New way of deployment model in SSIS 2012. It’s always been a challenge & a difficult thing for SSIS developers at the time of package deployment. It’s abrand new feature in SSIS coming with MS SQL Server 2012. Prior to this version, it was a tedious process to deploy SSIS packages in Legacy model. We can call this new deployment model in SSIS 2012 as “Project Deployment Model in SSIS”.

Why we call this as Project deployment model in SSIS and what is the reason behind this?

In the new deployment model in SSIS, we don’t have any option & we are unable to deploy the packages individually. Just we have deployment option at Project level only, that’s why we can call this as“Project Deployment Model”. The new Project Deployment Model in SSIS includes Project/Package Parameters, Environments, Environment variables and Environment references.

Project/package parameters :- In this new deployment model, we can declare project parameters/package parameters. The major difference between these two parameters is “scope”. You can create project parameters at project level and package parameters at package level.

We can use project parameters to any package in the project, package parameters can only use to that package only. These parameters allow us to assign values to the properties within at the time of package execution. Project parameters are used to supply any external input the project receives to one or more packages in the project.

In the above screen shot you can clearly observe project parameters option. Once you click and open it appears like left side image. The best part of these parameters is that you can mark any of them as sensitive and it will be stored in an encrypted form in the catalog.

There can be three default values for these parameters :-

• Design Default value is assigned and used in BIDS.
• Server Default value is assigned when project comes in the catalog and overwrites the Design Default value.
• Execution value is assigned in reference to a specific environment variable during execution.

Environments and Environment variables :-

We have different type of environments like Development, Test and Production. It is a place for environment variables which are used to apply different groups of values to the properties of package components by means of environment reference during runtime. An environment reference is the mapping between an environment variable to pass a value to a property of a package component. A project can have multiple environment references.

To know more about project/package parameters, environments and environment variables you can visit – www.msdn.com.

Integration services catalog :-

In the below theoretical part we will frequently use “catalog” term. Now we are going to discuss what is integration services catalog, where it exists?

This is the brand new feature in MS SQL Server 2012. It comes with SQL Server Management Studio(SSMS). It stores the data about deployed projects including packages, variables and environments. We must know one mandatory thing i.e. “we can create only one catalog per instance”. When you create a catalog you need to provide a password which will be used to create a database master key for encryption and therefore it’s recommended that you back up this database master key after creating the catalog.

The catalog uses SQLCLR (the .NET Common Language Runtime (CLR) hosted within SQL Server), so you need to enable CLR on the SQL Server instance before creating a catalog.

Finally let’s jump into practical session with example – My best part of any article.

STEP 1.  Create integration services catalog.

• Open SSMS and Go to Integration Services Catalog. Right click on that and choose Create catalog.

• Once you click on Create catalog option, below window will pop up. After filling the desired values, Click OK button.

• Once you click on OK button, One “ssisdb” database is created.
• It’s time to create one folder inside ssisdb database. When we are going to deploy our project than that total content is deployed in this folder only.
• To create a folder, Just click on ssisdb. Right click on ssisdb and choose create folder option.

• Once we click on Create folder, the below window will appear.fsf

STEP 2.  Create Integration services project in BIDS.

• Once we create a folder named “Test”, it’s time to go and create 1 Integration Services project inBIDS.
• Open BIDS and Create Integration Services project, name it as say “PHPRING”.
• Create Couple of packages inside this project “PHPRING”.

I hope you all are aware of how to create integration project in BIDS and how to create few sample packages inside that project. Now I don’t want to go and create all those things now. Already I have few packages  existed in PHPRING.

My First package name is “DataFlow Task”. The internal operation of this task is to extract the data from Flat file. After exteracting data it applies sorting on those columns by using soft transformation. Finally, we can load that sorted output into Flat file destination.
My second package name is “Execsql”. It contains 1 Execute SQL Task. I issued one Select statement in this package.

STEP 3.  Package Deployment time.

• Go to Project name, in our case it is “PHPRING”.
• Right click on the project name and click on deploy. If you have any doubt follow the below screenshot.

 

• Once you click on “Deploy” option, it will bring up the below window.

• Once we click on Next, it will bring up next window i.e. “Select source”.

• Once we click on Next, it will jump to 3 option i.e. “Select destination”.

• Once we click on Next, we will get a “Review window”. In this window, we can know all the information in – Select source, Select destination tabs.

• Once we click on Deploy option, immediately “Results window” will pop up.

Once our Deployment is over, simply click on Close button.

STEP 4.  Checking whether Project deployment is Succesful or not?

Once we complete the above process, we can jump into SSMS (SQL Server Management Studio) and see whether our project “PHPRING” is deployed in “Test” folder or not.

• Go to SSMS and expand Integration Services catalogs.
• Now, Expand ssisdb. Expand folder Test and then Expand Projects.
• Expand PHPRING (our project name) and then expand Packages.

By observing the above screen shot, we can conclude that our project “PHPRING” with two packageswere deployed successfully into SSISDB.

STEP 5.  Executing our Package.

In this step we are going to run our first Package i.e. “DataFlow.dtsx” from “Integration Services Catalog“. It is very simple to run packages from here.

• Simply right click on first package “DataFlow.dtsx”. Click on “Execute”.

• Once we click on Execute, it will bring up one window. Here simply click on “OK”.
• After that it will pop up below window. Just read the information and then click on “Yes”.

• Once we click on “YES” it will bring up a window with the following information.

STEP 6.  Output in Flat file Destination.

In this step we are going to see our package “DataFlow” is executed successfully or not. To do this, simply go to flat file destination path and see the data. Preety simple right?

By observing above screen shot we can concluded that first package i.e. “DataFlow” is executed successfully and we can also observe the data is in Flat file destination.