Hi Paul, thanks for the plan.

Points:

1. No clustered indexes on any of the 4 tables, a suitable clustered index on DeltaFAKT_DETAIL would probably help the expensive SORT in the plan. I'd start with the following columns in that clustered index, in the order shown:

FD.FILIALE_KEY, -- join column

FD.BRANCHE, -- join column

FD.KONSUMFELD, -- join column

FD.KUNDE_KEY,

FD.EK_DATUM,

FD.ABT,

FD.UN_3

I'd also change the GROUP BY to match this order:

GROUP BY

FD.FILIALE_KEY, --

FD.BRANCHE, --

FD.KONSUMFELD, --

FD.KUNDE_KEY,

FD.EK_DATUM,

FD.ABT,

FD.UN_3,

FI.FILIALE,

FI.FILIALE_KTEXT,

FI.FILIALE_VERKAUFSREGION,

FI.FILIALE_SAP_KEY,

BR.BRANCHE,

BR.BRANCHE_BEZ,

BR.BRANCHE_KBEZ,

KON.KONSUMFELD,

KON.KONSUMFELD_BEZ,

KON.KONSUMFELD_KBEZ;

Indexes on the other tables would promote more efficient joins, but their rowcounts are so low that the improvement might not be noticeable.

2. There's a 1:1 join between FILIALE and DeltaFAKT_DETAIL; however the 482,866 row product of this join, once joined with BRANCHE, has 10x the number of rows. Is this correct? Is there a join predicate missing here?

3. Likewise with the join to table KONSUMFELD; the rowcount goes up by a factor of 10.

4. The final output set of 537,859 rows is sufficiently similar to the rowcount of DeltaFAKT_DETAIL to raise an eyebrow.

I'd begin by checking that the join predicates are correct.