Click here to Skip to main content
15,904,500 members
Home / Discussions / Database
   

Database

 
GeneralRe: Databases concurrecny issues Pin
Mike Dimmick2-Oct-03 3:37
Mike Dimmick2-Oct-03 3:37 
GeneralRe: Databases concurrecny issues Pin
SimonS2-Oct-03 22:46
SimonS2-Oct-03 22:46 
GeneralDataRowState Problems Pin
Wjousts1-Oct-03 11:33
Wjousts1-Oct-03 11:33 
GeneralRe: DataRowState Problems Pin
Giovanni Bejarasco3-Oct-03 1:46
Giovanni Bejarasco3-Oct-03 1:46 
QuestionIndexing Problem??? Pin
Jason Weibel1-Oct-03 8:32
Jason Weibel1-Oct-03 8:32 
AnswerRe: Indexing Problem??? Pin
andyharman1-Oct-03 12:01
professionalandyharman1-Oct-03 12:01 
GeneralRe: Indexing Problem??? Pin
Jason Weibel2-Oct-03 12:09
Jason Weibel2-Oct-03 12:09 
GeneralRe: Indexing Problem??? Pin
Mike Dimmick2-Oct-03 12:49
Mike Dimmick2-Oct-03 12:49 
loop doesn't indicate a different type of join - it causes the underlying query interpreter to use a different logical operator to perform the operation.

It appears that the original query (without the hint) was using a hash-match join: hashing the data selected from one side of the join and comparing to a table of hashes generated from the other side of the join.

Adding the loop hint causes it to use the Nested Loops operator, which is the simplistic way to implement a join: consider each row on the left-hand side in turn, look through the right-hand side to see if anything matches. The loop over the right-hand side is nested inside the loop for the left-hand side; hence, Nested Loops (although SQL Server may decide to swap the tables or indexes over if appropriate).

If there isn't much data on at least one side of the join, nested loops can perform better than hash match. The downside of nested loops is simply that the server must iterate over every row of one side the number of times that there are rows on the other side.

When compiling a stored procedure, SQL Server caches the compiled execution plan. It does this the first time that the procedure is executed. When pressure for memory increases, SQL Server removes any pages that haven't been touched recently from cache - including cached execution plans.

However, when compiling the procedure for the first time, SQL Server is guided by the parameters. If the parameters will be very different, causing greatly different execution paths, the cached execution plan can be terrible. To force a recompile every time, add WITH RECOMPILE before the AS keyword in the definition of the procedure. As always, you should measure the effect this has.

Another reason the query optimizer might pick poor indexes is if your index statistics are not up to date. Generally SQL Server updates statistics automatically, but you might have turned this off. Look up UPDATE STATISTICS and sp_autostats. Alternatively, consider updating statistics via a scheduled maintenance job. The statistics tell SQL Server how selective an index is, and thus how useful it is in finding rows.

If your execution plan indicates that SQL Server is having to join two indexes on one table together - perhaps seeking one and scanning the other - and your query didn't join the table onto itself, you may find that defining a new index that includes all the columns projected or referenced (excluding the primary key columns, if this table has a clustered index) may help. If a single index contains all the data required, the query is referred to as a covered query. SQL Server can handle a covered query simply by reading the index - it never has to read the table, since all data is stored in the index.

I mention excluding the primary key columns if a clustered index. This is because, if a table has a clustered index, SQL Server stores the clustered index data as the 'destination' part of all non-clustered indexes - to find the rest of the row, after reading the non-clustered index, it has to seek through the clustered index. If there isn't a clustered index, it stores the row number instead.

Care should be taken, because inserts, updates and deletes take more time the more indexes are present.

For more information, try http://www.sql-server-performance.com/[^] or Inside SQL Server 2000[^] by Kalen Delaney (MS Press) - also see the book's website[^].
GeneralRe: Indexing Problem??? Pin
Jason Weibel3-Oct-03 6:08
Jason Weibel3-Oct-03 6:08 
GeneralRe: Indexing Problem??? Pin
Mike Dimmick3-Oct-03 6:27
Mike Dimmick3-Oct-03 6:27 
GeneralRe: Indexing Problem??? Pin
Jason Weibel3-Oct-03 6:44
Jason Weibel3-Oct-03 6:44 
GeneralDatabase documentation tools Pin
Michael P Butler1-Oct-03 7:19
Michael P Butler1-Oct-03 7:19 
GeneralRe: Database documentation tools Pin
Mike Dimmick2-Oct-03 3:49
Mike Dimmick2-Oct-03 3:49 
GeneralRe: Database documentation tools Pin
Michael P Butler2-Oct-03 22:47
Michael P Butler2-Oct-03 22:47 
GeneralConvert Access97 to 2000 programmatically Pin
Hans-Georg Ulrich1-Oct-03 5:37
Hans-Georg Ulrich1-Oct-03 5:37 
GeneralRe: Convert Access97 to 2000 programmatically Pin
Mike Ellison2-Oct-03 10:16
Mike Ellison2-Oct-03 10:16 
Generalerror in class type Pin
ranjjj1-Oct-03 5:02
ranjjj1-Oct-03 5:02 
Generalbcp Pin
sardinka1-Oct-03 3:07
sardinka1-Oct-03 3:07 
GeneralUpdating Related Tables Pin
Wjousts30-Sep-03 11:07
Wjousts30-Sep-03 11:07 
GeneralRe: Updating Related Tables Pin
STW2-Oct-03 7:29
STW2-Oct-03 7:29 
GeneralRe: Updating Related Tables Pin
Wjousts2-Oct-03 8:54
Wjousts2-Oct-03 8:54 
GeneralRe: Updating Related Tables Pin
STW2-Oct-03 22:31
STW2-Oct-03 22:31 
GeneralRe: Updating Related Tables Pin
Wjousts3-Oct-03 4:52
Wjousts3-Oct-03 4:52 
GeneralRe: Updating Related Tables Pin
Wjousts3-Oct-03 5:20
Wjousts3-Oct-03 5:20 
Generalwhere close Pin
sardinka30-Sep-03 5:05
sardinka30-Sep-03 5:05 

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.