合并数据库的缺点？答案

【问题标题】：Disadvantages of consolidating databases?合并数据库的缺点？
【发布时间】：2010-08-25 23:10:21
【问题描述】：

在一个拥有两个应用程序的组织中，每个应用程序都有自己的 Oracle 数据库实例，将两个数据库合并到一个具有两个模式的数据库有什么缺点？

备份和复制数据库可能更大更慢。还有什么？

一些背景：

这两个数据库是各自数据的“黄金来源”。每一个对组织的运营都至关重要，并且每一个实际上都被多个应用程序、工具和报告使用（但每个数据库主要由一个应用程序“拥有”）。经常需要跨数据库连接数据，将一个实体与另一个实体关联起来。出于这个原因，有连接两者的数据库链接和一些跨数据库物化视图来帮助提高性能。正在努力减少数据重复，这些具体化的观点正在讨论中。组织中的一些人希望逐步淘汰 DB 链接和物化视图，并引入更多 Web 服务以使数据跨应用程序可用。我担心的是，有太多情况需要跨两个数据库进行复杂的数据连接，因此暴露数据的服务将无法执行。另一种减少数据库链接和物化视图的方法是将模式整合到一个数据库中，但我想确保我不会忘记这种方法的任何严重缺点。

【问题讨论】：

合并的目标是什么？
@igor：向问题添加了“一些背景”。

标签： oracle database-design

【解决方案1】：

在单个统一数据库中，从 DBA 的角度来看，您将失去一些灵活性：

一个数据库显然只能有一个版本（例如 10.2.0.5），这意味着升级和补丁将影响所有架构 - 如果多个供应商应用程序要求不匹配，这可能是一件坏事。
同样，某些管理任务（将数据库 A 恢复到时间点 t）可能会因单个数据库而更加复杂。

总体而言，您将有更少的管理任务（一次备份、一次修补...），但每项任务都将更加关键，因为它们将产生全局影响。

在开发方面，请注意命名空间冲突：某些功能在单个数据库中是全局的，例如：

目录，
公共同义词，
数据库链接
架构

这意味着，如果您想整合两个具有相同名称的公共同义词指向两个不同事物的数据库，您将需要做一些工作。

【讨论】：

【解决方案2】：

可能与许可成本有关 - 扩大与扩大。

【讨论】：

有趣。你能解释一下吗？我认为甲骨文有每个 CPU 的许可。这对于扩大规模和扩大规模有什么作用？
我对 Oracle 许可不太熟悉，只是给了你一个想法。这是关于投资于更强大的硬件以节省许可成本（通过每台机器的许可），而不是投资于众多功能较弱的机器以节省昂贵的硬件。

【解决方案3】：

我最担心的是，您的所有代码都需要重写以适应新的数据库和模式。或者至少看过。本堂介绍了新的错误。我不知道 Oracle 如何处理对不同数据库的引用，所以我将使用一个示例来说明我的意思是使用 SQL Server 语法。如果我要加入不同数据库中同一服务器上的两个表，我的选择将是这样的：

选择 a.field1，b.field2 FROM database1.dbo.table1 一个加入数据库2.dbo.table2 b ON a.myid = b.myFK

要实现您新的统一想法，您需要编写：

选择 a.field1，b.field2 FROM schema1.table1 一个加入 schema2.table2 b ON a.myid = b.myFK

您现在需要特别注意两个数据库中具有相同名称的任何表，这可能会导致一些偷偷摸摸的错误。

请注意，这些更改并不困难，但必须检查所有访问数据库的 SQL 以查看它是否可以正常工作，如果不能正常工作，请进行调整。

我不确定将它们放在同一个数据库中是否也可以。您可能需要合并一些表以避免跨应用程序的重复。（在这种情况下，添加字段以引用人们习惯于通过 id 查找的东西的旧 id 编号，例如可能出现在旧文书工作上的 person_id，因此可以对其进行研究）这是一个相当大的重写，所有随之而来的可能性由于新的错误，情况变得更糟。

如果你走这条路，我强烈建议你在决定如何设计之前阅读一本关于重构数据库的书。

【讨论】：

【解决方案4】：

仅凭提供的信息很难判断，在 db 世界中大的将是 100GB 或更多，因此 2 个 dbs 将是 200GB。如果两个数据库都不大于 100GB，那么大小不应该是决定的一个重要因素，复制和同步可以仅对更改进行，备份不应该有很大的不同（同样这取决于具体情况，例如何时完成备份或如果可能停机或在非高峰时间完成备份）除此之外，其他因素有： dbo 中的命名冲突，例如键、外键名称、表名称等。表的一些重命名、存储过程名称也是如此。

【讨论】：