Click here to Skip to main content
15,886,774 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more:
Hello everyone!

I'm using Microsoft SQL Server 2008 SP1 with latest patches installed. I have found a problem recently: it runs lagre queries very bad.

I have created a simple program in C# as a demo:

C#
namespace Sandbox {
    public class Program {
        private static readonly StringBuilder _idsList = new StringBuilder("1000");

        private static void Main(string[] args) {
            Console.WriteLine("Connecting...");
            SqlConnection conn = new SqlConnection(@"Data Source=(local)\SQLEXPRESS;Integrated Security=SSPI;Persist Security Info=True;Initial Catalog=Test;");
            try {
                conn.Open();

                Console.WriteLine("Connected OK. Testing...");

                for (int i = 1; i < 1000000; i += 1000) {
                    RunSql(conn, i);
                }

                Console.WriteLine("Done.");
            } catch(Exception ex) {
                Console.WriteLine("ERROR: " + ex);
            }
        }

        private static void RunSql(SqlConnection conn, int queryLength) {
            while (_idsList.Length < queryLength) {
                _idsList.Append(", 1000");
            }
            Stopwatch stopWatch = new Stopwatch();
            stopWatch.Start();
            using (SqlCommand cmd = conn.CreateCommand()) {
                StringBuilder cmdText = new StringBuilder("declare @test table (id int) select * from @test where id in ");
                cmdText.AppendFormat("({0})", _idsList);
                cmd.CommandText = cmdText.ToString();
                cmd.ExecuteScalar();
            }

            stopWatch.Stop();
            Console.WriteLine(queryLength + ": \t" + stopWatch.ElapsedMilliseconds + " ms");
        }
    }


This program is simple and straightforward: it generates the following SQL queries:
SQL
declare @test table (id int) 
  select * from @test where id in (1000, 1000, ...)


Everything must be ok but what we see as output:

Console



I have measured the performance from this program and made the plot (query length -> time), here's it:

Plot



I have discovered one interesting moment:
When the query is large, it has last wait type SOS_SCHEDULER_YIELD. WHAT'S THIS???

Query results



Also, as you can see, it consumes too much cpu. If the server is undel heavy load, it can skip this query at all (in this case, we'll get a timeout in the calling code).

Please help.. Any workaround as appreciated.
Thanks in advance
Posted

As far as what SOS_SCHEDULER_YIELD is Read This[^]

As far as your code goes seriously your running 50,000+ values in an IN statement yes it will take some time but if you run the last with 1,000,000 values it still only takes just over 3 seconds, also an IN statement is the same as a whole bunch of OR clauses.

Also when creating a temporary table don't use @table as this creates a very slow local variable of type table, it's like accessing a normal table only through a cursor.
To create a temporary table that is going to hold a large amount of data or have a lot of queries run against it use #table instead.
 
Share this answer
 
v3
RE: Answer 1
Thank you but @table was just a test query.
In my case, query contents doesn't change the matter.

The real case is:
SQL Server was running on multi-processor machine, there are quite heavy load and all the queries (updates, inserts, selects) are okay.
Long queries are yield by the scheduler.
[My proposal] SQL Server's Scheduler thinks: It's a long query and perhaps parsing of it is CPU-intensive; we can run it after the small queries finish.

But on a production server small queries never finish, and as the result the long query is interrupted in a very rude manner. Maybe this is a bug of Microsoft SQL Server Scheduler?

I have read this: http://msdn.microsoft.com/en-us/library/aa175393(SQL.80).aspx

It's said there that SOS_SCHEDULER_YIELD means that a query has voluntarily stopped himself for other threads. Are there any ways to prevent this??

Thanks
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900