Indefinite CPU Utilization while no IO movement

Question

Env: SQL Server 2008R2.
RAM: 32GB
Processors: 4
Schema:
TableA (ACC int, TimePartOnly varchar, Office varchar, Store Varchar,EUNum int, sales int)
TableA has a million records.
TableB (TimePartOnly)
TableB has only 200 records.
Statistics updated, Indexes defragged. Very less concurrent work load.
SELECT
A.Acc,
B.[TimePartOnly],
EUNum,
Office,
Store,
SUM(A.Sales) AS AMOUNT
from
TableA A
CROSS JOIN TableB B
WHERE A.TimePartOnly <= B.TimePartOnly
Group by A.Acc,
B.TimePartOnly,
EUNum,
Office,
Store
having sum(SALES) <> 0
Issue: The above query runs for ever (more than 4 hours and then I cancelled it).
I see in sys.dm_exec_request or sp_who2 the CPU is increasing but the IO almost gets stalled after 5-6 seconds of running.
If I use the default 0 as maxdop, the query remains in the CXPacket but when I use the maxdop of 1 it is not even reflected in sys.dm_exec_request where as in sp_who2 its status is runnabel not running.
So my understand is that it goes in the processing mode for ever.
I then further did a change and from tableA which has a million records, I removed all records except 50K records and the results came back in 35 seconds.
I saw the execution plan and the most strage thing was the 'Hash Join' operator was showing 52% of the over all cost.
Now I pumped the data back in and again the same issue.
As per my understanding (may be incorrect), the following part makes it worse.
WHERE A.TimePartOnly <= B.TimePartOnly
This means A will do the processing for every match from tableB where the value of A is less than or equal to the value in B.
However, I am not sure if there is a way to fix it as it looks to be a business requirement.
Please advice if there can be something else done with the above query.

Answer 1

Hi Aanya,
This is a interesting issue and I'm sure others will be able to contribute better than me.
However let me make few comments
- The syntax that I would have preferred would be
FROM TableA A INNER JOIN TableB B ON A.TimePartOnly < B.TimePartOnly
although the syntax that you used (Cross Join with where clause) should result in same optimization. But you can give this a try. See if execution plan changes.
- You can add another where condition WHERE A.Sales <> 0.  The condition in HAVING clause will also be required as sum of positive/negative number might again results in 0.
- Are there any indexes at play here? Are those being utilized ?
I suppose after a while there would be no I/O activity as it must have read all the rows from both the tables and you are not writing output to any other table.  It must be generating the combinations of the rows in the memory and showing it in your
SSMS window (there should be network activity for that).
Cheers
liquidloop[at]live[dot]co[dot]uk