Question

Setup

  • Cost of Threshold for Parallelism : 5
  • Max Degree of Parallelism : 4
  • Number of Processors : 8
  • SQL Server 2008 10.0.2.2757
  • I have a query with many joins, many records.
  • The design is a star. ( Central table with fks to the reference tables )
  • The central table is partitioned on the relevant date column.
  • The partition schema is split by days
  • The data is very well split across the partition schema - as judged by comparing the sizes of the files in the filegroups assigned to the partition schema
  • Queries involved have the predicate set over the partitioned column. such as ( cs.dte >= @min_date and cs.dte < @max_date )
  • The values of the date parameters are a day apart @ midnight so, 2010-02-01, 2010-02-02
  • The estimated query plan shows no parallelism

a) This question is in regards to Sql Server 2008 Database Engine. When a query in the OLTP engine is running, I would like to see / have the sort of insight one gets when profiling an SSAS Query using Progress End event - where one sees something like "Done reading PartititionXYZ".

b) if the estimated query plan or the actual query plan shows no parallel processing does that mean that all partitions will be / were checked / read? * What I was trying to say here was - just b/c I don't see parallelism in a query plan, that doesn't guarantee the query isn't hitting multiple partitions - right? Or - is there a solid relationship between parallelism and # partitions accessed?

c) suggestions? Is there more information that I need to provide?

d) how can I tell if a query is processing in parallel w/o looking @ the actual query plan? * I'm really only interested in this if it is helpful in pinning down what partitions are being used.


Added Nov 10

Try this:

  • Create querys that should hit 1, 3, and all your partitions
  • Open an SSMS query window, and run SET SHOWPLAN_XML ON
  • Run each query one by one in that window
  • Each run will kick out a chunk of XML
  • Compare these XML results (I use a text diff tool, “CompareIt”, but any similar tool would do)

You should see that the execution plans are significantly different. In my “3” and “All” querys, there’s a chunk of text tagged as “ConstantScan” that has an entry for (respectively) 3 and All partitions in the table, and that section is not present for the “1 partition” query. I use this to infer that yes indeed, SQL doing what it says it will do, to wit: only read as much of the table as it believes it needs to in order to resovle the query.

Was it helpful?

OTHER TIPS

a) I am not aware of any way to determine how a query has progressed while the query is still running. Maybe something finicky with the latching and locking system views, but I doubt it. (I am, alas, not familiar enough with SSAS to draw parallels between the two.)

b) SQL will probably use parallelism when working with multiple partitions within a single table, in which case you will see parallel processing "tokens" in your query plan. However, if for whatever reason parallelism is not invoked yet multiple partitions must be read, they will be read without the use of parallelism.

d) Another thing that perhaps cannot be done. Under very controlled cirsumstances, you could use System Monitor (Perfmon) to track CPU usage or perhaps disk reads during the execution of they query. This won't help if the server is performing other work, or the data is resident in memory (the buffer cache), and so may be of limited use.

c) What is it you are actually trying to figure out? Which partitions (if any) are being accessed by users over a period of time? Is SQL generating a "smart" query plan? Without details of the data, structure, and query, it's hard to come up with advice.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top