November 18, 2003 at 11:04 am
Getting this from SqlServer error log:
I/O error (bad page ID) detected during
read at offset 0x00000106dea000 in file 'K:\smsdw_fg_files\SMSPHdss800r_smsdre_data_fg06_1.ndf'..
3rd party app doing numerous, extensive loads. No access to sql that is being run.
Any ideas as to how to determine what table/index/object the error might be referring to?
November 18, 2003 at 3:44 pm
Try executing a DBCC CHECKDB on the database. This grabs some resources. From the looks of it you may be able to execute a DBCC CHECKFILEGROUP <syntax?>
"Keep Your Stick On the Ice" ..Red Green
November 19, 2003 at 7:10 am
Ran checkdb. Getting numerous consistency errors (26 total) on several tables. Am puzzled by some entries:
DBCC results for 'bc_wAccount_ids'.
There are 14972 rows in 292 pages for object 'bc_wAccount_ids'.
DBCC results for 'rollup3_dim'.
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 1229247434, index ID 2: Page (14:538356) could not be processed. See other errors for details.
Server: Msg 8939, Level 16, State 1, Line 1
Table error: Object ID 1229247434, index ID 2, page (14:538356). Test (IS_ON (BUF_IOERR, bp->bstat) &&bp->berrcode) failed. Values are 2057 and -1.
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 1229247434, index ID 2: Page (14:538357) could not be processed. See other errors for details.
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 1229247434, index ID 2: Page (14:538358) could not be processed. See other errors for details.
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 1229247434, index ID 2: Page (14:538359) could not be processed. See other errors for details.
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 1339151816, index ID 0: Page (16:1143272) could not be processed. See other errors for details.
Server: Msg 8939, Level 16, State 1, Line 1
Table error: Object ID 1339151816, index ID 0, page (16:1143272). Test (IS_ON (BUF_IOERR, bp->bstat) &&bp->berrcode) failed. Values are 2057 and -1.
There are 0 rows in 0 pages for object 'rollup3_dim'.
DBCC results for 'perf_cmpnt_std_src_fltr'.
There are 0 rows in 0 pages for object 'perf_cmpnt_std_src_fltr'.
This would seem to indicate a problem with the rollup3_dim table, but there are 0 rows in it.
DBREINDEX helped clear errors on some tables/indexes. But there are other entries in the output that aren't much help:
DBCC results for 'mir_prov_claim_proc'.
There are 0 rows in 0 pages for object 'mir_prov_claim_proc'.
CHECKDB found 0 allocation errors and 1 consistency errors in table '(Object ID 331355172)' (object ID 331355172).
CHECKDB found 0 allocation errors and 1 consistency errors in table '(Object ID 331420702)' (object ID 331420702).
CHECKDB found 0 allocation errors and 1 consistency errors in table '(Object ID 331420706)' (object ID 331420706).
CHECKDB found 0 allocation errors and 1 consistency errors in table '(Object ID 331551777)' (object ID 331551777).
CHECKDB found 0 allocation errors and 1 consistency errors in table '(Object ID 331748387)' (object ID 331748387).
CHECKDB found 0 allocation errors and 1 consistency errors in table '(Object ID 332338225)' (object ID 332338225).
DBCC results for 'mir_mem'.
There are 0 rows in 0 pages for object 'mir_mem'.
The object id being referred to is not in sysobjects.
I can't seem to find any documentation to help interpret the output of DBCC.
November 19, 2003 at 8:28 am
Could it be an OS issue?
Drop/recreate objects with 0 rows and run
checkdb again
Mike
November 19, 2003 at 8:40 am
If I could identify the objects, I would drop & re-create them. DBCC is giving me object id numbers vs. table/index names.
November 19, 2003 at 8:53 am
select object_name(yourobjectid) will tell you the object.
sp_helpindex yourobjectnaem tells the indexes the object has.
November 19, 2003 at 9:25 am
Sorry, Mike, I misunderstood your posting.
I believe that DBCC is kind of randomly spitting out errors. The "CHECKDB..." errors being displayed for the table that has 0 rows are some examples of this. Dropping/recreating the table with 0 rows made no difference.
I did try running dbreindex on 2 of the larger tables, thinking they would be more prone to errors. The error now is:
Server: Msg 823, Level 24, State 2, Line 1
I/O error (torn page) detected during read at offset 0x0000022e3d0000 in file 'K:\smsdw_fg_files\SMSPHdss800r_smsdre_data_fg07_1.ndf'.
What is a "torn page"? and how can it be corrected? Do I stand to lose some data here?
November 19, 2003 at 9:31 am
Allen,
I had already tried that query. It returns null. The object ids being displayed (as in the excerpt from dbcc output in previous post) do not exist in sysobjects.
November 19, 2003 at 9:41 am
Make sure your run them in the correct database, ie your user database.
November 19, 2003 at 11:59 am
Again did you check the OS?Torn pages (When a partial page write to disk has occured) is an indication that your data is corrupt.
You may want to investigate more but I will check my last good backup
Mike
November 19, 2003 at 12:37 pm
Okay, I've narrowed my problem down to 2 tables. Tried to use checktable with repair_rebuild option but it did not work. Looks like I'm going to lose some data.
Wish these outputs were more specific about which rows are corrupt.
Thanks for the help.
November 19, 2003 at 12:49 pm
The index ID in error messages indicated which indexes are in problem. Drop the indexes, recreate them and run dbcc checktable against these table.
Please post the result of dbcc checktable.
Edited by - allen_cui on 11/19/2003 12:50:37 PM
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply