DBfile usage: consistency

Showing posts with label consistency. Show all posts

Friday, February 24, 2012

DBCC Consistency Errors after copying the backup file

Hello,
I am facing a problem that is *very* odd. I am runing DBCC CHECKDB on
my source database with *no errors*, then I take a full database backup
and copy(xcopy,robocopy) it to another server and restore it there.
Very often I am getting DBCC consistency errors when I run the CHECKDB
on the remote (backup) server.
Has anybody come acrross this? How do you copy your backup files?
Any tip will be really appreciated.
Noel
Looks strange .Perhaps during the copy process the file is getting
corrupted.
At my company we backup the db , then compres .BAK file by WINRAR and then
copy it. If you have VLDB , consider using third party tool like Litespeed
<zerg2k@.yahoo.com> wrote in message
news:1163603641.098898.40150@.m7g2000cwm.googlegrou ps.com...
> Hello,
> I am facing a problem that is *very* odd. I am runing DBCC CHECKDB on
> my source database with *no errors*, then I take a full database backup
> and copy(xcopy,robocopy) it to another server and restore it there.
> Very often I am getting DBCC consistency errors when I run the CHECKDB
> on the remote (backup) server.
> Has anybody come acrross this? How do you copy your backup files?
> Any tip will be really appreciated.
> Noel
>

DBCC Consistency Errors after copying the backup file

Hello,
I am facing a problem that is *very* odd. I am runing DBCC CHECKDB on
my source database with *no errors*, then I take a full database backup
and copy(xcopy,robocopy) it to another server and restore it there.
Very often I am getting DBCC consistency errors when I run the CHECKDB
on the remote (backup) server.
Has anybody come acrross this? How do you copy your backup files'
Any tip will be really appreciated.
NoelLooks strange .Perhaps during the copy process the file is getting
corrupted.
At my company we backup the db , then compres .BAK file by WINRAR and then
copy it. If you have VLDB , consider using third party tool like Litespeed
<zerg2k@.yahoo.com> wrote in message
news:1163603641.098898.40150@.m7g2000cwm.googlegroups.com...
> Hello,
> I am facing a problem that is *very* odd. I am runing DBCC CHECKDB on
> my source database with *no errors*, then I take a full database backup
> and copy(xcopy,robocopy) it to another server and restore it there.
> Very often I am getting DBCC consistency errors when I run the CHECKDB
> on the remote (backup) server.
> Has anybody come acrross this? How do you copy your backup files'
> Any tip will be really appreciated.
> Noel
>

DBCC Consistency Errors after copying the backup file

Hello,
I am facing a problem that is *very* odd. I am runing DBCC CHECKDB on
my source database with *no errors*, then I take a full database backup
and copy(xcopy,robocopy) it to another server and restore it there.
Very often I am getting DBCC consistency errors when I run the CHECKDB
on the remote (backup) server.
Has anybody come acrross this? How do you copy your backup files'
Any tip will be really appreciated.
NoelLooks strange .Perhaps during the copy process the file is getting
corrupted.
At my company we backup the db , then compres .BAK file by WINRAR and then
copy it. If you have VLDB , consider using third party tool like Litespeed
<zerg2k@.yahoo.com> wrote in message
news:1163603641.098898.40150@.m7g2000cwm.googlegroups.com...
> Hello,
> I am facing a problem that is *very* odd. I am runing DBCC CHECKDB on
> my source database with *no errors*, then I take a full database backup
> and copy(xcopy,robocopy) it to another server and restore it there.
> Very often I am getting DBCC consistency errors when I run the CHECKDB
> on the remote (backup) server.
> Has anybody come acrross this? How do you copy your backup files'
> Any tip will be really appreciated.
> Noel
>

DBCC CheckTable shows consistency errors

