Explanation

Box 1: msdb.dbo.suspect_pages
suspect_pages contains one row per page that failed with a minor 823 error or an 824 error. Pages are listed in this table because they are suspected of being bad, but they might actually be fine. When a suspect page is repaired, its status is updated in the event_type column.
The suspect_pages table resides in the msdb database.
SalesDb3 has pages with checksum errors.
Box 2: msdb.sys.database_files
We want to identify these pages and which database they are in, this is easy enough to do when we join out to sys.databases and sys.master_files, as seen here:
SELECT d.name AS databaseName,
mf.name AS logicalFileName,
mf.physical_name AS physicalFileName,
sp.page_id,
case sp.event_type
when 1 then N'823 or 824 error'
when 2 then N'Bad Checksum'
when 3 then N'Torn Page'
when 4 then N'Restored'
when 5 then N'Repaired'
when 7 then N'Deallocated'
end AS eventType,
sp.error_count,
sp.last_update_date
from msdb.dbo.suspect_pages as sp
join sys.databases as d ON sp.database_id = d.database_id
join sys.master_files as mf on sp.[file_id] = mf.[file_id]
and d.database_id = mf.database_id;
The result of this query will give you a high level view of where you have potential corruption in your databases, from here it is important to use tools such as DBCC CHECKDB and your backups to recover from in line with your RPO and RTO.
References:
https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/manage-the-suspect-pages-table-sql-ser
https://blogs.sentryone.com/johnmartin/monitoring-for-suspect-pages/