I am unclear on how dbcc updateusage (which fixes entries in sysindexes) differs from update statistics.
When would you use one vs the other? Are they any downsides to running these (other than a short performance hit?)
Any clarity my fellow dba's can provide is greatly appreciated!
TIA!
Back in the days when I did application support we often used DBCC updateusage against customers databases when things were running slow. It seemed to work although from what I know of it now I am not sure why. Do any of you have experience using this as part of a maintenance plan or to address performance issues?
------------------------
Future guru in the making.
I have a nightly jobs that runs dbcc updateusage (0) against one of our development databases and Enterprise Manager scheduled tasks window just reports the last run status as 'failed'.
The database has verified clean after running dbcc checkdb, checkcatalog, and newalloc.
Can someone tell me why the dbcc updateusage task fails? Even if I run it manually via ISQL/W it tells me 'DBCC execution completed. If DBCC printed error messages, see your System Administrator.'. I do set traceflag 3604 on before running the updateusage command.
In several years experience with 50+ SQL Servers I have not seen this message until recently, failing integrity check jobs normally indicate a table corruption due to faulty hard disks. This message however has come up several times in the last month with our SQL 2005 SP2 sites:-
DBCC results for 'DonorReceipts'.
Msg 2508, Level 16, State 3, Line 1
The In-row data RSVD page count for object "DonorReceipts", index ID 0, partition ID 49648614572032, alloc unit ID 49648614572032 (type In-row data) is incorrect. Run DBCC UPDATEUSAGE.
There are 6932 rows in 103 pages for object "DonorReceipts".
We have hundreds of tables and the message is normally on different tables each time. Running DBCC UPDATEUSAGE fixes the problem but does anyone know what causes it in the first place? Shouldn't the standard maintenance plans have an option to do this already?
Thanks
Steve