小编J. *_*ini的帖子

我的 SQL Server 版本是 SQL Server 2019 (RTM-CU18)。以下重现代码要求创建内存中文件组。对于后续操作的任何人，请记住，内存中的文件组一旦创建就无法从数据库中删除。

我有一个简单的内存表，在其中插入 1 - 1200 之间的整数：

DROP TABLE IF EXISTS [dbo].[InMem];

CREATE TABLE [dbo].[InMem] (
    i [int] NOT NULL,
    CONSTRAINT [PK_InMem]  PRIMARY KEY NONCLUSTERED (i ASC)
) WITH ( MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_ONLY );

INSERT INTO [dbo].[InMem]
SELECT TOP (1200) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;

我还有以下本机编译的存储过程：

GO

CREATE OR ALTER PROCEDURE p1
WITH NATIVE_COMPILATION, SCHEMABINDING 
AS
BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL …

我有一个巨大的表，假设有 500,000 行。我想将其（架构和数据）从一台服务器复制到另一台服务器。这不是更新插入或任何类型的更新；这是一次性的直接复制和粘贴。对此的惯用方法是什么？

我试过了：

• 将备份从一台服务器恢复到另一台服务器。这是不切实际的，因为众所周知，SQL Server 无法从备份中恢复表。它只能恢复数据库。而且我的数据库很大！
• 使用 SSMS 将表数据编写为 INSERT 语句序列。这是不切实际的，因为插入必须逐行完成，令人痛苦。我怀疑这也会对事务日志造成可怕的影响，但还没有人因此攻击我（我现在正在运行这样的脚本，这将需要几个小时）。

今天早些时候，我意识到我犯了一个非常愚蠢的错误。我没有编写视图，而是编写了无参数内联表值函数。这让我思考：除了界面之外，两者之间有什么区别吗？据我所知，它们在逻辑上是相同的并且执行相同。

那么，换句话来说，视图提供了哪些无参数内联表值函数所没有的功能呢？我想到的只是索引视图，但我从未见过有人真正使用它们。

最近，我意识到临时存储过程，并为我在职业生涯中从未见过它们使用过而感到震惊。当我记得这CREATE PROCEDURE必须是其批次的第一个语句时，我感到非常失望，这肯定限制了它们的使用。当我看到他们在这个网站上很少被提及时，我支持了这个想法。他们甚至没有标签！

临时存储过程的惯用用例是什么？他们如何避免因需要成为批次中的第一个语句而造成的限制？

即使对于相同的查询，计划缓存和查询存储也不相同。当寻找特定查询或一组相关查询的性能或监视信息时，每个查询的优点/缺点是什么？

我的在线研究表明的总体​​印象是，查询存储可以比计划缓存更快地查询（我不确定为什么），并且它的条目往往持续更长时间（这是可配置的），但我没有发现任何说法关于计划缓存优于查询存储的情况。

假设我不关心 SQL Server 2017 和 2022 引入的使用查询存储进行自动性能调优的功能。相反，假设我比较查询存储和计划缓存是出于两者可以执行的任务的目的。

请考虑以下错误消息。

消息 207 级别 16 状态 1 第 7 行

列名“FOO”无效。

由于我触发它的方式，我碰巧知道这是一个解析/编译时错误。

假设我正在运行一个不属于过程的长脚本，并且我收到了相同的错误消息。此错误消息中的内容告诉我错误是在解析/编译时而不是运行时发生的？

CREATE TABLE Department_History
(
    DepartmentNumber INT
);
GO

ALTER TABLE Department_History ADD FOO INT;

-- This is fine and shows FOO.
SELECT * FROM Department_History;

-- When uncommented, this fails at parse time.
INSERT Department_History (DepartmentNumber, FOO) VALUES (4, 5), (6, 7), (8, 9);

我还不是 DBA，但这似乎是 DBA 类型的问题，而不是编程问题。

有人问我：

• 哪些查询调用最频繁？
• 在正常项目中它们被调用多少次？
• 他们需要多长时间来执行
• 我们是否能够从 SQL 中提取执行计划来显示它当前的运行情况？
• 我们的 SQL 中是否存在任何潜在错误（不可接受的脏读等）？
• 哪些表最常被写入？
• 最常读取哪些表？
• 对于一个普通项目，这些表通常包含多少行？

由于需要在实时环境中运行，这变得很复杂。我们的愿望似乎是自动化一些维护过程，以修复我们发现的任何问题，并为开发提供输入以阻止他们做坏事。

我的第一个想法是——招聘一名 DBA，可能是一名顾问。

然后，所要求的规模之大令我震惊。一个项目可能会持续数月，其中一台 SQL Server 和多台应用程序服务器共享任务。此输出的数据量将是巨大的，监视每个正在执行的查询的性能开销也将是巨大的。

有没有推荐的此类分析工具？

缩小 SQL 数据文件是否存在导致数据文件损坏的风险？

我最近读完 《SQL Server 2008 中的计划缓存》 ，我感到很困惑。看起来，除了完全刷新计划缓存或明确要求重新编译存储过程之外，从 SQL Server 2008 开始，存储过程的重新编译都是在语句级别而不是存储过程级别完成的。

那么，除了显式刷新缓存或要求重新编译（例如WITH RECOMPILE）之外，什么可以在 SQL Server 2019 中重新编译完整的存储过程，而不仅仅是重新编译单个语句呢？

举一个我感到困惑的例子，请考虑以下过程。

CREATE PROCEDURE FOO AS
BEGIN
   SELECT * INTO #temp1 FROM table1
   INSERT BAR1 SELECT * FROM #temp1
   INSERT BAR2 SELECT * FROM #temp1
END

我可以想到很多可能导致SELECT * INTO #temp1 FROM table1重新编译的事情，但是如果没有下一行也重新编译，那么重新编译会很奇怪。这让我觉得 SQL Server 中一定有一些东西会导致整个存储过程重新编译。

昨天，我运行了一个大型临时查询，但没有保存。今天，我想再看一遍。我想我应该在计划缓存中寻找。令我惊讶的是，我可以找到较旧的查询和较新的查询，但找不到我运行的查询。为什么会这样？

我知道我应该打开查询存储，但我还没有这样做。