我们在 SQL Server HA 组中有几台服务器，一台作为主服务器，另一台作为辅助服务器。该系统运行良好，并且可以按预期进行故障转移（尽管这种情况非常罕见）。但是，我们还希望为另一个目的设置事务复制，以便与 HA 组中的一个 DB 推送的数据进行一些集成。集成希望数据尽可能实时（因此是事务性的，一些延迟很好），并且从 HA 组中的一台服务器进行单向推送。
我正在考虑仅将辅助节点用于事务复制，而不对主节点进行任何更改。辅助节点没有得到太多使用，当它进行故障转移时，我们会快速修复主节点上的问题并手动故障回复到主节点。Primary 的使用量相当大并且有点脆弱，而 Secondary 的使用量要少得多，因此使用 Secondary 作为 Publisher 似乎是一个聪明的解决方案。
我们有：
连接的连接字符串属性似乎是我想要的，注意加密设置为关闭和 trustservercertificate=true：
IR 报告为已连接且工作正常：
我已经在虚拟机上测试了 SQL Server 身份验证，并通过 IR 的诊断选项卡安装了 IR。工作正常：
从数据工厂，我在连接到 IR 的链接服务上使用相同的登录参数进行测试，它有效：
请注意，我们使用很多参数来定义连接，这些也可以正常工作。
我设置了一个数据集，使用相同的属性，测试连接工作：
现在，我使用相同的参数、相同的数据集和相同的链接服务设置了一个简单的复制活动：
我还预览了我想要的数据，它可以正常工作，按预期从服务器中取回数据。
这对我来说毫无意义，我在每个步骤中都使用完全相同的参数进行了测试，但是当所有其他连接测试都成功时，一个简单的复制活动就会失败。有人知道吗？
注意：我尝试设置 Linked Service 连接参数：Encryption = True，这有时意味着连接正常。同样，这没有什么意义。
我们有一个 SQL Server 2012 服务器，它在（据我所见）相同的基础架构上远远优于 SQL Server 2019 数据库。我们将这两个数据库托管在具有相同 SLA 的云平台上。两者都有 180GB RAM 和 16 个处理器。
然而，有一些关键的区别。
编辑：我刚刚意识到的另一个主要区别 - 一个是 Windows Server 2008，另一个是 Windows Server 2019。它也可能是服务器端设置......
所有 SQL 磁盘的分配单元大小设置为 64kb，SQL 具有能够自行控制文件大小的正确权限。服务器设置为高性能模式。还有什么我应该改变服务器端的吗？
其他数据库设置没有改变，所以以下设置是 2019 年的默认设置，我相信：
我们所做的查询类型主要是执行更新和插入的大型复杂多连接查询，偶尔还会有来自用户的小选择。我们将大文件加载到数据库中，然后在大查询中处理数据，通常一次一个。在这些大型“负载”之间，我们让用户对其他未加载/处理的数据库表进行选择，以准备未来的加载/处理步骤。通常，我们的处理性能会降低 30%-50%。我认为这是因为 MAXDOP 设置，但将其更改为 0 在一系列运行中没有任何区别。
我们的主要症状是当我们在忙于处理时尝试连接到 2019 服务器时，我们会遇到锁定超时，而 2012 服务器仍在提供连接服务，只是速度非常慢。我正在考虑将服务器上的连接超时设置设置为很高的值，但是我怀疑我们仍然不会得到服务器的响应。就好像它有点忙，它会阻止所有新的连接。
还有其他我应该尝试的事情吗？这些数据库设置值得摆弄吗？
我可以进一步深入研究并开始研究 DMV，但这似乎接近于“对等”环境升级，但性能会显着下降。在进行更大的调查之前，只需检查一下我应该检查的其他内容。
我之前在 Azure PaaS 数据库上使用以下内容设置了 Azure 弹性数据库查询：
在数据源数据库上：
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<encryption key>';
GO
CREATE DATABASE SCOPED CREDENTIAL CRED_Azure_Login
WITH IDENTITY = 'SomeUser', SECRET = '<Some password>'
GO
这次运行没有问题，我可以看到在查看 sys.database_scoped_credentials 时创建的凭据。所以看起来来源很好。
在目标数据库上：
CREATE EXTERNAL DATA SOURCE Source_AzureDatabase
WITH
(
TYPE=RDBMS,
LOCATION='<DB location>.database.windows.net',
DATABASE_NAME='SourceDBName',
CREDENTIAL= CRED_Azure_Login
);
这曾经可以正常工作，但是我收到以下错误：
Msg 46516, Level 16, State 26, Line 1
The specified credential cannot be found or the user does not have permission to perform this action.
我在目标数据库中使用管理员登录名（我通过数据库的 Azure 门户概述页面更改了管理员登录名并重新登录，以确保）。文档说您需要对数据库具有 CONTROL 权限，因此这应该不是问题。由于我已成功设置源数据库主密钥和凭据，因此链接到它应该不是问题。
其他人可以试试这个看看是不是只有我一个人？另一位 DBA 审查了代码，没有发现任何问题。感觉微软可能已经破坏了这个功能 - 其他人可以检查他们可以做到吗？
我有一个 SIMPLE 恢复模型的数据库，有 10GB 可用空间。
我试图通过 SSIS 批量加载加载的文件是 1GB。
该表是空的（在每次加载之前被截断），是一个堆并且没有非聚集索引。它是一个 varchar(255) 字段表。
运行批量插入任务时，我可以看到数据库大小从 2GB 增长到 12GB（最大可用空间），空间不足并返回以下消息：
[批量插入任务] 错误：发生错误并显示以下错误消息：“无法为数据库‘DBNAME’中的对象‘dbo.tablename’分配空间，因为‘PRIMARY’文件组已满。通过删除不需要的文件来创建磁盘空间，删除文件组中的对象，向文件组添加其他文件，或为文件组中的现有文件设置自动增长。”。
首先，我认为因为我处于 SIMPLE 恢复模式，所以没有记录批量加载。我知道这是当表中有数据和聚集索引时，但这里都不是这种情况。我假设批量插入任务包含在其中，因为它应该使用 BCP。我错了吗？
其次，一个 1GB 的文本文件会在 SQL Server varchar 字段中产生 10GB，这似乎很奇怪。这看起来很奇怪。数据没有被转换，它被批量加载到一个表中。为什么会长这么大？
SQL Server 2008 R2，但在所有其他版本的 SQL Server 上也会发现可能的行为。
这可能看起来很明显，但对我来说这似乎是一个错误。
以下查询给出了意外的结果，这里是设置：
CREATE TABLE #Base (
Key1 int,
RefDate date
)
CREATE TABLE #JoinTable (
Key1 int,
RefDate date
)
INSERT INTO #Base
SELECT 1, '2012-05-05'
UNION
SELECT 2, '2013-06-06'
UNION
SELECT 3, '2014-07-07'
UNION
SELECT 4, '2015-08-08'
UNION
SELECT 5, '2016-09-09'
INSERT INTO #JoinTable
SELECT 4, '2012-05-05'
UNION
SELECT 5, '2013-06-06'
UNION
SELECT 6, '2014-07-07'
UNION
SELECT 7, '2015-08-08'
UNION
SELECT 8, '2016-09-09'
以下查询按我的预期执行，返回仅出现在基表中的 3 行：
SELECT *
FROM #Base b
LEFT OUTER JOIN #JoinTable j ON b.Key1 = j.Key1
WHERE j.Key1 IS NULL
现在我想将行限制为 2014 年 1 月 1 日之前的行。据我了解，我可以采用以下两种方法，两者都应该是完全可行的：
SELECT b.*
FROM #Base b
LEFT OUTER JOIN #JoinTable j ON b.Key1 = j.Key1 AND b.RefDate < '2014-01-01'
WHERE j.Key1 IS NULL
SELECT b.*
FROM #Base b
LEFT OUTER JOIN #JoinTable j ON b.Key1 = j.Key1
WHERE j.Key1 IS NULL AND b.RefDate < '2014-01-01'
但是，只有第二个查询返回我想要的数据。第一个似乎忽略了连接行中 AND 之后添加的连接条件。
为什么？
（sql小提琴链接在这里）