SQL 2016 SP3 CHECKDB WITH EXTENDED_LOGICAL_CHECKS problem.

• Ken McKelvey

  SSCoach

  Points: 18890

  More actions

  September 19, 2021 at 12:58 pm

  #3930955

  This seems to be the same problem which occurred with SQL2017 CU21 and is now fixed:

  https://www.sqlservercentral.com/forums/topic/sql2017-cu21-checkdb-with-extended_logical_checks

  This problem is consistent with msdb. When I run:

  DBCC CHECKDB ([msdb]) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY, EXTENDED_LOGICAL_CHECKS;
  PRINT @@ERROR;

  error 2706 is always returned even though no errors are reported.

  If EXTENDED_LOGICAL_CHECKS is removed CHECKDB runs fine.

  Like the SQL2017 CU21 problem I suspect there is nothing actually wrong with msdb. ie This would not stop me from applying SP3 to production.

   

  • This topic was modified 3 years, 6 months ago by  Ken McKelvey.
  • This topic was modified 3 years, 6 months ago by  Ken McKelvey.
  • This topic was modified 3 years, 6 months ago by  Ken McKelvey.

• sterling3721

  SSChasing Mays

  Points: 658

  More actions

  September 19, 2021 at 6:37 pm

  #3930980

  I got the same on SQL 2019 with latest CU12.

  DBCC CHECKDB ([msdb]) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY;

  PRINT @@ERROR;

  -- result: 0

  DBCC CHECKDB ([msdb]) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY, EXTENDED_LOGICAL_CHECKS;

  PRINT @@ERROR;

  -- result: 2706

  • This reply was modified 3 years, 6 months ago by  sterling3721.

• Ken McKelvey

  SSCoach

  Points: 18890

  More actions

  September 20, 2021 at 9:41 am

  #3931082

  You are right. I missed it because our two SQL2019 servers were created after I had spotted the problem in SQL2017 so used the test restore routine which ignored error 2706.

  I have also noticed that the error is there again in SQL2017 CU26.