May 19, 2014 at 8:04 am
Hello All,
After a weekend CHECKDB against a VIPS (Very Important Production System) as (part of a weekly backup, restore, checkdb test process)...we ran into the following error:
DBCC results for 'DatabaseName'.
Service Broker Msg 9675, State 1: Message Types analyzed: 14.
Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.
Service Broker Msg 9667, State 1: Services analyzed: 3.
Service Broker Msg 9668, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.
Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0.
Msg 2576, Level 16, State 1, Line 1
The Index Allocation Map (IAM) page (0:0) is pointed to by the previous pointer of IAM page (10:241) in object ID 0, index ID -1, partition ID 0, alloc unit ID 72057594071547904 (type Unknown), but it was not detected in the scan.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
...
...
No reported issue
...
...
CHECKDB found 1 allocation errors and 0 consistency errors in database 'DatabaseName'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (DatabaseName).
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Quickly jumping online to review this type of error I ran across Paul's blog entry:
The previous weeks CheckDB was clean so the issue, I believe would have resulted in the past week.
One of the only "out of the norm" things that was done against this database was some reindexing (offline) during a scheduled outage.
During that reindexing effort a connection was lost during one of the reindexing statements (which I wouldn't think would cause this type of an issue, but figured I would state it).
Looking at the blog entry from Paul it states that a DBCC CHECKDB(DatabaseName, REPAIR_ALLOW_DATA_LOSS) is a fix, to return the database to a consistent state but I don't want to travel down that road at the moment.
I am hoping to have some help clarifying what options I have available. Is there a way to tie this back to a particular table / index? The full checkdb didn't report any individual table issues so to me means that reaffirms what is written in the blog post
"
The error is saying that the first IAM page in the IAM chain (page 1:153) does not have a reference from metadata. The sysallocunits system table contains a link to the first IAM page, the root page, and the first page. You can see these by querying the sys.system_internals_allocation_units catalog view
"
If someone has some time, can they offer any insight on what options are available to me on helping troubleshoot this issue?
Thanks much in advance,
Lee
Viewing post 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply