SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Tuning a query that takes 60 minutes to run,


Tuning a query that takes 60 minutes to run,

Author
Message
rajsin7786
rajsin7786
Valued Member
Valued Member (58 reputation)Valued Member (58 reputation)Valued Member (58 reputation)Valued Member (58 reputation)Valued Member (58 reputation)Valued Member (58 reputation)Valued Member (58 reputation)Valued Member (58 reputation)

Group: General Forum Members
Points: 58 Visits: 151
hi sean,

sales_fact has 1 billion records, other 3 tables have less than 100K records
Sean Lange
Sean Lange
One Orange Chip
One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)

Group: General Forum Members
Points: 26129 Visits: 17539
rajsin7786 (7/30/2014)
hi sean,

sales_fact has 1 billion records, other 3 tables have less than 100K records


That is how many rows, not the amount of movement. The reason I ask is looking at your execution plan you have differences in some cases between estimated and actual rows in the millions. That is a good indication that your stats are stale.

_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Modens splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
rajsin7786
rajsin7786
Valued Member
Valued Member (58 reputation)Valued Member (58 reputation)Valued Member (58 reputation)Valued Member (58 reputation)Valued Member (58 reputation)Valued Member (58 reputation)Valued Member (58 reputation)Valued Member (58 reputation)

Group: General Forum Members
Points: 58 Visits: 151
hi sean, sorry i am novice to DB so couldn't really understand what data movement means. You are correct the stats are stale. but i have a test environment, i update the stats for these tables in the test and ran the query but it took exactly the same time 50 mins to run.

did you mean how much data is added to each table per day? if so then the there are about a million records added to the sales_fact everyday
Chris Hurlbut
Chris Hurlbut
SSCommitted
SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)

Group: General Forum Members
Points: 1850 Visits: 540
Hello,

We just had a meeting a few months ago given by a DBA to us developers...
Big advice to us was to take the Items in a WHERE Clause (if you can), apply the logic to JOINS.
Something like this:
SELECT
Live.dbo.sales_fact.trans_ref,
Live.dbo.product_dim.pd_key,
Live.dbo.product_dim.pd_desc,
Live.dbo.multibuy_dim.mb_deal_number,
Live.dbo.sales_fact.LoyaltyNo,
sum(Live.dbo.sales_fact.qty),
sum(Live.dbo.sales_fact.totalPriceExVat),
( sum(Live.dbo.sales_fact.company_margin) ) - isnull((( sum(Live.dbo.sales_fact.wastageval) )),0)
FROM
Live.dbo.multibuy_dim INNER JOIN Live.dbo.sales_fact ON (Live.dbo.sales_fact.multibuy_id=Live.dbo.multibuy_dim.mb_id)
INNER JOIN Live.dbo.product_dim ON (Live.dbo.sales_fact.product_id=Live.dbo.product_dim.pd_id)
INNER JOIN Live.dbo.date_dim ON (Live.dbo.date_dim.date_id=Live.dbo.sales_fact.date_id)
AND ( Live.dbo.date_dim.date ) between DATEADD(WEEK, -3, (select min(date) from date_dim where last_week_prior_flag = 'Y'))
AND (select max(date) from Live.dbo.date_dim where Live.dbo.date_dim.last_week_prior_flag= 'Y' )

WHERE
(
Live.dbo.product_dim.pd_key IN ('481005', '850972', '860091', '860101', '860110', '860130', '860159', '860161', '860211', '860224', '860225', '860230', '860265', '860319', '860320', '860344', '860360', '860407', '860414', '860415', '860418', '860469', '860478', '871005', '874115', '874206', '880100', '881153', '890061', '890299', '890360', '890648', '890650', '890651', '891903')
AND
(
Live.dbo.multibuy_dim.mb_deal_number = '0000'
OR
Live.dbo.multibuy_dim.mb_deal_number Is Null
)

)
GROUP BY
Live.dbo.sales_fact.trans_ref,
Live.dbo.product_dim.pd_key,
Live.dbo.product_dim.pd_desc,
Live.dbo.multibuy_dim.mb_deal_number,
Live.dbo.sales_fact.LoyaltyNo


Evil Kraig F
Evil Kraig F
SSCrazy Eights
SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)

