THE SQL Server Blog Spot on the Web
Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | Join | Help
in Search

Peter DeBetta's SQL Programming Blog

Peter DeBetta's blog about programming in SQL Server 2008, 2005, etc. using technologies such as T-SQL, .NET, CLR, C#, VB, Visual Studio, and SQL Server Management Studio.

context connection=slow?

The subject of this post may be a little misleading. When writing CLR code in SQL Server 2005 that requires querying the data, you should connection back to the data using the connection string "context connection=true". However, there are occasions when this is not your best option…

 

I was working on a project recently that used a CLR-based user-defined type to persist some specialized data and a CLR-based function that would aggregate the data (why a function and not a user-defined aggregate is another post for another day). By default, the connection back to the database to fetch the UDT data was using the context connection string. There was a large amount of data being pulled, and the only apparent bottleneck was disk access when fetching all that data to process. But, after some inquiries, I found out that in this situation, it was more efficient o use a non-context connection string ("data source=server; initial catalog=database, etc…").

 

Why? Well, the context connection is written such that it only fetches a row at a time, so for each of the 20 million some odd rows, the code was asking for each row individually. Using a non-context connection, however, it requests 8K worth of rows at a time.

 

Now in many cases, the additional overhead of fetching a single row at a time is not overcome by the use of the already existing connection, but if you are fetching many narrow rows, then you will likely see better performance by using a non-context connection. Most scenarios, however, don’t do intense row by row operations on millions of rows, so by default, use the context connection, and then, if you want to see if you can get a little performance boost, try the non-context connection.

 

If you want to try this out yourself, you can use the following code in a SQL Server project (C#) in Visual Studio 2005 and deploy it to the AdventureWorks sample database. You will need to make the database permission level

 

[Microsoft.SqlServer.Server.SqlProcedure]

public static void ConnectWithContext()

{

    Object[] rowData = new Object[2];

 

    using (SqlConnection sqlConn = new SqlConnection("context connection=true;"))

    {

        sqlConn.Open();

 

        SqlCommand cmd =

         new SqlCommand("SELECT ContactID, ExtraText FROM dbo.Contact", sqlConn);

        cmd.CommandTimeout = 240;

        SqlDataReader dr = cmd.ExecuteReader();

 

        while (dr.Read())

        {

            dr.GetValues(rowData);

        }

        sqlConn.Close();

    }

 

}

 

[Microsoft.SqlServer.Server.SqlProcedure]

public static void ConnectWithContext()

{

    Object[] rowData = new Object[2];

 

    using (SqlConnection sqlConn = new SqlConnection(

      @"Data Source=SERVER;Initial Catalog=AdventureWorks;Integrated Security=True"))

    {

        sqlConn.Open();

 

        SqlCommand cmd =

         new SqlCommand("SELECT ContactID, ExtraText FROM dbo.Contact", sqlConn);

        cmd.CommandTimeout = 240;

        SqlDataReader dr = cmd.ExecuteReader();

 

        while (dr.Read())

        {

            dr.GetValues(rowData);

        }

        sqlConn.Close();

    }

 

}

 

--Peter


Published Friday, July 21, 2006 2:59 PM by Peter DeBetta

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Dis4ea said:

Now that's interesting information.  One of our projects here is using SQL CLR, I think I'll check with the database developer of that one asap :-)

Keep up the good work.
July 24, 2006 4:34 AM
 

Glen said:

Ok - we have code that creates a seperate connection but the problem is that we don't know what the server name and database name will be. So, to get around this issue we create a context connection as follows:

 SqlConnection sqlConn = new SqlConnection("context connection=true;");

Next we create a new connection as follows (remember that we need to figure out the server and database name at runtime):

 SqlConnection bConn = new SqlConnection("server=" + sqlConn.DataSource + ";integrated security=true;database=" + sqlConn.Database);

Okay so the second connection works...on a server with SQL 2005 as the default instance - however this isn't true on a machine with SQL2000 as the default instance. The problem is that in this case the sqlConn.DataSource property is empty whereas on the server with 2005 as the default instance it returns the server name.

Does SQL 2005 have to be the default instance - is their another way to getting the server name correctly?

August 13, 2007 3:46 AM

Leave a Comment

(required) 
(optional)
(required) 
Submit

About Peter DeBetta

Peter DeBetta is an independent consultant specializing in design, development, implementation, and deployment of Microsoft SQL Server, Microsoft SharePoint Server, and .NET solutions. Peter writes courseware, articles, and books – most recently the title Introducing SQL Server 2008 from Microsoft Press. Peter speaks at conferences around the world, including TechEd, SQL PASS Community Summit, DevTeach, SQL Connections, DevWeek, and VSLive!

Peter is a Microsoft MVP for SQL Server, an MCP, President of the North Texas SQL Server User Group, and a member of PASS.

When Peter isn’t working, you can find him singing and playing guitar (click here to hear an original song by Peter), taking pictures, or simply enjoying life with his wife, son, and daughter.
Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement