dbcc shrinkfile & recovery mode

Occasionally, we have gotten messages that the logfile is too big on one
of our servers. At that point, we will run a backup of the database and
then dbcc shrinkfile on it.
From what I've read, I thought that some of the properties we have set
would make it unnecessary to have to do that. On the Options tab on the
database properties, we have the Recovery model set to Simple, and have
the following settings checked: Auto Update Statistics, Auto Shrink,
and Auto Create Statistics.
Is there another setting I'm missing? Or, should I just set up a job to
back up the database and run the dbcc shrinkfile on it at set intervals?
BC
AutoShrink is taking your log file down to a very minimal size when it runs,
and then your Autogrow has to kick in when the db has a lot of
activity...if it is very busy, it could grow quite large. I've never seen
a SQL Server message "too big"...what are you really getting, and what is
the size at that point.?
In theory, if you set the db to Simple and DBCC Shrinkfile it down to a size
that is big enough to handle your busiest time frames you should be good
from there.
Kevin Hill
President
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
www.DallasDBAs.com/forum - new DB forum for Dallas/Ft. Worth area DBAs.
www.experts-exchange.com - experts compete for points to answer your
questions
"Blasting Cap" <goober@.christian.net> wrote in message
news:%23xn12hncFHA.1384@.TK2MSFTNGP09.phx.gbl...
> Occasionally, we have gotten messages that the logfile is too big on one
> of our servers. At that point, we will run a backup of the database and
> then dbcc shrinkfile on it.
> From what I've read, I thought that some of the properties we have set
> would make it unnecessary to have to do that. On the Options tab on the
> database properties, we have the Recovery model set to Simple, and have
> the following settings checked: Auto Update Statistics, Auto Shrink, and
> Auto Create Statistics.
> Is there another setting I'm missing? Or, should I just set up a job to
> back up the database and run the dbcc shrinkfile on it at set intervals?
> BC

dbcc shrinkfile & recovery mode

Occasionally, we have gotten messages that the logfile is too big on one
of our servers. At that point, we will run a backup of the database and
then dbcc shrinkfile on it.
From what I've read, I thought that some of the properties we have set
would make it unnecessary to have to do that. On the Options tab on the
database properties, we have the Recovery model set to Simple, and have
the following settings checked: Auto Update Statistics, Auto Shrink,
and Auto Create Statistics.
Is there another setting I'm missing? Or, should I just set up a job to
back up the database and run the dbcc shrinkfile on it at set intervals?
BCAutoShrink is taking your log file down to a very minimal size when it runs,
and then your Autogrow has to kick in when the db has a lot of
activity...if it is very busy, it could grow quite large. I've never seen
a SQL Server message "too big"...what are you really getting, and what is
the size at that point.?
In theory, if you set the db to Simple and DBCC Shrinkfile it down to a size
that is big enough to handle your busiest time frames you should be good
from there.
Kevin Hill
President
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
www.DallasDBAs.com/forum - new DB forum for Dallas/Ft. Worth area DBAs.
www.experts-exchange.com - experts compete for points to answer your
questions
"Blasting Cap" <goober@.christian.net> wrote in message
news:%23xn12hncFHA.1384@.TK2MSFTNGP09.phx.gbl...
> Occasionally, we have gotten messages that the logfile is too big on one
> of our servers. At that point, we will run a backup of the database and
> then dbcc shrinkfile on it.
> From what I've read, I thought that some of the properties we have set
> would make it unnecessary to have to do that. On the Options tab on the
> database properties, we have the Recovery model set to Simple, and have
> the following settings checked: Auto Update Statistics, Auto Shrink, and
> Auto Create Statistics.
> Is there another setting I'm missing? Or, should I just set up a job to
> back up the database and run the dbcc shrinkfile on it at set intervals?
> BC

dbcc shrinkfile & recovery mode

Occasionally, we have gotten messages that the logfile is too big on one
of our servers. At that point, we will run a backup of the database and
then dbcc shrinkfile on it.
From what I've read, I thought that some of the properties we have set
would make it unnecessary to have to do that. On the Options tab on the
database properties, we have the Recovery model set to Simple, and have
the following settings checked: Auto Update Statistics, Auto Shrink,
and Auto Create Statistics.
Is there another setting I'm missing? Or, should I just set up a job to
back up the database and run the dbcc shrinkfile on it at set intervals?
BCAutoShrink is taking your log file down to a very minimal size when it runs,
and then your Autogrow has to kick in when the db has a lot of
activity...if it is very busy, it could grow quite large. I've never seen
a SQL Server message "too big"...what are you really getting, and what is
the size at that point.?
In theory, if you set the db to Simple and DBCC Shrinkfile it down to a size
that is big enough to handle your busiest time frames you should be good
from there.
--
Kevin Hill
President
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
www.DallasDBAs.com/forum - new DB forum for Dallas/Ft. Worth area DBAs.
www.experts-exchange.com - experts compete for points to answer your
questions
"Blasting Cap" <goober@.christian.net> wrote in message
news:%23xn12hncFHA.1384@.TK2MSFTNGP09.phx.gbl...
> Occasionally, we have gotten messages that the logfile is too big on one
> of our servers. At that point, we will run a backup of the database and
> then dbcc shrinkfile on it.
> From what I've read, I thought that some of the properties we have set
> would make it unnecessary to have to do that. On the Options tab on the
> database properties, we have the Recovery model set to Simple, and have
> the following settings checked: Auto Update Statistics, Auto Shrink, and
> Auto Create Statistics.
> Is there another setting I'm missing? Or, should I just set up a job to
> back up the database and run the dbcc shrinkfile on it at set intervals?
> BC

DBCC Error Logging

Hello,

I am running some DBCC checks as a routine maintenance task on my sql server 2000 servers. I am running DBCC CHECKDB, DBCC CHECKCONSTRAINTS and DBCC CHECKCATALOG. I have established a set of procedures and tables to capture the output from the error log after running these DBCC commands. After running all three, it appears the same info captured for CHECKDB is not logged for these two: CHECKCONSTRAINTS and CHECKCATALOG. Does anyone know why these are not logged and if it is even necessary for me to run these 2 extra DBCC checks? If not, can anyone recommend what database consistency checks should be executed on a daily basis for a production database server?

DBCC CHECKDB (DBNAME) executed by lshores found 0 errors and repaired 0 errors. Elapsed time: 0 hours 20 minutes 32 seconds.I found help for this question in this article http://www.sql-server-performance.com/ak_inside_sql_server_maintenance_plans.asp
and further info in BOL (sqlmaint Utility.)

DBCC CHECKDB multiple errors

