SQL Server Performance

  • Home
  • Articles
  • Forums
  • Tips
  • Training
  • FAQ's
  • Blogs
  • Software
  • Books
  • About Us
RSS Feeds
Sign in | Join


Article Topics

All Articles
Performance Tuning
Audit
Business Intelligence
Clustering
Reporting Services
SQL Azure
Developer
General DBA
ASP.NET / ADO.NET
SQL Azure

USEFUL SITES :

ASP.NET Tutorials
Windows and SQL Azure Tutorials
Cloud Hosting Magazine
SharePoint Tutorials
Windows Server Help

Write for Us

Share your SQL Server knowledge with others and raise your profile in the community More...
Latest Articles

A High Level Comparison Between Oracle and SQL Server - Part ...
A High Level Comparison Between Oracle and SQL Server - Part ...
A High Level Comparison Between Oracle and SQL Server - Part ...
A High Level Comparison Between Oracle and SQL Server

More     
 
Latest FAQ's

Add Node to A SQL Server failover Cluster failed with invalid ...
SQL Server Destination remote server error
Setting Up Data And Log Files For SQL Server
Will Check Constraints Improve Database Performance?

More     
   
Latest Software Reviews

dbForge Review
Spotlight on ApexSQL Diff - Server-based database comparison tool ...
Spotlight on ApexSQL Data Diff - Server-based database comparison tool ...
Spotlight on ApexSQL Doc 2008

More     

articles >> performance tuning >> An Introduction to SQL Server Query Tuning ...

An Introduction to SQL Server Query Tuning

By : Randy Dyess
Oct 15, 2004

Page 2 / 3

If you find segments of code that seem to take a little longer than they should, use the following list to try to determine what is wrong in that segment. You should also use this list to optimize all of your code in general even though that code may not show up as a problem segment.

  • Are there any cursors in the code? Cursors are a major performance problem and can usually be worked around. A simple temp table with an IDENTITY field can usually be used to replace the need for just about any cursor.

     
  • Can you reduce the use of temporary tables or the TABLE data type in the query? While these objects have their uses, some developers have a habit of using them when they are not really needed. Ask yourself if a JOIN can be used instead or if a different WHERE clause will eliminate the need for the table. If you can't eliminate the table, see if you can reduce its size with filters or use a table permanently created in a database so you do not have to take the performance hit of creating the table each time it is needed.

     
  • Do you have any statements that modify table structures? Just as creating a temp table in a query, modify tables in queries also cause a performance hit. Look at ways to work around these statements. A generic table may be able to be created that will server your needs.

     
  • Does the query return more data than is needed? Network congestion can cause minor problems with stored procedures. Try not to return more data or columns than is needed by the application. Also try to use SET NOCOUNT ON to reduce the usually unneeded row count that is return by all queries.

     
  • Are you using the sp_executesql system stored procedure instead of the EXECUTE command to run strings? The sp_executesql system stored procedure has a slightly performance advantage over the EXECUTE command. Look into ways to replace EXECUTE with sp_executesql.

     
  • Have you created any transactions within the query? If you create transactions in your code, make sure you can estimate the cost of that transaction. By knowing the cost of the transaction, you can estimate if it will normally take 1 second, 1 minute, or 1 hour for the transaction to complete. Steps can then be taken to simplify the transaction if the estimated cost exceeds a few seconds. Otherwise, you run the chance of introducing very slow queries that might even cause database blocking problems because of the time needed for the transaction to complete.

     
  • Keep the size of the procedure as small as possible by eliminating unneeded code. Ask yourself if that IF statement will ever run all of its branches -- if not remove them. Better yet -- create other stored procedures that handles the function of each IF branch. Also see if there are segments of code that you use over and over again which can be extracted and made into separate stored procedures. Finally, understand the uses of the CASE statement. CASE statements can sometimes eliminate large amounts of code if you know how to use them properly.

     
  • Use the new ANSI JOIN syntax instead of the old style joins. The new join syntax has a slight performance advantage over the old way of using the WHERE clause for a join. The new syntax also tends to have better readability and should become the norm in your Transact-SQL coding.

     
  • Some schools of thought will tell you to replace dynamic portions of your code with parameterized queries. This switch depends on your situation as I have found that in some cases, the dynamic query performs better even though the cached plan is not always used. This is up to your own research based on the query and your database.

     
  • Look for objects that are not called with qualified owner names. Each time the query is run without qualified owner names on the objects referenced within the query, the Optimizer has to hold compile locks on system objects until it can determine if the objects are the same as the ones in the cached plan. Qualifying the owner name will solve this problem and help with performance and blocking problems.

  • Look at the data types being used in WHERE clauses and join statements. Any comparisons of data or joins should be done with the same data types. If the data types are different, then a slight performance hit is taken as the data types are converted before they are compared.


<< Prev Page     Next Page>>    








C# Help and Tutorials | PHP MySQL Tutorial | Sharepoint Tutorial | Azure Tutorial | Cloud Hosting Magazine | ASP.NET Tutorials | Windows Server Help | Windows Phone Pro | Silverlight Ace | Visual Studio Tutorials | Home | Peformance Articles | Audit Articles | Business Intelligence Articles | Clustering Articles | Developer Articles | Reporting Services Articles | DBA Articles | ASP.NET / ADO.NET Articles | SQL Server Training Videos | DBA FAQ's | Developer Peformance FAQ's | DBA Peformance FAQ's | Developer FAQ's | Clustering FAQ's | Error Messages | Audit Tool Reviews | Backup Tool Reviews | Coding Tool Reviews | Compare Tool Reviews | Documentation Tool Reviews | Design Tool Reviews | Monitoring Tool Reviews | Log Tool Reviews | Reporting Tool Reviews | Clustering Tool Reviews | Security Tool Reviews | Change Management Tool Reviews | Remote Access Tool Reviews | Book Reviews | Security Tool Reviews | ADO.NET / ASP.NET | Administration | Analysis/OLAP Services | Application Development | Configuration | Components | ETL | Hardware | High Availability | Hints | Index | Misc | Operating Systems | Performance Tuning | Replication | T-SQL | Views


              © 2010 Jude O'Kelly. All rights reserved