We recently migrated our SQL Server 2000 cluster to a new set of
hardware. We are now having sporadic table consistency errors.
Then we started having trouble with some of our tables. Yesterday, one
of our tables had a consistency error, which we dropped (it was
non-essential). Then today a different table (which had worked fine
yesterday) came up with consistency errors.
When I ran DBCC CheckTable on the table that has a problem today, this
is the result:
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 2039678314, index ID 0: Page (1:1144605) could not be
processed. See other errors for details.
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 2039678314, index ID 0: Page (1:1694520) could not be
processed. See other errors for details.
Server: Msg 8944, Level 16, State 1, Line 1
Table error: Object ID 2039678314, index ID 0, page (1:1694520), row
7. Test (ColumnOffsets <= (nextRec - pRec)) failed. Values are 1475
and 96.
DBCC results for 'ATN_Account_Charges'.
There are 4834481 rows in 78193 pages for object
'ATN_Account_Charges'.
CHECKTABLE found 0 allocation errors and 3 consistency errors in table
'ATN_Account_Charges' (object ID 2039678314).
repair_allow_data_loss is the minimum repair level for the errors
found by DBCC CHECKTABLE (CAT.dbo.ATN_Account_Charges ).
Each time someone tries to access this table, SQL Server generates a
.mdmp file in the LOGs folder.
Any ideas?
Thanks,
Lee"Lee" <lfalin@.ccitelecom.com> wrote in message
news:46781cf7.0311210840.15088d6d@.posting.google.com...
> We recently migrated our SQL Server 2000 cluster to a new set of
> hardware. We are now having sporadic table consistency errors.
> Then we started having trouble with some of our tables. Yesterday, one
> of our tables had a consistency error, which we dropped (it was
> non-essential). Then today a different table (which had worked fine
> yesterday) came up with consistency errors.
> When I ran DBCC CheckTable on the table that has a problem today, this
> is the result:
> Server: Msg 8928, Level 16, State 1, Line 1
> Object ID 2039678314, index ID 0: Page (1:1144605) could not be
> processed. See other errors for details.
> Server: Msg 8928, Level 16, State 1, Line 1
> Object ID 2039678314, index ID 0: Page (1:1694520) could not be
> processed. See other errors for details.
> Server: Msg 8944, Level 16, State 1, Line 1
> Table error: Object ID 2039678314, index ID 0, page (1:1694520), row
> 7. Test (ColumnOffsets <= (nextRec - pRec)) failed. Values are 1475
> and 96.
> DBCC results for 'ATN_Account_Charges'.
> There are 4834481 rows in 78193 pages for object
> 'ATN_Account_Charges'.
> CHECKTABLE found 0 allocation errors and 3 consistency errors in table
> 'ATN_Account_Charges' (object ID 2039678314).
> repair_allow_data_loss is the minimum repair level for the errors
> found by DBCC CHECKTABLE (CAT.dbo.ATN_Account_Charges ).
> Each time someone tries to access this table, SQL Server generates a
> .mdmp file in the LOGs folder.
> Any ideas?
It appears you have some internal corruption, you could start by running
DBCC CHECKTABLE ( 'tablename' , REPAIR_REBUILD )
on your effected tables. This will not cause data loss -- see BOL for
additional options and syntax. The output you pasted does show
"repair_allow_data_loss is the minimum repair level for the errors", which
is another option of DBCC, and may cause data loss. If you can track the
error down to an index, you may be able to drop and rebuild the indexes for
the effected tables...
Steve|||You have a corrupt record on the page. The record audit code is generating
an exception (and hence the mdmp you're seeing) whenever it encounters this
record during a query.
It sounds like the problems started happening when you moved to the new
hardware, and given the recurrence of the problem, it seems like you've got
bad hardware somewhere. You should look through the NT event logs and the
SQL Server error log for evidence of hardware problems. You should also run
all relevant hardware diagnostics on your new hardware.
If you still cannot isolate the cause, PSS should be able to help you.
Regards,
Paul.
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Lee" <lfalin@.ccitelecom.com> wrote in message
news:46781cf7.0311210840.15088d6d@.posting.google.com...
> We recently migrated our SQL Server 2000 cluster to a new set of
> hardware. We are now having sporadic table consistency errors.
> Then we started having trouble with some of our tables. Yesterday, one
> of our tables had a consistency error, which we dropped (it was
> non-essential). Then today a different table (which had worked fine
> yesterday) came up with consistency errors.
> When I ran DBCC CheckTable on the table that has a problem today, this
> is the result:
> Server: Msg 8928, Level 16, State 1, Line 1
> Object ID 2039678314, index ID 0: Page (1:1144605) could not be
> processed. See other errors for details.
> Server: Msg 8928, Level 16, State 1, Line 1
> Object ID 2039678314, index ID 0: Page (1:1694520) could not be
> processed. See other errors for details.
> Server: Msg 8944, Level 16, State 1, Line 1
> Table error: Object ID 2039678314, index ID 0, page (1:1694520), row
> 7. Test (ColumnOffsets <= (nextRec - pRec)) failed. Values are 1475
> and 96.
> DBCC results for 'ATN_Account_Charges'.
> There are 4834481 rows in 78193 pages for object
> 'ATN_Account_Charges'.
> CHECKTABLE found 0 allocation errors and 3 consistency errors in table
> 'ATN_Account_Charges' (object ID 2039678314).
> repair_allow_data_loss is the minimum repair level for the errors
> found by DBCC CHECKTABLE (CAT.dbo.ATN_Account_Charges ).
> Each time someone tries to access this table, SQL Server generates a
> .mdmp file in the LOGs folder.
> Any ideas?
> Thanks,
> Lee

Sunday, February 19, 2012

dbcc checkdb to output file

I've a job set up to run every sunday night, to check the consistency of our
databases.
Unfortunately, when writing a script to check the contents of this file, it
seems that the
file is in unicode.
Does anybody know which unicode format is used for the output file, it looks
like ucs2
but perl seems to recognise it as utf-8.
Any ideas?I don't know, perhaps someone else does, but another option can be to use OSQL through a CmdExec job
instead. I have a feeling that OSQL outputs ANSI...
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Stressed" <k@.c.co.uk> wrote in message news:eEhEQW9lDHA.644@.TK2MSFTNGP11.phx.gbl...
> I've a job set up to run every sunday night, to check the consistency of our
> databases.
> Unfortunately, when writing a script to check the contents of this file, it
> seems that the
> file is in unicode.
> Does anybody know which unicode format is used for the output file, it looks
> like ucs2
> but perl seems to recognise it as utf-8.
> Any ideas?
>|||Stressed,
use osql to do this, This is command line utitlity therefore if you want to run it from T-SQL use
xp_cmdshell extended stored procedure.
see following example
--osql
osql /S<server> /Usa /P /dmaster /Q"dbcc checkdb" >> c:\testthis.txt
--using xp_cmdshell
exec master..xp_cmdshell 'osql /S<server> /Usa /P /dmaster /Q"dbcc checkdb" >> c:\testthis1.txt'
--
- Vishal|||or you can use -o parameter of osql as well.
Ex;
osql /S<server> /Usa /P /dmaster /Q" dbcc checkdb" -o c:\testthis2.txt
--
- Vishal|||After looking into it, it appears to be UCS2 little endian.
In case anybody else falls into the same problems.
"Stressed" <k@.c.co.uk> wrote in message
news:eEhEQW9lDHA.644@.TK2MSFTNGP11.phx.gbl...
> I've a job set up to run every sunday night, to check the consistency of
our
> databases.
> Unfortunately, when writing a script to check the contents of this file,
it
> seems that the
> file is in unicode.
> Does anybody know which unicode format is used for the output file, it
looks
> like ucs2
> but perl seems to recognise it as utf-8.
> Any ideas?
>|||sorry, ucs2 big endian. i lied.
"Stressed" <k@.c.co.uk> wrote in message
news:uTzDi3HmDHA.2528@.TK2MSFTNGP12.phx.gbl...
> After looking into it, it appears to be UCS2 little endian.
> In case anybody else falls into the same problems.
>
> "Stressed" <k@.c.co.uk> wrote in message
> news:eEhEQW9lDHA.644@.TK2MSFTNGP11.phx.gbl...
> > I've a job set up to run every sunday night, to check the consistency of
> our
> > databases.
> >
> > Unfortunately, when writing a script to check the contents of this file,
> it
> > seems that the
> > file is in unicode.
> >
> > Does anybody know which unicode format is used for the output file, it
> looks
> > like ucs2
> > but perl seems to recognise it as utf-8.
> >
> > Any ideas?
> >
> >
>

DBCC CHECKDB shows errors

Results show 0 allocation errors and 42 consistency errors that all seem to be from one table. That is to the extent I understand the results. The errors are 8929, 8939, 8965, 8964 all for the same object id and varying text ids. The repair_fast and repair_rebuild did not work. Its calling for the repair_with_data_loss. Are there any work arounds? Does this mean that the table is corrupt? Is this a torn data page due to this table? If I need to run the repair_with_data_loss is there an easy way to determine which data has been lost? Welcome any feedback.Here are the general recommendations for handling a suspect or corrupt database:
0. Ensure you have a backup strategy that you can use to recover from hardware failures (including
corruption). I recommend performing both database and log backup in most situations.
1. If you can run DBCC CHECKDB against the database: Search Books Online and KB for the error
numbers that CHECKDB gives you. There might be specific info for that type of error.
2. Find out why this happened. Check eventlog, do HW diagnostics etc.; search Books Online and KB
for those errors. You don't want this to happen again! If the database is suspect, the file might
have been in use by for instance an anti-virus program and restarting SQL Server might be all that
is needed - but you still want to read logs etc to find out what happened.
3. If there is a hardware problem, ensure the faulty hardware is replaced.
4. Backup the log. This assumes that log backup schedule is in place, of course. If the database is
suspect, then the NO_TRUNCATE option for the RESTORE command must be used. Also, you might want to
do a file backup of the mdf and ldf files, for extra safety.
5. Restore is the best thing to do now. If you managed to backup log as per step 4, then you will
most probably have zero dataloss. You should restore the latest clean database backup and the
subsequent log backups including the one taken in above step.
If the database isn't suspect, then DBCC with a REPAIR option might be a secondary option but this
will often result in loss of data. Additional solutions, depending on the errors, may be to manually
rebuild non-clustered indexes, manually drop and reload a table if the data is static, and so on.
If the database is suspect, a secondary option can be to try to "un-suspect" the database using
sp_resetstatus. Read about it (books online, KB, google etc). It might help but if the database is
too damaged, it might just pop back to suspect again. There's also something called "emergency mode"
which is a "panic" status you can set in order to try to get data out of a damaged database. I think
the name of that option speaks for itself. Again search the net for info.
If you feel uncertain with above steps, I recommend letting MS hand-hold you through the steps
appropriate for your particular situation.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Bush" <anonymous@.discussions.microsoft.com> wrote in message
news:77FBEDC8-9B02-4CAB-970E-A96DC0F47EF9@.microsoft.com...
> Results show 0 allocation errors and 42 consistency errors that all seem to be from one table.
That is to the extent I understand the results. The errors are 8929, 8939, 8965, 8964 all for the
same object id and varying text ids. The repair_fast and repair_rebuild did not work. Its calling
for the repair_with_data_loss. Are there any work arounds? Does this mean that the table is
corrupt? Is this a torn data page due to this table? If I need to run the repair_with_data_loss is
there an easy way to determine which data has been lost? Welcome any feedback.|||Further to Tibor's comments, yes, you have corruption in your table. There
are no workarounds except restoring from a backup or running
repair_allow_data_loss (which will have to delete some data to fix this
particular corruption). There is no supported way of determining what data
has been lost apart from analyzing the error messages from DBCC.
I recommend you open a case with PSS who can help you address the
corruptions and also help you determine what caused them.
Regards.
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Bush" <anonymous@.discussions.microsoft.com> wrote in message
news:77FBEDC8-9B02-4CAB-970E-A96DC0F47EF9@.microsoft.com...
> Results show 0 allocation errors and 42 consistency errors that all seem
to be from one table. That is to the extent I understand the results. The
errors are 8929, 8939, 8965, 8964 all for the same object id and varying
text ids. The repair_fast and repair_rebuild did not work. Its calling for
the repair_with_data_loss. Are there any work arounds? Does this mean
that the table is corrupt? Is this a torn data page due to this table? If
I need to run the repair_with_data_loss is there an easy way to determine
which data has been lost? Welcome any feedback.

DBCC CHECKDB multiple errors

Friday, February 17, 2012

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][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.
> > 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).
> >
>|||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...
>> 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).
>> >
>>
>|||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 how to invoke to return any errors

