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