In the previous post, I shared demonstration on how to corrupt your table in SQL Server.

Generally, SQL DBAs are executing DBCC CHECKDB for checking and finding damaged table or data. But if your database size is very enormous and the result of DBCC CHECKDB is also huge, it is tough to find out suspected tables.

Then, what is the solution?
The solution is to check the suspect pages and find the table name using object id.

Check the below demonstration where I used one sample corrupted table, and more you can test the yesterday’s post for tbl_bad.

Check the suspect_pages:

SELECT * FROM [msdb].[dbo].[suspect_pages]

Result:

database_id file_id     page_id              
----------- ----------- -------------------- 
10          1           312

Execute below DBCC PAGE:
Database id =10
File no=1
Page id=312
Print option=0

DBCC TRACEON (3604);
DBCC PAGE (10, 1, 312, 0);
DBCC TRACEOFF (3604);
GO

Result:

PAGE HEADER:

Page @0x000000F815DC4000

m_pageId = (1:312)                  m_headerVersion = 1                 m_type = 1
m_typeFlagBits = 0x0                m_level = 0                         m_flagBits = 0x8200
m_objId (AllocUnitId.idObj) = 138   m_indexId (AllocUnitId.idInd) = 256 
Metadata: AllocUnitId = 72057594046971904                                
Metadata: PartitionId = 72057594041335808                                Metadata: IndexId = 1
Metadata: ObjectId = 565577053      m_prevPage = (0:0)                  m_nextPage = (0:0)
pminlen = 8                         m_slotCnt = 5                       m_freeCnt = 7976
m_freeData = 206                    m_reservedCnt = 0                   m_lsn = (34:228:3)
m_xactReserved = 0                  m_xdesId = (0:0)                    m_ghostRecCnt = 0
m_tornBits = -411585792             DB Frag ID = 1                      

Allocation Status

GAM (1:2) = ALLOCATED               SGAM (1:3) = NOT ALLOCATED          PFS (1:1) = 0x40 ALLOCATED   0_PCT_FULL
DIFF (1:6) = CHANGED                ML (1:7) = NOT MIN_LOGGED

Find Metadata: ObjectId and get the object name:

SELECT OBJECT_NAME (565577053);

In this post, I am sharing a demonstration on how to damage a table of SQL Server.
Why I am sharing this because practice on data corruption is required for SQL DBA before actual data corruption happens.

You can find N number of different solutions for restoring corrupted database or table, but what about like if you want to test any of this solution.
In most of the cases, the table gets corrupt because of invalid data or junk data of data page. Using DBCC WRITEPAGE, you can modify the table page.

Please check the below demonstration, and share your commands/options via comments to restore this table.

Create a sample database:

CREATE DATABASE KillMe
GO 
USE KillMe 
GO

Create a table with sample data:

CREATE TABLE tbl_bad
(
    ID INT IDENTITY(1,1) 
    ,Name VARCHAR(10) DEFAULT 'dbrnd'
)
GO 

CREATE CLUSTERED INDEX ix_ID ON tbl_bad(ID) 
GO
 
INSERT INTO tbl_bad DEFAULT VALUES
INSERT INTO tbl_bad DEFAULT VALUES
INSERT INTO tbl_bad DEFAULT VALUES
INSERT INTO tbl_bad DEFAULT VALUES
INSERT INTO tbl_bad DEFAULT VALUES 
GO

Find the page information of table:

DBCC IND (KillMe, 'tbl_bad', 1)
GO

Result:

PageFID PagePID     IAMFID IAMPID      ObjectID    PageType 
------- ----------- ------ ----------- ----------- -------- 
1       320         NULL   NULL        565577053   10       
1       312         1      320         565577053   1

Change database to single user mode:

ALTER DATABASE KillMe SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Modify page number which page type is 1:

DBCC WRITEPAGE('KillMe', 1, 312, 60, 1, 0x00, 1)

Now try to select your table data:

SELECT *FROM tbl_bad

Error in the result:

Msg 824, Level 24, State 2, Line 1
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xe777b300; actual: 0xe777b303). It occurred during a read of page (1:312) in database ID 10 at offset 0x00000000270000 
in file 'C:\Program Files\Microsoft SQL Server\MSSQL13.SQLSERVER\MSSQL\DATA\KillMe.mdf'.  Additional messages in the SQL Server error log or system event log may provide more detail. 
This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). 
This error can be caused by many factors; for more information, see SQL Server Books Online.

Check the suspect_pages:

SELECT * FROM [msdb].[dbo].[suspect_pages]

Result:

database_id file_id     page_id              
----------- ----------- -------------------- 
10          1           312

In this post, I am sharing T-SQL script to monitor the Corrupt Database Pages of SQL Server.

SQL Server: Enable CHECKSUM Page Verification to detect a prime spot of Data Corruption

You should not the wait for big data corruption. Periodically, DBA can monitor the data corruption in SQL Server.
Use msdb.dbo.suspect_pages table to get the information of corrupt pages.

SELECT 
	SD.NAME AS DatabaseName
	,SP.file_id AS FileID
	,MF.physical_name AS PhysicalFilePath
	,SP.page_id AS PageID
	,CASE 
		WHEN SP.event_type = 1
			THEN '823 error caused by an operating system CRC error or 824 error other than a bad checksum or a torn page'
		WHEN SP.event_type = 2
			THEN 'Bad checksum'
		WHEN SP.event_type = 3
			THEN 'Torn Page'
		WHEN SP.event_type = 4
			THEN 'Restored (The page was restored after it was marked bad)'
		WHEN SP.event_type = 5
			THEN 'Repaired (DBCC repaired the page)'
		WHEN SP.event_type = 7
			THEN 'Deallocated by DBCC'
	END AS EventDescription
	,SP.error_count AS ErrorCount
	,SP.last_update_date AS LastUpdated
FROM msdb.dbo.suspect_pages AS SP
INNER JOIN sys.databases AS SD 
	ON SD.database_id = SP.database_id
INNER JOIN sys.master_files AS MF 
	ON MF.database_id = SP.database_id
		AND MF.file_id = SP.file_id