SQL Server 2016 table corrupt I have an SQL Server 2016 v13.0.5101.9 hosting Sharepoint databases. The weekly DBCC CHECKDB job discovered database corruption (or inconsistency): Msg 8928,  and Msg 8965 popping up. 

I narrowed it down to the Docstreams table which occupies 99% of the database space, so that doesn't help much: the table is around 100GB, I suspect mostly in the "Content" column of type  varbinary(max). 

Within that table I narrowed down the corruption to 8 pages. The REPAIR ALLOW_DATA_LOSS option of DBCC CHECKTABLE which was suggested is not really appealing, considering the possible consequences in Sharepoint. So far, there are no complaints about the corruption from the users, but I suspect that is just a matter of time. 

What I'm trying to do is to identify corrupt rows and have the rows (=sharepoint content) removed in a controlled way using sharepoint. So there I go using DBCC PAGE (parameters) which I found is supposed to have four main sections: Buffer, Page Header, Data, and Offset Table  ... but it show only the first 2 sections, the third is supposed to show the data I want to see.

So the question is: Is there a(nother) way to identify the rows that are affected by the corrupt pages that allows me to point to the sharepoint content?

Note 1: this is a new database of which the contents were migrated from a filesystem by an external vendor last week. There is no indication of any faulty disk, but somehow this inconsistency must have crept in.

Note 2: I have copied the database to an non-prod SQL Server in order to investigate the issue. I have already removed the unique constraint and thus related clustered index. The problem lies in the table itself. In other words: recreating the (clustered) index doesn't work.

Note 3: I was thinking about doing a select * into newtable, but as I'm writing this, it crashed with: 


  Msg 824, Level 24, State 2, Line 67
  SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xd843cba2; actual: 0x908acba5). .... and actually pointing to the pages found in the DBCC.
To answer my own question for anyone in the same situation: Although the DBCC CHECKTABLE ... with ALLOW_DATA_LOSS option very nicely fixed the problem and removed the corrupt pages in a test-environment, it was decided to redo the migration. That was possible because the source-data turned out to be static: nothing had changed there...