Update intelligent-query-processing-cardinality-estimation-feedback.md

Author: thesqlsith

docs/relational-databases/performance/intelligent-query-processing-cardinality-estimation-feedback.md

@@ -150,17 +150,18 @@ This feature was introduced in [!INCLUDE [ssSQL22](../../includes/sssql22-md.md)
 
 | Issue | Date discovered | Status | Date resolved |
 | --- | --- | --- | --- |
-| Slow SQL Server performance after you apply Cumulative Update 8 for [!INCLUDE [sssql22-md](../../includes/sssql22-md.md)] under certain conditions. You might encounter dramatic Plan Cache memory utilization along with unexpected increases in CPU utilization when CE Feedback is enabled. | December 2023 | Has [workaround](#slow-sql-server-performance-after-you-apply-cumulative-update-8-for-sql-server-2022-under-certain-conditions) | |
+| Slow SQL Server performance after you apply Cumulative Update 8 for [!INCLUDE [sssql22-md](../../includes/sssql22-md.md)] under certain conditions. You might encounter dramatic Plan Cache memory utilization along with unexpected increases in CPU utilization when CE feedback is enabled. | December 2023 | Has [workaround](#slow-sql-server-performance-after-you-apply-cumulative-update-8-for-sql-server-2022-under-certain-conditions) | |
 
 ### Known issues details
 
 #### Slow SQL Server performance after you apply Cumulative Update 8 for SQL Server 2022 under certain conditions
 
 Starting with [!INCLUDE[sssql22-md](../../includes/sssql22-md.md)] Cumulative Update 8, SQL Server might exhibit unexpected increases in CPU and memory utilization. Additionally, an increase in RESOURCE_SEMAPHORE_QUERY_COMPILE waits may also be observed. You might also notice steady increases in the number of Plan Cache objects in use that approach the Plan Cache limits and manually clearing the Plan Cache with techniques like `ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE`, `DBCC FREESYSTEMCACHE`, or `DBCC FREEPROCCACHE` do not provide assistance. This behavior has only been observed by a small number of customers.
 
-This issue does not affect all workloads, and depends on the number of different plans that have been generated as well as the number of plans that were eligible for the CE Feedback feature to engage. During the period of time that CE Feedback is analyzing plan operators where significant model misestimations occurred, there is a scenario in which during this analysis phase, a plan that was being referenced can become dereferenced in memory without allowing the plan to subsequently be removed from memory by way of the normal Least Recently Used (LRU) algorithm. The LRU mechanism one way that SQL Server enforces plan eviction policies. SQL Server will also remove plans from memory if the system is under memory pressure. When SQL Server attempts to remove the plans that have been dereferenced improperly, it is unable to remove those plans from the plan cache, which causes the cache to continue to grow. The growing cache might start to cause additional compilations that will ultimately use more CPU and memory. For more information, see [Plan Cache Internals](/previous-versions/tn-archive/cc293624(v=technet.10)).
+This issue does not affect all workloads, and depends on the number of different plans that have been generated as well as the number of plans that were eligible for the CE feedback feature to engage. During the period of time that CE feedback is analyzing plan operators where significant model misestimations occurred, there is a scenario in which during this analysis phase, a plan that was being referenced can become dereferenced in memory without allowing the plan to subsequently be removed from memory by way of the normal Least Recently Used (LRU) algorithm. The LRU mechanism one way that SQL Server enforces plan eviction policies. SQL Server will also remove plans from memory if the system is under memory pressure. When SQL Server attempts to remove the plans that have been dereferenced improperly, it is unable to remove those plans from the plan cache, which causes the cache to continue to grow. The growing cache might start to cause additional compilations that will ultimately use more CPU and memory. For more information, see [Plan Cache Internals](/previous-versions/tn-archive/cc293624(v=technet.10)).
+
+**Symptom**: The number of plan cache **entries in use** and are marked as **dirty** from either SQL Plans or Object Plans increases over time to 50,000 or more. If you observe plan cache entries that start to approach this level along with unexpected increases in CPU utilization, your system may be encountering this issue. A related fix was provided in [!INCLUDE[sssql22-md](../../includes/sssql22-md.md)] Cumulative Update 9. See [KB5030731](https://learn.microsoft.com/troubleshoot/sql/releases/sqlserver-2022/cumulativeupdate9#2499342). The fix attempted to address an issue in which plan cache entries are evicted when the Cardinality Estimation (CE) feedback tries to get the associated profile, which causes a memory corruption. Additional fixes for this issue will be available in an upcomming Cumulative Update.
 
-**Symptom**: The number of plan cache **entries in use** and are marked as **dirty** from either SQL Plans or Object Plans increases over time to 50,000 or more. If you observe plan cache entries that start to approach this level along with unexpected increases in CPU utilization, your system may be encountering this issue. There was a related to a fix that was provided in [!INCLUDE[sssql22-md](../../includes/sssql22-md.md)] Cumulative Update 9. See [KB5030731](https://learn.microsoft.com/troubleshoot/sql/releases/sqlserver-2022/cumulativeupdate9#2499342). The fix attempted to address an issue in which plan cache entries are evicted when the Cardinality Estimation (CE) feedback tries to get the associated profile, which causes a memory corruption. Additional fixes for this issue will be available in an upcomming Cumulative Update.
 To monitor the number of plan cache entries that your system is using, the following examples can be used as a point in time view of the number of plan cache entries that exist. As an example, watching the number of plan cache entries that are marked as dirty, periodically over time is one way to monitor for this phenomenon.
 
 ```sql