SQL2K
SP4
Error: 7987, Severity: 22, State: 3
A possible database consistency problem has been detected
Ran DBCC CHECKDB on WV database on both servers (the dbs are not copies
of each other but are based on the same information, 1 is on the
development server, the other on the production server) but received
the same error messages for the same tables in both. At the end of the
message was:
CHECKDB found 0 allocation errors and 8 consistency errors in database
'WV'.
repair_allow_data_loss is the minimum repair level for the errors found
by DBCC CHECKDB (WV ).
When I ran DBCC DBREINDEX (as an alternative to allowing data loss) on
the tables indicated, it appeared to fix a few tables that only had 1
consistency error (they no longer show up with inconsistencies) but
there are 2 tables that still show up with multiple errors.
I haven't found a post with all the error messages (8928, 8944, 8964)
and I'm wondering what the best approach to this is to prevent any
data loss.
Ironically, I've never seen msg 8964 before this week, and we
installed SP4 last week, which is supposed to take care of this bug.
Could this have caused the bug?
DBCC results for 'sde.GDB_STRINGDOMAINS'.
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 1648724926, index ID 0: Page (1:155093) could not be
processed. See other errors for details.
Server: Msg 8944, Level 16, State 1, Line 1
Table error: Object ID 1648724926, index ID 0, page (1:155093), row 25.
Test (offsetNull >= BASEOFFSET) failed. Values are 0 and 4.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313603), slot 10, text ID 41680896 is not referenced.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313603), slot 11, text ID 1340932096 is not referenced.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313603), slot 12, text ID 23986176 is not referenced.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313604), slot 0, text ID 96010240 is not referenced.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313604), slot 1, text ID 817430528 is not referenced.
There are 0 rows in 0 pages for object 'sde.GDB_STRINGDOMAINS'.
DBCC results for 'wvowner.f8'.
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 1648724926, index ID 0: Page (1:155093) could not be
processed. See other errors for details.
Server: Msg 8944, Level 16, State 1, Line 1
Table error: Object ID 1648724926, index ID 0, page (1:155093), row 25.
Test (offsetNull >= BASEOFFSET) failed. Values are 0 and 4.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313603), slot 10, text ID 41680896 is not referenced.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313603), slot 11, text ID 1340932096 is not referenced.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313603), slot 12, text ID 23986176 is not referenced.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313604), slot 0, text ID 96010240 is not referenced.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313604), slot 1, text ID 817430528 is not referenced.
There are 1078620 rows in 30728 pages for object 'wvowner.f8'.
CHECKDB found 0 allocation errors and 7 consistency errors in table
'wvowner.f8' (object ID 1648724926).
For both of these tables, CHECKDB has found a row whose structure we cannot
validate (row 25 on page 1:155093). Because the structure of the rest of
the page is suspect due to this problem, DBCC will not process the page any
further. The 8964 errors reported are a result of our not processing any of
the data on this page. Running REPAIR_ALLOW_DATA_LOSS will result in this
page being deallocated. Because it is a data page, you will lose data.
(FYI, error 7987 is the run-time check that is equivalent to the corruption
that CHECKDB is reporting. It is a new error in SP4.)
The only way to ensure that you don't lose any data is to restore your last
known good database backups, plus any transaction log backups.

