I am unable to find an article yet, that is able to clearly help my understanding of the risks I run by running my Ola Hallengren DatabaseIntegrityCheck job with PHYSICALONLY parameter on our large databases. There is no mention of a FULL check being done: [https://ola.hallengren.com/] > Run Integrity Checks of Very Large Databases The SQL Server > Maintenance Solution has been designed to do integrity checks of very > large databases. In the DatabaseIntegrityCheck procedure you can > choose do the checks on the database level, the filegroup level, or > the table level. It also supports limiting the checks to the physical > structures of the database: > > EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'USER_DATABASES', > @CheckCommands = 'CHECKDB', @PhysicalOnly = 'Y' These checks are limited to checking only the physical consistency i.e. that all data is present and can be read. Is someone able to clarify for me please, or point me to an article that can clearly help me with exactly what are those logical checks that this PhysicalOnly check ignores, and what risks could be associated with ignoring the logical checks or doing a FULL check less frequently

I am logging the DBCC CHECKDB job output to a table. When I look at the job log using the below command, I want to verify that all is well. use msdb EXEC dbo.sp_help_jobsteplog @job_name = N'DatabaseIntegrityCheck - USER_DATABASES' ; Would you say that we are good if we see "Outcome: Succeeded" in the log for the job or is there something else we should also review? We are using Ola's job output but I am also logging it to a table and am just wondering about the output. If we see "outcome succeeded' in the job, is this enough to know the CHECKDB found nothing wrong?

Running DBCC Checktable on one of my tables causes several errors: > Msg 2570, Level 16, State 3, Line 1 errors, Page (1:442), slot 1 in > object ID 565577053, index ID 0, partition ID 72057594041270272, alloc > unit ID 72057594046906368 (type "In-row data"). Column "XXXX" value is > out of range for data type "decimal". Update column to a legal value. Column XXXX is Decimal (18,4) I've done some investigation suggested by: 1) SELECT XXXX FROM Table WHERE XXXX > 99999999999999.9999 OR XXXX < -99999999999999.9999 This is not returning any rows 2) DBCC TRACEON ( 3604 ) DBCC PAGE ( Database, 1 , 442, 3 ) I found entry with XXXX = INVALID COLUMN VALUE I found primary key values for it And when I run: Select XXXX from Table where ID = ValueFound It returns -0.4500 - valid value for Decimal (18,4). Is this value correct or is this some random value? Do I understand it correctly - the only way to fix this is to provide correct values for given fieds?

We have a SQL Server 2017 Standard version where recently the CHECKDB is failing with the operating system error 665. The fragmentation level of the disk drive is 0% as it is automatically defragmented weekly. The database is 24/7 OLTP database. Only way the checkdb completes is when we turn off the application. Now online solution suggests 1) Increase the size of the disk drive, I have 800gb free space on the drive which has a database with 550 gb used space 2) Defragment the data drive- Currently automatically defragment weekly 3) Break the database into smaller files- Currently not possible due to downtime 4) Consider placing the database files on ReFS volume which does not have the same ATTRIBUTE_LIST_ENTRY limits that NTFS presents. You must reformat the current NTFS volume using ReFS. – Again not possible due to downtime Currently the checkdb checks with the option Physical only and using Ola Hallengreen script My short term proposal is to do the checkdb into another server. But I am running out of ideas if there are other ways to cure the problem without any downtime.

--- - Details: - I am running Microsoft SQL Server 2022 > Microsoft SQL Server 2022 (RTM-GDR) (KB5046861) - 16.0.1135.2 (X64) Oct 18 2024 15:31:58 Copyright (C) 2022 Microsoft Corporation Standard Edition (64-bit) on Windows Server 2022 Standard 10.0 (Build 20348: ) - I am running DBCC CHECKDB on a user database (of which raised this error), each saturday - This has happened on one on-prem Windows Server with installation of SQL server, with a predefined set of configs - Then after a month, I set up an additional on-prem Windows Server with same installation of SQL server, with the same predefined set of configs. The DBCC CHECKDB runs fine the first two weeks, then fails. - The error output after DBCC CHECKDB run on the user database:

