第1章产品体系结构比较第2章在企业关键BI需求上BO 与 OBIEE对比第3章对比BO与Oracle BIEE的常见问题1.OBIEE是一个统一的、完整的架构，还是一个将并购而来的多种工具耦合而成的平台？Oracle BIEE是ORACLE将多个收购而来的BI产品简单耦合而成的，作为企业级的BI平台显然它还不够成熟。
OBIEE拥有看似统一的多个用户界面、多个服务器和多个存储在平面文件中的元数据，这些缺点都极大的制约了它的可伸缩性。
OBIEE Plus所提供的BI功能需要三个独立的服务来支持。
用户访问复杂报表的时候，查询的SQL不是由一个单独的集中的服务器产生的，而是需要两个服务通过两个步骤才能产生。
首先ORACLE BI Presentation Services产生逻辑SQL，然后Oracle BI Server再将接收到的逻辑SQL转化为物理SQL。
这两个步骤明显有些冗余，直接降低了系统的性能，增大了系统故障的风险。
根据Gartner公司10年的报告，Oracle的对其BI产品和产品线的整合在近期还将继续。
有强烈的证据表明，Hyperion的原有用户都在等待和观望，并没有升级到最新版本。
在所有的用户调查中，Hyperion用户运行最新版本的比率是最低的。
而且报告中还专门提到，Oracle用户反映得到的技术支持不够完善，Oracle在BIEE方面的一线技术专家还不够。
BO 产品是一个统一的、完整的架构，通过一个统一的门户向用户提供各种BI功能，整个系统采用统一的用户和权限管理。
2.OBIEE是否拥有统一的元数据？OBIEE 系统拥有三个不同版本的元数据：●BI Server的元数据：存储逻辑数据模型●BI Presentation Services的元数据：主要存储 WEB目录信息，包括报表、筛选、提示和用户信息●BI Publisher的元数据：主要存储复杂的企业级报表及其他报表对象的信息。
这些元数据在不同的功能模块间是无法完全共享的。
其中BI Server的元数据和BI Presentation Services的元数据只能保存在一个平面文件中，不能存储在关系型数据库中，从而没有负载均衡和数据回滚的能力。
在集群的环境中，保存在平面文件中的元数据必须要通过共享文件系统才能同时被多台服务器所访问。
但共享文件系统是无法针对高并发量的访问进行系统调优的，另外平面文件本身也存在大小的限制，进而也限制了元数据的增长。
此外，集群环境中的ORACLE BI SERVER仅仅在重启的时候，才会加载存储在平面文件中的元数据。
这意味着想要修改后元数据生效，管理员就必须要重启集群内的所有服务器。
这样即使OBIEE在集群环境中也不可能提供7*24小时的高可靠性。
Oracle BI Publisher的元数据不能充分利用来自Oracle BI Server元数据业务逻辑模型。
来自Oracle BI Answer的报表，不能被Oracle BI Publisher充分利用创建Publisher报表。
在Oracle BI Answers中创建的包含提示的报表，也不能在Oracle BI Publisher中正常使用。
Oracle BI Publisher报表不能在Oracle BI Presentation Services Web中被浏览，因为这两个系统的元数据库是完全独立的。
在OBIEE中报表中的提示是存储在报表级别的，这意味这用户创建了一个地区提示，这个提示不能被后来的报表所重用。
用户必须为每一张需要相同提示的报表重新创建。
这种缺乏元数据抽象的弱点，增加了额外的维护工作和重复的步骤。
BO BI 拥有统一的元数据库，BO BI的元数据可以保存在关系型数据库中，它支持三种最常见的关系型数据：DB2、ORACLE和MS SQLSERVER。
在BO中，提示、筛选等报表元素都可以作为一个对象保存下来，在多个报表引用。
这种可重用性提高了开发效率，减少了维护工作。
3.OBIEE 能否在一个统一的架构上，通过一个统一的界面提供各种BI应用？在OBIEE中不同组件的用户界面也不是统一的，它们看来像是一系列松散连接的WEB组件。
这些不同功能模块的界面布局、操作方式、下拉菜单都不太相同。
毕竟这些工具都是通过兼并或收购的方式获取的，彻底的融合还需要更多的时间才能完成。
在OBIEE中如果要创建复杂的企业级报表，就必须使用Oracle BI Publisher，这个工具不属于从前的Siebel Business Analytics平台，而是来自于Oracle e-Business解决方案，这就意味着它与Answers(即席查询和分析工具) 以及Dashboard很难统一起来。
Answers和Dashboard的界面是由Presentation Services生成的，而Oracle BI Publisher只是通过一个链接与Oracle Presentation Services生成的WEB界面整合起来的，Oracle采用这种方法使这些模块看起来像是一个统一的界面。
Oracle BI Publisher 拥有独立的管理工具、元数据和维护方式。
Oracle BI Publisher 用户如果想要获得Oracle BI Presentation Services 界面的访问权限，管理员就必须先把 Oracle BI Publisher 元数据库中的用户信息复制到Oracle BI Presentation Services的元数据库中。
也就是说，用户安全必须设置两次，一次在Oracle Web Catalog(BI Presentation的元数据)，另一次在Oracle BI Publisher元数据中，并且这个操作不能通过Web界面来完成。
冗余的用户设置不仅增加了额外的维护工作，也增加了出错的几率。
Oracle BI Publisher 的设计界面并不是完全基于Web的，报表设计者通过一个插件把Microsoft Word 作为BI Publisher 文档模板的设计工具。
BO BI是在统一的架构上，通过完整的、统一的界面向用户提供各种BI功能的，无论是即席查询，还是多维分析或是仪表盘，都是在同一个风格统一的Portal中进行的。
用户不会像使用OBIEE一样明显感到是在不同工具间切换。
4.OBIEE Plus 能否为企业提供7*24小时的高可靠性？OBIEE 宣称通过可以集群实现7*24小时的高可靠性，但事实上它的集群功能非常有限。
Oracle BI Server 集群并不是全部被激活的对等配置，而是需要一个集群控制器监控集群的活动。
实际上，它是一种主从集群的模式，主服务器会安装“集群控制器”组件，它负责将用户的请求分配到集群中的BI SERVER上。
因此，Oracle BIEE只允许非主服务器失效，如果主服务器失效，它将会影响到整个集群的服务器。
这种集群模式只给企业提供一个“单点故障”，并不能提供一种非常有效和可靠的解决方案。
因为Oracle BI Server元数据存储在平面文件中，多个Oracle BI Server必须通过共享文件系统才能访问它。
共享文件系统不像RDBMS关系型数据库系统那样健壮，很难应付大并发的用户同时访问元数据库的情况。
同样，共享文件系统也不能有效的进行线程管理、负载均衡和自动备份。
管理员必须为集群中的每一台Oracle BI Server 服务器手工修改配置文件的参数，而且，为了确保在群集中元数据库的正常升级，Oracle BIEE的管理员还要确保所有Oracle BI Servers中的时钟是同步的。
这不仅增加了维护的负担，也增大的出错的可能性。
在群集环境中，系统管理员必须通过“Master”服务器节点修改Oracle BI Server的元数据库。
为了使元数据的修改生效，群集的所有节点都必须重启。
由此看来OBIEE的集群功能不仅不能提供7*24小时的可靠性，而且还会带来额外的维护工作。
与Oracle相比，BO具有智能的集群功能，不需要额外的第三方软件的设置和维护，系统是作为一个统一的逻辑平台共同工作的群集。
相比Oracle BI EE使用的群集架构，BO的群集是一个全部激活的对等配置，并且这样的构建最小化了资源费用，确保了完全的故障恢复，并且不会产生单点失效。
5.Oracle BIEE 是否具有企业级的伸缩性，能否满足高并发高负载的需要？Oracle Presentation Services的实现技术限制了OBIEE平台的伸缩性。
在Oracle BIEE中SQL的产生和数据的处理是在两个层面中完成的。
第一步处理是在Oracle Presentation Services Server上完成的，第二部处理是在Oracle BI Server上完成的。
Oracle Presentation Services 功能模块首先产生Oracle Answers和Oracle interactive Dashboard 的用户界面，并且将用户的请求转化为逻辑SQL。
Oracle BI Presentation Services把Oracle BI Server 作为一个ODBC客户端，将生成的逻辑SQL提交给它。
Oracle BI Server 负责将逻辑SQL转化为物理SQL，并提交到数据库端去执行。
在我们看来，这两个步骤其实是冗余的，再高并发的情况下会影响到系统的性能。
Oracle BI Server 需要连接到一个 Oracle BI Server 平面文件元数据库，主要存储业务逻辑模型。
Oracle BI Presentation Services 也需要连接到一个 Oracle Web Catalog 平面文件资料库。
主要用来存储报表定义和用户信息。
这两个元数据容器都是平面文本文件，在集群情况下，需要建立一个共享文件系统以满足来自集群内的多个Oracle 服务器并发访问的要求。
而共享文件系统不像RDBMS关系型数据库系统那样健壮，很难应付大并发的用户同时访问元数据库的情况。
另外平面文件本身也存在大小的限制，进而也限制了元数据的增长。
所以，OBIEE是无法满足企业级伸缩性的要求的。
而BO 是在一个单一的、完整的架构上提供各种BI应用的，无论是即席查询还是多维分析，都是由BO 8 Server 来支撑的，不像OBIEE那样产生SQL都需要两个服务才能完成。
BO 的元数据库可以建立在关系型数据库中，它支持三种最常见的关系型数据库MS SQLSERVER、DB2和ORACLE，完全可以应付高并发情况下用户同时访问元数据库的情况。
另外，BO是一个模块化的系统，它为用户提供了各种即插即用的功能模块。