2

假设在你的工作中你的老板说，

那边的那个系统，它已经失去了所有的机构知识，但现在似乎运行得很好，我们能把双倍的数据转储到里面并生存下来吗？

你完全不熟悉这个系统。

它位于 SQL Server 2000（主要是数据库应用程序）中。

没有测试环境。

如果您需要运行基准测试，您也许可以在周末劫持它。

你会做三件事来说服自己和你的经理你可以承担额外的负担。如果你不能做到这一点，在相同的硬件上......额外的硬件（以美元衡量）将需要满足该要求。

为了解决来自 doofledorfer 的响应，您的假设几乎都偏离了 180 度。但对于一个模棱两可的问题，这是我的错。

  1. 其中一台主要服务器以 70% 的基础运行 7x24，并且从那里开始飙升，没有人知道它在做什么。

  2. 这不是买进或抱怨的问题……我们公司在这件事上可能没有太多选择。

  3. 由于这是外部强制执行的，因此延迟实施可能会导致巨额罚款。如此大的会议来评估风险几乎是不可能的。存在一个风险，即转储双倍数据会使现有客户的系统停机。

我希望有人会说类似的话，看看你是否在周日晚上的午夜让系统脱机并运行 SQLIO 测试，看看存储子系统有多接近饱和。像这样的东西。

4

4 回答 4

2

  1. 设置一个测试环境，即使我必须在我的笔记本电脑上进行。

  2. 在生产系统上启用某种日志记录以了解除了数据量之外的事务量。

  3. 当我在笔记本电脑上使用越来越多的数据运行压力测试时，请阅读源代码。

话虽如此，我很同情这个任务，因为它不公平。这就像问船上的人，船是否可以漂浮两倍的货物——但你不能下船，也不能让它停止正常服务。

于 2008-11-18T17:03:19.257 回答
2

您刚刚描述了一个典型的敏捷项目。你的答案应该是：

  1. 我不知道，如果没有测试，我将无法判断。
  2. 除了数据量之外，使用模式、应用程序交互、数据库和服务器调优等方面也可能存在问题。
  3. 因此，让我们研究一下风险因素的基本列表，以及我们如何解决它们。
  4. 一旦我们做到了，让我们以风险的相反顺序来解决它们；并在我们开发结果时做出停止/继续决定。
  5. 等等

至少在那个级别没有管理层的支持和参与，你可能给出的任何其他答案都是高风险的愿望，而“3 最重要”是不合逻辑的。

除非您当前的系统已经大量加载，否则我会很乐观。大多数服务器应在所有资源上以低于 50% 的容量运行，否则将处于生命支持状态。如果现有服务器已经在处理负载问题，我希望您不会进行对话；尽管“现在似乎运行得很好”不够精确，令人担忧。

于 2008-11-18T17:22:02.603 回答
0

这主要取决于其当前水平。如果加倍是从 2GB 到 4GB，那就去做吧。如果它从 1 TB 变为 2 TB，那么您有一些计划要做。

我会使用性能监视器收集一些信息并提供它以帮助做出明智的决定。

于 2008-11-18T17:00:35.067 回答
0

这取决于您所说的“数据加倍”是什么意思。

如果这只会影响一个表（比如产品表），那么您可能是安全的，因为大多数引用该表的查询最有可能将执行时间加倍（假设您不会两次引用同一时间在查询中）。

如果将所有表中的数据量加倍，就会出现问题，因为执行时间可能会以指数方式增长，并且可能导致一些严重的问题。

但总的来说，我会支持doofledorfer 的回答

于 2008-11-18T17:41:12.643 回答