假设您想要将所有关键任务数据库整合到一个实例中，以便节省一些许可费用，可能存在哪些潜在风险，是否有任何好的文章或案例研究？我意识到这是一个可怕的想法，但我有人想要这样做，并愿意在需要时最大化硬件资源。我试图向他提供可量化的东西或一些可以引导他远离这样做的文章。
有三个重要的关键任务数据库，其中包括Billing，Dynamics CRM和内部构建的应用程序，以跟踪事务。这些是针对中小型公司的高容量数据库。我需要量化或良好的案例研究支持，以使某人相信这是走向错误的道路。关于我如何说服这个人的任何其他建议也会有所帮助。
答案 0 :(得分：1)
答案取决于。乍一看，这可能看起来不错。另一方面，如果目标是整合一台服务器上的所有内容，然后在远程环境中复制该服务器，那么您就可以使用更可靠的系统了。 IT可能更喜欢在一个地方拥有所有东西，而不是处理遍布地形的关键任务服务器。
一个主要问题是需要更大的机器。因此，如果任何系统使用的软件的许可证不依赖于机器的大小，那么您最终会花费更多钱，因为您需要更大的服务器。例如，我已经看到SAS许可会发生这种情况。
但也许最大的问题是，不同的应用程序可能处于不同的开发周期 - 无论是内部开发还是外部供应商开发。因此，更新硬件/操作系统/软件可能会成为一场噩梦。 A中的修复或增强功能可能需要操作系统补丁，而补丁尚未在B上进行测试。此维护问题是我强烈提倡单独服务器的原因。
尽管如此，关键任务应用程序正是如此，关键任务。硬件上的驱动因素不应该是几美元。驱动因素应该是可靠性，维护，性能，可持续性和恢复。
答案 1 :(得分：1)
Oded，Catcall和Gilbert的评论都在现场发表。
我学习IT交易的银行在单个MVS（后来的Z / OS）大型机上运行其整个核心业务，该大型机运行单个DBMS和单个事务处理器（除非您将TSO视为事务处理器）。 / p>
交易处理器定期停机（比方说，每天一次）。它从未导致银行破产，因为它总是在不到一分钟的时间内再次运行。里程可能会有所不同，但在整个工作日（480分钟，或<0.25％）中失去一分钟的营业时间确实不会造成危险的破坏。
单个DBMS也有时下降（比如每月两次）。我仍然可以听到sysprogs大吼大叫“DBMS已经关闭”到了帮助台人员的围栏，这意味着“希望得到用户电话”。它从未导致银行破产，因为它总是在几分钟内重新启动并运行。里程可能会有所不同，但每个月失去几分钟的营业时间确实不应该造成危险的破坏。
有一次我记得当银行真正接近破产时，开发团队已经从银行绝对核心业务的新项目中弄得一团糟，银行就像完全停业一样好（它的真实业务）连续三到四天。这不是0.25％的营业时间损失，而是差不多100倍。
我的故事的道德？他们两个人。 （a）所有关于风险评估（=概率评估）和风险加权（=概率加权）成本估算。 （b）如果你问一个关于SO的问题（这意味着一种认可/期望回答者比你在主题上有更多的专业知识），像Oded和Catcall这样的人会为你提供一个简明的答案，这是准确的，关键，然后不要求文件或案例研究来支持他们的答案。如果你不想接受专家的专业知识，那么为什么一开始就要求任何事情呢？