Anyone seen this before? What causes it? How do I fix it?
Thanks!!
Richard
DBCC results for 'ivTransitItems'.
Msg 2537, Level 16, State 24, Line 5
Table error: object ID 295528682, index ID 0, partition ID 19367767703552,
alloc unit ID 19367767703552 (type In-row data), page (1:22320), row 0. The
record check (valid record length) failed. The values are 112 and 108.
Msg 8929, Level 16, State 1, Line 5
Object ID 295528682, index ID 0, partition ID 19367767703552, alloc unit ID
19367767703552 (type In-row data): Errors found in off-row data with ID
3755409408 owned by data record identified by RID = (1:22320:0)
Msg 2537, Level 16, State 24, Line 5
Hi,
Can you try doing these:-
1. Do a DBCC DBREINDEX and after that run a DBCC CHECKTABLE and see if error
persists
2. If error Persists then do a DBCC CHECKTABLE with REPAIR_REBUILD
3. If you still have error then take a backup of database and then execute
DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS
To use the repair optiion database must be set to single user mode.
Thanks
Hari
SQL Server MVP
"Richard Douglass" wrote:
> Anyone seen this before? What causes it? How do I fix it?
> Thanks!!
> Richard
>
> DBCC results for 'ivTransitItems'.
> Msg 2537, Level 16, State 24, Line 5
> Table error: object ID 295528682, index ID 0, partition ID 19367767703552,
> alloc unit ID 19367767703552 (type In-row data), page (1:22320), row 0. The
> record check (valid record length) failed. The values are 112 and 108.
> Msg 8929, Level 16, State 1, Line 5
> Object ID 295528682, index ID 0, partition ID 19367767703552, alloc unit ID
> 19367767703552 (type In-row data): Errors found in off-row data with ID
> 3755409408 owned by data record identified by RID = (1:22320:0)
> Msg 2537, Level 16, State 24, Line 5
>
>
|||Actually, before you do any of these, if you have a backup you should
restore from backup. This is much safer than running the DBCC commands you
list below (especially the third one), as those can result in dataloss
which could make your database totally inconsistent.
Thanks,
Marcel.
On Wed, 13 Sep 2006 16:11:01 -0700, Hari Prasad wrote:
[vbcol=seagreen]
> Hi,
> Can you try doing these:-
> 1. Do a DBCC DBREINDEX and after that run a DBCC CHECKTABLE and see if error
> persists
> 2. If error Persists then do a DBCC CHECKTABLE with REPAIR_REBUILD
> 3. If you still have error then take a backup of database and then execute
> DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS
> To use the repair optiion database must be set to single user mode.
> Thanks
> Hari
> SQL Server MVP
> "Richard Douglass" wrote:
Showing posts with label fix. Show all posts
Showing posts with label fix. Show all posts
Thursday, March 8, 2012
DBCC Error
Anyone seen this before? What causes it? How do I fix it?
Thanks!!
Richard
DBCC results for 'ivTransitItems'.
Msg 2537, Level 16, State 24, Line 5
Table error: object ID 295528682, index ID 0, partition ID 19367767703552,
alloc unit ID 19367767703552 (type In-row data), page (1:22320), row 0. The
record check (valid record length) failed. The values are 112 and 108.
Msg 8929, Level 16, State 1, Line 5
Object ID 295528682, index ID 0, partition ID 19367767703552, alloc unit ID
19367767703552 (type In-row data): Errors found in off-row data with ID
3755409408 owned by data record identified by RID = (1:22320:0)
Msg 2537, Level 16, State 24, Line 5Hi,
Can you try doing these:-
1. Do a DBCC DBREINDEX and after that run a DBCC CHECKTABLE and see if error
persists
2. If error Persists then do a DBCC CHECKTABLE with REPAIR_REBUILD
3. If you still have error then take a backup of database and then execute
DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS
To use the repair optiion database must be set to single user mode.
Thanks
Hari
SQL Server MVP
"Richard Douglass" wrote:
> Anyone seen this before? What causes it? How do I fix it?
> Thanks!!
> Richard
>
> DBCC results for 'ivTransitItems'.
> Msg 2537, Level 16, State 24, Line 5
> Table error: object ID 295528682, index ID 0, partition ID 19367767703552,
> alloc unit ID 19367767703552 (type In-row data), page (1:22320), row 0. The
> record check (valid record length) failed. The values are 112 and 108.
> Msg 8929, Level 16, State 1, Line 5
> Object ID 295528682, index ID 0, partition ID 19367767703552, alloc unit ID
> 19367767703552 (type In-row data): Errors found in off-row data with ID
> 3755409408 owned by data record identified by RID = (1:22320:0)
> Msg 2537, Level 16, State 24, Line 5
>
>|||Actually, before you do any of these, if you have a backup you should
restore from backup. This is much safer than running the DBCC commands you
list below (especially the third one), as those can result in dataloss
which could make your database totally inconsistent.
Thanks,
Marcel.
On Wed, 13 Sep 2006 16:11:01 -0700, Hari Prasad wrote:
> Hi,
> Can you try doing these:-
> 1. Do a DBCC DBREINDEX and after that run a DBCC CHECKTABLE and see if error
> persists
> 2. If error Persists then do a DBCC CHECKTABLE with REPAIR_REBUILD
> 3. If you still have error then take a backup of database and then execute
> DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS
> To use the repair optiion database must be set to single user mode.
> Thanks
> Hari
> SQL Server MVP
> "Richard Douglass" wrote:
>> Anyone seen this before? What causes it? How do I fix it?
>> Thanks!!
>> Richard
>>
>> DBCC results for 'ivTransitItems'.
>> Msg 2537, Level 16, State 24, Line 5
>> Table error: object ID 295528682, index ID 0, partition ID 19367767703552,
>> alloc unit ID 19367767703552 (type In-row data), page (1:22320), row 0. The
>> record check (valid record length) failed. The values are 112 and 108.
>> Msg 8929, Level 16, State 1, Line 5
>> Object ID 295528682, index ID 0, partition ID 19367767703552, alloc unit ID
>> 19367767703552 (type In-row data): Errors found in off-row data with ID
>> 3755409408 owned by data record identified by RID = (1:22320:0)
>> Msg 2537, Level 16, State 24, Line 5
>>
Thanks!!
Richard
DBCC results for 'ivTransitItems'.
Msg 2537, Level 16, State 24, Line 5
Table error: object ID 295528682, index ID 0, partition ID 19367767703552,
alloc unit ID 19367767703552 (type In-row data), page (1:22320), row 0. The
record check (valid record length) failed. The values are 112 and 108.
Msg 8929, Level 16, State 1, Line 5
Object ID 295528682, index ID 0, partition ID 19367767703552, alloc unit ID
19367767703552 (type In-row data): Errors found in off-row data with ID
3755409408 owned by data record identified by RID = (1:22320:0)
Msg 2537, Level 16, State 24, Line 5Hi,
Can you try doing these:-
1. Do a DBCC DBREINDEX and after that run a DBCC CHECKTABLE and see if error
persists
2. If error Persists then do a DBCC CHECKTABLE with REPAIR_REBUILD
3. If you still have error then take a backup of database and then execute
DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS
To use the repair optiion database must be set to single user mode.
Thanks
Hari
SQL Server MVP
"Richard Douglass" wrote:
> Anyone seen this before? What causes it? How do I fix it?
> Thanks!!
> Richard
>
> DBCC results for 'ivTransitItems'.
> Msg 2537, Level 16, State 24, Line 5
> Table error: object ID 295528682, index ID 0, partition ID 19367767703552,
> alloc unit ID 19367767703552 (type In-row data), page (1:22320), row 0. The
> record check (valid record length) failed. The values are 112 and 108.
> Msg 8929, Level 16, State 1, Line 5
> Object ID 295528682, index ID 0, partition ID 19367767703552, alloc unit ID
> 19367767703552 (type In-row data): Errors found in off-row data with ID
> 3755409408 owned by data record identified by RID = (1:22320:0)
> Msg 2537, Level 16, State 24, Line 5
>
>|||Actually, before you do any of these, if you have a backup you should
restore from backup. This is much safer than running the DBCC commands you
list below (especially the third one), as those can result in dataloss
which could make your database totally inconsistent.
Thanks,
Marcel.
On Wed, 13 Sep 2006 16:11:01 -0700, Hari Prasad wrote:
> Hi,
> Can you try doing these:-
> 1. Do a DBCC DBREINDEX and after that run a DBCC CHECKTABLE and see if error
> persists
> 2. If error Persists then do a DBCC CHECKTABLE with REPAIR_REBUILD
> 3. If you still have error then take a backup of database and then execute
> DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS
> To use the repair optiion database must be set to single user mode.
> Thanks
> Hari
> SQL Server MVP
> "Richard Douglass" wrote:
>> Anyone seen this before? What causes it? How do I fix it?
>> Thanks!!
>> Richard
>>
>> DBCC results for 'ivTransitItems'.
>> Msg 2537, Level 16, State 24, Line 5
>> Table error: object ID 295528682, index ID 0, partition ID 19367767703552,
>> alloc unit ID 19367767703552 (type In-row data), page (1:22320), row 0. The
>> record check (valid record length) failed. The values are 112 and 108.
>> Msg 8929, Level 16, State 1, Line 5
>> Object ID 295528682, index ID 0, partition ID 19367767703552, alloc unit ID
>> 19367767703552 (type In-row data): Errors found in off-row data with ID
>> 3755409408 owned by data record identified by RID = (1:22320:0)
>> Msg 2537, Level 16, State 24, Line 5
>>
DBCC Error
Anyone seen this before? What causes it? How do I fix it?
Thanks!!
Richard
DBCC results for 'ivTransitItems'.
Msg 2537, Level 16, State 24, Line 5
Table error: object ID 295528682, index ID 0, partition ID 19367767703552,
alloc unit ID 19367767703552 (type In-row data), page (1:22320), row 0. The
record check (valid record length) failed. The values are 112 and 108.
Msg 8929, Level 16, State 1, Line 5
Object ID 295528682, index ID 0, partition ID 19367767703552, alloc unit ID
19367767703552 (type In-row data): Errors found in off-row data with ID
3755409408 owned by data record identified by RID = (1:22320:0)
Msg 2537, Level 16, State 24, Line 5Hi,
Can you try doing these:-
1. Do a DBCC DBREINDEX and after that run a DBCC CHECKTABLE and see if error
persists
2. If error Persists then do a DBCC CHECKTABLE with REPAIR_REBUILD
3. If you still have error then take a backup of database and then execute
DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS
To use the repair optiion database must be set to single user mode.
Thanks
Hari
SQL Server MVP
"Richard Douglass" wrote:
> Anyone seen this before? What causes it? How do I fix it?
> Thanks!!
> Richard
>
> DBCC results for 'ivTransitItems'.
> Msg 2537, Level 16, State 24, Line 5
> Table error: object ID 295528682, index ID 0, partition ID 19367767703552,
> alloc unit ID 19367767703552 (type In-row data), page (1:22320), row 0. Th
e
> record check (valid record length) failed. The values are 112 and 108.
> Msg 8929, Level 16, State 1, Line 5
> Object ID 295528682, index ID 0, partition ID 19367767703552, alloc unit I
D
> 19367767703552 (type In-row data): Errors found in off-row data with ID
> 3755409408 owned by data record identified by RID = (1:22320:0)
> Msg 2537, Level 16, State 24, Line 5
>
>|||Actually, before you do any of these, if you have a backup you should
restore from backup. This is much safer than running the DBCC commands you
list below (especially the third one), as those can result in dataloss
which could make your database totally inconsistent.
Thanks,
Marcel.
On Wed, 13 Sep 2006 16:11:01 -0700, Hari Prasad wrote:
[vbcol=seagreen]
> Hi,
> Can you try doing these:-
> 1. Do a DBCC DBREINDEX and after that run a DBCC CHECKTABLE and see if err
or
> persists
> 2. If error Persists then do a DBCC CHECKTABLE with REPAIR_REBUILD
> 3. If you still have error then take a backup of database and then execute
> DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS
> To use the repair optiion database must be set to single user mode.
> Thanks
> Hari
> SQL Server MVP
> "Richard Douglass" wrote:
>
Thanks!!
Richard
DBCC results for 'ivTransitItems'.
Msg 2537, Level 16, State 24, Line 5
Table error: object ID 295528682, index ID 0, partition ID 19367767703552,
alloc unit ID 19367767703552 (type In-row data), page (1:22320), row 0. The
record check (valid record length) failed. The values are 112 and 108.
Msg 8929, Level 16, State 1, Line 5
Object ID 295528682, index ID 0, partition ID 19367767703552, alloc unit ID
19367767703552 (type In-row data): Errors found in off-row data with ID
3755409408 owned by data record identified by RID = (1:22320:0)
Msg 2537, Level 16, State 24, Line 5Hi,
Can you try doing these:-
1. Do a DBCC DBREINDEX and after that run a DBCC CHECKTABLE and see if error
persists
2. If error Persists then do a DBCC CHECKTABLE with REPAIR_REBUILD
3. If you still have error then take a backup of database and then execute
DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS
To use the repair optiion database must be set to single user mode.
Thanks
Hari
SQL Server MVP
"Richard Douglass" wrote:
> Anyone seen this before? What causes it? How do I fix it?
> Thanks!!
> Richard
>
> DBCC results for 'ivTransitItems'.
> Msg 2537, Level 16, State 24, Line 5
> Table error: object ID 295528682, index ID 0, partition ID 19367767703552,
> alloc unit ID 19367767703552 (type In-row data), page (1:22320), row 0. Th
e
> record check (valid record length) failed. The values are 112 and 108.
> Msg 8929, Level 16, State 1, Line 5
> Object ID 295528682, index ID 0, partition ID 19367767703552, alloc unit I
D
> 19367767703552 (type In-row data): Errors found in off-row data with ID
> 3755409408 owned by data record identified by RID = (1:22320:0)
> Msg 2537, Level 16, State 24, Line 5
>
>|||Actually, before you do any of these, if you have a backup you should
restore from backup. This is much safer than running the DBCC commands you
list below (especially the third one), as those can result in dataloss
which could make your database totally inconsistent.
Thanks,
Marcel.
On Wed, 13 Sep 2006 16:11:01 -0700, Hari Prasad wrote:
[vbcol=seagreen]
> Hi,
> Can you try doing these:-
> 1. Do a DBCC DBREINDEX and after that run a DBCC CHECKTABLE and see if err
or
> persists
> 2. If error Persists then do a DBCC CHECKTABLE with REPAIR_REBUILD
> 3. If you still have error then take a backup of database and then execute
> DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS
> To use the repair optiion database must be set to single user mode.
> Thanks
> Hari
> SQL Server MVP
> "Richard Douglass" wrote:
>
Wednesday, March 7, 2012
DBCC DBREINDEX question and problem
I have really bad database fragmentation, in some cases up to 95% fragmented. I continue to run DBCC DBREINDEX on these tables to try and fix this problem but from some reason, no matter how often I do it, I never see an increase in Scan Density. The tables in question do have more than 8 pages so I know that is not the issue. Anyone have any insight on this?
http://www.sql-server-performance.com/rd_index_fragmentation.asp
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx
The above links should help you to understand the features available in SQL Server and resolve the defragmentation problems.
Friday, February 24, 2012
dbcc checktable(syslogs)
In SQL Server 6.5, after I run the following command, it has error in the
result. How can I fix the Table Corrupt problem ?
Thanks a lot !
Query :
dbcc checktable(syslogs)
go
checkpoint
go
Result :
Checking syslogs
Msg 2578, Level 16, State 1
The first page 764720 in Sysindexes for table 'syslogs' has previous page #
764721 in its page header. The previous page # should be NULL. Please check
Sysindexes.
Msg 2503, Level 16, State 1
Table Corrupt: Page linkage is not consistent; check the following pages:
(current page#=764720; page# pointing to this page=0; previous page#
indicated in this page=764721)
DBCC execution completed. If DBCC printed error messages, see your System
Administrator.You could try just emptying the log (but please consider your backup strategy when doing this).
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Danny" <.> wrote in message news:ughx2LS0EHA.3596@.TK2MSFTNGP12.phx.gbl...
> In SQL Server 6.5, after I run the following command, it has error in the
> result. How can I fix the Table Corrupt problem ?
> Thanks a lot !
> Query :
> dbcc checktable(syslogs)
> go
> checkpoint
> go
> Result :
> Checking syslogs
> Msg 2578, Level 16, State 1
> The first page 764720 in Sysindexes for table 'syslogs' has previous page #
> 764721 in its page header. The previous page # should be NULL. Please check
> Sysindexes.
> Msg 2503, Level 16, State 1
> Table Corrupt: Page linkage is not consistent; check the following pages:
> (current page#=764720; page# pointing to this page=0; previous page#
> indicated in this page=764721)
> DBCC execution completed. If DBCC printed error messages, see your System
> Administrator.
>
result. How can I fix the Table Corrupt problem ?
Thanks a lot !
Query :
dbcc checktable(syslogs)
go
checkpoint
go
Result :
Checking syslogs
Msg 2578, Level 16, State 1
The first page 764720 in Sysindexes for table 'syslogs' has previous page #
764721 in its page header. The previous page # should be NULL. Please check
Sysindexes.
Msg 2503, Level 16, State 1
Table Corrupt: Page linkage is not consistent; check the following pages:
(current page#=764720; page# pointing to this page=0; previous page#
indicated in this page=764721)
DBCC execution completed. If DBCC printed error messages, see your System
Administrator.You could try just emptying the log (but please consider your backup strategy when doing this).
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Danny" <.> wrote in message news:ughx2LS0EHA.3596@.TK2MSFTNGP12.phx.gbl...
> In SQL Server 6.5, after I run the following command, it has error in the
> result. How can I fix the Table Corrupt problem ?
> Thanks a lot !
> Query :
> dbcc checktable(syslogs)
> go
> checkpoint
> go
> Result :
> Checking syslogs
> Msg 2578, Level 16, State 1
> The first page 764720 in Sysindexes for table 'syslogs' has previous page #
> 764721 in its page header. The previous page # should be NULL. Please check
> Sysindexes.
> Msg 2503, Level 16, State 1
> Table Corrupt: Page linkage is not consistent; check the following pages:
> (current page#=764720; page# pointing to this page=0; previous page#
> indicated in this page=764721)
> DBCC execution completed. If DBCC printed error messages, see your System
> Administrator.
>
dbcc checktable(syslogs)
In SQL Server 6.5, after I run the following command, it has error in the
result. How can I fix the Table Corrupt problem ?
Thanks a lot !
Query :
dbcc checktable(syslogs)
go
checkpoint
go
Result :
Checking syslogs
Msg 2578, Level 16, State 1
The first page 764720 in Sysindexes for table 'syslogs' has previous page #
764721 in its page header. The previous page # should be NULL. Please check
Sysindexes.
Msg 2503, Level 16, State 1
Table Corrupt: Page linkage is not consistent; check the following pages:
(current page#=764720; page# pointing to this page=0; previous page#
indicated in this page=764721)
DBCC execution completed. If DBCC printed error messages, see your System
Administrator.
You could try just emptying the log (but please consider your backup strategy when doing this).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Danny" <.> wrote in message news:ughx2LS0EHA.3596@.TK2MSFTNGP12.phx.gbl...
> In SQL Server 6.5, after I run the following command, it has error in the
> result. How can I fix the Table Corrupt problem ?
> Thanks a lot !
> Query :
> dbcc checktable(syslogs)
> go
> checkpoint
> go
> Result :
> Checking syslogs
> Msg 2578, Level 16, State 1
> The first page 764720 in Sysindexes for table 'syslogs' has previous page #
> 764721 in its page header. The previous page # should be NULL. Please check
> Sysindexes.
> Msg 2503, Level 16, State 1
> Table Corrupt: Page linkage is not consistent; check the following pages:
> (current page#=764720; page# pointing to this page=0; previous page#
> indicated in this page=764721)
> DBCC execution completed. If DBCC printed error messages, see your System
> Administrator.
>
result. How can I fix the Table Corrupt problem ?
Thanks a lot !
Query :
dbcc checktable(syslogs)
go
checkpoint
go
Result :
Checking syslogs
Msg 2578, Level 16, State 1
The first page 764720 in Sysindexes for table 'syslogs' has previous page #
764721 in its page header. The previous page # should be NULL. Please check
Sysindexes.
Msg 2503, Level 16, State 1
Table Corrupt: Page linkage is not consistent; check the following pages:
(current page#=764720; page# pointing to this page=0; previous page#
indicated in this page=764721)
DBCC execution completed. If DBCC printed error messages, see your System
Administrator.
You could try just emptying the log (but please consider your backup strategy when doing this).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Danny" <.> wrote in message news:ughx2LS0EHA.3596@.TK2MSFTNGP12.phx.gbl...
> In SQL Server 6.5, after I run the following command, it has error in the
> result. How can I fix the Table Corrupt problem ?
> Thanks a lot !
> Query :
> dbcc checktable(syslogs)
> go
> checkpoint
> go
> Result :
> Checking syslogs
> Msg 2578, Level 16, State 1
> The first page 764720 in Sysindexes for table 'syslogs' has previous page #
> 764721 in its page header. The previous page # should be NULL. Please check
> Sysindexes.
> Msg 2503, Level 16, State 1
> Table Corrupt: Page linkage is not consistent; check the following pages:
> (current page#=764720; page# pointing to this page=0; previous page#
> indicated in this page=764721)
> DBCC execution completed. If DBCC printed error messages, see your System
> Administrator.
>
dbcc checktable(syslogs)
In SQL Server 6.5, after I run the following command, it has error in the
result. How can I fix the Table Corrupt problem ?
Thanks a lot !
Query :
dbcc checktable(syslogs)
go
checkpoint
go
Result :
Checking syslogs
Msg 2578, Level 16, State 1
The first page 764720 in Sysindexes for table 'syslogs' has previous page #
764721 in its page header. The previous page # should be NULL. Please check
Sysindexes.
Msg 2503, Level 16, State 1
Table Corrupt: Page linkage is not consistent; check the following pages:
(current page#=764720; page# pointing to this page=0; previous page#
indicated in this page=764721)
DBCC execution completed. If DBCC printed error messages, see your System
Administrator.You could try just emptying the log (but please consider your backup strateg
y when doing this).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Danny" <.> wrote in message news:ughx2LS0EHA.3596@.TK2MSFTNGP12.phx.gbl...
> In SQL Server 6.5, after I run the following command, it has error in the
> result. How can I fix the Table Corrupt problem ?
> Thanks a lot !
> Query :
> dbcc checktable(syslogs)
> go
> checkpoint
> go
> Result :
> Checking syslogs
> Msg 2578, Level 16, State 1
> The first page 764720 in Sysindexes for table 'syslogs' has previous page
#
> 764721 in its page header. The previous page # should be NULL. Please chec
k
> Sysindexes.
> Msg 2503, Level 16, State 1
> Table Corrupt: Page linkage is not consistent; check the following pages:
> (current page#=764720; page# pointing to this page=0; previous page#
> indicated in this page=764721)
> DBCC execution completed. If DBCC printed error messages, see your System
> Administrator.
>
result. How can I fix the Table Corrupt problem ?
Thanks a lot !
Query :
dbcc checktable(syslogs)
go
checkpoint
go
Result :
Checking syslogs
Msg 2578, Level 16, State 1
The first page 764720 in Sysindexes for table 'syslogs' has previous page #
764721 in its page header. The previous page # should be NULL. Please check
Sysindexes.
Msg 2503, Level 16, State 1
Table Corrupt: Page linkage is not consistent; check the following pages:
(current page#=764720; page# pointing to this page=0; previous page#
indicated in this page=764721)
DBCC execution completed. If DBCC printed error messages, see your System
Administrator.You could try just emptying the log (but please consider your backup strateg
y when doing this).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Danny" <.> wrote in message news:ughx2LS0EHA.3596@.TK2MSFTNGP12.phx.gbl...
> In SQL Server 6.5, after I run the following command, it has error in the
> result. How can I fix the Table Corrupt problem ?
> Thanks a lot !
> Query :
> dbcc checktable(syslogs)
> go
> checkpoint
> go
> Result :
> Checking syslogs
> Msg 2578, Level 16, State 1
> The first page 764720 in Sysindexes for table 'syslogs' has previous page
#
> 764721 in its page header. The previous page # should be NULL. Please chec
k
> Sysindexes.
> Msg 2503, Level 16, State 1
> Table Corrupt: Page linkage is not consistent; check the following pages:
> (current page#=764720; page# pointing to this page=0; previous page#
> indicated in this page=764721)
> DBCC execution completed. If DBCC printed error messages, see your System
> Administrator.
>
Friday, February 17, 2012
dbcc checkdb gets hung
I have a server running Windows 2003 with sql server 2000 8.00.973 hot fix
level that is hanging when I run dbcc checkdb on one particular database. It
keeps getting io and cpu time -- but just runs and run and runs.
Once when I looked at it there were 81 threads running for the DBCC's. It
was completely using up resources on the server. This is an 8 way processor.
We've let it run up to 11 hours before the server eventually had to be
rebooted.
The database it is hanging on is 250 Gb -- but I think it should still
finish in less than 11 hours. Usually we kill the process after 9 hours so
we can run our backups and let users start running their jobs again. We do
run this at night during our lowest usage.
Any suggestions?first check space in your tempdb with
dbcc checkdb (databasename) WITH ESTIMATEONLY
run CHECKDB when the system usage is low
and READ "DBCC CHECKDB Recommendations" i BOL
"DML" wrote:
> I have a server running Windows 2003 with sql server 2000 8.00.973 hot fix
> level that is hanging when I run dbcc checkdb on one particular database. It
> keeps getting io and cpu time -- but just runs and run and runs.
> Once when I looked at it there were 81 threads running for the DBCC's. It
> was completely using up resources on the server. This is an 8 way processor.
> We've let it run up to 11 hours before the server eventually had to be
> rebooted.
> The database it is hanging on is 250 Gb -- but I think it should still
> finish in less than 11 hours. Usually we kill the process after 9 hours so
> we can run our backups and let users start running their jobs again. We do
> run this at night during our lowest usage.
> Any suggestions?
>|||We do run CHECKDB at night during low usage, and run it in the same job as
backups so that they do not conflict. Disk backups are done in the morning
when we're sure our db backups are finished. Tempdb is on SAN space -- and
has over 2 Gb allocated to it with 10% growth set and more space available.
We run it with NO_INFOMSGS also. We run the same steps on our other 100
servers.
It just hangs in this 1 particular database. It is not the largest db we
have. This is also a new server we finished setting up in the last few
months and is one side of an Active Active cluster.
I ran the with estimate only and it only said I'd need around 2 Gb of tempdb
space.
Any other suggestions would be most helpful.
"Aleksandar Grbic" wrote:
> first check space in your tempdb with
> dbcc checkdb (databasename) WITH ESTIMATEONLY
> run CHECKDB when the system usage is low
>
> and READ "DBCC CHECKDB Recommendations" i BOL
>
> "DML" wrote:
> > I have a server running Windows 2003 with sql server 2000 8.00.973 hot fix
> > level that is hanging when I run dbcc checkdb on one particular database. It
> > keeps getting io and cpu time -- but just runs and run and runs.
> >
> > Once when I looked at it there were 81 threads running for the DBCC's. It
> > was completely using up resources on the server. This is an 8 way processor.
> >
> > We've let it run up to 11 hours before the server eventually had to be
> > rebooted.
> >
> > The database it is hanging on is 250 Gb -- but I think it should still
> > finish in less than 11 hours. Usually we kill the process after 9 hours so
> > we can run our backups and let users start running their jobs again. We do
> > run this at night during our lowest usage.
> >
> > Any suggestions?
> >
> >|||Let it finish. Some things to consider:
1) what are the disk queue lengths on the drives holding the database? (i.e
is your IO subsystem the bottleneck)
2) does it complete a lot faster if you use the NOINDEX option? (See BOL).
If so, you've probably got a corruption somewhere in a non-clustered index
which is triggering a much more expensive set of checks to find the exact
row with the corruption in. In which case, remove the NOINDEX option and let
it complete so you know where the corruption is.
Number 2 is my bet.
Regards
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"DML" <DML@.discussions.microsoft.com> wrote in message
news:81778FD5-BEC9-4D52-8A71-14396E6F187F@.microsoft.com...
> We do run CHECKDB at night during low usage, and run it in the same job as
> backups so that they do not conflict. Disk backups are done in the
morning
> when we're sure our db backups are finished. Tempdb is on SAN space --
and
> has over 2 Gb allocated to it with 10% growth set and more space
available.
> We run it with NO_INFOMSGS also. We run the same steps on our other 100
> servers.
> It just hangs in this 1 particular database. It is not the largest db we
> have. This is also a new server we finished setting up in the last few
> months and is one side of an Active Active cluster.
> I ran the with estimate only and it only said I'd need around 2 Gb of
tempdb
> space.
> Any other suggestions would be most helpful.
> "Aleksandar Grbic" wrote:
> > first check space in your tempdb with
> > dbcc checkdb (databasename) WITH ESTIMATEONLY
> >
> > run CHECKDB when the system usage is low
> >
> >
> > and READ "DBCC CHECKDB Recommendations" i BOL
> >
> >
> > "DML" wrote:
> >
> > > I have a server running Windows 2003 with sql server 2000 8.00.973 hot
fix
> > > level that is hanging when I run dbcc checkdb on one particular
database. It
> > > keeps getting io and cpu time -- but just runs and run and runs.
> > >
> > > Once when I looked at it there were 81 threads running for the DBCC's.
It
> > > was completely using up resources on the server. This is an 8 way
processor.
> > >
> > > We've let it run up to 11 hours before the server eventually had to be
> > > rebooted.
> > >
> > > The database it is hanging on is 250 Gb -- but I think it should still
> > > finish in less than 11 hours. Usually we kill the process after 9
hours so
> > > we can run our backups and let users start running their jobs again.
We do
> > > run this at night during our lowest usage.
> > >
> > > Any suggestions?
> > >
> > >|||We were able to track down error messages regarding 2 tables in the database.
We ran DBCC Checktable against both tables. One table came back and the
other hung. On the table that hung (357 million rows) we dropped/recreated
the indexes and this seemed to fix the problem.
Thanks for your help.
"Paul S Randal [MS]" wrote:
> Let it finish. Some things to consider:
> 1) what are the disk queue lengths on the drives holding the database? (i.e
> is your IO subsystem the bottleneck)
> 2) does it complete a lot faster if you use the NOINDEX option? (See BOL).
> If so, you've probably got a corruption somewhere in a non-clustered index
> which is triggering a much more expensive set of checks to find the exact
> row with the corruption in. In which case, remove the NOINDEX option and let
> it complete so you know where the corruption is.
> Number 2 is my bet.
> Regards
> --
> Paul Randal
> Dev Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "DML" <DML@.discussions.microsoft.com> wrote in message
> news:81778FD5-BEC9-4D52-8A71-14396E6F187F@.microsoft.com...
> > We do run CHECKDB at night during low usage, and run it in the same job as
> > backups so that they do not conflict. Disk backups are done in the
> morning
> > when we're sure our db backups are finished. Tempdb is on SAN space --
> and
> > has over 2 Gb allocated to it with 10% growth set and more space
> available.
> > We run it with NO_INFOMSGS also. We run the same steps on our other 100
> > servers.
> >
> > It just hangs in this 1 particular database. It is not the largest db we
> > have. This is also a new server we finished setting up in the last few
> > months and is one side of an Active Active cluster.
> >
> > I ran the with estimate only and it only said I'd need around 2 Gb of
> tempdb
> > space.
> >
> > Any other suggestions would be most helpful.
> >
> > "Aleksandar Grbic" wrote:
> >
> > > first check space in your tempdb with
> > > dbcc checkdb (databasename) WITH ESTIMATEONLY
> > >
> > > run CHECKDB when the system usage is low
> > >
> > >
> > > and READ "DBCC CHECKDB Recommendations" i BOL
> > >
> > >
> > > "DML" wrote:
> > >
> > > > I have a server running Windows 2003 with sql server 2000 8.00.973 hot
> fix
> > > > level that is hanging when I run dbcc checkdb on one particular
> database. It
> > > > keeps getting io and cpu time -- but just runs and run and runs.
> > > >
> > > > Once when I looked at it there were 81 threads running for the DBCC's.
> It
> > > > was completely using up resources on the server. This is an 8 way
> processor.
> > > >
> > > > We've let it run up to 11 hours before the server eventually had to be
> > > > rebooted.
> > > >
> > > > The database it is hanging on is 250 Gb -- but I think it should still
> > > > finish in less than 11 hours. Usually we kill the process after 9
> hours so
> > > > we can run our backups and let users start running their jobs again.
> We do
> > > > run this at night during our lowest usage.
> > > >
> > > > Any suggestions?
> > > >
> > > >
>
>
level that is hanging when I run dbcc checkdb on one particular database. It
keeps getting io and cpu time -- but just runs and run and runs.
Once when I looked at it there were 81 threads running for the DBCC's. It
was completely using up resources on the server. This is an 8 way processor.
We've let it run up to 11 hours before the server eventually had to be
rebooted.
The database it is hanging on is 250 Gb -- but I think it should still
finish in less than 11 hours. Usually we kill the process after 9 hours so
we can run our backups and let users start running their jobs again. We do
run this at night during our lowest usage.
Any suggestions?first check space in your tempdb with
dbcc checkdb (databasename) WITH ESTIMATEONLY
run CHECKDB when the system usage is low
and READ "DBCC CHECKDB Recommendations" i BOL
"DML" wrote:
> I have a server running Windows 2003 with sql server 2000 8.00.973 hot fix
> level that is hanging when I run dbcc checkdb on one particular database. It
> keeps getting io and cpu time -- but just runs and run and runs.
> Once when I looked at it there were 81 threads running for the DBCC's. It
> was completely using up resources on the server. This is an 8 way processor.
> We've let it run up to 11 hours before the server eventually had to be
> rebooted.
> The database it is hanging on is 250 Gb -- but I think it should still
> finish in less than 11 hours. Usually we kill the process after 9 hours so
> we can run our backups and let users start running their jobs again. We do
> run this at night during our lowest usage.
> Any suggestions?
>|||We do run CHECKDB at night during low usage, and run it in the same job as
backups so that they do not conflict. Disk backups are done in the morning
when we're sure our db backups are finished. Tempdb is on SAN space -- and
has over 2 Gb allocated to it with 10% growth set and more space available.
We run it with NO_INFOMSGS also. We run the same steps on our other 100
servers.
It just hangs in this 1 particular database. It is not the largest db we
have. This is also a new server we finished setting up in the last few
months and is one side of an Active Active cluster.
I ran the with estimate only and it only said I'd need around 2 Gb of tempdb
space.
Any other suggestions would be most helpful.
"Aleksandar Grbic" wrote:
> first check space in your tempdb with
> dbcc checkdb (databasename) WITH ESTIMATEONLY
> run CHECKDB when the system usage is low
>
> and READ "DBCC CHECKDB Recommendations" i BOL
>
> "DML" wrote:
> > I have a server running Windows 2003 with sql server 2000 8.00.973 hot fix
> > level that is hanging when I run dbcc checkdb on one particular database. It
> > keeps getting io and cpu time -- but just runs and run and runs.
> >
> > Once when I looked at it there were 81 threads running for the DBCC's. It
> > was completely using up resources on the server. This is an 8 way processor.
> >
> > We've let it run up to 11 hours before the server eventually had to be
> > rebooted.
> >
> > The database it is hanging on is 250 Gb -- but I think it should still
> > finish in less than 11 hours. Usually we kill the process after 9 hours so
> > we can run our backups and let users start running their jobs again. We do
> > run this at night during our lowest usage.
> >
> > Any suggestions?
> >
> >|||Let it finish. Some things to consider:
1) what are the disk queue lengths on the drives holding the database? (i.e
is your IO subsystem the bottleneck)
2) does it complete a lot faster if you use the NOINDEX option? (See BOL).
If so, you've probably got a corruption somewhere in a non-clustered index
which is triggering a much more expensive set of checks to find the exact
row with the corruption in. In which case, remove the NOINDEX option and let
it complete so you know where the corruption is.
Number 2 is my bet.
Regards
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"DML" <DML@.discussions.microsoft.com> wrote in message
news:81778FD5-BEC9-4D52-8A71-14396E6F187F@.microsoft.com...
> We do run CHECKDB at night during low usage, and run it in the same job as
> backups so that they do not conflict. Disk backups are done in the
morning
> when we're sure our db backups are finished. Tempdb is on SAN space --
and
> has over 2 Gb allocated to it with 10% growth set and more space
available.
> We run it with NO_INFOMSGS also. We run the same steps on our other 100
> servers.
> It just hangs in this 1 particular database. It is not the largest db we
> have. This is also a new server we finished setting up in the last few
> months and is one side of an Active Active cluster.
> I ran the with estimate only and it only said I'd need around 2 Gb of
tempdb
> space.
> Any other suggestions would be most helpful.
> "Aleksandar Grbic" wrote:
> > first check space in your tempdb with
> > dbcc checkdb (databasename) WITH ESTIMATEONLY
> >
> > run CHECKDB when the system usage is low
> >
> >
> > and READ "DBCC CHECKDB Recommendations" i BOL
> >
> >
> > "DML" wrote:
> >
> > > I have a server running Windows 2003 with sql server 2000 8.00.973 hot
fix
> > > level that is hanging when I run dbcc checkdb on one particular
database. It
> > > keeps getting io and cpu time -- but just runs and run and runs.
> > >
> > > Once when I looked at it there were 81 threads running for the DBCC's.
It
> > > was completely using up resources on the server. This is an 8 way
processor.
> > >
> > > We've let it run up to 11 hours before the server eventually had to be
> > > rebooted.
> > >
> > > The database it is hanging on is 250 Gb -- but I think it should still
> > > finish in less than 11 hours. Usually we kill the process after 9
hours so
> > > we can run our backups and let users start running their jobs again.
We do
> > > run this at night during our lowest usage.
> > >
> > > Any suggestions?
> > >
> > >|||We were able to track down error messages regarding 2 tables in the database.
We ran DBCC Checktable against both tables. One table came back and the
other hung. On the table that hung (357 million rows) we dropped/recreated
the indexes and this seemed to fix the problem.
Thanks for your help.
"Paul S Randal [MS]" wrote:
> Let it finish. Some things to consider:
> 1) what are the disk queue lengths on the drives holding the database? (i.e
> is your IO subsystem the bottleneck)
> 2) does it complete a lot faster if you use the NOINDEX option? (See BOL).
> If so, you've probably got a corruption somewhere in a non-clustered index
> which is triggering a much more expensive set of checks to find the exact
> row with the corruption in. In which case, remove the NOINDEX option and let
> it complete so you know where the corruption is.
> Number 2 is my bet.
> Regards
> --
> Paul Randal
> Dev Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "DML" <DML@.discussions.microsoft.com> wrote in message
> news:81778FD5-BEC9-4D52-8A71-14396E6F187F@.microsoft.com...
> > We do run CHECKDB at night during low usage, and run it in the same job as
> > backups so that they do not conflict. Disk backups are done in the
> morning
> > when we're sure our db backups are finished. Tempdb is on SAN space --
> and
> > has over 2 Gb allocated to it with 10% growth set and more space
> available.
> > We run it with NO_INFOMSGS also. We run the same steps on our other 100
> > servers.
> >
> > It just hangs in this 1 particular database. It is not the largest db we
> > have. This is also a new server we finished setting up in the last few
> > months and is one side of an Active Active cluster.
> >
> > I ran the with estimate only and it only said I'd need around 2 Gb of
> tempdb
> > space.
> >
> > Any other suggestions would be most helpful.
> >
> > "Aleksandar Grbic" wrote:
> >
> > > first check space in your tempdb with
> > > dbcc checkdb (databasename) WITH ESTIMATEONLY
> > >
> > > run CHECKDB when the system usage is low
> > >
> > >
> > > and READ "DBCC CHECKDB Recommendations" i BOL
> > >
> > >
> > > "DML" wrote:
> > >
> > > > I have a server running Windows 2003 with sql server 2000 8.00.973 hot
> fix
> > > > level that is hanging when I run dbcc checkdb on one particular
> database. It
> > > > keeps getting io and cpu time -- but just runs and run and runs.
> > > >
> > > > Once when I looked at it there were 81 threads running for the DBCC's.
> It
> > > > was completely using up resources on the server. This is an 8 way
> processor.
> > > >
> > > > We've let it run up to 11 hours before the server eventually had to be
> > > > rebooted.
> > > >
> > > > The database it is hanging on is 250 Gb -- but I think it should still
> > > > finish in less than 11 hours. Usually we kill the process after 9
> hours so
> > > > we can run our backups and let users start running their jobs again.
> We do
> > > > run this at night during our lowest usage.
> > > >
> > > > Any suggestions?
> > > >
> > > >
>
>
Tuesday, February 14, 2012
DBCC CheckDB
How often should we run the DBCC CheckDB ? Do this command automatic
update or fix database if they find error ?Never run with the auto fix. You should decide how ad when to do the fix if
a problem occurs. You should basically run CHECKDB as often as is feasible.
If you have the window then once a night is great but most people only do it
once a week.
--
Andrew J. Kelly
SQL Server MVP
"John Smith" <someone@.nospam.com.us> wrote in message
news:eTs1GZOnDHA.2268@.TK2MSFTNGP12.phx.gbl...
> How often should we run the DBCC CheckDB ? Do this command automatic
> update or fix database if they find error ?
>|||Hi,
If your server is 24 X 7 , Load the latest database backup to the test
environment and run DBCC Checkdb atleast weekly once.
Incase if the output shows errors you can execute DBCC checkdb with REPAIR
options.
Thanks
Hari
MCDBA
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:eJm1O#OnDHA.3024@.tk2msftngp13.phx.gbl...
> Never run with the auto fix. You should decide how ad when to do the fix
if
> a problem occurs. You should basically run CHECKDB as often as is
feasible.
> If you have the window then once a night is great but most people only do
it
> once a week.
> --
> Andrew J. Kelly
> SQL Server MVP
>
> "John Smith" <someone@.nospam.com.us> wrote in message
> news:eTs1GZOnDHA.2268@.TK2MSFTNGP12.phx.gbl...
> > How often should we run the DBCC CheckDB ? Do this command automatic
> > update or fix database if they find error ?
> >
>|||> Incase if the output shows errors you can execute DBCC checkdb with REPAIR
> options.
The preferred option to recover from such problems is doing a log backup, restoring latest clean
database backup and subsequent log backups. Most cases, repair cannot fix and I wouldn't be
surprised if repair makes on loose the option to do the last tlog backup.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Hari" <hari_prasad_k@.hotmail.com> wrote in message news:eR0aNWRnDHA.2416@.TK2MSFTNGP10.phx.gbl...
> Hi,
> If your server is 24 X 7 , Load the latest database backup to the test
> environment and run DBCC Checkdb atleast weekly once.
> Incase if the output shows errors you can execute DBCC checkdb with REPAIR
> options.
> Thanks
> Hari
> MCDBA
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:eJm1O#OnDHA.3024@.tk2msftngp13.phx.gbl...
> > Never run with the auto fix. You should decide how ad when to do the fix
> if
> > a problem occurs. You should basically run CHECKDB as often as is
> feasible.
> > If you have the window then once a night is great but most people only do
> it
> > once a week.
> >
> > --
> >
> > Andrew J. Kelly
> > SQL Server MVP
> >
> >
> > "John Smith" <someone@.nospam.com.us> wrote in message
> > news:eTs1GZOnDHA.2268@.TK2MSFTNGP12.phx.gbl...
> > > How often should we run the DBCC CheckDB ? Do this command automatic
> > > update or fix database if they find error ?
> > >
> >
> >
>|||Is auto fix a default ? I mean, if I type dbcc checkdb in Query Analyzer
, it will auto fix the databases if there is an error ?
Andrew J. Kelly wrote:
> Never run with the auto fix. You should decide how ad when to do the fix if
> a problem occurs. You should basically run CHECKDB as often as is feasible.
> If you have the window then once a night is great but most people only do it
> once a week.
>|||No, if you specifically issue the DBCC command (vs using the maintenance
plan) you must specify the option to allow it to fix any issues. You must
also set the db to single user mode first.
--
Andrew J. Kelly
SQL Server MVP
"John Smith" <someone@.nospam.com.us> wrote in message
news:%236PBGbZnDHA.2272@.tk2msftngp13.phx.gbl...
> Is auto fix a default ? I mean, if I type dbcc checkdb in Query Analyzer
> , it will auto fix the databases if there is an error ?
>
> Andrew J. Kelly wrote:
> > Never run with the auto fix. You should decide how ad when to do the
fix if
> > a problem occurs. You should basically run CHECKDB as often as is
feasible.
> > If you have the window then once a night is great but most people only
do it
> > once a week.
> >
>
update or fix database if they find error ?Never run with the auto fix. You should decide how ad when to do the fix if
a problem occurs. You should basically run CHECKDB as often as is feasible.
If you have the window then once a night is great but most people only do it
once a week.
--
Andrew J. Kelly
SQL Server MVP
"John Smith" <someone@.nospam.com.us> wrote in message
news:eTs1GZOnDHA.2268@.TK2MSFTNGP12.phx.gbl...
> How often should we run the DBCC CheckDB ? Do this command automatic
> update or fix database if they find error ?
>|||Hi,
If your server is 24 X 7 , Load the latest database backup to the test
environment and run DBCC Checkdb atleast weekly once.
Incase if the output shows errors you can execute DBCC checkdb with REPAIR
options.
Thanks
Hari
MCDBA
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:eJm1O#OnDHA.3024@.tk2msftngp13.phx.gbl...
> Never run with the auto fix. You should decide how ad when to do the fix
if
> a problem occurs. You should basically run CHECKDB as often as is
feasible.
> If you have the window then once a night is great but most people only do
it
> once a week.
> --
> Andrew J. Kelly
> SQL Server MVP
>
> "John Smith" <someone@.nospam.com.us> wrote in message
> news:eTs1GZOnDHA.2268@.TK2MSFTNGP12.phx.gbl...
> > How often should we run the DBCC CheckDB ? Do this command automatic
> > update or fix database if they find error ?
> >
>|||> Incase if the output shows errors you can execute DBCC checkdb with REPAIR
> options.
The preferred option to recover from such problems is doing a log backup, restoring latest clean
database backup and subsequent log backups. Most cases, repair cannot fix and I wouldn't be
surprised if repair makes on loose the option to do the last tlog backup.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Hari" <hari_prasad_k@.hotmail.com> wrote in message news:eR0aNWRnDHA.2416@.TK2MSFTNGP10.phx.gbl...
> Hi,
> If your server is 24 X 7 , Load the latest database backup to the test
> environment and run DBCC Checkdb atleast weekly once.
> Incase if the output shows errors you can execute DBCC checkdb with REPAIR
> options.
> Thanks
> Hari
> MCDBA
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:eJm1O#OnDHA.3024@.tk2msftngp13.phx.gbl...
> > Never run with the auto fix. You should decide how ad when to do the fix
> if
> > a problem occurs. You should basically run CHECKDB as often as is
> feasible.
> > If you have the window then once a night is great but most people only do
> it
> > once a week.
> >
> > --
> >
> > Andrew J. Kelly
> > SQL Server MVP
> >
> >
> > "John Smith" <someone@.nospam.com.us> wrote in message
> > news:eTs1GZOnDHA.2268@.TK2MSFTNGP12.phx.gbl...
> > > How often should we run the DBCC CheckDB ? Do this command automatic
> > > update or fix database if they find error ?
> > >
> >
> >
>|||Is auto fix a default ? I mean, if I type dbcc checkdb in Query Analyzer
, it will auto fix the databases if there is an error ?
Andrew J. Kelly wrote:
> Never run with the auto fix. You should decide how ad when to do the fix if
> a problem occurs. You should basically run CHECKDB as often as is feasible.
> If you have the window then once a night is great but most people only do it
> once a week.
>|||No, if you specifically issue the DBCC command (vs using the maintenance
plan) you must specify the option to allow it to fix any issues. You must
also set the db to single user mode first.
--
Andrew J. Kelly
SQL Server MVP
"John Smith" <someone@.nospam.com.us> wrote in message
news:%236PBGbZnDHA.2272@.tk2msftngp13.phx.gbl...
> Is auto fix a default ? I mean, if I type dbcc checkdb in Query Analyzer
> , it will auto fix the databases if there is an error ?
>
> Andrew J. Kelly wrote:
> > Never run with the auto fix. You should decide how ad when to do the
fix if
> > a problem occurs. You should basically run CHECKDB as often as is
feasible.
> > If you have the window then once a night is great but most people only
do it
> > once a week.
> >
>
Subscribe to:
Posts (Atom)