SQL Search very slow please help

  • 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) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".

  • 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

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

Viewing 3 posts - 16 through 17 (of 17 total)

You must be logged in to reply to this topic. Login to reply