如果您只使用一个物理服务器，则在该服务器上的实例数量越少，管理越简单，过程效率越高。
如果您将两个实例放在同一物理服务器上，则会得到：
负面影响：
积极因素：
那么对于您来说，停机窗口还是 CPU 和内存更重要？
在同一物理服务器上，多个实例会使性能管理问题变得更加繁琐。如果您查看其中一个实例的运行状况，它可能看起来很好，但用户报告性能不佳，因此您必须查看下一个实例，以确定问题是否可能来自那里...... 以此类推。
使用多个实例也会增加安全难度。充其量，它与单个实例一样困难，但永远不会更容易。您将拥有两个管理员帐户（SYS 或其他），重复的进程帐户等。
请告诉我们您为什么认为拥有多个实例更好。
我们能不能明确一下术语。当你说“在同一个数据库中”时，你是指同一个实例还是同一个物理服务器。如果你将暂存区移动到一个新实例，它会驻留在同一台物理硬件上吗？
我认为人们对实例过于纠结了。如果你要在同一台硬件上放置两个实例，你只是将所有东西的数量增加了一倍，而几乎没有任何优势。所有服务器进程都将运行两次... 所有内存池都将减半。
所以假设你真的是指两个单独的物理盒子...
假设你购买了2个12路盒子（就这么说吧）。当你的暂存区数据库服务器完成当天的工作后，那12个CPU就浪费掉了。当你的用户收拾行囊回家时，你的生产DW CPU也在浪费。CPU周期是易逝的，你无法重新获得它们。但是，如果你有一个24路盒子... 那么暂存DB可以在晚上使用20个CPU来构建摘要表进行优秀的并行执行，而你的用户在白天的处理能力将翻倍。
所以假设你是指同一台硬件。
“这似乎会使安全、备份/恢复和性能管理问题更加繁琐。”
保证，共享相同硬件的实例越多，性能问题就越难解决。这是肯定的。
安全
您在实例级别上做了哪些安全措施？
备份
您在实例级别上备份了哪个DW？您不是在备份表空间，而是整个实例吗？似乎这种模式在一定规模下会失败。
平台：NETEZZA
不熟悉具体的工具。所以，如果它是单个实例在单个盒子上，那么分割似乎比物理分割更合乎逻辑，因此它们存在的原因是为了管理，而不是为了性能。通过添加数据库来增加CPU或内存，对吧？因此，似乎没有性能优势。每个数据库可能会添加单独的进程（性能损失），或者像Oracle中的模式一样完全逻辑。如果每个数据库都由新进程管理，则它们之间传输的数据将意味着IPC。
也许添加Netezza标签会引起一些关注。
我们为每个部分（库存、客户关系管理、计费等）使用数据库。没有性能方面的缺陷，维护和概览也更好。
SELECT操作，不允许进行INSERT、UPDATE或DELETE语句。THISDB(ADMIN)=>INSERT INTO OTHERDB..TBL SELECT * FROM THISDBTABLE;
但是您可以执行\c OTHERDB然后执行以下操作：
OTHERDB(ADMIN)=>INSERT INTO TBL SELECT * FROM THISDB..THISDBTABLE;
您也无法在跨数据库对象上创建材料化视图，例如：
OTHERDB(ADMIN)=>CREATE MATERIALIZED VIEW BLAH AS SELECT * FROM THISDB..THISDBTABLE;
管理可能是您决定（尽管您可能早就已经决定）要创建哪种类型的数据库的地方。根据您的基础设施，您可能在同一台计算机上或在不同的计算机上拥有一个测试/QA系统和一个PROD系统。如果表在同一个模式（数据库）中，您将在加载和输出速度方面获得更快的速度。显而易见...但是嘿，我说了。
放入一个模式中的表越多，开销就越大。备份时间、备份大小、易用性都会受到影响。
在我们这里，我们有许多个多TB的数据库在一个数据仓库中。我们的经验法则是单个加载过程或单个报告查询不应跨越数据库。这使得“类似”的表保持在一起，但也为我们的备份和应急处理提供了一些容错能力。它还使“查找”数据变得更加容易。
对于那些需要打破这个规则的过程，我们要么将数据从一个数据库移动到另一个数据库，要么允许该过程跨模式连接。
我对Netezza不是很熟悉，所以我不能100%确定您的选择。
以下是您需要考虑的几个要点： a）如果需要连接一个或多个暂存、审计、维度和事实表中的数据，则最好将它们保留在一个数据库中。
b）通常情况下，您会将维度表和事实表保留在同一个数据库中，并在最频繁连接的列上进行分布以利用 Netezza 的“共同连接”功能。
c）您应该能够使用 SQL 授予权限来管理对所有对象（数据库、表、视图等）的访问权限。