6

I have a simple select statement. It's basically 2 CTE's, one includes a ROW_NUMBER() OVER (PARTITION BY, then a join from these into 4 other tables. No functions or anything unusual.

WITH Safety_Check_CTE AS 
(
    SELECT  
        Fact_Unit_Safety_Checks_Wkey,
        ROW_NUMBER() OVER (PARTITION BY [Dim_Unit_Wkey], [Dim_Safety_Check_Type_Wkey] 
                           ORDER BY [Dim_Safety_Check_Date_Wkey] DESC) AS Check_No
    FROM 
        [Pitches].[Fact_Unit_Safety_Checks]
), Last_Safety_Check_CTE AS 
(
    SELECT 
        Fact_Unit_Safety_Checks_Wkey 
    FROM 
        Safety_Check_CTE 
    WHERE 
        Check_No = 1
)
SELECT
    COUNT(*)
FROM
    Last_Safety_Check_CTE lc
JOIN 
    Pitches.Fact_Unit_Safety_Checks f ON lc.Fact_Unit_Safety_Checks_Wkey = f.Fact_Unit_Safety_Checks_Wkey
JOIN 
    DIM.Dim_Unit u ON f.Dim_Unit_Wkey = u.Dim_Unit_Wkey
JOIN 
    DIM.Dim_Safety_Check_Type t ON f.Dim_Safety_Check_Type_Wkey = t.Dim_Safety_Check_Type_Wkey
JOIN 
    DIM.Dim_Date d ON f.Dim_Safety_Check_Date_Wkey = d.Dim_Date_Wkey
WHERE 
    f.Safety_Check_Certificate_No IN ('GP/KB11007') --option (maxdop 1)

Sometimes it returns 0, 1 or 2 rows. The result should obviously be consistent.

I have ran a profile trace whilst replicating the issue and my session was the only one in the database.

I have compared the Actual execution plans and they are both the same, except the final hash match returns the differing number of rows.

I cannot replicate if I use MAXDOP 0.

Plan Comparison

paparazzo
  • 44,497
  • 23
  • 105
  • 176
Mike Fleming
  • 107
  • 1
  • 9
  • Please [edit] the question and specify the SQL Server version + Service Packs installed. Run `select @@VERSION` if needed. And see here for an (old) very similar issue regarding MAXDOP: https://www.sqlteam.com/forums/topic.asp?TOPIC_ID=156173 – Peter B Nov 19 '18 at 14:35
  • 2
    My guess is ORDER BY [Dim_Safety_Check_Date_Wkey] is not deterministic. – paparazzo Nov 19 '18 at 14:47
  • Microsoft SQL Server 2016 (SP2-CU3) (KB4458871) - 13.0.5216.0 (X64) Sep 13 2018 22:16:01 Copyright (c) Microsoft Corporation Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2012 R2 Standard 6.3 (Build 9600: ) (Hypervisor) – Mike Fleming Nov 19 '18 at 14:53
  • Hi Paparazzo, that looks correct. Thanks – Mike Fleming Nov 19 '18 at 15:04

2 Answers2

1

In case you use my comment as the answer.

My guess is ORDER BY [Dim_Safety_Check_Date_Wkey] is not deterministic.

paparazzo
  • 44,497
  • 23
  • 105
  • 176
1

In the CTE's you are finding the [Fact_Unit_Safety_Checks_Wkey] that's associated with the most resent row for any given [Dim_Unit_Wkey], [Dim_Safety_Check_Type_Wkey] combination... With no regard for weather or not [Safety_Check_Certificate_No] is equal to 'GP/KB11007'.

Then, in the outer query, you are filtering results based on [Safety_Check_Certificate_No] = 'GP/KB11007'.

So, unless the most recent [Fact_Unit_Safety_Checks_Wkey] happens to have [Safety_Check_Certificate_No] = 'GP/KB11007', the data is going to be filtered out.

Jason A. Long
  • 4,382
  • 1
  • 12
  • 17
  • If the most recent row is repeatable then the count should repeat. – paparazzo Nov 19 '18 at 15:44
  • @paparazzo - Yes, assuming that there are no changes to the underlying data, the query should yield repeatable results. But, I don't see anything in the OP that would indicate that is the case. – Jason A. Long Nov 19 '18 at 16:20
  • See my answer. If the OP states results should be the same then I trust they are not changing data. – paparazzo Nov 19 '18 at 16:22
  • I saw your answer. A unique set of date values will always sort in the same order. That said, it's entirely possible that that the same date key is exists on multiple rows, essentially creating ties and those ties could be getting broken differently with each execution. Assuming that's the case, my answer still applies. As far as trusting the what the OP is or isn't doing... I don't take anything for granted. – Jason A. Long Nov 19 '18 at 16:42
  • Not the same. OP did comment I was correct. Good day. I not not vote you down. – paparazzo Nov 19 '18 at 16:45