Msg 8622: Query processor could not produce a query plan for SQLServerCEIP

The Analysis

After an extended event setup of the error_reported event, I’ve been getting an error from time to time regarding the SQLServerCEIP application. This application collects anonymized usage and diagnostics data “telemetry” from Microsoft SQL Server and sends it back to Microsoft to help improve future versions of the product.

I’ve been curious why we are getting this error.

Msg 8622, Level 16, State 1, Line 9 Query processor could not produce a query plan because of the hints defined in this query. Resubmit the query without specifying any hints and without using SET FORCEPLAN.

From the error, I thought it was due to some forced plan that I was not aware of from Query Store , a plan guide or a session level SET FORCEPLAN. After a few hours, I remembered the database level FORCED PARAMETERIZATION setting. That’s it! The database has FORCED PARAMETERIZATION enabled.

The Bug

In the background, SQLCEIP is executing this query:

/* SQLServerCEIP query */
SELECT database_id = DB_ID(),
       [percent_open_deltastore] = ISNULL(
                                       AVG(100 * ((cs2.open_deltastore_count * 1.0)
                                              / ((CASE
                                                      WHEN cs1.total_row_group_count = 0 THEN 1
                                                      ELSE cs1.total_row_group_count
                                                  END) * 1.0))),
                                       0)
FROM (SELECT object_id,
             index_id,
             [total_row_group_count] = COUNT_BIG(*)
      FROM sys.column_store_row_groups
      GROUP BY object_id,index_id) AS cs1
    JOIN (SELECT object_id,
                 index_id,
                 [open_deltastore_count] = COUNT_BIG(*),
                 [avg_rows_in_deltastore] = AVG(total_rows)
          FROM sys.column_store_row_groups
          WHERE state = 1
          GROUP BY object_id,index_id) AS cs2
        ON cs1.object_id = cs2.object_id AND cs1.index_id = cs2.index_id;

The culprit was this query:

SELECT * FROM sys.column_store_row_groups WHERE state = 1;

If you execute the query above on a database with FORCED PARAMETERIZATION enabled, you will get the 8622 error.

Sample Script to Reproduce the Bug

You can easily reproduce this behavior with the following script:

/* create a test database */
CREATE DATABASE [TEST]
GO
/* enable forced parameterization */
ALTER DATABASE [TEST] SET PARAMETERIZATION FORCED WITH NO_WAIT
GO
/* execute the dmv */
USE [TEST]
GO

SELECT * FROM sys.column_store_row_groups WHERE state = 1;
GO
/* cleanup */
USE [master]
GO
DROP DATABASE [TEST]
GO

The sys.column_store_row_groups DMV is used specifically to check columnstore index health. I remember a few years back Bart Duncan from Microsoft posted about the problem. However, his sample query included an explicit index hint to reproduce the error. For this scenario, there is no index hint in the SQLCEIP query, which suggests this could be a Microsoft bug in how the telemetry interacts with the forced parameterization.

As of this writing, I was able to reproduce the error on SQL Server 2019 CU32 build 15.0.4455.2 and SQL Server 2025 CU2 build 17.0.4015.4.

Summary

This is another reason why you should avoid enabling FORCED PARAMETERIZATION at the database level because you don’t know how it will impact the entire workload and can lead to poor performance as documented by Microsoft. If you have an isolated query that needs to be forced, apply it to that specific query alone and not at the database level.

if you have columnstore indexes with database that has FORCED PARAMETERIZATION enabled and need to check row group states without triggering this error, try using negation comparison as a workaround. Instead of WHERE state = 1, use WHERE state NOT IN (0,2,3,4) can sometimes skip the 8622 error if you want to check the open row group.

Microsoft need to fix this bug or just simply use simple parameterization (the default) to skip the SQLCEIP 8622 error.

Dan Co

SQL Server Specialist.