Group: General Forum Members
Points: 8599 Visits: 7660
churlbut (7/30/2014)
Hello,

We just had a meeting a few months ago given by a DBA to us developers...
Big advice to us was to take the Items in a WHERE Clause (if you can), apply the logic to JOINS.


Whut? Why would he recommend that? WHERE or ON clause basically only matters as to the application of OUTER JOIN logic. Predicates are predicates. What reasoning and examples did he use to support this statement?


- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
Sean Lange
Sean Lange
One Orange Chip
One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)

Group: General Forum Members
Points: 26129 Visits: 17539
Evil Kraig F (7/30/2014)
churlbut (7/30/2014)
Hello,

We just had a meeting a few months ago given by a DBA to us developers...
Big advice to us was to take the Items in a WHERE Clause (if you can), apply the logic to JOINS.


Whut? Why would he recommend that? WHERE or ON clause basically only matters as to the application of OUTER JOIN logic. Predicates are predicates. What reasoning and examples did he use to support this statement?


I have heard others regurgitate that same myth. Not sure where it came from or why it perpetuates. w00t

_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Modens splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
Evil Kraig F
Evil Kraig F
SSCrazy Eights
SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)

Group: General Forum Members
Points: 8599 Visits: 7660
Sean Lange (7/30/2014)
Evil Kraig F (7/30/2014)
churlbut (7/30/2014)
Hello,

We just had a meeting a few months ago given by a DBA to us developers...
Big advice to us was to take the Items in a WHERE Clause (if you can), apply the logic to JOINS.


Whut? Why would he recommend that? WHERE or ON clause basically only matters as to the application of OUTER JOIN logic. Predicates are predicates. What reasoning and examples did he use to support this statement?


I have heard others regurgitate that same myth. Not sure where it came from or why it perpetuates. w00t


It's nuts. If anything, it's backwards. A subselect in an ON clause has the possibility of running for every row if it's non-deterministic (an honest mistake by an uninformed coder), whereas the WHERE clause should run and cache since you have to make it deterministic (well, as per the query parameters, just not row dependent) so the query runs right.

Gyeah. No no no. Churlbut, please get your DBA on here and start up a thread on this. I'd love to see his justifications for this and be able to work with him to dismiss this myth, at least for one person. Gotta start somewhere.

EDIT: On a side note, I was debating on if I should do another article, this one for tech instead of soft stuff. I may have found a topic...


- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
Sean Lange
Sean Lange
One Orange Chip
One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)

Group: General Forum Members
Points: 26129 Visits: 17539
Evil Kraig F (7/30/2014)

EDIT: On a side note, I was debating on if I should do another article, this one for tech instead of soft stuff. I may have found a topic...


Sounds like a good one. I will help proofread if you want. :-P

_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Modens splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
ScottPletcher
ScottPletcher
SSCertifiable
SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)

Group: General Forum Members
Points: 7901 Visits: 7155
I suspect it's because SQL's internal processing does "ON" clauses before WHERE clauses.

Therefore, I think they figure the ON clause might eliminate rows sooner than a WHERE clause, and avoid joining unwanted rows. To me, that's a logical goal, then, as far as it goes. But, I know that SQL will pull comparison values out of the WHERE and include them on the underlying table seek. So does putting them in the ON clause really save anything? I'm not sure, would have to create some test cases.

SQL DBA,SQL Server MVP(07, 08, 09)[size=2]Prosecutor James Blackburn, in closing argument in the Fatal Vision murders trial: If in the future, you should cry a tear, cry one for them [the murder victims]. If in the future, you should say a prayer, say one for them. And if in the future, you should light a candle, light one for them.[/size]
Chris Hurlbut
Chris Hurlbut
SSCommitted
SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)

Group: General Forum Members
Points: 1850 Visits: 540
I posted my reply just to give the original poster something to test. I usually don't put sub-selects in my joins but If I am desperate I will consider anything...
The point was not the sub-select but weeding records out before they are selected makes sense to me.
I definitely don't have all the answers and a lot of what I do is trial and error...

I do know one thing, I would rather work with someone who is willing to try new things and consider new ideas than someone who is adamant they are right and that is that...
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search