SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


SQL Search very slow please help


SQL Search very slow please help

Author
Message
Mike.brickles
Mike.brickles
Grasshopper
Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)

Group: General Forum Members
Points: 23 Visits: 7
Hi Thank you for the help

I have managed to sort it I did a fully backup of the database from 2005 and did a restore on to 2008 job done
Mike.brickles
Mike.brickles
Grasshopper
Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)

Group: General Forum Members
Points: 23 Visits: 7
thanks
Kurt W. Zimmerman
Kurt W. Zimmerman
SSCrazy
SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)

Group: General Forum Members
Points: 2608 Visits: 1400
clayman (11/1/2013)
Kurt W. Zimmerman (11/1/2013)
If I'm going to move data from one server to another via Import/Export I will script out the source database first and place it on the destination box. Then when I move the data from source to destination at least I know the 2 schemas are the same. Finally I reindex all of the indexes and update the statistics before querying the destination tables.

Unless the source & destination boxes are exactly the same, it has been my experience that the 2 boxes will not respond the same. There are so many issues that determine performance that I've realized that the 2 will be different. But if there is a difference in minutes or hours then chances are there is something I've might have overlooked.

Preferably I like to do all of my development on a slower box anyway. This way I can see performance related issues that are not masked by a higher performing box.

Kurt


Just out of interest..why would you update statistics in this case?


Simply to insure that there is no fragmentation in the statistics. Fragmented statistics will cause poor performance.

Kurt

Kurt W. Zimmerman
SR DBA
Lefrak Organization
New York, NY

http://www.linkedin.com/in/kurtwzimmerman
kiril.lazarov.77
kiril.lazarov.77
SSC Eights!
SSC Eights! (882 reputation)SSC Eights! (882 reputation)SSC Eights! (882 reputation)SSC Eights! (882 reputation)SSC Eights! (882 reputation)SSC Eights! (882 reputation)SSC Eights! (882 reputation)SSC Eights! (882 reputation)

Group: General Forum Members
Points: 882 Visits: 2248
Kurt W. Zimmerman (11/1/2013)
clayman (11/1/2013)
Kurt W. Zimmerman (11/1/2013)
If I'm going to move data from one server to another via Import/Export I will script out the source database first and place it on the destination box. Then when I move the data from source to destination at least I know the 2 schemas are the same. Finally I reindex all of the indexes and update the statistics before querying the destination tables.

Unless the source & destination boxes are exactly the same, it has been my experience that the 2 boxes will not respond the same. There are so many issues that determine performance that I've realized that the 2 will be different. But if there is a difference in minutes or hours then chances are there is something I've might have overlooked.

Preferably I like to do all of my development on a slower box anyway. This way I can see performance related issues that are not masked by a higher performing box.

Kurt


Just out of interest..why would you update statistics in this case?


Simply to insure that there is no fragmentation in the statistics. Fragmented statistics will cause poor performance.

Kurt


No idea what you mean by that.. Did you mean index fragmentation? If so, why would index fragmentation be an issue right after the indexing process? Bear with me, just trying to understand things better.
Kurt W. Zimmerman
Kurt W. Zimmerman
SSCrazy
SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)

Group: General Forum Members
Points: 2608 Visits: 1400
clayman (11/1/2013)
Kurt W. Zimmerman (11/1/2013)
clayman (11/1/2013)
Kurt W. Zimmerman (11/1/2013)
If I'm going to move data from one server to another via Import/Export I will script out the source database first and place it on the destination box. Then when I move the data from source to destination at least I know the 2 schemas are the same. Finally I reindex all of the indexes and update the statistics before querying the destination tables.

Unless the source & destination boxes are exactly the same, it has been my experience that the 2 boxes will not respond the same. There are so many issues that determine performance that I've realized that the 2 will be different. But if there is a difference in minutes or hours then chances are there is something I've might have overlooked.

Preferably I like to do all of my development on a slower box anyway. This way I can see performance related issues that are not masked by a higher performing box.

Kurt


Just out of interest..why would you update statistics in this case?


Simply to insure that there is no fragmentation in the statistics. Fragmented statistics will cause poor performance.

Kurt


No idea what you mean by that.. Did you mean index fragmentation? If so, why would index fragmentation be an issue right after the indexing process? Bear with me, just trying to understand things better.


Here is a link that can give you a better understanding of Statistics.

http://technet.microsoft.com/en-us/library/ms190397.aspx

Kurt

Kurt W. Zimmerman
SR DBA
Lefrak Organization
New York, NY

