小编Sup*_*oss的帖子

我有一个大表，它有一个带有标识主键的聚集索引。我正在决定该表的填充因子的正确值以最小化页面拆分。我们使用每天运行的脚本来维护索引，该脚本测量碎片并采取适当的措施。该表包含可变长度列。

我的第一个想法是将它设置为 100（因为记录应该只写入表的末尾）但我认为对可变长度列的更改也可能导致页面拆分，所以我现在转向 90。

任何建议表示赞赏。

我们计划通过同步数据库镜像更新两个 SQL 服务器。这将包括配置为见证服务器的第三个环境。

对于标准的 Windows 修补 - 我们应该以什么顺序修补/重新启动服务器？

我们公司的一位架构师设计了一个基于64位SQL2005标准版同步镜像的解决方案，在物理（4个四核，32GB RAM）服务器和虚拟DR服务器（4个虚拟CPU，16GB RAM）之间的两个地理远程数据中心之间见证服务器（1 个虚拟 CPU）。两个数据中心的存储都是企业级 SAN。

前端应用程序面向 Web，具有混合读/写用法。

作为一名 DBA（在设计阶段没有咨询过他），我担心这种配置的设计以最大限度地减少冗余为主要标准，并且它不会作为现实世界的解决方案工作 - 网络延迟和虚拟性能box 会导致不可接受的响应时间吗？如果调用故障转移，则性能甚至会更差。

有没有人有类似设置的经验？

我们有一个较大的数据库 (350GB)，它被复制到一个不同位置的订阅者。不幸的是，我们在两个站点之间的连接速度很慢。

今天我们在分销商处收到以下错误：

订阅已被标记为非活动状态，必须重新初始化。

无论如何，我们是否可以在不从快照重建订阅的情况下将其重新启动？

我知道在 64 位系统上将内存特权中的锁定页面设置为包含 SQL2005/2008 服务的服务帐户使用 AWE API 并有效地阻止 SQL 的缓冲池被分页到磁盘 - 提高稳定性。

但是，如果您有一个具有足够空闲内存的专用机器，那么您确信 SQL 不会分页 - 原生 SQL 64 位内存管理是否更快？