具有远程数据库的业务对象宇宙性能

Question

我的公司正在考虑将业务对象用于报告目的，因为我们的母公司已经购买了许可证。

场景

• A站点上的1个大型数据库(20+gb)
• 安装在B站点(100英里外)的业务对象
• 站点A和站点B之间的10 and线
• 站点A的用户希望使用B站点的业务对象宇宙设置来报告他们的实时数据

如果不了解业务对象和宇宙是如何设置的，我看不出在一个站点上运行带有数据的报表，而在另一个站点上运行业务对象，这将考虑到数据库的大小和必须通过有线查询的数据量。

我有两个问题：

1. 所建议的场景是否可以配置？
2. 如果有数据存储在远程服务器上，业务对象将如何执行？

更新：

我们每3小时运行一次实时数据库备份，这样理论上我们就可以将数据库从站点A复制到站点B，或者在需要的情况下更频繁地复制数据库，但我仍然不确定在有线上运行报告对性能的影响。

Answer 1

在Business中，您有三个层(按以下顺序排列)：Report、Universe、Connection和Data (我看到的大多数情况是ODBC驱动程序)。您可以将数据库连接(SQL、Oracle或任何DBMS连接)定义为站点A(应用层)上的ODBC，并使用ODBC连接到位于站点B的数据库。

可能发生的性能问题与数据库中的数据量无关。这实际上取决于报告中“查询”的数据量。我相信您需要创建一个试点报告，并尝试从数据源中获取一些全面的大数据作为概念的证明。

我们有同样的架构，你提到的应用在我们公司。我们在站点A中有几个报告，并从不同站点/位置的几个数据库中获取数据(但是站点A和站点B都在同一个网络上)。我们还在使用几个DBMS，如MySQL、Oracle和SQL服务器。无论如何，我们没有您提到的数据量，但是在运行报告时，我们没有看到对性能的显著影响。

Answer 2

这里没有关于业务对象产品的具体知识，但是无论使用什么报告工具，您最好在一夜之间将一组数据扁平化和推送，以便在第二天报告，如果一天一次不够的话，也可以在一天中的设定点进行报告。

允许用户在活动数据集上运行潜在的复杂和耗时的查询可能会给实时系统带来很大压力。

我们在一个全国性的系统上经历了这一问题，并通过在SQL server中运行过夜作业来解决这个问题，该作业将数据平平(实质上消除了连接表的需要)，并将其导出到一个单独的服务器，报告工具将连接到该服务器--基本上是数据仓库。

如果企业坚持他们需要报告中的“分钟”数据，你需要提出一个更好的基础设施来支持这一点，并与企业合作，找出它对他们的价值。

Answer 3

根据我们的经验，对数据库的BusinessObjects访问与任何其他SQL没有什么不同。InfoView应用程序甚至会向您展示报表将执行的SQL。当我们怀疑报表的性能时，我们通常会复制该SQL并将其粘贴到中，并在BusinessObjects之外对查询进行分析。