小编Low*_*n M的帖子

从其他编程语言转向 SQL，递归查询的结构看起来很奇怪。一步步走过来，仿佛分崩离析。

考虑以下简单示例：

CREATE TABLE #NUMS
(N BIGINT);

INSERT INTO #NUMS
VALUES (3), (5), (7);

WITH R AS
(
    SELECT N FROM #NUMS
    UNION ALL
    SELECT N*N AS N FROM R WHERE N*N < 10000000
)
SELECT N FROM R ORDER BY N;

让我们来看看吧。

首先，执行锚成员并将结果集放入 R。因此 R 被初始化为 {3, 5, 7}。

然后，执行低于 UNION ALL 并且第一次执行递归成员。它在 R 上执行（即，在我们目前手头的 R 上：{3, 5, 7}）。这导致 {9, 25, 49}。

这个新结果有什么用？它是否将 {9, 25, 49} 附加到现有的 {3, 5, 7}，标记结果联合 R，然后从那里继续递归？或者它是否将 R 重新定义为这个新结果 {9, 25, 49} 并在以后进行所有联合？

两种选择都没有意义。 …

所以我最近在一家新公司开始工作，有很多 ArcGIS 用户似乎非常热衷于使用 PostGIS 实例为我们的客户提供一些数据。虽然我对此没有意见，但我们是 95% 的 SQL Server 和 5% 的 Oracle 商店。我们当前的内部 GIS 运行在 SQL Server 上，我还没有听到任何抱怨。

我知道 SQL Server 截至 2012 年有很多改进的空间/几何功能，但是 PostGIS 中是否有任何值得进入新平台的杀手级功能？我试图研究它，但找不到任何真正深入的东西，或者这不完全是偏见。

我想给他们最好的工具来完成他们的工作，但也必须权衡一个事实，即我将从一开始就学习 Postgres/GIS，这本身就是一个完整的旅程。

我有一个包含数百万行的表，我需要不时从中运行一些查询。第一个查询通常会很慢（大约 10 秒），随后的查询通常会更快（大约 1 秒）。几个小时后，一个缓慢/然后快速的循环再次开始。

我已经在我的执行计划中检查了所有需要的索引都存在并得到了适当的使用，我认为性能差异是由于索引实际上在内存中用于后续查询（我是对的，还是有其他可能的原因？）

我还使用索引运行了许多其他查询，但这些查询耗时较少，性能也不那么重要，所以我担心这些索引实际上是将我的关键索引从内存缓存中推出。

除了明显的“添加更多 RAM”修复之外，我一直在考虑编写虚拟查询脚本，使其每小时运行一次，以强制索引返回内存。

有没有更优雅的方法来做到这一点？就像暗示 SQLServer 的一种方式，如果它只有足够的内存来保持一个索引缓存，它应该是那个？

我知道通常最好的办法是不要在这类事情上搞砸 SQLServer，但是我的查询的不寻常性质（很少运行，但对时间要求严格）让我相信它是有意义的（如果可能的话） .

我也很想知道是否有办法知道在给定时间哪些索引缓存在内存中？

在 SQL 2014 版服务器（12.0.2430.0 - 还没有 SP1）中，数据库处于 2012 兼容模式（正在努力将其切换到 2014...）我有一些外键对象，它们始终标记为not trusted在数据库中. 我在没有NOCHECK选项的情况下删除并重新创建了它们，但在 5-10 分钟内它们再次变得不受信任，如果我生成一个CREATE脚本，它会显示为：

ALTER TABLE [dbo].[Points]  WITH NOCHECK 
ADD  CONSTRAINT [FK_BadgeId] FOREIGN KEY([BadgeId])
REFERENCES [dbo].[Badge] ([Id])
GO

正在使用的创建脚本是：

ALTER TABLE [dbo].[Points]
ADD  CONSTRAINT [FK_BadgeId] FOREIGN KEY([BadgeId])
REFERENCES [dbo].[Badge] ([Id])
GO

ALTER TABLE [dbo].[Points] CHECK CONSTRAINT [FK_BadgeId]
GO

没有复制，没有第三方工具，我正在监视数据库上的所有 DDL 语句，因此它不是另一个用户。

