Hi All
I am really open to any advice as I have hit a kind of brick wall, a developer came to me asking about y a procedure was performing so slowly in beta as opposed to dev and after looking at exactly what it did I indentified the offending select statement.
The query was basically passing some ids into a user defined table and using that thoses ids to filter.
Select gc.id
From temperatures as gcm left outer join
gauges gc ON ( gc.id = gcm.id Or gc.id IS NULL )
AND ( gc.countryid = gcm.countryid or gcm.countryid is null )
where souriceid = 3
So the gauges table has around 90K where as the temperatures has around 3 million .
K the test on the development server and the above returns in under 3 seconds where as the beta is just over 1 minute .
The beta in terms of processing power is much fast and both have the same version of SQL2012 sp1 ( 11.0.3128 ( x64))
having ran a quick query on index fragmentation i find there are a few indexes within the temperature table that are reasonable high. I then rebuild them and see that they are pretty much back to an acceptable level. Again I try the select and a few times and get a range of times .
I then tried a restore from the weekend just to see if there was anything that may have changed and wondering if I was beginning to clutch at straws.
low and behold the restore was not only quick but from an index fragmentation point of view not in as great shape.
Ive compared the two tables which are identical with the only difference being in data to which I copied over to the restore and got the same 2 second result.
Any help on what to do next would be great , as I could replace the table with the restored one but I would like to know why this is happening .
Many Thanks
Robert