What is the Suspect Pages Table?

Located in the msdb database, the Suspect Pages Table (msdb.dbo.suspect_pages) is essentially a log that SQL Server uses to record information about database pages that it suspects are corrupted. A “page” in SQL Server is a basic unit of data storage, consisting of 8 KB. Pages can become suspect due to a variety of reasons, including but not limited to hardware failures, software errors, or issues with the storage system itself.

How Does SQL Server Use the Suspect Pages Table?

Whenever SQL Server encounters a problem reading a page due to suspected corruption, it logs an entry in the Suspect Pages Table. This entry includes crucial information such as the database ID, file ID, page number, the type of error encountered, and when the error was logged.

This functionality serves two primary purposes:

1. Alerting and Monitoring: DBAs can query the table to identify potential issues within their databases, allowing for proactive measures to be taken before the corruption leads to significant data loss or downtime.
2. Repair Guidance: The details logged in the Suspect Pages Table can guide DBAs in determining the best course of action for repairing the corruption, whether that be restoring from a backup, running DBCC CHECKDB with appropriate repair options, or other corrective measures.

Interacting with the Suspect Pages Table

Querying the Suspect Pages Table is straightforward and can provide invaluable insights into the health of a database. Here’s a simple query to list all suspect pages:

SELECT * FROM msdb.dbo.suspect_pages;

This will return a list of all pages that have been marked as suspect, along with details about the corruption. It’s a good practice for DBAs to regularly monitor this table and set up alerts based on its entries to ensure they are aware of any potential data integrity issues.

Best Practices for Managing Suspect Pages

1. Regular Monitoring: Incorporate checks of the Suspect Pages Table into regular database health assessments.
2. Prompt Action: Upon discovering suspect pages, assess the extent of the corruption and take appropriate action immediately to prevent further damage.
3. Comprehensive Backups: Maintain a robust backup and recovery strategy. Regular backups can be a lifesaver in the event that data corruption cannot be resolved without data loss.
4. Investigate Underlying Causes: After addressing the immediate corruption, investigate the root cause to prevent future occurrences. This may involve hardware diagnostics, reviewing system logs, or considering software updates.

Conclusion

The Suspect Pages Table in SQL Server is a critical tool in the DBA’s arsenal for maintaining data integrity and ensuring the health of a database. By understanding how to effectively monitor and respond to entries in this table, DBAs can better protect their organizations from the potentially devastating effects of data corruption. As with many aspects of database administration, proactive vigilance is key to ensuring data remains secure, consistent, and available when needed.

The DAC connection doesn’t support parallel executed operations like BACKUP and RESTORE are. This means, the when the server isn’t responding to regular connections we can’t simply connect to it via DAC and make backups of the critical databases when necessary. If we will try to run BACKUP from it, the following error message will appear:

There is not much more to say. Simply remember it as a crucial limitation when you will think about your disaster recovery plans.

You can review how these two functions behave on any database and compare their results with sys.columns view max_length, precision, and scale columns:

SELECT DISTINCT *
FROM (
	SELECT 
		t.[name], c.[max_length], c.[precision], 
		OdbcPrec(t.system_type_id, c.max_length, c.precision) odbc_prec,
		c.[scale],
		OdbcScale(t.system_type_id, c.[scale]) odbc_scale
	FROM sys.columns c
	    INNER JOIN sys. t ON [t].[system_type_id] = [c].[system_type_id] AND [t].[user_type_id] = [c].[user_type_id]
	) a    
WHERE ISNULL([max_length], 0) <> ISNULL([odbc_prec], 0) OR
      ISNULL([scale], 0) <> ISNULL(odbc_scale, 0)
GO

Based on this result I will say these two functions are just converting specific SQL Server-related data types length, precision, and scale to ODBC standard specification.

USE [master]
GO

DECLARE @Sql VARCHAR(1000)
SET @Sql = ''    
SELECT  @Sql = @Sql + 'kill ' + CONVERT(NVARCHAR(3), [spid]) + '; '
FROM    [master].[dbo].[sysprocesses]
WHERE   DB_NAME([dbid]) = 'MY_DATABASE'  AND spid > 50
EXECUTE(@Sql)
GO

Most of the time it’s working perfectly but for some specific databases and only at some point in time we can see this exception to be fired:

The question is: Is there an active system SPID in our database? Let’s check it in the Activity Monitor or with the query below:

SELECT 
	[spid], [kpid], [cmd],  [blocked], [waittype], [waittime], [lastwaittype], [waitresource], [dbid], [uid], [cpu],
	[physical_io], [memusage], [login_time], [last_batch]
FROM    [master].[dbo].[sysprocesses] 
WHERE   DB_NAME([dbid]) = 'MY_DATABASE' 
GO

There is really one active system SPID running and it looks like to do some serious work based on CPU and physical_io columns. Where is this coming from?

Most probably our database has Change Tracking feature active on it and this system SPID is a background task to maintain the history cleanup. We can check for it:

SELECT * FROM sys.[change_tracking_databases]

If we see one row listed there for our database then most probably the system SPID belongs to the Change Tracking cleanup job which is activated on our database and is blocking restore from the snapshot. You can read more about this in the documentation. A similar situation we can expect for the Change Data Capture feature.

When Change Tracking doesn’t need to be active on our development database then the best option is to switch it off before snapshot creation:

