小编Oni*_*ght的帖子

我继承了执行以下操作的维护计划：

• 清理旧数据
• 检查数据库完整性
• 执行数据库和事务日志备份
• 重组我们的索引
• 更新统计
• 删除旧备份和维护计划文件

在 23 分钟的维护计划中，更新统计数据需要惊人的 13 分钟。在这 13 分钟期间，对数据库的访问被阻止（或者至少，从这个数据库到我们其他数据库的复制被暂停）。

我的问题是：

我们应该什么时候更新统计数据，为什么？

这似乎是我们应该比每天少做的事情。我试图让我们摆脱“仅仅因为”进行不必要维护的心态。

尝试运行我的维护计划时，我收到以下错误：

执行查询“”失败，出现以下错误：“无法重新组织表“”上的索引“”（分区 1），因为禁用了页级锁定。”

我们目前在此索引上启用了行级锁定。我可以启用页面级别锁定，但我不确定影响是什么。

我的问题是：这两种锁定方案有什么区别，它们在现实世界（生产中）的后果是什么？

今天，当我从 ASP.NET 网页运行时，我遇到了一个存储过程超时（花费超过 30 秒）的问题，但从 SSMS 运行时执行得很快（花费了 5 秒）。

在怀疑参数嗅探是罪魁祸首后，我屏蔽了输入参数，查询执行得更快。

我的问题是：为什么会发生这种情况？

这个系统已经投入生产超过 5 年了，这是我们第一次在我们的存储过程中看到这样的事情。这是“数据库磨损”吗？

我们已经解决了这个问题，所以这没什么大不了的，但我只是好奇为什么会发生这种情况。

我有一个包含以下列定义的表：

ID (INT, PK)
Name (VarChar)
Active (Bit)
Bunch_of (Other_columns)

问：我想有一个约束Name/Active，使得我们只能有1条记录与给定的Name是Active（Active= 1），但我们也能有同样的多条记录Name是Inactive（Active= 0）。这可能吗？

我已经尝试了普通的 Unique 约束，但它们将数据集限制为仅允许 1 条记录的给定Name为Inactive.

设置：

假设我们有一个处于完全恢复模式的数据库，它执行夜间数据库备份、事务日志备份和事务日志收缩。

现在事务日志在白天增长如此之快，因此我们需要每6小时执行一次事务日志备份+事务日志收缩以保持其较小。

问题：

鉴于这些事件序列（特别是每六小时的事务日志备份/收缩），我们是否仍然能够执行“最新”恢复？（即使用上次 DB Backup + Transaction Log 获取最新数据）。

故事：每周一次，我们运行一个特殊的维护计划，其中涉及重新索引 2 个关键表，它们之间有大约 600 万条记录。我们使用 SQL Server 2005 标准版。

问题：在此重新索引期间（大约 15 分钟的操作），我们无法将数据插入表中，并且我们的客户端没有数据。

有人告诉我，SQL Server 2008 Enterprise 有一个“在线重新索引”，它在较低版本的 SQL Server 中不存在，可以解决我们的问题。

但是，我刚刚在我们的维护计划选项（SQL 2005 标准）中找到了以下选项：

我的问题：这是否执行与 2008 Enterprise 相同的“在线重新索引”？启用此选项的影响（性能方面）是什么？我是否几乎被不必要地吸引购买了 2008 Enterprise 许可证？

系统：

我有一个维护计划，可以为多个表（10 个表，总共 50M 条记录）重建索引。

问题：

在索引重建期间（约 20 分钟），我们无法将数据插入数据库

题：

如何减少维护计划期间的停机时间？我正在考虑确保事务日志的大小很小（每天截断 4 次），但我认为这无济于事。

我也不确定更频繁地重建索引是否会有所帮助。（因为我不知道这是否是将从最近重新索引表中受益的“批量”操作）。

注意：升级到 SQL Server 2005 Enterprise 以获得实时重新索引功能不是一个选项。

在事务复制期间，我们将数据从服务器 A 传输到服务器 B。

假设我们要在服务器 A 上的表上重新植入身份列（无论出于何种原因），这将如何影响服务器 B 上的数据？

我的直觉是，服务器 A 上的数据将使用新播种的身份，并将按原样发送到服务器 B（服务器 B 将具有使用新身份的内容），但我不确定这是否是正确的。