> Ironically, I've never seen msg 8964 before this week, and we
> installed SP4 last week, which is supposed to take care of this bug.
> Could this have caused the bug?
I'm not sure I understand this statement. Which bug are you referring to?
Thanks,
Ryan Stonecipher
Microsoft Sql Server Storage Engine, DBCC
This posting is provided "AS IS" with no warranties, and confers no rights.
<naomimsm@.gmail.com> wrote in message
news:1122478968.737696.309790@.f14g2000cwb.googlegr oups.com...
> SQL2K
> SP4
> Error: 7987, Severity: 22, State: 3
> A possible database consistency problem has been detected
> Ran DBCC CHECKDB on WV database on both servers (the dbs are not copies
> of each other but are based on the same information, 1 is on the
> development server, the other on the production server) but received
> the same error messages for the same tables in both. At the end of the
> message was:
> CHECKDB found 0 allocation errors and 8 consistency errors in database
> 'WV'.
> repair_allow_data_loss is the minimum repair level for the errors found
> by DBCC CHECKDB (WV ).
> When I ran DBCC DBREINDEX (as an alternative to allowing data loss) on
> the tables indicated, it appeared to fix a few tables that only had 1
> consistency error (they no longer show up with inconsistencies) but
> there are 2 tables that still show up with multiple errors.
> I haven't found a post with all the error messages (8928, 8944, 8964)
> and I'm wondering what the best approach to this is to prevent any
> data loss.
> Ironically, I've never seen msg 8964 before this week, and we
> installed SP4 last week, which is supposed to take care of this bug.
> Could this have caused the bug?
> DBCC results for 'sde.GDB_STRINGDOMAINS'.
> Server: Msg 8928, Level 16, State 1, Line 1
> Object ID 1648724926, index ID 0: Page (1:155093) could not be
> processed. See other errors for details.
> Server: Msg 8944, Level 16, State 1, Line 1
> Table error: Object ID 1648724926, index ID 0, page (1:155093), row 25.
> Test (offsetNull >= BASEOFFSET) failed. Values are 0 and 4.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313603), slot 10, text ID 41680896 is not referenced.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313603), slot 11, text ID 1340932096 is not referenced.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313603), slot 12, text ID 23986176 is not referenced.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313604), slot 0, text ID 96010240 is not referenced.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313604), slot 1, text ID 817430528 is not referenced.
> There are 0 rows in 0 pages for object 'sde.GDB_STRINGDOMAINS'.
>
> DBCC results for 'wvowner.f8'.
> Server: Msg 8928, Level 16, State 1, Line 1
> Object ID 1648724926, index ID 0: Page (1:155093) could not be
> processed. See other errors for details.
> Server: Msg 8944, Level 16, State 1, Line 1
> Table error: Object ID 1648724926, index ID 0, page (1:155093), row 25.
> Test (offsetNull >= BASEOFFSET) failed. Values are 0 and 4.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313603), slot 10, text ID 41680896 is not referenced.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313603), slot 11, text ID 1340932096 is not referenced.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313603), slot 12, text ID 23986176 is not referenced.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313604), slot 0, text ID 96010240 is not referenced.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313604), slot 1, text ID 817430528 is not referenced.
> There are 1078620 rows in 30728 pages for object 'wvowner.f8'.
> CHECKDB found 0 allocation errors and 7 consistency errors in table
> 'wvowner.f8' (object ID 1648724926).
>
|||Ryan, we, too, have had DBCC CHECKDB errors, and the errors we have had
seemed to disappear on subsquent runs of DBCC CHECKDB. Why? Does some
automatic fix happen with some types of errors, or is something getting
swept under the rug?
How does one track down the cause of CHECKDB errors?
Can virus protection software (Avast in our case) ever be a cause of DB
corruption?
The error(s) that disappeared are as follows:
[2] Database VMed1: Check Data and Index Linkage...
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8928: [Microsoft][ODBC SQL
Server Driver][SQL Server]Object ID 2050874423, index ID 2: Page (1:21349)
could not be processed. See other errors for details.
[Microsoft][ODBC SQL Server Driver][SQL Server]Table error: Object ID
2050874423, index ID 2, page (1:21349), row 339. Test (ColumnOffsets <=
(nextRec - pRec)) failed. Values are 13 and 3.
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation
errors and 2 consistency errors in table 'NodeRelation' (object ID
2050874423).
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation
errors and 2 consistency errors in database 'VMed1'.
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss is the
minimum repair level for the errors found by DBCC CHECKDB (VMed1 ).
Thanks,
Randy Neall
"Ryan Stonecipher [MSFT]" <ryanston@.microsoft.com> wrote in message
news:eihMfCukFHA.3380@.TK2MSFTNGP12.phx.gbl...
> For both of these tables, CHECKDB has found a row whose structure we
cannot
> validate (row 25 on page 1:155093). Because the structure of the rest of
> the page is suspect due to this problem, DBCC will not process the page
any
> further. The 8964 errors reported are a result of our not processing any
of
> the data on this page. Running REPAIR_ALLOW_DATA_LOSS will result in this
> page being deallocated. Because it is a data page, you will lose data.
> (FYI, error 7987 is the run-time check that is equivalent to the
corruption
> that CHECKDB is reporting. It is a new error in SP4.)
> The only way to ensure that you don't lose any data is to restore your
last
> known good database backups, plus any transaction log backups.
>
> I'm not sure I understand this statement. Which bug are you referring to?
> Thanks,
> --
> Ryan Stonecipher
> Microsoft Sql Server Storage Engine, DBCC
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> <naomimsm@.gmail.com> wrote in message
> news:1122478968.737696.309790@.f14g2000cwb.googlegr oups.com...
>
|||Randy,
There are a couple of possibilities: the first is hardware, the second is
normal workload processing.
In some circumstances, corruption problems can exist in memory only. For
instance, bad disk firmware can generate single-byte or single-bit
discrepancies when a page is read from disk. If CHECKDB is run on this
data, then it can generate corruption errors. Subsequent reads of the same
page may come back just fine. In SQL Server 2005, we've introduced a page
checksum feature that will help to identify these issues when they happen.
Bad memory can also cause problems like this...
In other cases, true corruption can exist in your database, but your normal
maintenance plans (that rebuild indexes, for instance) could eliminate the
corruption by regenerating the index pages during the rebuild. (The index
rebuild "fix" really only works for nonclustered indexes; if you have hard
corruption in your data pages, then a rebuild won't fix the issue.)
In your case, either is possible. Since this was a nonclustered index,
could a maintenance rebuild have fixed your problem? Have you run complete
hardware diagnostics on your IO stack?
Ryan Stonecipher
Microsoft Sql Server Storage Engine, DBCC
This posting is provided "AS IS" with no warranties, and confers no rights.
"Randolph Neall" <randolphneall@.veracitycomputing.com> wrote in message
news:OK2GwxukFHA.3148@.TK2MSFTNGP09.phx.gbl...
> Ryan, we, too, have had DBCC CHECKDB errors, and the errors we have had
> seemed to disappear on subsquent runs of DBCC CHECKDB. Why? Does some
> automatic fix happen with some types of errors, or is something getting
> swept under the rug?
> How does one track down the cause of CHECKDB errors?
> Can virus protection software (Avast in our case) ever be a cause of DB
> corruption?
> The error(s) that disappeared are as follows:
> [2] Database VMed1: Check Data and Index Linkage...
> [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8928: [Microsoft][ODBC
> SQL
> Server Driver][SQL Server]Object ID 2050874423, index ID 2: Page (1:21349)
> could not be processed. See other errors for details.
> [Microsoft][ODBC SQL Server Driver][SQL Server]Table error: Object ID
> 2050874423, index ID 2, page (1:21349), row 339. Test (ColumnOffsets <=
> (nextRec - pRec)) failed. Values are 13 and 3.
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation
> errors and 2 consistency errors in table 'NodeRelation' (object ID
> 2050874423).
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation
> errors and 2 consistency errors in database 'VMed1'.
> [Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss is
> the
> minimum repair level for the errors found by DBCC CHECKDB (VMed1 ).
> Thanks,
> Randy Neall
>
> "Ryan Stonecipher [MSFT]" <ryanston@.microsoft.com> wrote in message
> news:eihMfCukFHA.3380@.TK2MSFTNGP12.phx.gbl...
> cannot
> any
> of
> corruption
> last
> rights.
>
|||Thanks much, Ryan. In fact we ARE rebuilding indexes every night (possibly
overkill), and this error occurs AFTER that rebuild, I mean immediately
after (30 minutes) in the wee hours when no one is working. So it appears
that we got the problem as a direct result of the rebuild itself.
Apparently, the following night, the rebuild happens again, and that one
evidently fixes it.
We will check out our hardware with whatever diagnostics are available.
The errors we have seen tend to always be on the same table and possibly the
same index. I'm wondering if some table/index designs are more vulnerable
and unstable than others. This particular table has about seven integers
with overlapping indexes on all columns, including a single-column identity
clustered index and an alternate key on six of the integer columns, plus
others.
Thanks,
Randy Neall
|||I would strongly recommend that you open up a case with Microsoft support in
this case (http://support.microsoft.com), as it doesn't sound at all like
normal behavior. To answer your question, there aren't any particular index
structures that are more susceptible to this problem than others. I would
get in touch with the experts in PSS and have them help you narrow down the
problem.
Thanks,
Ryan Stonecipher
Microsoft Sql Server Storage Engine, DBCC
This posting is provided "AS IS" with no warranties, and confers no rights.
"Brandon Owensby" <123@.abc.com> wrote in message
news:Og2k4B5kFHA.1148@.TK2MSFTNGP12.phx.gbl...
> Thanks much, Ryan. In fact we ARE rebuilding indexes every night (possibly
> overkill), and this error occurs AFTER that rebuild, I mean immediately
> after (30 minutes) in the wee hours when no one is working. So it appears
> that we got the problem as a direct result of the rebuild itself.
> Apparently, the following night, the rebuild happens again, and that one
> evidently fixes it.
> We will check out our hardware with whatever diagnostics are available.
> The errors we have seen tend to always be on the same table and possibly
> the same index. I'm wondering if some table/index designs are more
> vulnerable and unstable than others. This particular table has about seven
> integers with overlapping indexes on all columns, including a
> single-column identity clustered index and an alternate key on six of the
> integer columns, plus others.
> Thanks,
> Randy Neall
>
>

DBCC CHECKDB multiple errors

SQL2K
SP4
Error: 7987, Severity: 22, State: 3
A possible database consistency problem has been detected
Ran DBCC CHECKDB on WV database on both servers (the dbs are not copies
of each other but are based on the same information, 1 is on the
development server, the other on the production server) but received
the same error messages for the same tables in both. At the end of the
message was:
CHECKDB found 0 allocation errors and 8 consistency errors in database
'WV'.
repair_allow_data_loss is the minimum repair level for the errors found
by DBCC CHECKDB (WV ).
When I ran DBCC DBREINDEX (as an alternative to allowing data loss) on
the tables indicated, it appeared to fix a few tables that only had 1
consistency error (they no longer show up with inconsistencies) but
there are 2 tables that still show up with multiple errors.
I haven't found a post with all the error messages (8928, 8944, 8964)
and I'm wondering what the best approach to this is to prevent any
data loss.
Ironically, I've never seen msg 8964 before this week, and we
installed SP4 last week, which is supposed to take care of this bug.
Could this have caused the bug?
DBCC results for 'sde.GDB_STRINGDOMAINS'.
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 1648724926, index ID 0: Page (1:155093) could not be
processed. See other errors for details.
Server: Msg 8944, Level 16, State 1, Line 1
Table error: Object ID 1648724926, index ID 0, page (1:155093), row 25.
Test (offsetNull >= BASEOFFSET) failed. Values are 0 and 4.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313603), slot 10, text ID 41680896 is not referenced.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313603), slot 11, text ID 1340932096 is not referenced.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313603), slot 12, text ID 23986176 is not referenced.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313604), slot 0, text ID 96010240 is not referenced.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313604), slot 1, text ID 817430528 is not referenced.
There are 0 rows in 0 pages for object 'sde.GDB_STRINGDOMAINS'.
DBCC results for 'wvowner.f8'.
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 1648724926, index ID 0: Page (1:155093) could not be
processed. See other errors for details.
Server: Msg 8944, Level 16, State 1, Line 1
Table error: Object ID 1648724926, index ID 0, page (1:155093), row 25.
Test (offsetNull >= BASEOFFSET) failed. Values are 0 and 4.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313603), slot 10, text ID 41680896 is not referenced.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313603), slot 11, text ID 1340932096 is not referenced.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313603), slot 12, text ID 23986176 is not referenced.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313604), slot 0, text ID 96010240 is not referenced.
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1648724926. The text, ntext, or image node at
page (1:313604), slot 1, text ID 817430528 is not referenced.
There are 1078620 rows in 30728 pages for object 'wvowner.f8'.
CHECKDB found 0 allocation errors and 7 consistency errors in table
'wvowner.f8' (object ID 1648724926).For both of these tables, CHECKDB has found a row whose structure we cannot
validate (row 25 on page 1:155093). Because the structure of the rest of
the page is suspect due to this problem, DBCC will not process the page any
further. The 8964 errors reported are a result of our not processing any of
the data on this page. Running REPAIR_ALLOW_DATA_LOSS will result in this
page being deallocated. Because it is a data page, you will lose data.
(FYI, error 7987 is the run-time check that is equivalent to the corruption
that CHECKDB is reporting. It is a new error in SP4.)
The only way to ensure that you don't lose any data is to restore your last
known good database backups, plus any transaction log backups.

