Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 


 
     
Recent Posts
   
Popular Topics
Home   
Search
    Members    Calendar    Who's On

Home » SQL Server 2008 » SQL Server 2008 - General » Previously well-behaved query is now causing...
Add to briefcase
16 posts, Page 2 of 2
««12

Previously well-behaved query is now causing tempdb to choke up Expand / Collapse
Rate Topic
Display Mode
Topic Options
Author
Message
ChrisM@Work
Posted Wednesday, October 31, 2012 8:03 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: 2 days ago @ 9:27 AM
Points: 5,618, Visits: 10,990
How many rows are returned by the SELECT version of the first update in your script?

SELECT PatientKey = P.PatientKey 
, AgeKey = PM.AgeKey 
, GenderKey = P.GenderKey 
, GenderCode = P.GenderCode 
, GPPracticeKey = P.GPPracticeKey 
, GPCodeKey = P.GPCodeKey 
-- , PCTKey = P.PCTKey 
--, PCTCode = P.PCTCode 
--Added on 11/04/2007 
, GPPracticeCode = P.GPPracticeCode 
-- 
, LocationKey = P.LocationKey 
, DeprivationIMDKey = PM.DeprivationIMDKey 
, DeprivationNationalKey = PM.DeprivationNationalKey 
FROM dbo.LoadConsultationsOP SCOP 
INNER JOIN dbo.Patient P ON SCOP.PatientId = P.PatientId 
INNER JOIN dbo.PatientMonths PM ON P.PatientKey = PM.PatientKey 
AND SCOP.DatePeriodKey = PM.DatePeriodKey

You might also want to change the update slightly;
UPDATE SCOP 
SET PatientKey = P.PatientKey 
, AgeKey = PM.AgeKey 
, GenderKey = P.GenderKey 
, GenderCode = P.GenderCode 
, GPPracticeKey = P.GPPracticeKey 
, GPCodeKey = P.GPCodeKey 
-- , PCTKey = P.PCTKey 
--, PCTCode = P.PCTCode 
--Added on 11/04/2007 
, GPPracticeCode = P.GPPracticeCode 
-- 
, LocationKey = P.LocationKey 
, DeprivationIMDKey = PM.DeprivationIMDKey 
, DeprivationNationalKey = PM.DeprivationNationalKey 
FROM dbo.LoadConsultationsOP SCOP 
INNER JOIN dbo.Patient P ON SCOP.PatientId = P.PatientId 
INNER JOIN dbo.PatientMonths PM ON P.PatientKey = PM.PatientKey 
AND SCOP.DatePeriodKey = PM.DatePeriodKey



“Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
Exploring Recursive CTEs by Example Dwain Camps
Post #1379326
Mark Dalley
Posted Wednesday, October 31, 2012 8:43 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, May 16, 2013 4:57 AM
Points: 39, Visits: 788


Was the Tempdb log previously capped?


No, it wasn't, but it is now (10 GB).

@ChrisM@Work

Number of recs returned by your SELECT version of the query is unknown but large...it has now been running for 28 minutes, no 34 minutes; and is still going!!

What does SELECT PatientKey = P.PatientKey, AgeKey = PM.AgeKey ... mean - in a SELECT query that is? are the assignments just ignored?

Hmm, just looked at the PatienMonths table - it has 47303750 records and occupies 2,469.805 MB data space and 816.430 MB index space!

MarkD
Post #1379361
ChrisM@Work
Posted Wednesday, October 31, 2012 9:20 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: 2 days ago @ 9:27 AM
Points: 5,618, Visits: 10,990
There’s your problem. You’re only updating a maximum of a few tens of thousands of rows in the target table, but the source – now rejigged as a SELECT for this purpose, is returning millions. The SELECT shouldn’t return more than one row per target row. In some RDBMS it would throw an error, and SQL Server is heading in the right direction with MERGE, which won’t allow more than one source row per target row.
Flag it up with the vendor as a lemon, it’s cost you time and money and justifies an immediate rewrite.

“Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
Exploring Recursive CTEs by Example Dwain Camps
Post #1379381
Jason-299789
Posted Wednesday, October 31, 2012 9:27 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, May 22, 2013 1:30 AM
Points: 803, Visits: 2,124
What does SELECT PatientKey = P.PatientKey, AgeKey = PM.AgeKey ... mean - in a SELECT query that is? are the assignments just ignored?


Its practiacally the same as doing : Select P.PaitentKey AS PatientKey,.......

_________________________________________________________________________
SSC Guide to Posting and Best Practices
Post #1379386
Jason-299789
Posted Wednesday, October 31, 2012 9:29 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, May 22, 2013 1:30 AM
Points: 803, Visits: 2,124
ChrisM@Work (10/31/2012)
There’s your problem. You’re only updating a maximum of a few tens of thousands of rows in the target table, but the source – now rejigged as a SELECT for this purpose, is returning millions. The SELECT shouldn’t return more than one row per target row. In some RDBMS it would throw an error, and SQL Server is heading in the right direction with MERGE, which won’t allow more than one source row per target row.
Flag it up with the vendor as a lemon, it’s cost you time and money and justifies an immediate rewrite.


+1, The supplier should have someone on hand to deal with this, and I wouldnt accept that the 'relevant' person is on holiday as an excuse either.

_________________________________________________________________________
SSC Guide to Posting and Best Practices
Post #1379389
Mark Dalley
Posted Wednesday, October 31, 2012 9:59 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, May 16, 2013 4:57 AM
Points: 39, Visits: 788
I have now killed the SELECT query, which was still churning away after more than an hour.

Many thanks everyone for helping to nail this one. I can now make my case to the vendor in really distinct and specific terms.

You guys rock.

MarkD
Post #1379410
« Prev Topic | Next Topic »

Add to briefcase
16 posts, Page 2 of 2
««12

Permissions Expand / Collapse

 
 
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.