如果我使用ntext、text或image数据类型对表进行分区并使用 重建单个分区上的索引online = off，这会锁定整个表还是仅锁定有问题的分区？

我有 3 个“大”表，它们连接在一对列上（都是ints）。

• 表 1 有大约 2 亿行
• 表 2 有大约 150 万行
• 表 3 有约 600 万行

每个表在Key1、上都有一个聚集索引Key2，然后还有一个列。Key1具有低基数并且非常偏斜。它总是在WHERE子句中被引用。条款中Key2从未提及WHERE。每个连接都是多对多的。

问题在于基数估计。每个连接的输出估计变小而不是变大。当实际结果达到数百万时，这导致最终估计值低至数百。

我有什么办法可以让 CE 做出更好的估计吗？

SELECT 1
FROM Table1 t1
     JOIN Table2 t2
       ON t1.Key1 = t2.Key1
          AND t1.Key2 = t2.Key2
     JOIN Table3 t3
       ON t1.Key1 = t3.Key1
          AND t1.Key2 = t3.Key2
WHERE t1.Key1 = 1;

我尝试过的解决方案：

• 在 上创建多列统计信息Key1，Key2
• 创建大量 …

对 SQL 系统数据库（master、model、msdb、tempdb）的查询存储只能在 msdb 上使用。我查看并没有在 msdb 上找到任何有关查询存储的文档。

虽然您无法在 GUI 中看到它，但可以在您的 SQL 2016 实例上对其进行验证

验证查询存储已关闭

USE msdb
SELECT * FROM sys.database_query_store_options; 

打开查询存储

USE [master]
GO
ALTER DATABASE msdb SET QUERY_STORE = ON
GO
ALTER DATABASE msdb SET QUERY_STORE (OPERATION_MODE = READ_WRITE
, INTERVAL_LENGTH_MINUTES = 30
, MAX_STORAGE_SIZE_MB = 1000
, QUERY_CAPTURE_MODE = AUTO)
GO

验证查询存储已开启

USE msdb
SELECT * FROM sys.database_query_store_options; 

在所有系统数据库中，为什么 msdb 是唯一一个可以选择使用查询存储的数据库，它增加了什么价值？

-- Stop Query Store
USE [master]
GO
ALTER DATABASE msdb SET QUERY_STORE = OFF
GO

我在我的数据库中使用时态表，当我在 Management Studio 2017 (v17.4 14.0.17213.0) 中右键单击我的表时，我没有在上下文菜单中看到选择前 1000 行（非时态表没有问题)

任何想法如何让这个上下文菜单回来？我感觉这与我运行的 SQL Server 版本有关（SQL 13.1.4001.0 Express Edition）

我有：

• 包含现有数据的表格
• SQL Server 2016 SP1
• SQL Server 管理工作室 17.5

我正在使用以下语句使我的表成为临时表：

ALTER TABLE [dbo].[AnalysisCustomRollupsV2JoinGroups]
ADD [SysStartTime] DATETIME2(0) GENERATED ALWAYS AS ROW START HIDDEN CONSTRAINT DF_AnalysisCustomRollupsV2JoinGroups_SysStart DEFAULT GETUTCDATE()  
   ,[SysEndTime] DATETIME2(0) GENERATED ALWAYS AS ROW END HIDDEN CONSTRAINT DF_AnalysisCustomRollupsV2JoinGroups_SysEnd DEFAULT CONVERT(DATETIME2(0), '9999-12-31 23:59:59'),   
PERIOD FOR SYSTEM_TIME ([SysStartTime], [SysEndTime]); 

ALTER TABLE [dbo].[AnalysisCustomRollupsV2JoinGroups]   
SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.AnalysisCustomRollupsV2JoinGroupsChanges));

问题：

在我的本地 SQL 实例上，我有很多数据库；查询在其中一些上成功运行非常奇怪，而在其中一些上它给了我以下错误：

消息 13542，级别 16，状态 0，第 51 行 ADD PERIOD FOR SYSTEM_TIME 在表 'dbo.AnalysisCustomRollupsV2JoinGroups' 上失败，因为有打开的记录，期间的开始时间设置为将来的某个值。

有时，当我调试/执行查询时，初始查询运行成功。

我读到，这可能是因为我在表中有现有数据。所以，我改变了这样的逻辑：

• 创建缓冲表并用所有记录填充它
• 删除原表中的记录
• 创建时态表
• 将记录移回并删除缓冲表

再说一次，在某些数据库上它是可以的，而在其他数据库上则不是。试图解决这个问题，我 …

我无法理解Ola Hallengren 服务器维护解决方案中的CleanupTime选项的确切期望。我正在寻找一些相关的问题和详尽的答案，但这些解释仍然让我有些困惑。

具体来说：

我正在做每周完整备份、每日 DIFF 备份和每小时日志备份。完整备份使用默认值CleanupTime24 小时。DIFF 和 LOG 备份的 NULL 为CleanupTime。

从CleanupTime 参数的文档中，我无法理解是否设置FULLCleanupTime备份的设置BackupType也会删除旧的 DIFF 和 LOG 备份文件，或仅删除FULL 备份文件。