DECLARE @SQL NVARCHAR(MAX) = '';
SELECT @SQL = @SQL + 'ALTER TABLE ' + [s].[name] + '.' + [t].[name] + ' Disable Change_tracking;' + CHAR(10)
FROM [sys].[change_tracking_tables] [ct]
	JOIN [sys].[tables] [t] ON [ct].[object_id]= [t].[object_id] 
	JOIN [sys].[schemas] [s] ON [t].[schema_id]= [s].[schema_id];

EXEC sp_executesql @SQL;
GO

ALTER DATABASE [MY_DATABASE] SET CHANGE_TRACKING = OFF
GO

If Change Tracking needs to be active we can use the undocumented stored procedure sp_flush_commit_table_on_demand. There is more info about it at sirsql.net.

After some searching and investigating detail about the server we captured two core informations:

1. The database is set for read-only access
2. The server was upgraded last week to never version (higher service pack).

This combination is the root cause of the database to be inaccessible: because it was set read-only during the instance upgrade, setup wasn’t able to upgrade the database too. The error above appears at every single action to recover now.

All these steps has failed:

1. Set the database for read_write access:

USE master;  
GO  
ALTER DATABASE [DB1] SET READ_WRITE;  
GO

2. Detach the database

3. Backup the database

4. Check if files aren’t locked at the file system level (read-only attribute)

In the end, we have finished with dropping the database and restoring it from the previous backup which led to successful database version upgrade.

It’s really one the best practices that before any patching or upgrade of SQL Server instance all read-only database should be set back to read-write mode.

• SQLServerManager14.msc => pro SQL Server 2017
• SQLServerManager13.msc => pro SQL Server 2016
• SQLServerManager12.msc => pro SQL Server 2014
• SQLServerManager11.msc => pro SQL Server 2012

Pokud si chcete vytvořit zástupce na ploše, najde jednotlivé verze Manageru zde:

Více na MSDN – SQL Server Configuration Manager.

There is sample of one filter we are using in production which is near this maximum. You can imagine lot of other things we would like to remove from capturing but we can’t because of the 3000 characters limit.

Below is simple script to generate required triggers for every table in database. You only need to set @ReplAccount variable to your replication system account. If you will later remove all triggers you can switch @DeleteOnly variable from 0 to 1.

DECLARE @Stmt NVARCHAR(MAX)
DECLARE @DeleteOnly BIT
DECLARE @ReplAccount NVARCHAR(128)

SET @ReplAccount = 'domain\account'
SET @DeleteOnly = 0

SET @Stmt = ''

SELECT 
	@Stmt = @Stmt + 
	CASE @DeleteOnly 
		WHEN 0 THEN 
			N'EXECUTE(''CREATE TRIGGER ['+ [sch].[name] + '].[trg_prevent_modify_' + [tab].[name] + '] 
							ON [' + [sch].[name] + '].[' + [tab].[name] + ']
			FOR INSERT, UPDATE, DELETE
			AS
			BEGIN
				IF SUSER_SNAME() <> ''''' + @ReplAccount + '''''
				BEGIN
					RAISERROR(''''Database is replicated and data cannot be modified!'''',16,1);
					ROLLBACK;
				END
			END'');

			'
		ELSE 'DROP TRIGGER ['+[sch].[name]+'].[trg_prevent_modify_'+[tab].[name]+']' + CHAR(13)
	END
FROM sys.tables AS tab
	JOIN sys.schemas AS sch ON tab.[schema_id] = sch.[schema_id]
WHERE tab.[type] = 'U'

PRINT @Stmt
EXECUTE(@Stmt)
GO

If you will test this solution the try to update the data in any table and the following exception will be generated:

Usually, you will capture this error in Replication Monitor as visible in this picture:

As a first step, we need to browse replication commands that are waiting in the distribution database to be replayed on subscribers. We will select these data from the Msrepl_errors table:

USE [distribution]
GO

SELECT 
	[id], [time], [error_code], [error_text], [xact_seqno]
FROM [dbo].[MSrepl_errors] 
ORDER BY [time] desc
GO

Once we have selected our error rising command the most important information is hidden in the xact_seqno column: it’s the starting transaction log sequence number of the first failed transaction in the execution batch.

We will use this sequence number as an input parameter for sys.sp_browsereplcmds stored procedure which returns a readable version of the replicated commands stored in the distribution database.

USE [distribution]
GO

EXEC [sys].[sp_browsereplcmds]
	 @xact_seqno_start = N'0x0000A31F0007BC9E01A200000000',
     @xact_seqno_end = N'0x0000A31F0007BC9E01A200000000'
GO

In the command column is the user-friendly text representation of the command to be replicated. The most important part of it is the number in parentheses which is in our particular case the primary key value of the row that should be deleted by this command. And because this row was deleted on the subscriber manually, a replication error is raised when this command is executed on the subscriber.

If we have the option to insert deleted rows on subscriber manually, replication will continue without an error and there is no need for subscription reinitialization.

EXEC sp_altermessage 102, 'WITH_LOG', 'true'
EXEC sp_altermessage 208, 'WITH_LOG', 'true'
GO

SELECT * F_ROM dbo.table1
GO
SELECT * FROM dbo.invalid_name
GO

We have altered two system messages to be stored in SQL/WINDOWS logs:

SQL Server Log:

WINDOWS Applications Log:

Both messages are logged there as expected.

The effect of sp_altermessage with the WITH_LOG option is basically the same as of the RAISERROR WITH LOG parameter, except that sp_altermessage changes the logging behavior for all messages fired inside the engine.