Getting Strange Execution Plan w/ DBCC

Hi,
I'm running this:
DBCC CHECKDB ( '<database>', REPAIR_FAST ) WITH ALL_ERRORMSGS, TABLOCK
And I'm getting this:
Server: Msg 8649, Level 17, State 1, Line 2
The query has been canceled because the estimated cost of this query (13451)
exceeds the configured threshold of 10800. Contact the system administrator.
When I remove the query governor it runs in about 30 seconds not 10800+.
The stats on this database were manually updated with sp_createstats and
sp_updatestats.
Does anyone have any recommendations?
Thanks,
BryanBDB wrote:
> Hi,
> I'm running this:
> DBCC CHECKDB ( '<database>', REPAIR_FAST ) WITH ALL_ERRORMSGS, TABLOCK
> And I'm getting this:
> Server: Msg 8649, Level 17, State 1, Line 2
> The query has been canceled because the estimated cost of this query
> (13451) exceeds the configured threshold of 10800. Contact the system
> administrator.
> When I remove the query governor it runs in about 30 seconds not
> 10800+. The stats on this database were manually updated with
> sp_createstats and sp_updatestats.
> Does anyone have any recommendations?
> Thanks,
> Bryan
You can remove the query governor setting for the connection using SET
QUERY_GOVERNOR_COST_LIMIT 0. It's possible SQL Server is having a
difficult time determining if the CHECKDB (which could be quite an
intense operation) is going to use more time than the set limit.
David Gugick
Quest Software
www.imceda.com
www.quest.com|||FIX: You receive a "Msg 8649" error message when you execute the DBCC CHECKD
B
statement in SQL Server 2000 Service Pack 3 (SP3)
http://support.microsoft.com/defaul...kb;en-us;840208
AMB
"BDB" wrote:

> Hi,
> I'm running this:
> DBCC CHECKDB ( '<database>', REPAIR_FAST ) WITH ALL_ERRORMSGS, TABLOCK
> And I'm getting this:
> Server: Msg 8649, Level 17, State 1, Line 2
> The query has been canceled because the estimated cost of this query (1345
1)
> exceeds the configured threshold of 10800. Contact the system administrato
r.
> When I remove the query governor it runs in about 30 seconds not 10800+.
> The stats on this database were manually updated with sp_createstats and
> sp_updatestats.
> Does anyone have any recommendations?
> Thanks,
> Bryan
>
>