[SQLSTATE 01000] (Message 50000)  Command: DBCC CHECKDB ([]) WITH ALL_ERRORMSGS   
    [SQLSTATE 01000] (Message 50000)  Check Catalog Msg 3853, State 1: Attribute (objid=317307915,indexid=1) of row (class=0,objid=317307915,indexid=1,rowsetnum=1) in sys.sysrowsetrefs does not have a matching row (object_id=317307915,index_id=1) in sys.indexes.  
    ...  
    
    CHECKDB found 0 allocation errors and 12 consistency errors not associated with any single object

And there is 11 more objects with the same error, I just didn't print them all here right now. - Both servers have several of these errors, with same message, but just different object_ids. - Both servers use the same type of hardware, server model, hardware provider, disk provider and disk model. - Both servers have restored to this userdatabase, from a database in an Azure SQL Managed Instance. - A small overview of errors returned by DBCC CHECKDB: | Date | Errors | Notes | | -----| -------| ------| | See *Notes | 12 errors | From 08/01/2025 to today(07/05/2025) | | 08/01/2025 | 12 errors | We tried REPAIR_ALLOW_DATA_LOSS here | | 04/01/2025 | 12 errors | | | 28/12/2024 | 12 errors | | | 21/12/2024 | 12 errors | | | 14/12/2024 | 12 errors | | | 07/12/2024 | 7 errors | | | 30/11/2024 | 7 errors | | | 23/11/2024 | 7 errors | | | 16/11/2024 | 7 errors | | | 09/11/2024 | 7 errors | | | 02/11/2024 | 7 errors | | | 26/10/2024 | 3 errors | First appearance | | 19/10/2024 | No errors | | | 17/10/2024 | No errors | | | 16/10/2024 | No errors | | | 12/10/2024 | No errors | | | 05/10/2024 | No errors | | - Troubleshooting steps already taken: - Firstly worth noting - No clean backups available. - Second thing worth noting - We have not experienced this causing or impacting the performance or functionality or integrity of the "user-created" objects (tables, views, constraints, procedures, indexes, ) - DBCC CHECKDB on userdatabase have been runned on the Azure SQL Managed Instance as well, no DBCC CHECKDB Errors there - Performed several selects against: - sys.sysrowsetrefs, - sys.sysrowsets, - sys.partitions, - sys.objects, - sys.sql_modules, - sys.stats, - sys.indexes, - sys.allocation_units - sys.system_internals_partition_columns, To try and retrieve info, by Object_id (and/or rowsetid based on object_id from sys.sysrowsetrefs) None of the querries I ran, returned rows based on objid/rowsetid, except for sys.sysrowsetrefs ; the table that DBCC found does not have a matching row in sys.indexes for instance. It's like that this is a ghost object, just dangling reference to an object that is deleted or none-existent. And I can't retrieve any info about what this object was, why and how it is now gone, nor where on disk/page/partition it was stored. - I therefore tried running sp_clean_db_free_space manually in hope that it would eliminate the ghost records the DBCC CHECKDB was reporting - But nothing happened to the records. - Tried DBCC CHECKDB ([], REPAIR) No errors repaired, still getting the same errors - Tried DBCC CHECKDB ([], REPAIR_ALLOW_DATA_LOSS) No errors repaired, still getting the same errors. (After running this, I restored to full backup taken just before I ran this command, in order to rule out that REPAIR_ALLOW_DATA_LOSS could have messed this up even more.) - Tried running hardware providers disk check, and hardware check, to rule out if this could be I/O issue. No events registred, nor no errors or fails reported. --- I really feel like I've tried everything here, but I'm eager to find the root cause to this, since It's happened on two servers now, not just one. Also a solution to how I should fix this going forward now would be highly appriciated!

Going through Ola H FAQ's, https://ola.hallengren.com/frequently-asked-questions.html , I see that > I also recommend that you perform the full backup after the integrity > check. Isn't the opposite true? That is - running integrity check after the backup is better because then you'd know for sure whether that backup is corrupted or not.