> Ironically, I've never seen msg 8964 before this week, and we
> installed SP4 last week, which is supposed to take care of this bug.
> Could this have caused the bug?
I'm not sure I understand this statement. Which bug are you referring to?
Thanks,
--
Ryan Stonecipher
Microsoft Sql Server Storage Engine, DBCC
This posting is provided "AS IS" with no warranties, and confers no rights.
<naomimsm@.gmail.com> wrote in message
news:1122478968.737696.309790@.f14g2000cwb.googlegroups.com...
> SQL2K
> SP4
> Error: 7987, Severity: 22, State: 3
> A possible database consistency problem has been detected
> Ran DBCC CHECKDB on WV database on both servers (the dbs are not copies
> of each other but are based on the same information, 1 is on the
> development server, the other on the production server) but received
> the same error messages for the same tables in both. At the end of the
> message was:
> CHECKDB found 0 allocation errors and 8 consistency errors in database
> 'WV'.
> repair_allow_data_loss is the minimum repair level for the errors found
> by DBCC CHECKDB (WV ).
> When I ran DBCC DBREINDEX (as an alternative to allowing data loss) on
> the tables indicated, it appeared to fix a few tables that only had 1
> consistency error (they no longer show up with inconsistencies) but
> there are 2 tables that still show up with multiple errors.
> I haven't found a post with all the error messages (8928, 8944, 8964)
> and I'm wondering what the best approach to this is to prevent any
> data loss.
> Ironically, I've never seen msg 8964 before this week, and we
> installed SP4 last week, which is supposed to take care of this bug.
> Could this have caused the bug?
> DBCC results for 'sde.GDB_STRINGDOMAINS'.
> Server: Msg 8928, Level 16, State 1, Line 1
> Object ID 1648724926, index ID 0: Page (1:155093) could not be
> processed. See other errors for details.
> Server: Msg 8944, Level 16, State 1, Line 1
> Table error: Object ID 1648724926, index ID 0, page (1:155093), row 25.
> Test (offsetNull >= BASEOFFSET) failed. Values are 0 and 4.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313603), slot 10, text ID 41680896 is not referenced.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313603), slot 11, text ID 1340932096 is not referenced.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313603), slot 12, text ID 23986176 is not referenced.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313604), slot 0, text ID 96010240 is not referenced.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313604), slot 1, text ID 817430528 is not referenced.
> There are 0 rows in 0 pages for object 'sde.GDB_STRINGDOMAINS'.
>
> DBCC results for 'wvowner.f8'.
> Server: Msg 8928, Level 16, State 1, Line 1
> Object ID 1648724926, index ID 0: Page (1:155093) could not be
> processed. See other errors for details.
> Server: Msg 8944, Level 16, State 1, Line 1
> Table error: Object ID 1648724926, index ID 0, page (1:155093), row 25.
> Test (offsetNull >= BASEOFFSET) failed. Values are 0 and 4.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313603), slot 10, text ID 41680896 is not referenced.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313603), slot 11, text ID 1340932096 is not referenced.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313603), slot 12, text ID 23986176 is not referenced.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313604), slot 0, text ID 96010240 is not referenced.
> Server: Msg 8964, Level 16, State 1, Line 1
> Table error: Object ID 1648724926. The text, ntext, or image node at
> page (1:313604), slot 1, text ID 817430528 is not referenced.
> There are 1078620 rows in 30728 pages for object 'wvowner.f8'.
> CHECKDB found 0 allocation errors and 7 consistency errors in table
> 'wvowner.f8' (object ID 1648724926).
>|||Ryan, we, too, have had DBCC CHECKDB errors, and the errors we have had
seemed to disappear on subsquent runs of DBCC CHECKDB. Why? Does some
automatic fix happen with some types of errors, or is something getting
swept under the rug?
How does one track down the cause of CHECKDB errors?
Can virus protection software (Avast in our case) ever be a cause of DB
corruption?
The error(s) that disappeared are as follows:
[2] Database VMed1: Check Data and Index Linkage...
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8928: [Microsoft]&#
91;ODBC SQL
Server Driver][SQL Server]Object ID 2050874423, index ID 2: Page (1:2134
9)
could not be processed. See other errors for details.
[Microsoft][ODBC SQL Server Driver][SQL Server]Table error: Obje
ct ID
2050874423, index ID 2, page (1:21349), row 339. Test (ColumnOffsets <=
(nextRec - pRec)) failed. Values are 13 and 3.
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 a
llocation
errors and 2 consistency errors in table 'NodeRelation' (object ID
2050874423).
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 a
llocation
errors and 2 consistency errors in database 'VMed1'.
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data
_loss is the
minimum repair level for the errors found by DBCC CHECKDB (VMed1 ).
Thanks,
Randy Neall
"Ryan Stonecipher [MSFT]" <ryanston@.microsoft.com> wrote in message
news:eihMfCukFHA.3380@.TK2MSFTNGP12.phx.gbl...
> For both of these tables, CHECKDB has found a row whose structure we
cannot
> validate (row 25 on page 1:155093). Because the structure of the rest of
> the page is suspect due to this problem, DBCC will not process the page
any
> further. The 8964 errors reported are a result of our not processing any
of
> the data on this page. Running REPAIR_ALLOW_DATA_LOSS will result in this
> page being deallocated. Because it is a data page, you will lose data.
> (FYI, error 7987 is the run-time check that is equivalent to the
corruption
> that CHECKDB is reporting. It is a new error in SP4.)
> The only way to ensure that you don't lose any data is to restore your
last
> known good database backups, plus any transaction log backups.
>
> I'm not sure I understand this statement. Which bug are you referring to?
> Thanks,
> --
> Ryan Stonecipher
> Microsoft Sql Server Storage Engine, DBCC
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> <naomimsm@.gmail.com> wrote in message
> news:1122478968.737696.309790@.f14g2000cwb.googlegroups.com...
>|||Randy,
There are a couple of possibilities: the first is hardware, the second is
normal workload processing.
In some circumstances, corruption problems can exist in memory only. For
instance, bad disk firmware can generate single-byte or single-bit
discrepancies when a page is read from disk. If CHECKDB is run on this
data, then it can generate corruption errors. Subsequent reads of the same
page may come back just fine. In SQL Server 2005, we've introduced a page
checksum feature that will help to identify these issues when they happen.
Bad memory can also cause problems like this...
In other cases, true corruption can exist in your database, but your normal
maintenance plans (that rebuild indexes, for instance) could eliminate the
corruption by regenerating the index pages during the rebuild. (The index
rebuild "fix" really only works for nonclustered indexes; if you have hard
corruption in your data pages, then a rebuild won't fix the issue.)
In your case, either is possible. Since this was a nonclustered index,
could a maintenance rebuild have fixed your problem? Have you run complete
hardware diagnostics on your IO stack?
Ryan Stonecipher
Microsoft Sql Server Storage Engine, DBCC
This posting is provided "AS IS" with no warranties, and confers no rights.
"Randolph Neall" <randolphneall@.veracitycomputing.com> wrote in message
news:OK2GwxukFHA.3148@.TK2MSFTNGP09.phx.gbl...
> Ryan, we, too, have had DBCC CHECKDB errors, and the errors we have had
> seemed to disappear on subsquent runs of DBCC CHECKDB. Why? Does some
> automatic fix happen with some types of errors, or is something getting
> swept under the rug?
> How does one track down the cause of CHECKDB errors?
> Can virus protection software (Avast in our case) ever be a cause of DB
> corruption?
> The error(s) that disappeared are as follows:
> [2] Database VMed1: Check Data and Index Linkage...
> [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8928: [Microsoft]
[ODBC
> SQL
> Server Driver][SQL Server]Object ID 2050874423, index ID 2: Page (1:21
349)
> could not be processed. See other errors for details.
> [Microsoft][ODBC SQL Server Driver][SQL Server]Table error: Ob
ject ID
> 2050874423, index ID 2, page (1:21349), row 339. Test (ColumnOffsets <=
> (nextRec - pRec)) failed. Values are 13 and 3.
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0
allocation
> errors and 2 consistency errors in table 'NodeRelation' (object ID
> 2050874423).
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0
allocation
> errors and 2 consistency errors in database 'VMed1'.
> [Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_da
ta_loss is
> the
> minimum repair level for the errors found by DBCC CHECKDB (VMed1 ).
> Thanks,
> Randy Neall
>
> "Ryan Stonecipher [MSFT]" <ryanston@.microsoft.com> wrote in message
> news:eihMfCukFHA.3380@.TK2MSFTNGP12.phx.gbl...
> cannot
> any
> of
> corruption
> last
> rights.
>|||Thanks much, Ryan. In fact we ARE rebuilding indexes every night (possibly
overkill), and this error occurs AFTER that rebuild, I mean immediately
after (30 minutes) in the wee hours when no one is working. So it appears
that we got the problem as a direct result of the rebuild itself.
Apparently, the following night, the rebuild happens again, and that one
evidently fixes it.
We will check out our hardware with whatever diagnostics are available.
The errors we have seen tend to always be on the same table and possibly the
same index. I'm wondering if some table/index designs are more vulnerable
and unstable than others. This particular table has about seven integers
with overlapping indexes on all columns, including a single-column identity
clustered index and an alternate key on six of the integer columns, plus
others.
Thanks,
Randy Neall|||I would strongly recommend that you open up a case with Microsoft support in
this case (http://support.microsoft.com), as it doesn't sound at all like
normal behavior. To answer your question, there aren't any particular index
structures that are more susceptible to this problem than others. I would
get in touch with the experts in PSS and have them help you narrow down the
problem.
Thanks,
--
Ryan Stonecipher
Microsoft Sql Server Storage Engine, DBCC
This posting is provided "AS IS" with no warranties, and confers no rights.
"Brandon Owensby" <123@.abc.com> wrote in message
news:Og2k4B5kFHA.1148@.TK2MSFTNGP12.phx.gbl...
> Thanks much, Ryan. In fact we ARE rebuilding indexes every night (possibly
> overkill), and this error occurs AFTER that rebuild, I mean immediately
> after (30 minutes) in the wee hours when no one is working. So it appears
> that we got the problem as a direct result of the rebuild itself.
> Apparently, the following night, the rebuild happens again, and that one
> evidently fixes it.
> We will check out our hardware with whatever diagnostics are available.
> The errors we have seen tend to always be on the same table and possibly
> the same index. I'm wondering if some table/index designs are more
> vulnerable and unstable than others. This particular table has about seven
> integers with overlapping indexes on all columns, including a
> single-column identity clustered index and an alternate key on six of the
> integer columns, plus others.
> Thanks,
> Randy Neall
>
>

DBCC CheckDB error

We run nightly jobs on all of our SQL Servers (over 70) which run
DBCC CHECKDB ('<db_name>') with ALL_ERRORMSGS. Frequently we get the
following errors:
Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
IAM page (1:4216) object ID 16 index ID 0 but was not detected in the scan.
[SQLSTATE 42000]
Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
IAM page (1:4218) object ID 16 index ID 2 but was not detected in the scan.
[SQLSTATE 42000]
Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
IAM page (1:7811) object ID 17 index ID 0 but was not detected in the scan.
[SQLSTATE 42000]
Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
IAM page (1:7819) object ID 17 index ID 2 but was not detected in the scan.
[SQLSTATE 42000]
Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
IAM page (1:7821) object ID 17 index ID 3 but was not detected in the scan.
[SQLSTATE 42000]
These errors happen on different servers/databases. When I try to fix these
errors with DBCC CHECKDB and any of the repair options it reports that it is
not running at the correct repair level to fix the errors. Also when you
look in the database there is no object with an id of 16 or 17.
Can anyone help with this?
This is happening on SQL Server 2K with SP3 and SP4.
Thank you.
These two tables are replication tables:
SYSARTICLES = 16, SYSPUBLICATIONS = 17,
The errors say that the metadata entries for the tables and their indexes do
not exist in sysindexes. Have you had an replication problems? Did someone
manually remove the entries from sysindexes?
Thanks
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Len Gustafson" <LenGustafson@.discussions.microsoft.com> wrote in message
news:BAABD7AB-294C-4D01-85CA-3CC3312434A5@.microsoft.com...
> We run nightly jobs on all of our SQL Servers (over 70) which run
> DBCC CHECKDB ('<db_name>') with ALL_ERRORMSGS. Frequently we get the
> following errors:
> Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> IAM page (1:4216) object ID 16 index ID 0 but was not detected in the
> scan.
> [SQLSTATE 42000]
> Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> IAM page (1:4218) object ID 16 index ID 2 but was not detected in the
> scan.
> [SQLSTATE 42000]
> Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> IAM page (1:7811) object ID 17 index ID 0 but was not detected in the
> scan.
> [SQLSTATE 42000]
> Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> IAM page (1:7819) object ID 17 index ID 2 but was not detected in the
> scan.
> [SQLSTATE 42000]
> Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> IAM page (1:7821) object ID 17 index ID 3 but was not detected in the
> scan.
> [SQLSTATE 42000]
> These errors happen on different servers/databases. When I try to fix
> these
> errors with DBCC CHECKDB and any of the repair options it reports that it
> is
> not running at the correct repair level to fix the errors. Also when you
> look in the database there is no object with an id of 16 or 17.
> Can anyone help with this?
> This is happening on SQL Server 2K with SP3 and SP4.
> Thank you.
>
|||Paul,
Thank you for your response.
We have not had any replication problems and we did not manually remove the
entries from sysindexes. Do you know of a way we could prevent this from
happening in the future?
I did want to correct something i wrote in the original post, DBCC CheckDB
does fix these errors if you run it in the REPAIR_ALLOW_DATA_LOSS mode but
not in the others.
Thanks,
Len Gustafson
"Paul S Randal [MS]" wrote:

> These two tables are replication tables:
> SYSARTICLES = 16, SYSPUBLICATIONS = 17,
> The errors say that the metadata entries for the tables and their indexes do
> not exist in sysindexes. Have you had an replication problems? Did someone
> manually remove the entries from sysindexes?
> Thanks
> --
> Paul Randal
> Dev Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "Len Gustafson" <LenGustafson@.discussions.microsoft.com> wrote in message
> news:BAABD7AB-294C-4D01-85CA-3CC3312434A5@.microsoft.com...
>
>
|||I don't know why this happened so can't suggest a way to stop it happening.
You should call Product Support to help you (http://support.microsoft.com).
Thanks
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Len Gustafson" <LenGustafson@.discussions.microsoft.com> wrote in message
news:631CD829-06C3-4A1C-ADF9-60799AE08077@.microsoft.com...[vbcol=seagreen]
> Paul,
> Thank you for your response.
> We have not had any replication problems and we did not manually remove
> the
> entries from sysindexes. Do you know of a way we could prevent this from
> happening in the future?
> I did want to correct something i wrote in the original post, DBCC CheckDB
> does fix these errors if you run it in the REPAIR_ALLOW_DATA_LOSS mode but
> not in the others.
>
> Thanks,
> Len Gustafson
>
> "Paul S Randal [MS]" wrote:
|||Paul,
Thank you for your help.
Len Gustafson
"Paul S Randal [MS]" wrote:

> I don't know why this happened so can't suggest a way to stop it happening.
> You should call Product Support to help you (http://support.microsoft.com).
> Thanks
> --
> Paul Randal
> Dev Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "Len Gustafson" <LenGustafson@.discussions.microsoft.com> wrote in message
> news:631CD829-06C3-4A1C-ADF9-60799AE08077@.microsoft.com...
>
>

DBCC CheckDB error

We run nightly jobs on all of our SQL Servers (over 70) which run
DBCC CHECKDB ('<db_name>') with ALL_ERRORMSGS. Frequently we get the
following errors:
Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
IAM page (1:4216) object ID 16 index ID 0 but was not detected in the scan.
[SQLSTATE 42000]
Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
IAM page (1:4218) object ID 16 index ID 2 but was not detected in the scan.
[SQLSTATE 42000]
Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
IAM page (1:7811) object ID 17 index ID 0 but was not detected in the scan.
[SQLSTATE 42000]
Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
IAM page (1:7819) object ID 17 index ID 2 but was not detected in the scan.
[SQLSTATE 42000]
Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
IAM page (1:7821) object ID 17 index ID 3 but was not detected in the scan.
[SQLSTATE 42000]
These errors happen on different servers/databases. When I try to fix these
errors with DBCC CHECKDB and any of the repair options it reports that it is
not running at the correct repair level to fix the errors. Also when you
look in the database there is no object with an id of 16 or 17.
Can anyone help with this?
This is happening on SQL Server 2K with SP3 and SP4.
Thank you.These two tables are replication tables:
SYSARTICLES = 16, SYSPUBLICATIONS = 17,
The errors say that the metadata entries for the tables and their indexes do
not exist in sysindexes. Have you had an replication problems? Did someone
manually remove the entries from sysindexes?
Thanks
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Len Gustafson" <LenGustafson@.discussions.microsoft.com> wrote in message
news:BAABD7AB-294C-4D01-85CA-3CC3312434A5@.microsoft.com...
> We run nightly jobs on all of our SQL Servers (over 70) which run
> DBCC CHECKDB ('<db_name>') with ALL_ERRORMSGS. Frequently we get the
> following errors:
> Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> IAM page (1:4216) object ID 16 index ID 0 but was not detected in the
> scan.
> [SQLSTATE 42000]
> Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> IAM page (1:4218) object ID 16 index ID 2 but was not detected in the
> scan.
> [SQLSTATE 42000]
> Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> IAM page (1:7811) object ID 17 index ID 0 but was not detected in the
> scan.
> [SQLSTATE 42000]
> Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> IAM page (1:7819) object ID 17 index ID 2 but was not detected in the
> scan.
> [SQLSTATE 42000]
> Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> IAM page (1:7821) object ID 17 index ID 3 but was not detected in the
> scan.
> [SQLSTATE 42000]
> These errors happen on different servers/databases. When I try to fix
> these
> errors with DBCC CHECKDB and any of the repair options it reports that it
> is
> not running at the correct repair level to fix the errors. Also when you
> look in the database there is no object with an id of 16 or 17.
> Can anyone help with this?
> This is happening on SQL Server 2K with SP3 and SP4.
> Thank you.
>|||Paul,
Thank you for your response.
We have not had any replication problems and we did not manually remove the
entries from sysindexes. Do you know of a way we could prevent this from
happening in the future?
I did want to correct something i wrote in the original post, DBCC CheckDB
does fix these errors if you run it in the REPAIR_ALLOW_DATA_LOSS mode but
not in the others.
Thanks,
Len Gustafson
"Paul S Randal [MS]" wrote:
> These two tables are replication tables:
> SYSARTICLES = 16, SYSPUBLICATIONS = 17,
> The errors say that the metadata entries for the tables and their indexes do
> not exist in sysindexes. Have you had an replication problems? Did someone
> manually remove the entries from sysindexes?
> Thanks
> --
> Paul Randal
> Dev Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "Len Gustafson" <LenGustafson@.discussions.microsoft.com> wrote in message
> news:BAABD7AB-294C-4D01-85CA-3CC3312434A5@.microsoft.com...
> > We run nightly jobs on all of our SQL Servers (over 70) which run
> > DBCC CHECKDB ('<db_name>') with ALL_ERRORMSGS. Frequently we get the
> > following errors:
> >
> > Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> > IAM page (1:4216) object ID 16 index ID 0 but was not detected in the
> > scan.
> > [SQLSTATE 42000]
> > Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> > IAM page (1:4218) object ID 16 index ID 2 but was not detected in the
> > scan.
> > [SQLSTATE 42000]
> > Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> > IAM page (1:7811) object ID 17 index ID 0 but was not detected in the
> > scan.
> > [SQLSTATE 42000]
> > Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> > IAM page (1:7819) object ID 17 index ID 2 but was not detected in the
> > scan.
> > [SQLSTATE 42000]
> > Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> > IAM page (1:7821) object ID 17 index ID 3 but was not detected in the
> > scan.
> > [SQLSTATE 42000]
> >
> > These errors happen on different servers/databases. When I try to fix
> > these
> > errors with DBCC CHECKDB and any of the repair options it reports that it
> > is
> > not running at the correct repair level to fix the errors. Also when you
> > look in the database there is no object with an id of 16 or 17.
> >
> > Can anyone help with this?
> >
> > This is happening on SQL Server 2K with SP3 and SP4.
> >
> > Thank you.
> >
>
>|||I don't know why this happened so can't suggest a way to stop it happening.
You should call Product Support to help you (http://support.microsoft.com).
Thanks
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Len Gustafson" <LenGustafson@.discussions.microsoft.com> wrote in message
news:631CD829-06C3-4A1C-ADF9-60799AE08077@.microsoft.com...
> Paul,
> Thank you for your response.
> We have not had any replication problems and we did not manually remove
> the
> entries from sysindexes. Do you know of a way we could prevent this from
> happening in the future?
> I did want to correct something i wrote in the original post, DBCC CheckDB
> does fix these errors if you run it in the REPAIR_ALLOW_DATA_LOSS mode but
> not in the others.
>
> Thanks,
> Len Gustafson
>
> "Paul S Randal [MS]" wrote:
>> These two tables are replication tables:
>> SYSARTICLES = 16, SYSPUBLICATIONS = 17,
>> The errors say that the metadata entries for the tables and their indexes
>> do
>> not exist in sysindexes. Have you had an replication problems? Did
>> someone
>> manually remove the entries from sysindexes?
>> Thanks
>> --
>> Paul Randal
>> Dev Lead, Microsoft SQL Server Storage Engine
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> "Len Gustafson" <LenGustafson@.discussions.microsoft.com> wrote in message
>> news:BAABD7AB-294C-4D01-85CA-3CC3312434A5@.microsoft.com...
>> > We run nightly jobs on all of our SQL Servers (over 70) which run
>> > DBCC CHECKDB ('<db_name>') with ALL_ERRORMSGS. Frequently we get the
>> > following errors:
>> >
>> > Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer
>> > of
>> > IAM page (1:4216) object ID 16 index ID 0 but was not detected in the
>> > scan.
>> > [SQLSTATE 42000]
>> > Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer
>> > of
>> > IAM page (1:4218) object ID 16 index ID 2 but was not detected in the
>> > scan.
>> > [SQLSTATE 42000]
>> > Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer
>> > of
>> > IAM page (1:7811) object ID 17 index ID 0 but was not detected in the
>> > scan.
>> > [SQLSTATE 42000]
>> > Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer
>> > of
>> > IAM page (1:7819) object ID 17 index ID 2 but was not detected in the
>> > scan.
>> > [SQLSTATE 42000]
>> > Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer
>> > of
>> > IAM page (1:7821) object ID 17 index ID 3 but was not detected in the
>> > scan.
>> > [SQLSTATE 42000]
>> >
>> > These errors happen on different servers/databases. When I try to fix
>> > these
>> > errors with DBCC CHECKDB and any of the repair options it reports that
>> > it
>> > is
>> > not running at the correct repair level to fix the errors. Also when
>> > you
>> > look in the database there is no object with an id of 16 or 17.
>> >
>> > Can anyone help with this?
>> >
>> > This is happening on SQL Server 2K with SP3 and SP4.
>> >
>> > Thank you.
>> >
>>|||Paul,
Thank you for your help.
Len Gustafson
"Paul S Randal [MS]" wrote:
> I don't know why this happened so can't suggest a way to stop it happening.
> You should call Product Support to help you (http://support.microsoft.com).
> Thanks
> --
> Paul Randal
> Dev Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "Len Gustafson" <LenGustafson@.discussions.microsoft.com> wrote in message
> news:631CD829-06C3-4A1C-ADF9-60799AE08077@.microsoft.com...
> > Paul,
> >
> > Thank you for your response.
> >
> > We have not had any replication problems and we did not manually remove
> > the
> > entries from sysindexes. Do you know of a way we could prevent this from
> > happening in the future?
> >
> > I did want to correct something i wrote in the original post, DBCC CheckDB
> > does fix these errors if you run it in the REPAIR_ALLOW_DATA_LOSS mode but
> > not in the others.
> >
> >
> > Thanks,
> >
> > Len Gustafson
> >
> >
> > "Paul S Randal [MS]" wrote:
> >
> >> These two tables are replication tables:
> >> SYSARTICLES = 16, SYSPUBLICATIONS = 17,
> >>
> >> The errors say that the metadata entries for the tables and their indexes
> >> do
> >> not exist in sysindexes. Have you had an replication problems? Did
> >> someone
> >> manually remove the entries from sysindexes?
> >>
> >> Thanks
> >>
> >> --
> >> Paul Randal
> >> Dev Lead, Microsoft SQL Server Storage Engine
> >>
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >>
> >> "Len Gustafson" <LenGustafson@.discussions.microsoft.com> wrote in message
> >> news:BAABD7AB-294C-4D01-85CA-3CC3312434A5@.microsoft.com...
> >> > We run nightly jobs on all of our SQL Servers (over 70) which run
> >> > DBCC CHECKDB ('<db_name>') with ALL_ERRORMSGS. Frequently we get the
> >> > following errors:
> >> >
> >> > Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer
> >> > of
> >> > IAM page (1:4216) object ID 16 index ID 0 but was not detected in the
> >> > scan.
> >> > [SQLSTATE 42000]
> >> > Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer
> >> > of
> >> > IAM page (1:4218) object ID 16 index ID 2 but was not detected in the
> >> > scan.
> >> > [SQLSTATE 42000]
> >> > Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer
> >> > of
> >> > IAM page (1:7811) object ID 17 index ID 0 but was not detected in the
> >> > scan.
> >> > [SQLSTATE 42000]
> >> > Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer
> >> > of
> >> > IAM page (1:7819) object ID 17 index ID 2 but was not detected in the
> >> > scan.
> >> > [SQLSTATE 42000]
> >> > Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer
> >> > of
> >> > IAM page (1:7821) object ID 17 index ID 3 but was not detected in the
> >> > scan.
> >> > [SQLSTATE 42000]
> >> >
> >> > These errors happen on different servers/databases. When I try to fix
> >> > these
> >> > errors with DBCC CHECKDB and any of the repair options it reports that
> >> > it
> >> > is
> >> > not running at the correct repair level to fix the errors. Also when
> >> > you
> >> > look in the database there is no object with an id of 16 or 17.
> >> >
> >> > Can anyone help with this?
> >> >
> >> > This is happening on SQL Server 2K with SP3 and SP4.
> >> >
> >> > Thank you.
> >> >
> >>
> >>
> >>
>
>

DBCC CheckDB error

We run nightly jobs on all of our SQL Servers (over 70) which run
DBCC CHECKDB ('<db_name>') with ALL_ERRORMSGS. Frequently we get the
following errors:
Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
IAM page (1:4216) object ID 16 index ID 0 but was not detected in the scan.
[SQLSTATE 42000]
Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
IAM page (1:4218) object ID 16 index ID 2 but was not detected in the scan.
[SQLSTATE 42000]
Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
IAM page (1:7811) object ID 17 index ID 0 but was not detected in the scan.
[SQLSTATE 42000]
Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
IAM page (1:7819) object ID 17 index ID 2 but was not detected in the scan.
[SQLSTATE 42000]
Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
IAM page (1:7821) object ID 17 index ID 3 but was not detected in the scan.
[SQLSTATE 42000]
These errors happen on different servers/databases. When I try to fix these
errors with DBCC CHECKDB and any of the repair options it reports that it is
not running at the correct repair level to fix the errors. Also when you
look in the database there is no object with an id of 16 or 17.
Can anyone help with this?
This is happening on SQL Server 2K with SP3 and SP4.
Thank you.These two tables are replication tables:
SYSARTICLES = 16, SYSPUBLICATIONS = 17,
The errors say that the metadata entries for the tables and their indexes do
not exist in sysindexes. Have you had an replication problems? Did someone
manually remove the entries from sysindexes?
Thanks
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Len Gustafson" <LenGustafson@.discussions.microsoft.com> wrote in message
news:BAABD7AB-294C-4D01-85CA-3CC3312434A5@.microsoft.com...
> We run nightly jobs on all of our SQL Servers (over 70) which run
> DBCC CHECKDB ('<db_name>') with ALL_ERRORMSGS. Frequently we get the
> following errors:
> Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> IAM page (1:4216) object ID 16 index ID 0 but was not detected in the
> scan.
> [SQLSTATE 42000]
> Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> IAM page (1:4218) object ID 16 index ID 2 but was not detected in the
> scan.
> [SQLSTATE 42000]
> Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> IAM page (1:7811) object ID 17 index ID 0 but was not detected in the
> scan.
> [SQLSTATE 42000]
> Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> IAM page (1:7819) object ID 17 index ID 2 but was not detected in the
> scan.
> [SQLSTATE 42000]
> Msg 2576, Sev 16: IAM page (0:0) is pointed to by the previous pointer of
> IAM page (1:7821) object ID 17 index ID 3 but was not detected in the
> scan.
> [SQLSTATE 42000]
> These errors happen on different servers/databases. When I try to fix
> these
> errors with DBCC CHECKDB and any of the repair options it reports that it
> is
> not running at the correct repair level to fix the errors. Also when you
> look in the database there is no object with an id of 16 or 17.
> Can anyone help with this?
> This is happening on SQL Server 2K with SP3 and SP4.
> Thank you.
>|||Paul,
Thank you for your response.
We have not had any replication problems and we did not manually remove the
entries from sysindexes. Do you know of a way we could prevent this from
happening in the future?
I did want to correct something i wrote in the original post, DBCC CheckDB
does fix these errors if you run it in the REPAIR_ALLOW_DATA_LOSS mode but
not in the others.
Thanks,
Len Gustafson
"Paul S Randal [MS]" wrote:

> These two tables are replication tables:
> SYSARTICLES = 16, SYSPUBLICATIONS = 17,
> The errors say that the metadata entries for the tables and their indexes
do
> not exist in sysindexes. Have you had an replication problems? Did someone
> manually remove the entries from sysindexes?
> Thanks
> --
> Paul Randal
> Dev Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no rights
.
> "Len Gustafson" <LenGustafson@.discussions.microsoft.com> wrote in message
> news:BAABD7AB-294C-4D01-85CA-3CC3312434A5@.microsoft.com...
>
>|||I don't know why this happened so can't suggest a way to stop it happening.
You should call Product Support to help you (http://support.microsoft.com).
Thanks
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Len Gustafson" <LenGustafson@.discussions.microsoft.com> wrote in message
news:631CD829-06C3-4A1C-ADF9-60799AE08077@.microsoft.com...[vbcol=seagreen]
> Paul,
> Thank you for your response.
> We have not had any replication problems and we did not manually remove
> the
> entries from sysindexes. Do you know of a way we could prevent this from
> happening in the future?
> I did want to correct something i wrote in the original post, DBCC CheckDB
> does fix these errors if you run it in the REPAIR_ALLOW_DATA_LOSS mode but
> not in the others.
>
> Thanks,
> Len Gustafson
>
> "Paul S Randal [MS]" wrote:
>|||Paul,
Thank you for your help.
Len Gustafson
"Paul S Randal [MS]" wrote:

> I don't know why this happened so can't suggest a way to stop it happening
.
> You should call Product Support to help you (http://support.microsoft.com)
.
> Thanks
> --
> Paul Randal
> Dev Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no rights
.
> "Len Gustafson" <LenGustafson@.discussions.microsoft.com> wrote in message
> news:631CD829-06C3-4A1C-ADF9-60799AE08077@.microsoft.com...
>
>

DBCC CheckDB

Another question from the new Admin on the block.
I read in the docs that as of SQL7 dbccs are not required as part of your
backup plan. The servers I just inherited are not running any database
integrity checks at any time.
Should checks still be run occasionally.
Thanks!
Mike Lackey
Database Adminstration
Sybase/Oracle and recently back to MSSQL
They are never required but a good idea. The idea behind a DBCC CHECKDB is
to ensure (mostly) physical integrity of your database objects. While it is
true there is not as much a problem with 7.0 and 2000 like there was with
6.5 it can still happen. Mainly hardware related issues caused problems
that this checks. The sooner you find out there is a problem the best
chance you have of not loosing valuable data. So while it is not required
it is recommended. How often depends mainly on how often you can afford to
run it etc.
Andrew J. Kelly SQL MVP
"Mike Lackey" <MikeLackey@.discussions.microsoft.com> wrote in message
news:C11410C3-6891-486C-A375-CC51E42FE0EA@.microsoft.com...
> Another question from the new Admin on the block.
> I read in the docs that as of SQL7 dbccs are not required as part of your
> backup plan. The servers I just inherited are not running any database
> integrity checks at any time.
> Should checks still be run occasionally.
> Thanks!
> --
> Mike Lackey
> Database Adminstration
> Sybase/Oracle and recently back to MSSQL
|||Hi,
I agree with Andrew. I recommend you to run the DBCC CHECKDB atleast once a
week. By this you can always ensure that your data is in good shape.
Thanks
Hari
MCDBA
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:esgBN5noEHA.2340@.TK2MSFTNGP11.phx.gbl...
> They are never required but a good idea. The idea behind a DBCC CHECKDB
> is
> to ensure (mostly) physical integrity of your database objects. While it
> is
> true there is not as much a problem with 7.0 and 2000 like there was with
> 6.5 it can still happen. Mainly hardware related issues caused problems
> that this checks. The sooner you find out there is a problem the best
> chance you have of not loosing valuable data. So while it is not required
> it is recommended. How often depends mainly on how often you can afford
> to
> run it etc.
> --
> Andrew J. Kelly SQL MVP
>
> "Mike Lackey" <MikeLackey@.discussions.microsoft.com> wrote in message
> news:C11410C3-6891-486C-A375-CC51E42FE0EA@.microsoft.com...
>

DBCC CheckDB

Another question from the new Admin on the block.
I read in the docs that as of SQL7 dbccs are not required as part of your
backup plan. The servers I just inherited are not running any database
integrity checks at any time.
Should checks still be run occasionally.
Thanks!
--
Mike Lackey
Database Adminstration
Sybase/Oracle and recently back to MSSQLThey are never required but a good idea. The idea behind a DBCC CHECKDB is
to ensure (mostly) physical integrity of your database objects. While it is
true there is not as much a problem with 7.0 and 2000 like there was with
6.5 it can still happen. Mainly hardware related issues caused problems
that this checks. The sooner you find out there is a problem the best
chance you have of not loosing valuable data. So while it is not required
it is recommended. How often depends mainly on how often you can afford to
run it etc.
--
Andrew J. Kelly SQL MVP
"Mike Lackey" <MikeLackey@.discussions.microsoft.com> wrote in message
news:C11410C3-6891-486C-A375-CC51E42FE0EA@.microsoft.com...
> Another question from the new Admin on the block.
> I read in the docs that as of SQL7 dbccs are not required as part of your
> backup plan. The servers I just inherited are not running any database
> integrity checks at any time.
> Should checks still be run occasionally.
> Thanks!
> --
> Mike Lackey
> Database Adminstration
> Sybase/Oracle and recently back to MSSQL|||Hi,
I agree with Andrew. I recommend you to run the DBCC CHECKDB atleast once a
week. By this you can always ensure that your data is in good shape.
Thanks
Hari
MCDBA
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:esgBN5noEHA.2340@.TK2MSFTNGP11.phx.gbl...
> They are never required but a good idea. The idea behind a DBCC CHECKDB
> is
> to ensure (mostly) physical integrity of your database objects. While it
> is
> true there is not as much a problem with 7.0 and 2000 like there was with
> 6.5 it can still happen. Mainly hardware related issues caused problems
> that this checks. The sooner you find out there is a problem the best
> chance you have of not loosing valuable data. So while it is not required
> it is recommended. How often depends mainly on how often you can afford
> to
> run it etc.
> --
> Andrew J. Kelly SQL MVP
>
> "Mike Lackey" <MikeLackey@.discussions.microsoft.com> wrote in message
> news:C11410C3-6891-486C-A375-CC51E42FE0EA@.microsoft.com...
>> Another question from the new Admin on the block.
>> I read in the docs that as of SQL7 dbccs are not required as part of your
>> backup plan. The servers I just inherited are not running any database
>> integrity checks at any time.
>> Should checks still be run occasionally.
>> Thanks!
>> --
>> Mike Lackey
>> Database Adminstration
>> Sybase/Oracle and recently back to MSSQL
>