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