http://www.linkedin.com/in/kurtwzimmerman
ScottPletcher
ScottPletcher
SSCoach
SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)

Group: General Forum Members
Points: 19561 Visits: 7410
Kurt W. Zimmerman (11/1/2013)
clayman (11/1/2013)
Kurt W. Zimmerman (11/1/2013)
clayman (11/1/2013)
Kurt W. Zimmerman (11/1/2013)
If I'm going to move data from one server to another via Import/Export I will script out the source database first and place it on the destination box. Then when I move the data from source to destination at least I know the 2 schemas are the same. Finally I reindex all of the indexes and update the statistics before querying the destination tables.

Unless the source & destination boxes are exactly the same, it has been my experience that the 2 boxes will not respond the same. There are so many issues that determine performance that I've realized that the 2 will be different. But if there is a difference in minutes or hours then chances are there is something I've might have overlooked.

Preferably I like to do all of my development on a slower box anyway. This way I can see performance related issues that are not masked by a higher performing box.

Kurt


Just out of interest..why would you update statistics in this case?


Simply to insure that there is no fragmentation in the statistics. Fragmented statistics will cause poor performance.

Kurt


No idea what you mean by that.. Did you mean index fragmentation? If so, why would index fragmentation be an issue right after the indexing process? Bear with me, just trying to understand things better.


Here is a link that can give you a better understanding of Statistics.

http://technet.microsoft.com/en-us/library/ms190397.aspx

Kurt



"Fragmented statistics" doesn't really make sense. What does that mean?

SQL DBA,SQL Server MVP(07, 08, 09) Prosecutor James Blackburn, in closing argument in the Fatal Vision murders trial:
If in the future, you should cry a tear, cry one for them [the murder victims]. If in the future, you should say a prayer, say one for them. And if in the future, you should light a candle, light one for them.
Kurt W. Zimmerman
Kurt W. Zimmerman
SSCrazy
SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)

Group: General Forum Members
Points: 2608 Visits: 1400
I guess better stated is Out-of-Date statistics.
Kurt

Kurt W. Zimmerman
SR DBA
Lefrak Organization
New York, NY

http://www.linkedin.com/in/kurtwzimmerman
kiril.lazarov.77
kiril.lazarov.77
SSC Eights!
SSC Eights! (882 reputation)SSC Eights! (882 reputation)SSC Eights! (882 reputation)SSC Eights! (882 reputation)SSC Eights! (882 reputation)SSC Eights! (882 reputation)SSC Eights! (882 reputation)SSC Eights! (882 reputation)

Group: General Forum Members
Points: 882 Visits: 2248
Kurt W. Zimmerman (11/1/2013)
clayman (11/1/2013)
Kurt W. Zimmerman (11/1/2013)
clayman (11/1/2013)
Kurt W. Zimmerman (11/1/2013)
If I'm going to move data from one server to another via Import/Export I will script out the source database first and place it on the destination box. Then when I move the data from source to destination at least I know the 2 schemas are the same. Finally I reindex all of the indexes and update the statistics before querying the destination tables.

Unless the source & destination boxes are exactly the same, it has been my experience that the 2 boxes will not respond the same. There are so many issues that determine performance that I've realized that the 2 will be different. But if there is a difference in minutes or hours then chances are there is something I've might have overlooked.

Preferably I like to do all of my development on a slower box anyway. This way I can see performance related issues that are not masked by a higher performing box.

Kurt


Just out of interest..why would you update statistics in this case?


Simply to insure that there is no fragmentation in the statistics. Fragmented statistics will cause poor performance.

Kurt


No idea what you mean by that.. Did you mean index fragmentation? If so, why would index fragmentation be an issue right after the indexing process? Bear with me, just trying to understand things better.


Here is a link that can give you a better understanding of Statistics.

http://technet.microsoft.com/en-us/library/ms190397.aspx

Kurt


Oh thanks!


Operations such as rebuilding, defragmenting, or reorganizing an index do not change the distribution of data. Therefore, you do not need to update statistics after performing ALTER INDEX REBUILD, DBCC REINDEX, DBCC INDEXDEFRAG, or ALTER INDEX REORGANIZE operations. The query optimizer updates statistics when you rebuild an index on a table or view with ALTER INDEX REBUILD or DBCC DBREINDEX, however; this statistics update is a byproduct of re-creating the index. The query optimizer does not update statistics after DBCC INDEXDEFRAG or ALTER INDEX REORGANIZE operations.

Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search