小编Mar*_*ian的帖子

我的任务是为我们的 Sql Server 2005 数据库制定维护计划。我知道对于备份，我希望每 15 分钟执行一次完整的数据库备份和事务日志备份。我的问题是弄清楚我想做哪些其他任务以及我应该多久做一次。

所以，到目前为止，我已经想到了这一点。如果我的想法有任何缺陷或更好的方法，请纠正我。

1. 备份 - 所有表，完整备份（每日）
2. 备份 - 选定表，完整备份（每小时）
3. 备份 - 事务日志（每 15 分钟）
4. 检查数据库完整性（每天）
5. 重组索引（每日）
6. 更新统计数据（每日）
7. 收缩数据库（每周）
8. 重建指数（每周）
9. 维护清理（每日）

我记得前段时间（当我在另一份工作中制定类似计划时）读到其中一些任务不需要每天运行或不应该每天运行。至于哪些，它逃脱了我。我可以使用一些指导来创建更好的维护计划，以减少灾难中的数据丢失，但不会在高峰时段运行时对系统造成负担（并提高性能）。

我从一开始说，我的问题/问题类似于此之前的一个，但因为我不知道的原因或起始信息是一样的，我决定后，我的问题有一些更多的细节。

手头问题：

• 在一个奇怪的时间（接近工作日结束），一个生产实例开始出现异常行为：
  • 实例的高 CPU（从大约 30% 的基线增加到大约两倍并且仍在增长）
  • 增加的事务数/秒（尽管应用程序负载没有看到任何变化）
  • 增加空闲会话数
  • 从未显示此行为的会话之间的奇怪阻塞事件（即使读取未提交的会话也会导致阻塞）
  • 间隔的顶部等待是非页面闩锁排在第一位，锁排在第二位

初步调查：

• 使用 sp_whoIsActive 我们看到我们的监控工具执行的查询决定运行速度极慢并占用大量 CPU，这是以前从未发生过的；
• 其隔离级别未提交读取；
• 我们查看了我们看到古怪数字的计划：StatementEstRows="3.86846e+010" 有大约 150 TB 的估计数据要返回
• 我们怀疑是监控工具的查询监控功能造成的，所以我们禁用了该功能（我们还向我们的提供商开了一张票，以检查他们是否知道任何问题）
• 从第一个事件开始，它又发生了几次，每次我们终止会话，一切都会恢复正常；
• 我们意识到该查询与MS 在 BOL 中用于查询存储监控的查询之一极为相似- 最近性能下降的查询（比较不同时间点）
• 我们手动运行相同的查询并看到相同的行为（CPU 使用不断增加，增加闩锁等待，意外锁定......等）

有罪查询：

Select qt.query_sql_text, 
    q.query_id, 
    qt.query_text_id, 
    rs1.runtime_stats_id AS runtime_stats_id_1,
    interval_1 = DateAdd(minute, -(DateDiff(minute, getdate(), getutcdate())), rsi1.start_time), 
    p1.plan_id AS plan_1, 
    rs1.avg_duration AS avg_duration_1, 
    rs2.avg_duration AS avg_duration_2,
    p2.plan_id AS plan_2, 
    interval_2 = DateAdd(minute, -(DateDiff(minute, getdate(), getutcdate())), rsi2.start_time), 
    rs2.runtime_stats_id AS runtime_stats_id_2
From sys.query_store_query_text AS qt 
Inner Join sys.query_store_query AS …

通常/大致将具有 1T 数据的 Oracle DB 从 10g 升级到 11g 需要多长时间？我需要估计它的停机时间，因为它是一个生产数据库。非常感谢！

我在两个 SQL Server 2008 SP1 服务器之间有一个事务复制，它们都在 Windows 2003 Server 上。发现主库和订阅库的部分表存在差异。我已经对记录计数进行了手动验证，并且存在细微差异。我知道双方之间存在延迟，所以不用太担心，但是有一个特定的表无论如何都不会同步（新行出现，但一些特定的旧行没有出现，所以它们看起来像同步后删除）。

情况是订阅数据库不是只读的，因此应用程序可以读取数据，也可以向该数据库写入数据。

现在我想知道您将使用哪些解决方案来同步双方。我现在能想到两个：

• 对每篇文章使用 tablediff.exe 实用程序来比较源表和目标表并生成脚本

• 重新初始化订阅，这样它就会使上一个快照无效并生成一个新快照。

有没有其他解决方案来解决这个问题？

我们处于 SSAS 类型的环境中，拥有 100 名客户。

目前，每个客户端都有一个数据库，我们在 SQL Server 2008R2 上每个实例有 200 个。这会限制 snapmanager 能够进行备份，因为建议的数量是每个实例 (netapp) 35 个数据库。

我们正在研究的解决方案之一是整合数据库——使用单独的模式将其中的 150 个收集到一个数据库中。

有没有人做过这样的事情？
每个数据库的模式数量是否有限制，或者我们应该注意的性能问题与使用单独数据库的比较？

谢谢您的回答。

我们需要 Snapmanager 的原因是因为这是我们目前用于 DR 复制的内容，他们的建议是每个实例 35 个数据库，否则备份/传输数据可能需要一个多小时，这打破了我们的 1 小时恢复要求。

但是根据他们的说法，如果我们每个实例有 1 个数据库（或 35 个以下），他们应该能够让它没有问题。

所以这就是为什么我们可能会研究模式，但这意味着每个数据库很可能至少有 100 个模式。

我有一个在多个位置复制的数据库。它被设置为事务复制。但是，现在我需要向表中添加更多列。添加更多存储过程等。因此，如果我在发布者中进行更改，它会跨订阅者复制还是会对复制产生负面影响？

建议会很有帮助。