指定删除备份文件之前的时间（以小时为单位）。如果未指定时间，则不会删除任何备份文件。

后一段让我认为设置FULLCleanupTime备份BackupType也会删除旧的事务日志。然而，不清楚这一段是只适用于BackupTypeLOG的备份，还是也适用于BackupTypeFULL的备份。

DatabaseBackup 有一个检查来验证比最近的完整或差异备份更新的事务日志备份没有被删除。

我想要实现的是，我可以进行长达 1 周的时间点恢复。（我们有一个非常缓慢变化的数据库，所以这是可行的）按照我现在的理解，这需要一周的完整备份，以及一周的事务日志备份。由于完整备份和差异备份只能用于恢复到一个特定的时间点。

那么，我应该将CleanupTime完整备份作业的选项设置为24*7吗？我现在猜测的是，将其设置为 24 小时，将导致下一次完整备份删除所有较旧的完整、差异和事务日志备份文件，从而使我的时间点恢复窗口为 ... 0 小时。对？

我最近将我们的 2016 SQL Server 更新到 SP2 和 2018 年 8 月发布的最新 CU (KB4458621)。就在最后一天左右，我注意到我有一些阻塞。我无法杀死 SPID b/c，它不是用户进程。根据 SP_WHO2，命令是“Query Store ASYN”。我尝试通过脚本和 UI 清除数据并禁用查询存储。似乎没有任何效果，它只是旋转，然后开始造成更多阻塞。还有其他人有这个问题吗？谁能帮我弄清楚如何成功禁用查询存储？SP_WhoIsActive @show_System_SPIDS = 1 个结果如下（仅查询存储结果）

更新 - 这现在导致 TempDB 驱动器填满。几个小时后尝试重新启动，看看是否能解决问题。将及时向大家发布。

谢谢，内特

我有一个由四个聚集列存储索引表 (CCI) 和九个行存储表组成的数据仓库。这些表仅用于分析，并且每 15 分钟从临时表中插入 CCI 数据。我希望通过添加分区和排序来优化查询性能。

该数据的所有查询都基于一个包含大约 350 个不同值的整数字段。最左边的 CCI 有 100M 条记录和 125 列。有三个子 CCI 具有相同的整数字段。CCI 2 有 1500 万条记录和 150 列，CCI 3 和 4 都有大约 3000 万条记录和 25 列。

在这 350 个不同的整数中，最左边表中的记录数分布如下：

• 5% 大于 1M
• 46% 大于 100K
• 83% 大于 10K

此外，还有其他九个行存储表也连接到 CCI。它们具有涓流插入，是 CCI 的子项，它们都包含相同的整数字段。这些行存储具有相似或更小的记录量，每个 < 10 列，两个包含 LOBS，两个经常进行大规模更新（这些更新也基于 ID 字段）。

我应该做多少个分区？

我还应该对行存储表进行分区吗？

是否有我忽略的重要考虑因素？

关于我之前提到的“排序”的注意事项：

最左边的 CCI 中的日期字段通常是这些查询中的次要谓词，因此我正在考虑每四个星期左右按日期重新排序 CCI 作为维护。我将通过删除 CCI、在日期上添加聚集行存储索引、删除该索引，然后使用 MAXDOP=1 重新添加 CCI 来实现这种排序。我也在考虑通过其父级的连接键对子 CCI 进行排序。

TL; 博士

我想将SQL Server 2014 Analysis Services添加到SQL Server的特定实例并以这样的方式对其进行配置，即 Analysis Services (SSAS) 和未来的 Reporting Services (SSRS) 将仅接收对特定实例的请求IP，为了让SQL Server Browser 服务保持在停止状态。

先决条件

对于运行多个 SQL Server 2014 实例的单个 Windows Server，我有以下先决条件：

基本信息

- 2 x 网卡
- 12 个 IP 地址
- 10 个 SQL Server Server 服务实例（正在运行）
- 10 个 SQL Server 代理服务器服务实例（正在运行）
- 1 x SQL Server 浏览器服务（未运行）

网卡配置

Windows Server NIC 的配置如下：

- 1 x NIC（备份网络） 
    - 10.2.0.1 
- 1 x 网卡 (LAN) …

我们有一个最大内存设置为 24GB 的 SQL Server 2016 SP1。
该服务器有大量编译，这些编译中只有 10% 来自 Ad-Hoc 查询。所以新编译的计划应该存储在计划缓存中，但计划缓存的大小没有增加（大约 3.72GB）。

我怀疑存在导致从缓存中删除计划的本地内存压力。计划缓存压力限制为 5GB。（0-4GB 可见目标内存的 75% + 4GB-64GB 可见目标内存的 10% + 可见目标内存的 5%>64GB）。当缓存存储达到压力限制的 75% 时，应从缓存中删除计划。就我而言，5 GB 的 75% 是 3.75 GB。因此，这可能是高编译的原因。

有没有办法测量（性能，扩展事件，...）从缓存中删除计划？所以我可以确定本地内存压力真的是高编译的原因吗？