小编Wri*_*ree的帖子

如果我创建一个以标识列作为主键的表，并且所有其他列都有默认值，例如

create table rr (id int identity(1,1) primary key, dt datetime default getdate())

我们进行了不同类型的基本测试，并且 AlwaysOn 通过了许多测试。我们终于对 AlwaysOn 进行了大量的写测试，它给出了令人惊讶的结果。

实际的测试详细信息在这里，目标是查看 AlwaysOn 可用性组是否可以容纳高写入负载。

1. 我有两个虚拟机，每个虚拟机都运行在 8 个内核和 17GB 的 RAM 上，分配给 SQL Server。

2. 我们编写了一个脚本来生成相当不错的写 I/O（在 20 个线程中）。

3. 每个线程基本上将 24 MB 的数据插入到一个表中，然后在无限循环中删除。

在测试运行的 15 分钟内，自动故障转移的恢复时间估计达到了 12 分钟，这是非常糟糕的。我们尝试了故障转移来确认是否真的需要 12 分钟，大约需要 5 分钟，这仍然太高了。此外，如果我们继续测试三个小时的恢复时间，ETA 几乎是 3 小时，并且在故障转移时需要几个小时才能恢复（显然，如果是集群故障转移，情况就不应该如此，因为所有事务都是已提交的事务）。

所以有几件事..

很明显，synchronous次要副本无法跟上主要正在生成的负载（即使两台机器的配置相同）。这样做的副作用是主日志将继续增长（即使我们进行日志备份，它也无法截断日志）。

我们知道辅助节点每 4 个 CPU 核心使用一个线程来执行重做，这看起来是一个明显的限制。如果主节点运行 100 个线程来生成负载，那么辅助节点无论如何都不能使用那么多线程。

此外，主要在内存中执行其所有事务，并将实际数据文件写入到检查点。但是，secondary 似乎必须从物理日志驱动器读取所有事务并重做。辅助日志池应该使这个过程更快？但是在这种情况下它做得不好。

最后向 AlwaysOn 专家提问：

1. 有谁知道这个redo过程究竟是如何发生的？
   • 它被缓存了吗？
   • 是否涉及缓冲池？

2. 二级是否使用日志池来缓存日志条目以进行重做？

3. 日志池的大小是多少？它可以增长到最大可用内存吗？

4. 当重做发生时，重做线程将页面读取到缓冲池并像正常事务一样维护它们？

5. 如果二级不能跟上怎么来AlwaysOn文章说恢复时间是几秒？

这使得可用性组的高可用性部分存在问题，因为这些恢复时间是不可持续的。

[由提问者编辑]澄清，由于人们似乎认为这已得到回答，因此主服务器上的事务确实得到了确认（即日志已硬化），因为辅助服务器的状态始终是“同步的”。所以日志的硬化不是问题。因此，在故障转移时永远需要重做过程。这意味着对于生成日志 > 重做线程容量的任何负载，AlwaysOn 将始终比没有它需要更长的时间来恢复。

我在做这个

SELECT * INTO table1 FROM Table0

我在 datetime 列上出现算术溢出（错误转换为 smalldatetime），但是创建的目标模式有一个 datetime 列而不是 smalldatetime 列。

我专门针对 SQL Server 询问这个问题，我可以看到多个数据库的优点是：

1. 日志更小（因此一个失控的事务不会导致其他事务（复制等）停滞）
2. 页面损坏不会影响多个应用程序（这可以使用文件组隔离吗？）

我似乎无法从单个数据库架构中找到任何好处（也许代码管理更简单）。

您选择了哪种架构，为什么？