Kris's questions

我们设置了一个双节点 Always On 可用性组。两个节点都在 SQL Server 2016 SP3 上。

主服务器有两个 1Gb NIC。辅助有两个 10Gb NIC。

主要和次要都为所有四个 IP 配置了默认网关。

我们要在主服务器上启用单个 10Gb NIC，并在两个节点上禁用其中一个 IP 的默认网关，请执行以下步骤：

1. 禁用辅助服务器上 IP 之一的默认网关
2. 故障转移到辅助
3. 禁用主服务器上 IP 之一的默认网关
4. 在主服务器上配置 10Gb NIC
5. 禁用主服务器上的一个 1Gb NIC
6. 故障回复到主要

上述步骤是否足以完成任务？

集群是否自动识别新 NIC 并将其反映在集群网络详细信息中？

我们可以使用 1Gb NIC 和 10Gb NIC 运行主节点（禁用 1Gb NIC IP 的默认网关）吗？

这样做的原因：

1. 我们正在将网络从 1Gb 升级到 10Gb，因此我们希望利用 10Gb 管道。
2. 我们正在将备份从 prod 复制到 DR 服务器，然后从那里复制到磁带。我们的几个数据库大约 6TB，备份大约 500GB-800GB。我们也想加快复制速度。未使用这些盒子上的 NIC。

目前我们的服务器在 Microsoft SQL Server 2016 (SP3) (KB5003279) - 13.0.6300.2 (X64) Aug 7 2021 01:20:37 版权所有 (c) Microsoft Corporation Enterprise Edition (64-bit) o​​n Windows Server 2016 Standard 10.0 (构建 14393:)。这是辅助只读 AG 副本。我们在主副本和辅助副本上都安装了 SP3。但是最近第二个节点在 Windows 更新中声明了这一点

可用更新：SQL Server 2016 Service Pack 2 (KB4052908)

如果服务包是累积的，为什么服务器会这样说。有什么想法吗？谢谢。

我们收到了来自外部供应商的组件

CREATE ASSEMBLY MYCALC_DLL
AUTHORIZATION dbo
FROM 0x42A728....<300,000 binary values> 
WITH PERMISSION_SET = UNSAFE
GO

这个 DLL 是从 SP 调用的。

我们不想为数据库设置 TRUSTWORTHY ON 以将此程序集加载到 SQL Server DB 中，并且正在探索选项。遇到这些链接 https://nielsberglund.com/2017/07/01/sqlclr-and-certificates/
https://sqlquantumleap.com/2017/08/09/sqlclr-vs-sql-server-2017-part- 2-clr-strict-security-solution-1/
https://sqlquantumleap.com/2017/08/16/sqlclr-vs-sql-server-2017-part-3-clr-strict-security-solution-2/

然而，这些链接使用的工具如 MAKECERT（由 new-selfsignedcertificate 代替）、pvk2pfx.exe 和 signtool.exe 在我们的 win2016 服务器上不存在。

也可以用这种方法调用 DLL

在数据库中启用 TRUSTWORTHY -> 在数据库中安装程序集 AS WITH PERMISSION_SET = UNSAFE-> 在数据库中禁用 TRUSTWORTHY

我想这是一个愚蠢的问题，但是我将程序集加载为不安全，那么禁用 TRUSTWORTHY 有什么意义呢？纠正我...

我们想使用证书。如何进一步进行？并且这些数据库将很快配置为 AlwaysOn，会有任何并发​​症吗？谢谢

现在开发者给了这些文件

-----它是这样工作的。这是正确的方法吗？--------

<这是我第一次使用VS>

1. 已下载 Visual Studio 社区版 2019
2. 从上面的一组文件中，打开工程文件
3. 构建 CALC 项目
4. 它创建了一个 .dll 文件
5. 在项目的属性中，签名选项卡 创建了一个新的强名称密钥文件**没有选中复选框“使用密码保护我的密钥文件”并选择 sha256RSA 作为签名算法保存项目并构建，它会创建一个 .snk文件
6. 将 DLL 和 snk 文件复制到 SQL Server 框
7. 运行以下脚本

USE [Master]
GO

CREATE ASYMMETRIC KEY CLR_SP_Key
FROM EXECUTABLE FILE = 'H:\CLR_SP\CALC.dll'
GO

CREATE LOGIN CLR_SP_Login FROM ASYMMETRIC KEY CLR_SP_Key
GO

GRANT UNSAFE ASSEMBLY TO CLR_SP_Login
GO

USE [target_database]
GO
CREATE USER CLR_SP_Login FOR LOGIN CLR_SP_Login
GO

CREATE ASSEMBLY DBCALC_DLL FROM 'H:\CLR_SP\CALC.dll'
WITH PERMISSION_SET=UNSAFE
GO
CREATE function dbo.Proc_CLR_SP
(
@name as nvarchar(200) ,
@name2 as nvarchar(200)
)
RETURNS nvarchar(200)
AS EXTERNAL NAME DBCALC_DLL

我们已经在物理服务器上运行了一个 SQL Server Enterprise Edition 实例。现在配置 AlwaysOn 可用性组

1. 我们可以在现有 SQL Server 实例上配置 WSFC（Windows Server Failover Cluster）服务吗？
2. 还是卸载 SQL Server，安装 WSFC，然后重新安装 SQL？（这可能不是一件好事，因为他们持有巨大的数据库。）

由于我们正在计划一个 3 节点（都是物理机并且当前正在运行 SQL 实例）集群，如何继续前进？从安装媒体中选择哪些选项以继续进行 AlwaysOn 可用性组配置。谢谢

我们有 2 个 VLDB - 6TB（主数据库，OLTP 流量不多）和 4TB（存档数据库）。每天将从 5 个大表中移动/归档数据（从主表中删除并插入到归档中）。目前该服务器是 2016 标准版，拥有 2 个 VLDB 和 1 个小型数据库。我们正在计划一个 HADR 策略，考虑到标准版本，我只能想到日志传送（有时日志备份范围为 2-5gb）或 FCI。如果我们升级到企业版，我们可以使用 AlwaysOn AG。我的问题是这两个 VLDB 的最佳策略是什么。并且考虑到将来会为主数据库添加更多功能，因此大小会增长并成为更高的 OLTP 系统。

在我们的环境中，用户被授予对 tempdb 数据库 (dev/qa/prod) 的读/写/ddladmin 权限。当 SQL 服务重新启动时，这些权限将丢失，因为 tempdb 每次都会重新生成。当前采用的一种解决方案是 - 在 SQLAgent 启动时从 SQL Agent 作业重新应用权限脚本。这是不准确的，因为用户/权限会随着时间的推移而修改。另一个想法是每天备份 tempdb 权限（使用 15 天保留策略），并使用相同的作业来选择最新的文件，以便在 SQL 重新启动时重新应用权限。这是解决问题的准确方法吗？

谢谢！！