Anybody out there using [Azure Files](https://learn.microsoft.com/en-us/azure/storage/files/storage-files-introduction) for SQL data and log file storage? I've got one SQL Server using an AF share in this manner and am having issues running CHECKDB on its databases. Has anyone out there used Azure Files for SQL stuff and, if so, have you run into the following problem? When attempting to run CHECKDB on master: > Msg 5030, Level 16, State 12, Line 1 The database could not be exclusively locked to perform the operation. Msg 7926, Level 16, State 1, Line 1 Check statement aborted. The database could not be checked as a database snapshot could not be created and the database or table could not be locked. See Books Online for details of when this behavior is expected and what workarounds exist. Also see previous errors for more details. When attempting to run CHECKDB on user database: > DBCC CHECKDB will not check SQL Server catalog or Service Broker consistency because a database snapshot could not be created or because WITH TABLOCK was specified.

I have an Enterprise Edition SQL Server 2022 cluster with multiple AGs. Two of the AGs consider different instances primary. Both of these consider their secondaries readable and are correct to think this. Aside from being in this readable secondary configuration, nothing makes any of the databases on any of the instances read-only. They are not Basic Availability Groups. Here's the shocker: when I run DBCC CHECKCATALOG targeting a readable secondary database while connected to an instance that is not that database's primary, the query fails like this > Msg 3906, Level 16, State 8, Line 1 > > Failed to update database "DB NAME" because the database is read-only. #### but DBCC CHECKDB works just fine! I've searched high and low, but I've found nothing helpful about this. * [This issue on Ola Hallengren's Maintenance Solution's GitHub](https://github.com/olahallengren/sql-server-maintenance-solution/issues/403) is identical, but has no solution. Ola, who I trust to be an utter expert in this, seems to think it's a bug on his end rather than Microsoft's. * [This git commit](https://github.com/rentadba/dbaTDPMon/commit/077a1de89570a469df14f834cac01f1e25a64b23) suggests that its author, dan-andreistefan, has seen this before. I found no corresponding issue or PR. [Dan emerged from the void and solved the problem](https://xkcd.com/979/) . * Aside from the limitations on BAGs, I cannot find *anything at all* in the official SQL Server documentation about doing integrity checks on AGs. It's only in the licensing guide. How can I debug this? Why would DBCC CHECKDB, which is a superset of DBCC CHECKCATALOG, work where DBCC CHECKCATALOG fails?

Integrity checks are important on a regular basis to find out errors . Even on servers involved in availability groups . we can normally find out how long it took to run? It is a known fact that dbcc checkdb use a great deal of resources . So I have run it to one of my databases - 170 Gb size. with estimate only :

dbcc checkdb(DEV_My_Database) with estimateonly

It came out: > DBCC results for 'DEV_My_Database'. Estimated TEMPDB space (in KB) > needed for CHECKDB on database DEV_My_Database = 44320313. DBCC > execution completed. If DBCC printed error messages, contact your > system administrator. However, I never saw any extra usage of tempdb as everything seemed to fit in there for this purpose. How can I work out the right usage of resources, including tempdb, for my dbcc ?

On Enterprise Edition and Development edition, database integrity checks (e.g. DBCC CHECKDB) can run in parallel. According to best practice, backups should be tested regularly. So if I'm following best practice, I would be regularly restoring my production Enterprise Edition box's backups on to a non-production Development edition box and running CHECKDB there. This means that **I would never actually be running database integrity checks on my production Enterprise Edition box**. So, why is running database integrity checks in parallel beneficial if you are following best practice on Enterprise Edition? The exception to this is system databases, but they're so tiny that running CHECKDB in parallel is unlikely to matter.

I am investigating a high memory usage issue of tempdb on a production SQL Server 2017 Enterprise (64-bit) deployment. This is similar to an issue discussed here . The server has two production DBs each with a FILESTREAM. As part of my investigation, I ran DBCC CHECKDB ([db_name]) WITH ESTIMATEONLY; to check if tempdb is sized correctly. The output was as follows. > DBCC results for 'db_name'. > Estimated TEMPDB space (in KB) needed for CHECKDB on database db_name = 53. > Msg 7933, Level 16, State 1, Line 1 > Table error: A FILESTREAM directory ID b1e50dcc-0511-4488-8eeb-ea34966edfab exists for a partition, but the corresponding partition does not exist in the database. > Estimated TEMPDB space (in KB) needed for CHECKDB on database db_name = 16379997. > CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object. > DBCC execution completed. If DBCC printed error messages, contact your system administrator. I was surprised by the error considering that the senior DBA has all of Ola Hallengren's scripts running on a schedule. No errors were reported by these scheduled scripts and despite the error, the DBs are still functioning with the FILESTREAM. I continued my troubleshooting on a test environment with a restore of the full production DB backups. As expected the same error is present. Consequently, I ran DBCC CHECKDB ([db_name]) WITH NO_INFOMSGS, EXTENDED_LOGICAL_CHECKS, DATA_PURITY; but no errors were found. I wanted to execute DBCC CHECKFILEGROUP but as per the documentation , it cannot be executed on a FILESTREAM filegroup. # Question # Is the FILESTREAM-partition-does-not-exist-in-database-error a problem? Can it be resolved? It does not seem that any of the other DBCC commands detect a problem.

I ran DBCC CheckDB in our Production SQL Server 2014. It reported back with one consistency error: Failed:(-1073548784) Executing the query "DBCC CHECKDB(N'MYDB') WITH NO_INF..." failed with the following error: "Table error: Object ID 629577392, index ID 1, partition ID 72057594387039319, alloc unit ID 72057594045596759 (type LOB data). The off-row data node at page (1:6009), slot 24, text ID 15754068079 is not referenced. CHECKDB found 0 allocation errors and 1 consistency errors in table 'MYTABLE' (object ID 629577281). CHECKDB found 0 allocation errors and 1 consistency errors in database 'MYDB'. repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (MYDB).". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly. Since we do not have a good backup for that DB, we have to route to the below scenario. What I did to troubleshoot: 1. I restored the recent backup file from Prod to UAT and ran DBCC CheckDB again to replicate the error. The same consistency error came back. 2. Ran DBCC CHECKTABLE (MYTABLE) = same consistency error shows:

Table error: Object ID 629577392, index ID 1, partition ID 72057594387039319, alloc unit ID 72057594045596759 (type LOB data). 

The off-row data node at page (1:6009), slot 24, text ID 15754068079 is not referenced.
DBCC results for 'MYTABLE'.
There are 53635 rows in 2705 pages for object "MYTABLE".
CHECKTABLE found 0 allocation errors and 1 consistency errors in table 'MYTABLE' (object ID 629577281).
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKTABLE

3. Then implemented the following steps below: -- step 1 ALTER DATABASE [MYDB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE; -- step 2 DBCC CHECKDB(N'[MYDB]', REPAIR_ALLOW_DATA_LOSS);

Msg 8964, Level 16, State 1, Line 3
Table error: Object ID 629577392, index ID 1, partition ID 72057594387039319, alloc unit ID 72057594045596759 (type LOB data). The off-row data node at page (1:6009), slot 24, text ID 15754068079 is not referenced.
        The error has been repaired.
There are 53635 rows in 2705 pages for object "MYTABLE".

-- step 3 DBCC CHECKDB ('[MYDB]') ---(Re-run to check for any additional errors = no errors reported) -- step 4 ALTER DATABASE [MYDB] SET MULTI_USER; ---(setting it back to multi user mode = users can access the DB) My questions/concerns: 1. How do I know which data has been lost? From my understanding it doesn't seem like any data was lost because before the repair the table had 53635 rows. After the repair it still has 53635 rows. 2. Do we need to to schedule downtime/ outage for that exact site when setting the DB to single user mode? 3. After doing the repair in Production, what are some best practices to keep aware of?

I would like to know the working principle of DBCC regarding the tempdb. I want to know why it uses tempdb for what purpose. I didn't find any advanced article about that so maybe someone can shortly explain or at least share links for the article about that.

We are trying to recover from an event and struggling with some issues that have been created within our database. One of our tables (Users) seems to have gotten corrupted somehow, as we get this message anytime we touch the table:

No catalog entry found for partition ID 72057594068664320 in database 7. 
The metadata is inconsistent. 
Run DBCC CHECKDB to check for a metadata corruption.

We tried to load from an old mdf file but got the same message. Our path forward seems to be to delete the user table and rebuild it with data from our test database. However, I can't drop the table from our live database because I still receive the message above. I ran DBCC CHECKTABLE and got this message:

Could not find an entry for table or index with partition ID 
72057594068664320 in database 8. This error can occur if a stored 
procedure references a dropped table, or metadata is corrupted. 
Drop and re-create the stored procedure, or execute DBCC CHECKDB.

Is there anything I can do to drop the existing table that seems to be corrupted?

I have a database containing an unreasonably large full-text index. DBCC CHECKDB WITH PHYSICAL_ONLY takes about 25 minutes on this database, but DBCC CHECKDB WITH DATA_PURITY, EXTENDED_LOGICAL_CHECKS takes about 2 hours longer. This suggests to me that PHYSICAL_ONLY skips full-text indexes. Am I correct? What parameters need to be passed to CHECKDB to have it check full-text indexes?

DBCC CHECKDB makes many other integrity checks redundant, but I can't see anything in the documentation saying if it makes DBCC CHECKFILEGROUP redundant. Is DBCC CHECKFILEGROUP worthless if you already run DBCC CHECKDB on all databases?

I have been exchanging TDE certificates on various servers to make restores easier - some had the wrong name, the wrong thumbprint, or even both. This involves transferring databases to a temporary cert, dropping old certs, creating the intended cert (from the certificate & key files), and transferring databases to it. This has all gone fine and dandy, except for databases on *one* server. On executing DBCC CHECKDB(SomeDatabase) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY, I receive this:

Msg 33111, Level 16, State 3, Line 106
Cannot find server certificate with thumbprint ''.
Msg 1823, Level 16, State 2, Line 106
A database snapshot cannot be created because it failed to start.
Msg 1823, Level 16, State 8, Line 106
A database snapshot cannot be created because it failed to start.
Msg 7928, Level 16, State 1, Line 106
The database snapshot for online checks could not be created. Either the reason is given in a previous error or one of the underlying volumes does not support sparse files or alternate streams. Attempting to get exclusive access to run checks offline.

If rerun with info messages, it does the expected CHECKDB behavior afterwards, so it appears to get the necessary access for offline. Backups have a similar output. I typically use the SSMS UI for ad hoc backups, which scripts out as this command: BACKUP DATABASE [SomeDatabase] TO DISK = N'some\path\SomeDatabase.bak' WITH DIFFERENTIAL , NOFORMAT, NOINIT, NAME = N'SomeDatabase-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10. This results in:

Msg 33111, Level 16, State 3, Line 108
Cannot find server certificate with thumbprint ''.
Msg 3013, Level 16, State 1, Line 108
BACKUP DATABASE is terminating abnormally.

The same thing happens with full and copy-only backups. Observing the encryption status:

SELECT a.dbid, a.name AS DatabaseName
,b.encryption_state
,CASE b.encryption_state
WHEN 0 THEN 'No database encryption key present, no encryption'
WHEN 1 THEN 'Unencrypted - Encryption enabled, but not turned on'
WHEN 2 THEN 'Encryption in progress'
WHEN 3 THEN 'Encrypted'
WHEN 4 THEN 'Key change in progress'
WHEN 5 THEN 'Decryption in progress'
WHEN 6 THEN 'Protection change in progress (The certificate or asymmetric key that is encrypting the database encryption key is being changed.)'
END AS encryption_state_desc
,percent_complete
,encryptor_type
,key_algorithm
,key_length
,encryptor_thumbprint
,create_date
,regenerate_date
,modify_date
,set_date
,opened_date
FROM master.dbo.sysdatabases a
LEFT JOIN sys.dm_database_encryption_keys b
ON a.dbid = b.database_id
ORDER BY b.encryption_state desc,
DatabaseName;

The failing databases are in state 1 (database encryption key created but encryption not turned on) and show the new TdeCert thumbprint as the encryptor_thumbprint column. There are a few databases that are in state 3 (encrypted), and those will happily back up without the old certificate. If I simply put the certificate back on the server, then CHECKDB/backups will happily execute - no additional commands against the database are required. ### Questions ### * Why is it still trying to use the old certificate? I thought that since the database encryption key was encrypted by the new certificate, there would be no need for the old certificate anymore. * Why does simply putting the old cert back on the server make things work again? I would have expected to have to change something in the database again. * Why isn't there an error when I remove the old certificate if something is using it? * Is there a likely reason that I encountered this behavior on only one server? ### General information ### - Version: Microsoft SQL Server 2019 (RTM-CU27) (KB5037331) - 15.0.4375.4 (X64) ... Standard Edition - TDE is set up with symmetric keys, no external key vaults. - Everything is on-prem, no Azure/cloud factors. - This is a non-prod server; all databases use the SIMPLE recovery model (no transaction logs). - These errors occur in automated jobs as well as statements executed directly in SSMS. Both myself and the account used for jobs have sysadmin on the server. - This is happening on a *single* server. Every other server I have exchanged certificates on (including ones on the same version) has not had this problem, and I cannot replicate this problem on other servers. - The old cert had the same name as the certificate I would like it to use. I wouldn't expect this to matter - it didn't matter to other servers - but given that something seems to be "stuck", it may be relevant. ### Tests ### * Failure: CHECKDB outputs an error message and goes to work offline * Success: No error message, commands execute successfully 1. Fully enable encryption (ALTER DATABASE SomeDatabase SET ENCRYPTION ON) - **failure** 2. Just bring the old cert back, don't alter any databases - **success** 1. But as soon as the old cert is dropped again, it goes back to **failure** 3. Change database encryption key to something else, then run CHECKDB 1. New temporary certificate - **failure** 2. Restoring the desired certificate and changing the DEK to that cert - **success** 3. Transfer back to temporary cert while restored cert is still present - **success** 4. Drop old/restored cert - **failure** 4. Regenerate database encryption key - **failure** 5. Get rid of the new standard TdeCert certificate and rerun the transfer script - still a **failure** 5. Drop the database encryption key, then run CHECKDB - **success** 1. Create a new database encryption key with any cert - **success** ### Related items that didn't solve my problem ### - [This question](https://dba.stackexchange.com/questions/196364/backup-errors-after-tde-certificate-expired-and-new-cert-was-created-with-always) demonstrates something quite similar, but doesn't seem relevant as I am on a different version, several releases after the described fix. - [This Microsoft article](https://support.microsoft.com/en-us/topic/kb4052134-fix-errors-33111-and-3013-when-backing-up-tde-encrypted-database-in-sql-server-551fd963-1ed2-ba49-30aa-a017e29b7d98) describing an error where "Cannot find server certificate" occurred when specifying COMPRESSION and MAXTRANSFERSIZE options. The backup command I am using does not specify these options, and the described issue was resolved in older versions. - There are many questions and articles out there about encountering "Cannot find server certificate" when attempting a restore, none of which appear relevant as I am not doing a restore.

Create the simplest database possible: CREATE DATABASE DatabaseCheck Add this database to an Availability Group, where secondary is not readable On primary run: DBCC CHECKDB ('DatabaseCheck') WITH EXTENDED_LOGICAL_CHECKS It succeeds: > CHECKDB found 0 allocation errors and 0 consistency errors in database > 'DatabaseCheck'. DBCC execution completed. If DBCC printed error > messages, contact your system administrator. Run the same DBCC command on secondary. It fails even though no errors were found: > CHECKDB found 0 allocation errors and 0 consistency errors in database > 'DatabaseCheck'. Msg 0, Level 11, State 0, Line 1 A severe error > occurred on the current command. The results, if any, should be > discarded. - Removing WITH EXTENDED_LOGICAL_CHECKS makes the error go away - Making the secondary replica readable makes the error go away - Doing a failover and checking the new primary makes the error go away. Checking the new secondary shows the error again. Any idea what is this about? Checking DBCC CHECKDB documentation doesn't say anything about EXTENDED_LOGICAL_CHECKS being unsupported on non-readable secondary replica. Looks like a bug in the command itself to me. One thing I noticed in the command output is that it checks statistics like here: > Verified integrity of statistics 'sys.sysrscols.clst'. Verified > integrity of statistics 'sys.sysrowsets.clust'. Verified integrity of > statistics 'sys.sysrowsets._WA_Sys_00000002_00000005'. Verified > integrity of statistics 'sys.sysrowsets._WA_Sys_00000003_00000005'. > Verified integrity of statistics > 'sys.sysrowsets._WA_Sys_00000006_00000005'. Verified integrity of > statistics 'sys.sysrowsets._WA_Sys_00000004_00000005'. Verified > integrity of statistics 'sys.sysrowsets._WA_Sys_00000005_00000005'. > Verified integrity of statistics > 'sys.sysrowsets._WA_Sys_00000008_00000005'. These are absent when run on secondary Reproduced on: > Microsoft SQL Server 2019 (RTM-CU23) (KB5030333) - 15.0.4335.1 (X64) > Sep 21 2023 17:28:44 Copyright (C) 2019 Microsoft Corporation > Developer Edition (64-bit) on Windows Server 2019 Standard 10.0 > (Build 17763: ) **Edit:** The only message in error log is this: > DBCC CHECKDB (DatabaseCheck) executed by Domain\user found 0 errors > and repaired 0 errors. Elapsed time: 0 hours 0 minutes 0 seconds. > Internal database snapshot has split point LSN = > 00000034:000001b1:0001 and first LSN = 00000034:000001af:0002. There are no recent dumps in sys.dm_server_memory_dumps

First what I do is to check consistency of database in SQL Server 2012: CHECKDB (DATABASE1) And it is ok, no errors and warnings. Next I do FULL backup and restore it on another machine with has SQL Server 2014 using SQL Server Management Studio with WITH REPLACE option. However after I run CHECKDB (DATABASE1) I receive consistency errors messages: Msg 8939, Level 16, State 98, Line 1 Table error: Object ID 293576084, index ID 67, partition ID 72057594074628096, alloc unit ID 72057594126598144 (type In-row data), page (1:5589561). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 133129 and -4. Msg 8928, Level 16, State 1, Line 1 Object ID 293576084, index ID 67, partition ID 72057594074628096, alloc unit ID 72057594126598144 (type In-row data): Page (1:5589561) could not be processed. See other errors for details. Msg 8976, Level 16, State 1, Line 1 Table error: Object ID 293576084, index ID 67, partition ID 72057594074628096, alloc unit ID 72057594126598144 (type In-row data). Page (1:5589561) was not seen in the scan although its parent (1:5580238) and previous (1:5589560) refer to it. Check any previous errors. Msg 8978, Level 16, State 1, Line 1 Table error: Object ID 293576084, index ID 67, partition ID 72057594074628096, alloc unit ID 72057594126598144 (type In-row data). Page (1:5589562) is missing a reference from previous page (1:5589561). Possible chain linkage problem. Msg 8939, Level 16, State 98, Line 1 Table error: Object ID 293576084, index ID 1, partition ID 72057594073645056, alloc unit ID 72057594125615104 (type In-row data), page (1:21142097). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 133129 and -4. Msg 8928, Level 16, State 1, Line 1 Object ID 293576084, index ID 1, partition ID 72057594073645056, alloc unit ID 72057594125615104 (type In-row data): Page (1:21142097) could not be processed. See other errors for details. Msg 8976, Level 16, State 1, Line 1 Table error: Object ID 293576084, index ID 1, partition ID 72057594073645056, alloc unit ID 72057594125615104 (type In-row data). Page (1:21142097) was not seen in the scan although its parent (1:21112030) and previous (1:21142096) refer to it. Check any previous errors. Msg 8978, Level 16, State 1, Line 1 Table error: Object ID 293576084, index ID 1, partition ID 72057594073645056, alloc unit ID 72057594125615104 (type In-row data). Page (1:21142098) is missing a reference from previous page (1:21142097). Possible chain linkage problem. CHECKDB found 0 allocation errors and 8 consistency errors in table 'TABLE1' (object ID 293576084). CHECKDB found 0 allocation errors and 8 consistency errors in database 'DATABASE1'. repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (DATABASE1). Am I doing something wrong with backup restoration?

I have created an SSIS package to run DBCC CHECKDB on all the databases on the server and send error messages by email. But for several of the databases, I get an exception running my script: > Timeout expired. > The timeout period elapsed prior to completion of the operation or the server is not responding. The only timeout I can find in the project/package is set to 0, which I presume means no timeout. DBCC CHECKDB runs from SSMS just fine.