?
Solved

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

Posted on 2014-11-10
3
Medium Priority
?
143 Views
Last Modified: 2014-11-17
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,
0
Comment
Question by:GracoIT
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
3 Comments
 
LVL 75

Expert Comment

by:Aneesh Retnakaran
ID: 40433366
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
 
LVL 69

Accepted Solution

by:
Scott Pletcher earned 2000 total points
ID: 40433387
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
 

Author Comment

by:GracoIT
ID: 40433621
I'll give these a try individually tonight and test.

Thanks
0

Featured Post

Want to be a Web Developer? Get Certified Today!

Enroll in the Certified Web Development Professional course package to learn HTML, Javascript, and PHP. Build a solid foundation to work toward your dream job!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Everyone has problem when going to load data into Data warehouse (EDW). They all need to confirm that data quality is good but they don't no how to proceed. Microsoft has provided new task within SSIS 2008 called "Data Profiler Task". It solve th…
This article shows gives you an overview on SQL Server 2016 row level security. You will also get to know the usages of row-level-security and how it works
Familiarize people with the process of retrieving data from SQL Server using an Access pass-thru query. Microsoft Access is a very powerful client/server development tool. One of the ways that you can retrieve data from a SQL Server is by using a pa…
Via a live example, show how to shrink a transaction log file down to a reasonable size.
Suggested Courses

770 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question