July 28, 2014 at 1:36 am
Hi Experts,
July 28, 2014 at 2:43 am
Sometimes you don't want to rebuild an index, no matter what its fragmentation.
Sometimes the fragmentation doesn't matter.
The challenge of deciding, automatically, when one can take a huge table completely offline for long periods is extremely hard, there's no way they'd get it right every time, probably not even most of the time. Hence safer to let the people who actually know the system and its usage patters decide.
Edit: Since the OP decided to edit his question out, for anyone interested the original question was asking why SQL doesn't include automatic index rebuilds.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
July 29, 2014 at 6:09 am
Anything that the server does in a completely automated fashion needs to, under most circumstances, and in most cases, not cause harm. Rebuilding indexes could be problematic. For example, an index rebuild results in a full scan update of statistics. Maybe you can't afford a full scan, or maybe the full scan results in skewed statistics compared to the sampled approach (possibly unlikely, but...). Now do you want the rebuild to run automatically?
So, instead, you get to pick and choose what gets run where. That's part of the job as an administrator.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
August 12, 2014 at 2:21 pm
What is the comparison of server sizing in terms of RAM/CPU/storage type et between the access and SQL Server. Trying running the query directly on the SQL Server and Access backend server to get the actual query execution time.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply