Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

SQL Search very slow please help Expand / Collapse
Author
Message
Posted Friday, November 01, 2013 9:35 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, November 01, 2013 9:47 AM
Points: 5, 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

Post #1510648
Posted Friday, November 01, 2013 9:36 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, November 01, 2013 9:47 AM
Points: 5, Visits: 7
thanks
Post #1510649
Posted Friday, November 01, 2013 9:38 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 7:42 AM
Points: 958, Visits: 1,283
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
Post #1510651
Posted Friday, November 01, 2013 9:55 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 10:16 PM
Points: 263, Visits: 1,529
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.
Post #1510663
Posted Friday, November 01, 2013 10:25 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 7:42 AM
Points: 958, Visits: 1,283
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
Post #1510694
Posted Friday, November 01, 2013 1:56 PM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 8:36 AM
Points: 1,743, Visits: 2,547
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)
I'm not fat, I'm gravity challenged.
Post #1510799
Posted Friday, November 01, 2013 2:02 PM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 7:42 AM
Points: 958, Visits: 1,283
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
Post #1510802
Posted Monday, November 04, 2013 7:22 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 10:16 PM
Points: 263, Visits: 1,529
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.
Post #1511100
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse