我们有一台 256 GB RAM 的机器。
SQL Server 的最大服务器内存设置为 180 GB。
在 180 GB 中，SQL Server 通常使用：
- 数据库缓存内存 - ~ 140-150 GB
- 计划缓存 - ~ 10 GB
- 被盗服务器内存：~ 30 GB
- 可用内存：~ 9 GB
- 授予的工作区内存：这通常很低，峰值可以是 0.5-1 GB
缓冲区缓存命中率 - 一直徘徊在 99.9% 以上。
页面预期寿命是相当高的数字。
数据库数据文件的总大小 - 650 GB。
数据增长率约为每天 500-1500 MB（但是！旧数据每 6-8 个月被删除一次，所以基本上数据文件的增长速度要慢得多）。
问题
需要将 SQL Server 迁移到另一台计算机。面向 SQL Server 2022 推出时。
它是混合 OLTP 和 OLAP 类型的工作负载，许多应用程序使用相同的数据库；大部分 RAM 被缓存的数据库页面使用，这意味着 SQL Server 不必一直从磁盘读取它。
感觉新机器 128 GB 就足够了，最大服务器内存设置为 ~ 110 GB，为操作系统留下 18-13 GB。
目标服务器将位于 Azure VM 中，您无法在其中独立扩展 vCPU 和 RAM。与 128 GB 机器相比，具有 256 GB RAM 的机器具有两倍的内核数，从而导致相当大的成本差异。我认为与最初预计的相比降低成本，从长远来看可能对我有好处，所以我认为值得探索。在 Azure 中，您可以根据需要随时进行扩展。
如果你是我，你将如何科学地向你的经理证明，将内存减半不会降低 SQL Server 的性能，不会破坏缓冲区缓存命中率或类似的东西？
我知道对于 DBA，考虑到工作负载不会改变，将这台机器缩小到 128 GB 看起来很安全。但是，根据您的经验，您将如何说服经理呢？
这是一个很难回答/证明的问题，如果您不知道比提供的工作量更多的信息。
但是，我认为在提交到较小的服务器之前进行检查的一种简单方法是更改当前生产实例上的 Max Memory 设置并查看性能情况。
您所描述的一切似乎都不像一个展示停止器，它可以在较低的内存（只是更多的磁盘活动）下正常运行，或者它可能会崩溃和烧毁。（或者只是在运行月度报告时崩溃和燃烧，很难说）。
如果我面临这个项目，我会让企业购买这个计划，然后更改 Max Memory 设置，看看会发生什么。可能会减少一定数量，然后再继续观望。像鹰一样观察它，准备好在需要时将数字向上移动，但它是在线操作并且可以快速更改。