Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««1234»»

Why Object Qualification is important. Expand / Collapse
Author
Message
Posted Monday, March 10, 2008 9:12 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, August 13, 2013 11:43 AM
Points: 242, Visits: 433
Bother. At least I have them running separately through the Job Agent rather than calling each other so I'll only have to change them in one place. Thanks for letting me know Roy.


Puto me cogitare, ergo puto me esse.
I think that I think, therefore I think that I am.
Post #466748
Posted Monday, March 10, 2008 9:25 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, July 23, 2014 1:01 PM
Points: 266, Visits: 2,567
Fun article and great discussion. Thanks.
Post #466756
Posted Monday, March 10, 2008 9:33 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Thursday, July 24, 2014 9:07 AM
Points: 11,157, Visits: 12,899
I did a quick test kind of following Gregory's suggestion except I did not use profiler I user Set Statistics Time On. The first thing I did was create a user who did not "own" the dbo schema nor have dbo as it's default schema, but did have select permissions on the dbo schema. I wanted to make sure I was crossing schemas. I also ran DBCC DropCleanBuffers and DBCC FreeProcCache between each execution. Then I ran it only executing the DBCC statements before the first run of each query. The query did use a covering non-clustered index as well. I was trying to stick it in here, but decided the formatting wasn't appropriate so I attached an Excel file instead.

A quick summary is that, if the plan is in cache they took about the same time. When the plan was not in cache, the non-qualified query took about 33ms to parse and compile and the qualified query to 1ms to parse and compile. This is a very big difference in performance.

I also ran it with the users default schema being DBO, results not in the Excel File, and the Parse and Compile times were the same after running the DBCC statements. This would lead me to believe that in SQL 2005, if you have only 1 schema, that they both perform the same way. I am not going to make any definitive statements based on this limited testing though.

I think the biggest argument for using fully qualified names in ad-hoc SQL is consistency so that you only get 1 plan in cache for each query vs. 1 for non-qualified queries and 1 for qualified queries. This allows you to have more distinct plans in the cache.

Paul,

I guess I was slightly confused in terminology between compiled and cached. I know that ad-hoc queries plans are cached and, after looking it up in BOL, realize that this is what compilation really is. Thanks for the prompt.






Jack Corbett

Applications Developer

Don't let the good be the enemy of the best. -- Paul Fleming

Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
How to Post Performance Problems
Crosstabs and Pivots or How to turn rows into columns Part 1
Crosstabs and Pivots or How to turn rows into columns Part 2


  Post Attachments 
Object Qualification Test.xls (23 views, 21.50 KB)
Post #466763
Posted Monday, March 10, 2008 9:42 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Thursday, July 17, 2014 10:43 AM
Points: 3,309, Visits: 6,700
Hey Jack,
Thanks for the excel file. Thats a pretty good testing.. :)


-Roy
Post #466773
Posted Monday, March 10, 2008 10:16 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, August 12, 2009 10:14 AM
Points: 18, Visits: 167
To recap...is the consensus that using non-fully qualified object names, including for tables, stored procedures, and other objects, will have a performance hit for both SQL 2000 and SQL 2005?
Post #466799
Posted Monday, March 10, 2008 10:19 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Thursday, July 17, 2014 10:43 AM
Points: 3,309, Visits: 6,700
Sideout, Yes it is always better to call objects with their qualifier.


-Roy
Post #466801
Posted Monday, March 10, 2008 11:17 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, December 20, 2012 1:03 PM
Points: 265, Visits: 589
Good article, but perhaps a bit overreaching in its conclusions: "The best thing to do is to make sure you qualify all objects with the Schema (Also known as Owner)"

Well, good advice if you're dealing with one server and single schemas or need to optimize for in specific instances. But if you're writing procedures that need to run across many schemas, servers, and automatically pick the right tables without undue hard coding makes sense.

For example, I have several lookup tables with the same names but with different data on different servers, schemas, and so on. But my stored procedures are the same across all machines. By not using dbo, I let the appropriate table get picked up at execution time. Price I pay is minimal compared to managing customized code for each server. To save compute cycles, fully qualified names could make a difference in certain circumstances, but to save programmer cycles, then the substitution model could be your friend.
Post #466844
Posted Monday, March 10, 2008 11:28 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, August 13, 2013 11:43 AM
Points: 242, Visits: 433
sjsubscribe (3/10/2008)
Well, good advice if you're dealing with one server and single schemas or need to optimize for in specific instances. But if you're writing procedures that need to run across many schemas, servers, and automatically pick the right tables without undue hard coding makes sense.

For example, I have several lookup tables with the same names but with different data on different servers, schemas, and so on. But my stored procedures are the same across all machines. By not using dbo, I let the appropriate table get picked up at execution time. Price I pay is minimal compared to managing customized code for each server. To save compute cycles, fully qualified names could make a difference in certain circumstances, but to save programmer cycles, then the substitution model could be your friend.

Do you have difference lookup tables in the same database with different owners, or are they owned by dbo but in different databases/on different servers? If you need different results within the same database then the substitution method makes sense, but using the two-part name wouldn't impact the functionality you're looking for if the relevant tables are all owned by dbo in different databases.

Three part naming is obviously right out in your situation, but my understanding is that three part naming has no performance advantage to the more flexible two part naming.



Puto me cogitare, ergo puto me esse.
I think that I think, therefore I think that I am.
Post #466851
Posted Monday, March 10, 2008 12:10 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, December 20, 2012 1:03 PM
Points: 265, Visits: 589
Do you have difference lookup tables in the same database with different owners, or are they owned by dbo but in different databases/on different servers?


Yes.

he best thing to do is to make sure you qualify all objects with the Schema...


No. It's not the best thing.
Post #466868
Posted Monday, March 10, 2008 12:23 PM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, August 13, 2013 11:43 AM
Points: 242, Visits: 433
sjsubscribe (3/10/2008)
Do you have difference lookup tables in the same database with different owners, or are they owned by dbo but in different databases/on different servers?


Yes.

Are you saying that both apply, or was I unclear in phrasing my question?
he best thing to do is to make sure you qualify all objects with the Schema...


No. It's not the best thing.

While basically everything falls into "It depends", it is still often, if not quite universally, advisable. 32ms of compile time may be insignificant, and a few ms on each run may be acceptable, but unless there is a specific need to choose a less efficient method, efficient is preferred.



Puto me cogitare, ergo puto me esse.
I think that I think, therefore I think that I am.
Post #466874
« Prev Topic | Next Topic »

Add to briefcase «««1234»»

Permissions Expand / Collapse