Click here to Skip to main content
16,005,389 members
Home / Discussions / Database
   

Database

 
GeneralRe: Parameterized query Pin
Javier Lozano23-Jun-05 16:59
Javier Lozano23-Jun-05 16:59 
GeneralRe: Parameterized query Pin
Colin Angus Mackay23-Jun-05 21:09
Colin Angus Mackay23-Jun-05 21:09 
GeneralRe: Parameterized query Pin
csylesh24-Jun-05 7:56
csylesh24-Jun-05 7:56 
GeneralRe: Parameterized query Pin
Colin Angus Mackay24-Jun-05 8:04
Colin Angus Mackay24-Jun-05 8:04 
GeneralRe: Parameterized query Pin
csylesh27-Jun-05 6:33
csylesh27-Jun-05 6:33 
GeneralUnderstanding of Execution Plan????? Pls help me out!! Pin
under281123-Jun-05 3:54
under281123-Jun-05 3:54 
GeneralRe: Understanding of Execution Plan????? Pls help me out!! Pin
Colin Angus Mackay23-Jun-05 4:26
Colin Angus Mackay23-Jun-05 4:26 
GeneralRe: Understanding of Execution Plan????? Pls help me out!! Pin
Mike Dimmick24-Jun-05 3:23
Mike Dimmick24-Jun-05 3:23 
1. The most important thing, generally, to look at is whether the operations being performed are what you think should be performed. Are any indexes being maintained that you think are unnecessary? Is an index being ignored? If there are multiple steps in a query (perhaps this was a batch of statements, or a stored procedure) look first at the one that consumed the most time - this is reported as a percentage. Concentrate your efforts on improving the subtrees that consumed the most time.

2. These are the operations being performed. The SELECT operator returns the rows returned by the operations to its right to the client - as such it doesn't add very much overhead at all. TOP guides the operations to the right to stop once the given number of rows are returned.

A Hash Match[^] is a way of performing a join, useful if there are a lot of join conditions. The server builds a hash table for both the left and right sides and compares the hash values to determine if there's a match. The Left Anti Semi Join[^] means that rows that are in the first but not in the second are returned - your query probably uses NOT IN, or similar.

Hash matches tend to be used if no suitable index was used. If a suitable index is available, and the number of rows to be returned is small, SQL Server will normally use nested loops with an index seek to find rows in the second table.

3. An Index Scan is where SQL Server starts at the beginning of the index and reads every row, to the end, looking for rows that match. Compare this to an Index Seek, where SQL Server looks directly for a particular value by looking in the right place. It's the difference between looking for an entry in a phone book by starting at the beginning and looking at every page, and looking instead for the first letter, then the next letter, etc.

a) This is the number of rows that were actually returned by this operator.

b) This is how big each row was. If the source was an actual database table, this is the size of the row from the table. Multiplying this by the number of rows gives an indication of how much data needed to be transferred from disk or read from buffers. If the query plan includes a Spool operator, it indicates how much needed to be written out to the disk and re-read.

c) I/O cost - seconds spent waiting for data to be retrieved from disk

d) CPU Cost - seconds of CPU time spent

e) Number of executes - the number of times this operator was executed. If a child of a 'nested loops' operation, the larger data set will show as 1, while the smaller will be the number of rows returned from the larger set, typically (because for each entry in the data set, the execution engine performs the second operation to find rows that match).

f) Cost - total cost of this operation, which is I/O + CPU cost

h) Subtree cost - seconds of time spent executing this operation and the operations to the right of it

i) Estimated row count - number of rows that SQL Server estimated that this operation would produce, based on the statistics it keeps for indexes and optionally for other columns too.

4. Compute Scalar[^] simply calculates values from other values in the row. This seems to also appear if you have text, ntext or image type columns - an additional lookup has to occur to find the data if it's not stored in the row.

5. Stream Aggregate/Aggregate computes aggregate expressions such as SUM, AVG, COUNT, etc. The difference between Stream Aggregate and Aggregate is that Stream Aggregate requires that the data is already sorted into the correct groups.

6. Table Scan[^] reads the table from beginning to end to match rows.

Why would SQL Server choose an Index Scan rather than a Table Scan? It has to do with how the index is implemented. Basically, all the columns listed in the index definition are duplicated in the index data, plus the lookup key to correlate this entry in the index back into the main table. If the table has a clustered index, this lookup key is the data from the columns that make up the clustered index. If all the columns needed for the query are included in the index, SQL Server may decide to read the index rather than the table itself. Doing so will reduce the amount of data that needs to be read from disk, since the index row size is smaller than the table row size.

The first thing I'd do would be to try to turn your table scans and index scans into index seeks. To do that we have to make your existing indexes work better and perhaps add new indexes. First, ensure that you're not trying to optimise an operation that will occur very rarely - introducing new indexes to speed up this operation will normally slow down insert, update and delete operations as the indexes need to be maintained. Of course an index may also speed up write operations as the appropriate place for the record may be found faster.

Without seeing the data it's hard to say what could help. The Index Tuning Wizard will be able to offer some suggestions. Ensure you give it a decent amount of realistic trace data.

Stability. What an interesting concept. -- Chris Maunder
GeneralAbout Store Procedure. Pin
Blue_Skye23-Jun-05 1:22
Blue_Skye23-Jun-05 1:22 
GeneralRe: About Store Procedure. Pin
Colin Angus Mackay23-Jun-05 2:15
Colin Angus Mackay23-Jun-05 2:15 
GeneralRe: About Store Procedure. Pin
Blue_Skye23-Jun-05 5:39
Blue_Skye23-Jun-05 5:39 
QuestionHow I can debug a dll file Pin
Deepa.N22-Jun-05 23:30
Deepa.N22-Jun-05 23:30 
AnswerRe: How I can debug a dll file Pin
Andre.Net23-Jun-05 0:31
Andre.Net23-Jun-05 0:31 
Questionmaster.dbo.spt_values means?????? Pin
under281122-Jun-05 23:23
under281122-Jun-05 23:23 
QuestionList All Triggers in Database ? Pin
Andre.Net22-Jun-05 22:20
Andre.Net22-Jun-05 22:20 
GeneralADO.NET --> Dataset... Pin
Khanh Duy22-Jun-05 16:32
Khanh Duy22-Jun-05 16:32 
GeneralRe: ADO.NET --> Dataset... Pin
Sindhu Saravanan28-Jun-05 4:03
sussSindhu Saravanan28-Jun-05 4:03 
GeneralMicrosoft.JET Engine- need help Pin
...---...22-Jun-05 15:50
...---...22-Jun-05 15:50 
GeneralObject must implement IConvertible Pin
gharryh22-Jun-05 8:05
gharryh22-Jun-05 8:05 
GeneralBARCODE (Code39) Pin
OMalleyW22-Jun-05 7:42
OMalleyW22-Jun-05 7:42 
GeneralAny Comments? Pin
OMalleyW23-Jun-05 3:51
OMalleyW23-Jun-05 3:51 
GeneralRe: BARCODE (Code39) Pin
Mike Dimmick24-Jun-05 2:38
Mike Dimmick24-Jun-05 2:38 
GeneralRe: BARCODE (Code39) Pin
OMalleyW24-Jun-05 4:12
OMalleyW24-Jun-05 4:12 
GeneralRe: BARCODE (Code39) Pin
Ian Darling29-Jun-05 23:22
Ian Darling29-Jun-05 23:22 
GeneralRe: BARCODE (Code39) Pin
OMalleyW30-Jun-05 10:58
OMalleyW30-Jun-05 10:58 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.