Hello,
I would like to make intented error in the consistency of a database
and watch what will be the outcome from the DBCC CHECKDB.
Then train repair the database.
I would like to corrupt some data or index pages in mdf file.
How to do that ?
Tanks.
misoHmmmm...
well - you could try this, BUT BE CAREFUL!!! Do not run this on a live
database - it WILL break it!
It will definately cause DBCC CHECKDB to error.
Use this script at your own risk!!!
sp_configure allow, 1
go
reconfigure with override
go
update sysindexes set FirstIAM = 1234 where id = (select max(id) from
sysindexes)
go
sp_configure allow, 0
go
reconfigure with override
go
Immy
"Michal Valent" <valent@.spirit.sk> wrote in message
news:OeBJmQSRHHA.488@.TK2MSFTNGP06.phx.gbl...
> Hello,
> I would like to make intented error in the consistency of a database
> and watch what will be the outcome from the DBCC CHECKDB.
> Then train repair the database.
> I would like to corrupt some data or index pages in mdf file.
> How to do that ?
> Tanks.
> miso
>

DBCC CHECKDB how to invoke to return any errors

Tuesday, February 14, 2012

dbcc checkdb

I found the error 2508 after I ran dbcc checkdb on one of my tables. It
says it found a consistency error. What should I do? Can I run the
dbcc checkdb <dbname>,repair_rebuild.
Please advice.
Regards
JaideepYou have some serious data corruption problems.
Issue a DBCC CHECKDB('DatabaseName',repair_allow_data_loss)
If this does not fix the problem or cause important data to be lost you will
have to restore the latest backup.
Hopefully you will have a recent backup available you can restore from.
--
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"jai" <dbasybase@.gmail.com> wrote in message
news:1157504133.116486.17050@.d34g2000cwd.googlegroups.com...
>I found the error 2508 after I ran dbcc checkdb on one of my tables. It
> says it found a consistency error. What should I do? Can I run the
> dbcc checkdb <dbname>,repair_rebuild.
> Please advice.
> Regards
> Jaideep
>|||Hi,
Please do not execute CHECKDB with option repair_allow_data_loss directly.
1. Do a Full database backup
2. Then execute dbcc checkdb <dbname>,repair_rebuild.
3. See if the error is fixed. If the error is not fixed then go with
repair_allow_data_loss
Thanks
Hari
SQL Server MVP
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23e0A$GV0GHA.4808@.TK2MSFTNGP04.phx.gbl...
> You have some serious data corruption problems.
> Issue a DBCC CHECKDB('DatabaseName',repair_allow_data_loss)
> If this does not fix the problem or cause important data to be lost you
> will have to restore the latest backup.
> Hopefully you will have a recent backup available you can restore from.
> --
> Hilary Cotter
> Director of Text Mining and Database Strategy
> RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
> This posting is my own and doesn't necessarily represent RelevantNoise's
> positions, strategies or opinions.
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "jai" <dbasybase@.gmail.com> wrote in message
> news:1157504133.116486.17050@.d34g2000cwd.googlegroups.com...
>>I found the error 2508 after I ran dbcc checkdb on one of my tables. It
>> says it found a consistency error. What should I do? Can I run the
>> dbcc checkdb <dbname>,repair_rebuild.
>> Please advice.
>> Regards
>> Jaideep
>|||Hello,
Thanks Hari for your help. Actually, I was able to fix the problem
using DBCC UPDATEUSAGE. I don't know if dbcc checkdb would have solved
the row count error in the system views.
Regards
Jaideep
Hari Prasad wrote:
> Hi,
> Please do not execute CHECKDB with option repair_allow_data_loss directly.
> 1. Do a Full database backup
> 2. Then execute dbcc checkdb <dbname>,repair_rebuild.
> 3. See if the error is fixed. If the error is not fixed then go with
> repair_allow_data_loss
> Thanks
> Hari
> SQL Server MVP
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:%23e0A$GV0GHA.4808@.TK2MSFTNGP04.phx.gbl...
> > You have some serious data corruption problems.
> >
> > Issue a DBCC CHECKDB('DatabaseName',repair_allow_data_loss)
> >
> > If this does not fix the problem or cause important data to be lost you
> > will have to restore the latest backup.
> >
> > Hopefully you will have a recent backup available you can restore from.
> >
> > --
> > Hilary Cotter
> > Director of Text Mining and Database Strategy
> > RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
> >
> > This posting is my own and doesn't necessarily represent RelevantNoise's
> > positions, strategies or opinions.
> >
> > Looking for a SQL Server replication book?
> > http://www.nwsu.com/0974973602.html
> >
> > Looking for a FAQ on Indexing Services/SQL FTS
> > http://www.indexserverfaq.com
> >
> >
> >
> > "jai" <dbasybase@.gmail.com> wrote in message
> > news:1157504133.116486.17050@.d34g2000cwd.googlegroups.com...
> >>I found the error 2508 after I ran dbcc checkdb on one of my tables. It
> >> says it found a consistency error. What should I do? Can I run the
> >> dbcc checkdb <dbname>,repair_rebuild.
> >>
> >> Please advice.
> >>
> >> Regards
> >>
> >> Jaideep
> >>
> >
> >|||Hi,
Thanks for getting back with the update. Actually DBCC CHECKDB will report
the rewcount errors and need to use DBCC UPDATEUSAGE
to fix it. You did the right action.
Thanks
Hari
SQL Server MVP
"jai" <dbasybase@.gmail.com> wrote in message
news:1157639412.832187.165890@.d34g2000cwd.googlegroups.com...
> Hello,
> Thanks Hari for your help. Actually, I was able to fix the problem
> using DBCC UPDATEUSAGE. I don't know if dbcc checkdb would have solved
> the row count error in the system views.
> Regards
> Jaideep
> Hari Prasad wrote:
>> Hi,
>> Please do not execute CHECKDB with option repair_allow_data_loss
>> directly.
>> 1. Do a Full database backup
>> 2. Then execute dbcc checkdb <dbname>,repair_rebuild.
>> 3. See if the error is fixed. If the error is not fixed then go with
>> repair_allow_data_loss
>> Thanks
>> Hari
>> SQL Server MVP
>> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
>> news:%23e0A$GV0GHA.4808@.TK2MSFTNGP04.phx.gbl...
>> > You have some serious data corruption problems.
>> >
>> > Issue a DBCC CHECKDB('DatabaseName',repair_allow_data_loss)
>> >
>> > If this does not fix the problem or cause important data to be lost you
>> > will have to restore the latest backup.
>> >
>> > Hopefully you will have a recent backup available you can restore from.
>> >
>> > --
>> > Hilary Cotter
>> > Director of Text Mining and Database Strategy
>> > RelevantNOISE.Com - Dedicated to mining blogs for business
>> > intelligence.
>> >
>> > This posting is my own and doesn't necessarily represent
>> > RelevantNoise's
>> > positions, strategies or opinions.
>> >
>> > Looking for a SQL Server replication book?
>> > http://www.nwsu.com/0974973602.html
>> >
>> > Looking for a FAQ on Indexing Services/SQL FTS
>> > http://www.indexserverfaq.com
>> >
>> >
>> >
>> > "jai" <dbasybase@.gmail.com> wrote in message
>> > news:1157504133.116486.17050@.d34g2000cwd.googlegroups.com...
>> >>I found the error 2508 after I ran dbcc checkdb on one of my tables. It
>> >> says it found a consistency error. What should I do? Can I run the
>> >> dbcc checkdb <dbname>,repair_rebuild.
>> >>
>> >> Please advice.
>> >>
>> >> Regards
>> >>
>> >> Jaideep
>> >>
>> >
>> >
>

Friday, February 24, 2012

DBCC Consistency Errors after copying the backup file

DBCC Consistency Errors after copying the backup file

DBCC Consistency Errors after copying the backup file

DBCC CheckTable shows consistency errors

Sunday, February 19, 2012

dbcc checkdb to output file

DBCC CHECKDB shows errors

DBCC CHECKDB multiple errors

Friday, February 17, 2012

DBCC CHECKDB multiple errors

DBCC CHECKDB multiple errors

DBCC CHECKDB how to invoke to return any errors

DBCC CHECKDB how to invoke to return any errors

Tuesday, February 14, 2012

dbcc checkdb

dbcc checkdb

DBfile usage

Blog Archive

About Me