我能够很好地检查约束（WITH CHECK CHECK在每个约束上使用），但不久之后它们仍然不受信任。只有在凌晨运行的维护作业是 Ola 的，而且这种情况全天都在发生。

更新：

因此，经过几次跟踪以缩小可能性之后，似乎 aBULK INSERT可能会导致FK不可信。这个 msdn 问题指出这是密钥变得不受信任的有效途径，这是我第一次听说它。

所以我现在的问题是，是否有替代策略BULK INSERT可以保持外键 …

我有点好奇，具有 128 GB 数据库 RAM 大小的 SQL 2012 企业版之一是 370 GB 并且还在增长，锁 (OBJECTSTORE_LOCK_Manager) 内存管理员使用的内存量显示为 7466016 KB。我也可以通过查看性能计数器来确认select * from sys.dm_os_performance_counters where counter_name = 'Lock Memory (KB)'

但是，当我运行查询时

select count(*) from sys.dm_tran_locks

它只显示了 16 个锁。那么什么是使用超过 7 GB 的锁。有办法查到吗？

这是否意味着一旦分配了锁的内存，SQL 还没有释放它？在过去的 1 小时内，我没有看到锁计数超过 500，但锁内存保持不变。

最大服务器内存为 106 GB，我们没有在内存中使用锁定页面，我在过去 12 小时内没有看到任何内存压力或错误日志中的任何错误。可用 MBytes 计数器显示超过 15 GB 的可用内存。

活动监视器始终显示 0 个等待任务，因此显然没有阻塞。

考虑到 SQL 服务器锁占用大约 100 字节的内存，7 GB 是大量内存，并试图找出谁在使用它。

我通过锁计数运行服务器仪表板报告最高事务，它说“当前系统上没有运行锁定事务。但是，锁内存仍然显示如上所述。数据库在夜间最忙。

我发现，如果我将 SQL Server 代理作业编写为脚本开头的“创建到”脚本use msdb- 所以我假设作业存储在 msdb 数据库中？

将 SQL Server 作业添加到 Visual Studio 数据库项目的最佳方法是什么？我将 msdb 数据库添加到数据库解决方案中，但这似乎没有对作业的任何引用。

我希望将作业与数据库一起部署/更新......这似乎不可能？

我正在运行一些SHRINKFILE操作来清理文件组中的一堆微小的、不必要的文件。对于其中一种收缩，以下命令会导致错误：

DBCC SHRINKFILE (N'myfile' , EMPTYFILE)'

数据库 ID x 的文件 ID x 无法收缩，因为它正在被另一个进程收缩或为空

它不是空的，也不是被缩小的。它正在一个数据库上运行，除了我自己，其他人目前都没有使用它。自动收缩未启用且从未启用。但是，在我开始使用它之前，会定期对这个数据库进行手动收缩，如果这很重要的话。

在SQLServerCentral 上，十年前的一个线程建议向文件添加几 MB，因为这“会重置一个内部计数器或开关，告诉它现在不在缩小中间。”

这有效 - 太棒了。但是任何人都可以更详细地解释如何/为什么在 SQL Server 内部工作？

我有 SQL Server 2012 备份文件，想将这些文件还原到 SQL Server 2016/2014。它会起作用吗？

我需要在卸载 SQL Server 2012 之前找出这一点。

DBCC CHECKDB 返回：

无法为数据库 'tempdb' 中的对象 'dbo.SORT 临时运行存储：140737951236096' 分配空间，因为 'PRIMARY' 文件组已满。

通过删除不需要的文件、删除文件组中的对象、向文件组添加其他文件或为文件组中的现有文件设置自动增长来创建磁盘空间。

消息 9002，级别 17，状态 4，第 1 行

我们有使用 SQL Server 2016 加密敏感列数据的要求，并选择了 Always Encrypted(AE) 功能来使用确定性方法加密这些列。

由于 AE 确定性加密不允许对这些加密列进行不等式、范围或 LIKE 查询，因此我们尝试使用对称密钥（列级）加密技术对这些类型的列进行加密。

在某些列（不需要任何不等式、范围或 LIKE 查询）上实现 AE 功能并在需要生成不等式、范围或 LIKE 查询的列上实现对称密钥类型加密是否是一个好习惯？

考虑到性能、安全性和维护性，将 AE 加密和列级加密结合在一个表上是一个好习惯吗？

请专家指教。