我有三个数据库节点，节点 1 和 2 使用故障转移集群实例参与 HA。节点 3 使用 SQL Always On 可用性组充当 DR，类似于下图：
我真的很想摆脱 HA 部分，这样我就只剩下节点 1 和节点 3 了。如果我不关心节点 2，如何正确删除它，以便节点 1 不再参与 FCI？
当我在 Window Failover Cluster Manager 中查看 FCI 角色时，我看到了删除选项，就这么简单吗？我内心的声音在尖叫不，因为聚集了简单的反面。
我正在运行命令
ALTER TABLE [DB].dbo.TABLEA ADD [Field1] [xml] DEFAULT
CAST(N'<SettingValues xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://someurl.com/schemas.xsd" />' AS xml)
我期待一个带有 xml 字符串的新列出现，但它们都显示为 NULL。我做错什么了吗？
我的语法基于这个Microsoft 文档资源。
您可以在我创建的SQLFiddle上对此进行测试。
我是一名常驻开发人员，自愿成为 MSSQL 2016 的数据库管理员。请多多包涵，因为我仍在尝试自学数据库管理员的艺术。
我最近使用下面的架构（Always On High Availability Group）设置了一个 DR 解决方案，并且一切正常。所有数据库正在同步。
在我的主数据中心，我有两个节点（主动和被动）共享同一个磁盘（日志磁盘、数据等）。目前我在我的活动节点上看到以下内容，它们是我的前辈在那里设置的。
- 所有数据库都处于完全恢复模式。
- 它有一个完整备份维护计划，每天上午 12 点进行完整的数据库备份。
- 它有一个日志备份维护计划，其中事务日志每 5 分钟备份一次。
我了解 Always On 高可用性组使用事务日志在主数据节点和灾难恢复节点之间同步数据。我可以禁用#3 中的事务日志备份吗？
如果我不每隔 5 分钟备份一次事务日志，您会发现任何问题吗？我是否可以将我的 DR 节点用作“备份”以防出现问题，而不是使用我们上次的每日备份恢复我的数据库，然后从那天开始按程序恢复整个事务日志备份？
我们的数据库结构在 Window Failover Cluster Manager 中使用了两个角色。
- 一种是用于 FCI - 在主数据中心的主动/被动节点之间切换。
- 一种是 SQL 可用性组设置将数据从主数据中心复制到 DR 数据中心。这也用于发生灾难情况时的手动故障转移。
我们的 IT 团队希望在预定的停机时间定期对这些服务器执行操作系统修补，发生这种情况时应用程序将处于脱机状态。这对我们有点帮助，因为我们不必担心在修补另一个节点时故障转移到另一个节点，但是我们可以假设我们可以在修补期间使数据库完全脱机。
我的问题是最好的方法是什么，因为 IT 团队可能对 FCI 或数据库知之甚少。我不希望我们的数据库意外故障转移，因为在此过程中，活动 SQL 节点之一可能需要重新启动。我正在考虑给他们以下指示。
- RDP进入节点活动集群组，可以通过运行powershell命令找到这个：Get-ClusterGroup并找到“集群组”的OwnerNodeValue。
- 打开故障转移集群管理器扩展到角色，有两个角色，一个用于 AG，一个用于 FCI。
- 右键单击每个并选择“停止角色”
- 执行补丁，重新启动等..
- 完成后，RDP 重新进入并在“Start Role”上恢复这两个角色。
这会起作用吗？它被认为是好的做法吗？我希望强制故障转移服务停止，以便 SQL 节点在服务器重新启动期间不会故障转移到另一个节点。
我的设置：我们有两个节点 SQL 设置，带有主动/被动 Windows 故障转移集群实例。
我的目标：在活动节点上停止正在运行的 SQL Server 服务，并在一段时间内防止故障转移发生，然后将它们重新联机。
我正在使用 Windows 故障转移群集管理器，经过大量研究后，我看到了以下可用选项以及我认为每个选项的含义。
- Drain Role - 在节点级别完成以从节点中删除所有正在运行的角色，本质上是在集群上暂停它，当您想要修补或使集群中的特定节点脱机时很有用。
- 停止角色- 在角色级别完成以使 FCI 服务器脱机并防止所有节点上的故障转移功能属于此特定角色。
- 关闭集群- 在集群组级别完成，它类似于停止角色，只是它停止所有角色。
- Stop Cluster Service - 在节点级别完成，类似于 Drain Role????
您能否根据我对这些的理解验证我写的内容是否正确？
因此，如果我想关闭我的主动/被动 FCI SQL Server 服务，我打算执行以下操作，这些步骤是否正确？
关闭 FCI SQL Server 服务：
- 在运行我的 SQL FCI 的角色上停止角色，以防止主动/被动节点之间的故障转移。
- 使用活动节点上的 Windows 服务窗口关闭 SQL Server 服务。
启动 FCI SQL Server 服务：
- 在我想要激活的节点之一上使用窗口服务打开 SQL Server 服务。
- 在运行我的 SQL Server FCI 的角色上启动角色。
我可以考虑的另一个选项但不确定其有效性，基本上我正在停止 SQL 服务，同时拒绝它具有故障转移到另一个节点的能力。
停止我的“被动”节点上的集群服务。停止我的“活动”节点上的 SQL Server 服务。
我继承了两个节点（主要和次要副本）可用性组的设置。
在我的辅助副本节点上，SQL Server 实例默认文件存储在：
我的默认主副本节点文件如下：
当我查看辅助副本上的同步数据库属性时，我看到它的数据库文件如下
它们是主副本节点目录。这是它在可用性组中的工作方式吗？
也就是说，当您查看辅助副本数据库的文件组时，即使数据文件和日志文件存储在不同的本地目录中，它们也会显示主副本数据库的路径？
我看到很多资源，但它们都是关于如何使用空数据库实例从头开始设置 SQL 故障转移集群（不是可用性组）的说明。
我现在正在运行一个非集群数据库，我想通过添加另一个节点/虚拟机将其转换为 HA 故障转移。我不是 100% 确定，但一些 Google 资源说您无法将非集群 SQL Server 实例转换为集群实例。
在我的情况下，使用 FCI（不是可用性组）将现有数据库实例转换为 HA 的最佳方法或方法是什么？
我有一个简洁的小查询，它让我知道任何持续运行超过 3 分钟的持续查询。
SELECT
sqltext.TEXT,
s.session_id, r.status,
r.total_elapsed_time, r.cpu_time, r.wait_time
FROM sys.dm_exec_sessions s
INNER JOIN sys.dm_exec_connections c ON s.session_id = c.session_id
INNER JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS sqltext
WHERE s.is_user_process = 1
AND s.session_id <> @@SPID AND r.total_elapsed_time > 300000000
我遇到了这篇文章，它展示了如何设置 SQL 代理警报并作为通知发送。我可以结合我的查询，以便在我的查询运行时间超过 3 分钟时发送警报电子邮件吗？
我有以下查询，为简单起见，我使用下面的简单示例格式：
SELECT
col1, col2, dbo.fun3(col3)
GROUP BY col1, col2, dbo.fun3(col3)
这需要 30 秒运行并返回 6000 条记录。当我在SELECT和GROUP BY中删除dbo.func3(col3)时，它只需要 5 秒就可以返回 6000 条记录。
所以我想我的性能影响归结为以下几点：
- dbo.func3() 很慢，需要进一步的工作来提高它的性能
- GROUP BY中的函数调用会导致缓慢。
我想隔离 dbo.func3() 有多慢所以我在没有GROUP BY的情况下运行了以下查询：
SELECT col1, col2, col3
相对
SELECT col1, col2, dbo.fun3(col3)
第一个在 15 秒内返回大约 900,000 条记录。第二个在 15 秒内返回 500,000 条记录。
这证明我应该改进我的 func3() 函数。但是，您知道我可以通过部分查询在组中做些什么来减少延迟吗？
这个函数是否被调用了两次，因为我在查询的 select 和 group by 部分中有它？
去年，我有一个 SQL 代理工作，每晚凌晨 2 点成功运行；我们没有专门对该工作进行任何更改，但它突然给出了错误：
MERGE 失败，因为以下 SET 选项的设置不正确：'QUOTED_IDENTIFIER'。验证 SET 选项是否适用于索引视图和/或计算列上的索引和/或过滤索引和/或查询通知和/或 XML 数据类型方法和/或空间索引操作
我四处阅读，看起来一个快速的解决方法是在这项工作的最顶部插入命令“SET QUOTED_IDENTIFIER ON”。
但是，我真的很想知道为什么会这样？该作业不调用任何存储过程，而是使用某些视图、表进行合并、插入、更新。
我验证了我所有的视图和表格都将quoted_identifier 设置为true，我认为这是默认值。
我运行了以下脚本，发现我的 SQLAgent - Job Invocation Engine 已将quoted_identifier 设置为关闭。
SELECT *
FROM sys.dm_exec_sessions
WHERE is_user_process = 1
AND quoted_identifier = 0 ;
这也许可以解释为什么我的工作失败了？但是，为什么前一天晚上成功运行的同一份工作突然失败了？
添加新索引或更改存储过程的脚本是否会导致此quoted_identifier 值为false？可以重新启动数据库吗？
我们使用 MSSQL 2016 数据库，我最近在我的数据库 .mdf 文件所在的同一位置看到一个名为 DatabaseName.mdf_MSSQL_DBCC15 的文件。它的文件大小与我的 .mdf 数据库文件相同。
你知道这个文件是什么，是什么导致它被创建？我四处搜索，术语快照出现在这里和那里，但我无法确认 100%。