Update row count on corrupt table I have a corrupt table, 1 dodgy page about 1.6 million rows into a 2.9 million row table. I want to attempt this:

ALTER DATABASE [CorruptDB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB (CorruptDB, REPAIR_ALLOW_DATA_LOSS) WITH TABLOCK;


..but I want to know how I can be certain the number of rows before and after the data loss. If I do:

UPDATE STATISTICS [corrupt_table] WITH FULLSCAN;


It fails as there is of course a torn page half way down. The same goes for:

SELECT COUNT(*) FROM [corrupt_table];


I suppose my question is, will a non-fullscan UPDATE STATISTICS definitely update the number of rows correctly?

I know it's only one torn page, that should equate to about 100 rows in this table, I just want to know for sure.

Note: This is not on a production system, it's just local on my laptop (2012 Std x64) and the actual issue has been resolved (with a restore) - I've taken a copy of the DB to play with.
Dealing with the corruption:

First: Any chance you have a good backup from before the page went bad?  If so then you may be able to do a page restore rather than repair data loss.  This would certainly be your best bet.  Remember that in most cases the corruption that caused the error on disk does not affect your transaction logs. So as long as your full backup has a good page then you can restore over the bad page from the full backup, then apply all of the transaction logs (restoring only that single page of course) from that point on.  Of course this only works if you have full recovery.
 https://msdn.microsoft.com/en-us/ms175168.aspx?f=255&amp;MSPPError=-2147217396

Also you might take a look at what was done here: http://stevestedman.com/2015/04/a-weekend-full-of-database-corruption/

If you look at Brent Ozar's answer he used a comparison of the non-clustered index vs the clustered (all of the damage was on the clustered index like I'm guessing yours is if it's a single page) to find the actual damage.  He was also then able to recover the missing information by the same method (clustered index vs non-clustered).

The actual question

You might try using sys.partitions for your counts. They are almost always correct in my experience.  No guarantees given your corruption but it should be good, particularly if you compare multiple indexes.  

SELECT * FROM sys.partitions WHERE object_id = OBJECT_ID('db.schema.table')


If the corruption is in a single page (or if there is no corruption in at least one of the non-clustered indexes) then you will have at least one index where there is no problem and sys.partitions should be correct.  Of course you can also do this to force your count to look at the uncorrupted index.

SELECT COUNT(1) FROM dbo.table WITH (INDEX = [ix_table])