If you think that a query should run in parallel but does not, possible explanations are:
The max parallel degree configuration parameter is set to 1, or the session-level setting set parallel_degree is set to 1, preventing all parallel access.
The max scan parallel degree configuration parameter is set to 1, or the session level setting set scan_parallel_degree is set to 1, preventing hash-based parallel access.
There are insufficient worker threads at execution time. Check for runtime adjustments, using the tools discussed in “Runtime adjustments to worker processes”.
The scope of the scan is less than 20 data pages. This can be bypassed with the (parallel) clause.
The plan calls for a table scan and:
The table is not a heap,
The table is not partitioned,
The partitioning is unbalanced, or
The table is a heap but is not the outer table of a join.
The last two conditions can be bypassed with the (parallel) clause.
The plan calls for a clustered index scan and:
The table is not partitioned, or
The partitioning is unbalanced. This can be bypassed with the (parallel) clause.
The plan calls for a nonclustered index scan, and the chosen index covers the required columns.
The table is a temporary table or a system table.
The table is the inner table of an outer join.
A limit has been set through the Resource Governor, and all parallel plans exceed that limit in terms of total work.
The query is a type that is not made parallel, such as an insert, update, or delete command, a nested (not the outermost) query, or a cursor.
