小编Nik*_*Nik的帖子

我有几个大桌子。我想通过每周维护计划确保他们的统计数据是最新的。

但是，这样做需要花费太多时间。

如果我指定

WITH SAMPLE 50 PERCENT

SQL Server 然后采样：

1. 前 50% 的页面
2. 每隔一页
3. 或其他一些策略？

BOL对此并不明确。

Sql Server 2008 R2。

我有一个包含 ~70m 记录的表，每秒大约插入 10 次。

它当前聚集在 CreatedAt 日期时间列上，该列始终增加。50% 的查询涉及此列。

还有另一个日期时间列“IssuedAt”，它具有不同的含义，但通常在 CreatedAt 的一天左右。50% 的查询涉及此列。此列上的 NC 索引。

还有许多其他 FK 列 - 如果相关，可能大约 150 字节宽。还有一些索引 - 以不同方式对表格进行大量查询以获取各种报告。

我的问题是针对聚集索引和两个日期时间列索引该表的最佳方法。

a）我担心聚集键比它必须的大（日期时间+隐式鉴别器）导致更大的NC索引大小。我应该添加一个 INT 身份，而不是集群吗？

b) 由于书签查找，我对 IssuedAt 列的查询可能很昂贵。我面临着在其中包含越来越多的列（损害写入性能）。这里有替代策略吗？

提前致谢。

更新：

只是为了清楚起见 - 我知道需要进行基准测试 - 我可以看到一些查询没有得到令人满意的满足。

50% 的查询依赖于具有 CI 的日期时间列 A 和 50% 的依赖于具有 NCI 的日期时间列 B 之间存在固有的紧张关系。我希望可能有某种值得考虑的方法/技巧来抵消这种紧张局势。例如，一个新的过滤索引，或者移动到一个聚集索引，如果它们匹配，它是两者的日期组件，或者其他人用来缓解这种紧张局势的其他技术。

第二次更新：

我现在正在考虑以下几点：

1. 创建一个新列： IssuedAtOffset (int)。这是 CreatedAt 和 IssuedAt 之间的差异，以秒为单位。我从业务现实中知道 int 足以捕获这个增量，而且 IssuedAt 的毫秒数是无关紧要的，所以这会起作用。

2. 将 IssuedAtOffset 更新为正确的值。

3. 丢弃发布于。

4. 现在创建 CI：CreatedAt + IssuedAtOffset。

5. 创建一个视图，其中 IssuedAt 作为基于 CreatedAt …

从文档来看，似乎可以恢复完整的数据库备份文件，但也可以恢复事务日志吗？

（这个想法是尽量减少从本地迁移到 MI 过程中的停机时间）。

谢谢。

我已将一个数据库添加到已经拥有一些数据库的可用性组，所有这些数据库都已播种并同步到辅助数据库。

最后一个似乎被添加到可用性组中，但被标记为“不同步”并且不会返回任何错误。我已经尝试了多次，结果相同。

我查看了扩展事件、事件查看器......什么也没有。单击仪表板中的“警告”没有任何有用的信息。辅助数据库上根本不存在数据库文件。我怀疑它在播种过程开始时就被阻止了（但显然是在“添加到 AG”向导中的初始验证之后）。

我有一种明显的感觉，SQL Server 一定正在将相关的故障消息记录到一些我不知道的 DMV 中。

是否有一个规范的指南来指导人们应该在所有地方寻找与AlwaysOn相关的错误？