Sql 优化OBIEE生成的选择查询

我们在Oracle 11g上的数据集市/仓库以星形模式实现。业务报告是使用OBIEE设计的。我来自ETL背景，对OBIE知之甚少

一旦设计了obieerpd，我看到OBIEE开始在后台生成SELECT查询，以便将数据提供给报表。在很多情况下，我注意到SELECT查询没有得到优化（大事实表在单独的WITH子句中被完全扫描了不止一次）

当报告性能不好时，OBIEE查询将发送给ETL团队进行性能调优。我对如何调整它们感到困惑，因为它们是自动生成的。我知道有一个选项可以在OBIEE中为每个报告编写定制sql（不通过RPD），但我们的标准不允许这样做，我还认为它没有利用OBIEE的好处

---

有没有人遇到过这样的问题？如何优化此类查询？

如果您拥有诊断和优化包许可证，则可以运行SQL tuning Advisor。SQL Tuning Advisor正在优化模式下运行优化器，它可能能够生成具有更好执行计划的SQL概要文件。有时，advisor还建议使用索引进行调优。SQL配置文件和索引都不需要对应用程序进行更改。

首先，您是对的，自定义SQL（称为直接数据库查询）原则上不是一个好主意，尽管它有时很有用。但这不是解决你问题的办法

对于OBI开发人员来说，优化生成的OBI查询是一项OBI RPD任务；为生成的OBI查询调优数据库是一项数据库/ETL任务。但如果没有另一个，你就无法真正做到这一点——OBI的设计需要能够生成合适的查询，数据库的设计需要能够生成合适的好查询来回答所提出的问题

OBI基本上是一个SQL生成器，如果RPD模型是次优的，那么生成的查询将是次优的。OBI将根据RPD中关于数据和数据库的布局和结构的信息生成SQL

---

很明显，您是从数据库方面着手的，因此对您来说，SQL是不好的，因为它不是您要编写的。数据库设计也有可能不利于回答OBI提出的问题。

正如jackohug所说，OBIE是一个SQL生成器，一般的做法是尝试优化OBIE生成的查询，而不是尝试更改此查询。不知何故，根据性能问题，您可以尝试一些技巧。 首先，您的表是否已分区，您的报表是否可以从分区中受益？ 第二，在事实表上添加索引，以便维度上的任何过滤器都有利于对事实表的访问。 第三，构建agregate表，恢复事实表，这样当报告没有显示太多细节时，您首先可以使用更少的数据访问agregate表，并且只有在用户向下钻取结构时才可以访问（这样做时，他们会对感兴趣的数据应用过滤器）他们访问非常详细的事实表，但应用过滤器以避免完全扫描。 您还可以告诉OBIEE在访问表时使用提示，不过，与直接数据库查询一样，我不推荐使用它，我会首先尝试使用前三种方法进行优化。

---

关于

我还没有在SQL调优顾问方面取得很大成功。SQL调优方面的一些经验和一些研究通常可以产生更好的计划

如果所有层都构建得很好，并且您只需要进行最后的调整，那么就可以使用SQL提示在报告（回答/分析）的开头添加一个隐藏列

---

我会非常小心地通过RPD层添加提示，因为其他人会以许多不同的、意想不到的方式加入并使用这些表。

谢谢。是的，我知道可以分析执行计划，可以添加任何索引以提高性能。如果OBIEE生成的查询不好，有没有办法处理这个问题？我不熟悉OBIEE，但我做了很多从Java到Oracle的对象关系映射。在这种情况下，O-R映射程序偶尔会生成性能差、连接条件复杂的SQL。为了解决这些问题，我通常会在Oracle端创建一个优化的连接视图，然后映射到该视图。另一个好处是，如果我将来需要调整查询，我不需要触摸应用程序端，只需要触摸Oracle端。我认为在OBIEE上也可以使用相同的概念，在OBIEE中，自定义查询是针对视图而不是基表创建的。谢谢罗杰。有一种方法可以在OBIEE中编写自定义SQL（就像您的视图一样），但这通常不是一种好的做法，因为一旦这样做，您就可以在OBIEE中进行其他RPD优化（例如：应用任何统计函数）。一种方法是通过查询重写实现一些具体化视图，但这是解决症状而不是原因。谢谢你的评论。我明白你的意思。我想看看我是否能得到更具体的信息——是否有任何迹象表明RPD设计得不好，无法生成最佳的OBI查询？类似地，是否有迹象表明星型模式设计得不好，无法以最佳方式执行OBI查询。@museshad如果没有真正的指标，那就归结为对数据的了解和使用RPD/数据库的技能。谢谢。我会看看你提到的方法。