July 20, 2020 at 11:57 am
I have a problem running CHECKDB WITH EXTENDED_LOGICAL_CHECKS using dynamic SQL since upgrading SQL2017 standard edition to CU21.
The problem occurs with msdb on all seven instances and on two out of 63 user databases. The problem does not occur with CU20.
If I run the following static SQL from SSMS:
DBCC CHECKDB ([msdb]) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY, EXTENDED_LOGICAL_CHECKS;
I just get:
Commands completed successfully.
If I run the following dynamic SQL:
DECLARE @SQL nvarchar(MAX)
,@RetVal int;
SET @SQL = 'DBCC CHECKDB ([msdb]) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY, EXTENDED_LOGICAL_CHECKS;'
EXEC @RetVal = sp_executesql @SQL;
IF @RetVal <> 0
PRINT 'Database [msdb] failed to CheckDB with return value of ' + CAST(@RetVal AS varchar(20)) + '.';
I get:
Database [msdb] failed to CheckDB with return value of 2706.
If I remove NO_INFOMSGS, in the dynamic SQL, I get all the information with the following at the end:
CHECKDB found 0 allocation errors and 0 consistency errors in database 'msdb'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
followed by:
Database [msdb] failed to CheckDB with return value of 2706.
I get similar results using Ola Hallengren's DatabaseIntegrityCheck:
EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'msdb', @ExtendedLogicalChecks = 'N';
gives an outcome of Succeeded while:
EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'msdb', @ExtendedLogicalChecks = 'Y';
gives an outcome of failed.
Does this just look like a bug in CU21? If it is a bug, what is the best way to report it?
July 21, 2020 at 12:10 pm
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
July 21, 2020 at 4:16 pm
Is that the only output? Isn't there something from DBCC besides what you are returning?
July 22, 2020 at 7:48 am
There are no error messages. If I just run:
DECLARE @SQL nvarchar(MAX)
,@RetVal int;
SET @SQL = 'DBCC CHECKDB ([msdb]) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY, EXTENDED_LOGICAL_CHECKS;'
EXEC @RetVal = sp_executesql @SQL;
then I just get:- Commands completed successfully.
If I remove NO_INFOMSGS there are no allocation or consistency errors. Also there are no problems if I remove EXTENDED_LOGICAL_CHECKS.
I only use EXTENDED_LOGICAL_CHECKS as part of my weekly routine as I have some databases which I do not know a great deal about.
I have just decided to ignore the 2706 return values as DATA_PURITY is fine, there are no error messages and it seems unlikely that installing CU21 alone would corrupt msdb.
When I tried to report this to Microsoft it looked as though money is required for support. As the university requires a few committees to pay for anything I gave up.
Thanks for your help.
July 22, 2020 at 1:52 pm
I'll post a note to Microsoft and see if I can get a response.
July 22, 2020 at 4:38 pm
Thanks.
Incidentally I just tried running the following:
DBCC CHECKDB ([msdb]) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY, EXTENDED_LOGICAL_CHECKS;
PRINT @@ERROR;
which gave a result of 2706.
ie When EXTEND_LOGICAL_CHECKS are included in CHECKDB then error 2706 is returned even thought no errors are reported.
July 22, 2020 at 5:18 pm
Thanks. Posted in the MVP list. Hopefully someone responds.
September 11, 2020 at 6:29 pm
If anyone else is affected by this, it still occurs with SQL2017 CU22 on a test VM.
September 16, 2020 at 1:58 am
I'm having this same problem on CU21.
But only on our production server. All of our test servers are running the same CU21 and are not having this issue. For us it is the MSDB database, and one of our user databases only.
December 2, 2020 at 1:20 pm
We are also still having the issue, with CU 22 and it is also only happening on our production server as well.
Has there been any progress with Microsoft on this?
December 2, 2020 at 1:32 pm
I bumped my post. I had one response where someone was using this with AGs and hadn't had this error.
December 2, 2020 at 3:14 pm
I am still getting the error mainly on msdb. As I do not think anything is actually wrong I am ignoring it.
We use standard edition on Windows 2016 with VMWare.
April 15, 2021 at 8:50 am
SQL SERVER 2019 CU9
dbcc checkdb(N'msdb') with all_errormsgs, extended_logical_checks;
I caught the error, it appears twice with this message "Table 'fn_available_backups' does not exist."
Two objects - two messages
It turns out that dbcc does not always correctly understand whether an object is a table or not.
I caught the same errors on other databases, where table types were the culprit
April 20, 2021 at 3:34 am
This was removed by the editor as SPAM
November 13, 2021 at 9:51 am
Same for SQL Server 2019 CU13. Ola's script still reports the error for msdb:
Messages from the script:
Date and time: 2021-11-13 11:15:49
Database: [msdb]
State: ONLINE
Standby: No
Updateability: READ_WRITE
User access: MULTI_USER
Recovery model: SIMPLE
Is accessible: Yes
Date and time: 2021-11-13 11:15:49
Database context: [master]
Command: DBCC CHECKDB ([msdb]) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY, EXTENDED_LOGICAL_CHECKS
Outcome: Failed
Duration: 00:00:01
Date and time: 2021-11-13 11:15:50
However, I could not find any noticeable output in the results of DBCC CHECKDB:
DBCC CHECKDB ([msdb]) WITH ALL_ERRORMSGS, DATA_PURITY, EXTENDED_LOGICAL_CHECKS;
Regards,
Dex
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply