标签: sql-server

由于业务逻辑，我们需要在表中添加一个新列，以确保始终填充该列。因此，应将其添加到表中NOT NULL。与之前解释如何手动执行此操作的问题不同，这需要由 SSDT 发布管理。

由于一些认识，我一直在用头撞墙一段时间来完成这个听起来简单的任务：

1. 默认值不合适，不能是计算列。也许它是一个外键列，但对于其他列，我们不能使用像 0 或 -1 这样的假值，因为这些值可能具有重要意义（例如数字数据）。
2. 在预部署脚本中添加列将在第二次自动尝试创建同一列时发布失败（即使预部署脚本被编写为幂等）_{（这真的很糟糕，否则我可以想一个简单的解决方案）}
3. 每次发生 SSDT 架构刷新时，在部署后脚本中将列更改为 NOT NULL 将被恢复（因此，至少我们的代码库将在源代码控制和服务器上的实际内容之间不匹配）
4. 现在将列添加为可空，以便将来更改为 NOT NULL 在源代码管理中的多个分支/分支中不起作用，因为目标系统在下次升级时不一定都具有相同状态的表_{（并不是说这无论如何都是一个好方法 IMO）}

我听别人说的方法是直接更新表定义（这样schema刷新是一致的），写一个预部署脚本，将表的全部内容移动到一个包含新列填充逻辑的临时表，然后移动后部署脚本中的行。尽管如此，这似乎很危险，并且当它检测到一个 NOT NULL 列被添加到一个包含现有数据的表中时仍然会激怒发布预览（因为验证在预部署脚本之前运行）。

我应该如何添加一个新的、不可为空的列，而不会冒孤立数据的风险，或者在每次发布时使用固有风险的冗长迁移脚本来回移动数据？

谢谢。

我无法理解 DB Session 状态的含义。我搜索了一些参考资料，但没有得到任何帮助。任何人都可以解释这些状态（可运行、睡眠、暂停、运行和后台）的实际含义，这对我有很大帮助。提前致谢。

我的计算机上安装了 SQL Server 2017。这是SELECT @@VERSION返回的内容：

Microsoft SQL Server 2017 (RTM-GDR) (KB4293803) - 14.0.2002.14 (X64) 2018 年 7 月 21 日 07:47:45 版权所有 (C) 2017 Microsoft Corporation Enterprise Edition（64 位），Windows 10 Enterprise 10.0（Build 171） )`

直到昨天它都运行良好。突然SQL SERVER Service没跑了。当我想手动运行该服务时，它显示3417 error. 当我检查事件日志时，我看到了这个错误：

数据库 'master' 的脚本级升级失败，因为升级步骤 'msdb110_upgrade.sql' 遇到错误 200，状态 7，严重性 25。这是一个严重的错误情况，可能会干扰正常操作，数据库将脱机。如果在升级“master”数据库期间发生错误，它将阻止整个 SQL Server 实例启动。检查以前的错误日志条目是否有错误，采取适当的纠正措施并重新启动数据库，以便脚本升级步骤运行完成。`

经过一番谷歌搜索后，我发现我可以运行它/T902 switch并尝试解决问题。但没有任何解决方案对我有用。所以我安装了相同SQL SERVER 2017和恢复数据库的另一个实例。现在新安装的实例也有同样的问题。

可能是什么问题呢？

更新 这是 SQL Server 的完整错误日志。

2018-09-17 13:06:47.29 spid6s 配置选项“显示高级选项”从 1 更改为 1。运行 RECONFIGURE 语句进行安装。

2018-09-17 …

我正在将一些 XML 数据插入 SQL Server 中的 XML 列，但在插入数据后，它已被 sql server 更改。这是我插入的数据

              <xsl:value-of select="name/n/given" />
            <xsl:text> </xsl:text>
          <xsl:value-of select="name/n/family" />

当我读回来时，它看起来像这样

              <xsl:value-of select="name/n/given" />
          <xsl:text />
          <xsl:value-of select="name/n/family" />

注意第二行。这是一个问题，因为它改变了 XSLT 转换输出的方式。第一个例子将在给定和姓氏之间创建一个空格，而第二个不会创建任何空格，所以它会像约翰约翰森，而第一个会像约翰约翰森。

有没有办法解决这个问题？

沙袋

虽然其高质量博客Posts®工作，我碰到了一些优化的行为，我发现真的真气有趣。我没有立即得到解释，至少不是我满意的解释，所以我把它放在这里，以防有人聪明出现。

如果您想继续学习，可以在此处获取Stack Overflow 数据转储的 2013 版本。我正在使用 Comments 表，上面有一个额外的索引。

CREATE INDEX [ix_ennui] ON [dbo].[Comments] ( [UserId], [Score] DESC );

查询一

当我像这样查询表时，我得到了一个奇怪的查询计划。

WITH x
    AS
     (
         SELECT   TOP 101
                  c.UserId, c.Text, c.Score
         FROM     dbo.Comments AS c
         ORDER BY c.Score DESC
     )
SELECT *
FROM   x
WHERE  x.Score >= 500;

Score 上的 SARGable 谓词不会被推入 CTE。它在计划后期的过滤器运算符中。

我觉得很奇怪，因为它ORDER BY与过滤器位于同一列。

查询二

如果我更改查询，它会被推送。

WITH x
    AS
     (
         SELECT   c.UserId, c.Text, c.Score
         FROM     dbo.Comments AS c
     ) …

我编写了一个使用临时表的存储过程。我知道在 SQL Server 中，临时表是会话范围的。但是，我无法找到有关会话确切功能的确切信息。特别是，如果此存储过程可以在单个会话中并发执行两次，则该过程中的事务需要显着更高的隔离级别，因为这两个执行现在共享一个临时表。

我正在与其他人一起创建 SQL Server 数据库。其中一个表很小（6 行），其中的数据可能会保持不变。添加新行的可能性很小。该表看起来像这样：

CREATE TABLE someTable (
    id int primary key identity(1,1) not null,
    name varchar(128) not null unique
    );
INSERT INTO someTable values ('alice', 'bob something', 'charles can dance', 'dugan was here');

我正在查看该name列的字符长度，我认为它的值可能永远不会大于 32 个字符，甚至可能不会大于 24。我将此列更改为，有什么好处，例如，varchar(32)？

另外，将默认列大小保持为 4、8、32 等的倍数有什么好处吗？

如果在可用性组中的主节点上强制执行计划，它是否应用于在辅助节点上运行的查询？

我正在寻找涵盖计划强制两种可能性的答案：

• 计划指南
• 查询存储强制计划

我已阅读以下内容，这些内容表明 QS 强制计划不会结转，但在文档中找不到任何权威信息，或任何有关计划指南的信息。

• Erin Stellato 的查询存储和可用性组
• Vikas Rana在 AlwaysOn Readable Secondary 上查询数据存储强制计划行为

强制的决定性证据是辅助节点的执行计划中存在Use Plan或PlanGuideName和PlanGuideDB属性。

在谷歌搜索时，我发现了一些相互矛盾的信息。

某些站点指出，当没有为数据留下物理内存时，SQL Server 会将现有数据移动到 TEMPDB（请参阅：SQL Server：揭秘 TempDb 和建议）。

但是其他站点声明，当没有足够的物理内存时，操作系统可以使用 PAGE FILE 并将数据从物理内存移到它（请参阅SQL Server 的页面文件）。

我想知道当 SQL Server 物理内存不足时，它会在哪里写入数据？到 tempdb 还是到 OS Page 文件？或者两者都有？

我正在使用 Microsoft SQL Server 2016 (SP2-CU11) (KB4527378) - 13.0.5598.27 (X64) Nov 27 2019 18:09:22 版权所有 (c) Windows Server 2012 R2 上的 Microsoft Corporation 标准版（64 位）标准 6.3（内部版本 9600：）

该服务器位于 SSD 驱动器上，最大内存为 128 GB。Parallelism 的 CostTheshold 是 70，MaxDegree of Parallelism 是 3。

我有一个“行程”表，它由 23 个外键引用，带有 ON DELETE CASCADE 选项。

这个表本身并没有那么大（530 万行，1.3 GB 数据）。但是在 23 个引用的表中，有两个表非常大（超过 10 亿行，每行 54 和 69 GB）。

问题是当我们尝试删除“Trips”表中的少量行（假设为 4 行）时，SQL 估计将要删除这么多行，它需要 10GB 的 RAM，估计将有数百万行返回，并锁定表。一切都停止，其他查询阻塞，应用程序超时。

以下是 1 个删除语句的主表和行数：

• 行程（4 行）
• 细分（27 行，与 SegmentId 的旅行相关）
• 配置文件（2012 行，按 SegmentId 与 Segments …