SQL Server Performance

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


Tip Topics

All Tips
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

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     

tips >> performance tuning >> Using SQL Server Query Analyzer

Using SQL Server Query Analyzer

By : Brad McGehee
Feb 23, 2006

Page 2 / 3

The SQL Server 2000 Query Analyzer has a tool called "Manage Statistics". Normally, without doing anything, SQL Server automatically creates and maintains internal statistics on the rows in all of your tables that is used by the Query Optimizer to select the optimal execution plan for your query. Most of the time, SQL Server does a fine job doing this, and the Query Optimizer has the necessary information it needs to do its job.

But sometimes, the statistics SQL Server creates and maintains is not optimal, and that's what the Manage Statistics Tool is for. This tool, available from the Tools menu of Query Analyzer, allows you to modify how SQL Server automatically creates and maintains statistics. You can add, edit, or delete the various statistics maintained by SQL Server. And because this tool is available from the Query Analyzer, you can experiment with different sets of statistics and see how it affects the query optimizer's execution plans. [2000] Updated 1-10-2006

*****

If you run the same query in an application, and in Query Analyzer, and note that the performance of the query runs much faster in Query Analyzer than the application, this is an indication that there is a problem with the application causing this problem. One way to help diagnose the problem is to take a Profiler trace of the application running the query and see, in detail, what is really happening. [7.0, 2000] Updated 4-17-2006

*****

When analyzing the performance of a query, viewing the query's Execution Plan can be helpful. An Execution Plan describes how the Query Optimizer plans to, or actual optimized, a particular query. This information is useful because it can be used to help optimize the performance of a query.

There are two ways to display the Execution Plan of a Query. First, you can use the "Display Estimated Execution Plan" option, which displays the proposed Execution Plan for the query you are examining. This plan is displayed for viewing without actually running the query.

Second, you can use the "Show Execution Plan" option. This option also displays a query's Execution Plan, but it is based on the actual Execution Plan used to run the query, not the estimated Execution Plan. In other words, the query is actually run in order for this Execution Plan to be displayed.

As you might expect, there can be a difference between an "estimated" plan and an "actual" plan, but not as much difference as you might think. The main difference between the two is that an "actual" Execution Plan takes into account current activity on your server, while the "estimated" Execution Plan does not. In most cases, the Execution Plan is the same, as server load does not usually make that much difference in a query's Execution Plan.

So which option should you use when analyzing queries? The advantage of the "Estimated" Execution plan is that it runs very quickly (the query does not actually run), which can save a lot of time if the query is a long running one. In addition, some DBAs believe that you should ignore the affect of the server's current performance on an Execution Plan because performance varies from time to time, and this makes it difficult to compare query performance fairly from one run to the next.

On the other hand, an "actual" Execution Plan is the one that really ran. Assuming that the server load, when the query ran and the Execution Plan created, is typical of your server's load, then its results should be ideal for tuning in the real world.

One option you might want to consider is to do your preliminary query analysis using "estimated" Execution Plans, then when you feel that you have optimized the query the best you can, run an "actual" Execution Plan, and take note of any differences, if any.

Whichever option you choose, using Execution Plans to analyze poorly performing queries is a valuable tool. [7.0, 2000] Updated 4-17-2006

*****

In SQL Server 2000, Query Analyzer has a shortcut key feature that allows you to assign commonly run queries or stored procedures to a specific keyboard combination. For example, you might assign sp_helpdb to CTRL-5, for example. This feature can come in handy if you reuse the same code over and over when working in Query Analyzer.

To assign a query or stored procedure to a keyboard combination, go to Tools|Customize from Query Analyzer. [2000] Updated 4-17-2006

*****

SQL Server 2000's Query Analyzer allows you to create Transact-SQL templates that you can use to boost your productivity when coding Transact-SQL. This feature is available from the "Templates" tab of the "Object Browser." Many templates come included with SQL Server 2000, and you can create your own. This makes it very easy for you to store and manage Transact-SQL templates that you can use over and over, saving you much typing time. You can also add as many as you need. To use a template, all you have to do is to drag it from the Object Browser to the code window. [2000] Updated 4-17-2006


<< 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