What would cause a simple query to use tempdb after reindexing until you update statistics a second time?

This is in regards to Microsoft SQL 2012 Enterprise.

Immediately after updating Indexes and statistics (Manually and also using Hallengren's scripts), several fairly simple queries start using tempdb heavily to the point that it severally impacts the entire SQL Servers performance. Avg. Queue depth goes from .25 to 5 in this state on the tempdb disk on a mirror set. The worst running query goes from a 2 second to 120+ second average run time.

In order to correct the problem we have to manually rerun update statistics on one specific table involved in those queries. I can schedule a second update stats to correct the effects, but would rather fix the root issue if I can identify it.

- Auto Update and Create Statistics are ON in the database. Asynch options are OFF
- No other tables seem to have the problem. (Assumption based on query performance and Tempdb usage)
- Indexes show low fragmentation on the table in question.
- After the second run of Update Statistics, the system operates as expected until the next re-indexing.

Does anyone have any recommendations on how to Root cause this? I have been Googling on this for several weeks now.

I'm hoping I have missed something obvious.

Thanks,
GracoITAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Aneesh RetnakaranDatabase AdministratorCommented:
I faced this issue before, the resolution was to recompile all the stored procedures, which I have added at the end of my maintenance plan
0
Scott PletcherSenior DBACommented:
You don't want to update statistics on an index that has just been rebuilt, as you'll the stats will be based on fewer rows.

If you have a less-active time frame for that table, I suggest doing a full/100% statistics rebuild on that table during that time, and turning off auto-update stats -- but not auto-create stats -- on that table.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
GracoITAuthor Commented:
I'll give these a try individually tonight and test.

Thanks
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SQL Server

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.