Oracle 这是微软的问题还是甲骨文的问题？

在我的原始帖子中：我描述了一个试图将Oracle表链接到Microsoft Access（office 365）数据库的问题。输入UID和密码后，进程超时

在研究该问题时，我能够确定ODBC驱动程序和DSN是否适用于ADO、Toad和Microsoft Power BI（在对Oracle表使用特定查询时）。我无法从Access或Excel记录Oracle V$SQL表中的条目，以进一步解决问题

然而，今晚，通过尝试通过DSN连接并在Oracle中浏览表，我能够让Power BI重新创建相同的行为。Oracle捕获了SQL调用，结果如下：

SELECT
    *
FROM
    (
        SELECT
            NULL table_qualifier,
            o1.owner         table_owner,
            o1.object_name   table_name,
            DECODE(o1.owner, 'SYS', DECODE(o1.object_type, 'TABLE', 'SYSTEM TABLE', 'VIEW', 'SYSTEM VIEW', o1.object_type), 'SYSTEM'
            , DECODE(o1.object_type, 'TABLE', 'SYSTEM TABLE', 'VIEW', 'SYSTEM VIEW', o1.object_type), o1.object_type) table_type,
            NULL remarks
        FROM
            all_objects o1
        WHERE
            o1.object_type IN ('TABLE',
                'VIEW'
            )
        UNION
        SELECT
            NULL table_qualifier,
            s.owner          table_owner,
            s.synonym_name   table_name,
            'SYNONYM' table_type, null remarks
        FROM
            all_objects    o3,
            all_synonyms   s
        WHERE
            o3.object_type IN (
                'TABLE',
                'VIEW'
            )
            AND s.table_owner = o3.owner
            AND s.table_name = o3.object_name
        UNION
        SELECT
            NULL table_qualifier,
            s1.owner          table_owner,
            s1.synonym_name   table_name,
            'SYNONYM' table_type,
            NULL remarks
        FROM
            all_synonyms s1
        WHERE
            s1.db_link IS NOT NULL
    ) tables
WHERE
    1 = 1
    AND ( table_type = 'TABLE'
          OR table_type = 'VIEW' )
ORDER BY
    4,
    2,
    3

我不知道从哪里开始这个查询。union语句中的第二个子查询和第三个子查询被最后的where子句过滤掉，因此它们是无用的。第一个子查询试图从所有_对象检索表/模式列表。如果我将SQL块限制在前100000行，并在SQLPLUS中运行它，那么在Oracle18c（XE）中的运行时间将超过20分钟。我认为这是因为即使在查询运行时，该对象也在不断更新

Oracle认证的MS ODBC规范的细节让我摸不着头脑，因此我不知道是否要继续与Microsoft合作，或者是否要将注意力转向Oracle作为问题的罪魁祸首

感谢您的任何建议。我真的需要知道哪一方负责上面的SQL

---

谢谢

这看起来像是Oracle的问题。尽管该错误是ODBC超时设置的直接结果，但该查询不应花费20分钟来完成运行

遇到数据字典性能问题时，首先要尝试收集数据字典的统计信息。这为Oracle提供了有关对象大小的更多信息，因此它可以更好地决定如何连接表

begin
    dbms_stats.gather_fixed_objects_stats;
    dbms_stats.gather_dictionary_stats;
end;
/

如果这不起作用，您将希望将查询缩小到仍然存在问题的尽可能小的大小。共有三个查询

将所有查询合并在一起，可能只有一个查询速度较慢。然后，我们可以对这一查询进行优化

（但调整查询是一个需要反复进行的过程，很难在Internet上完成。您可能需要尝试找到一位可以提供帮助的本地数据库管理员。由于您使用的是Express Edition，因此无法联系Oracle支持部门寻求帮助。）
如果我能够从Power BI更改SQL调用，我发现下面的查询产生相同的输出。它在安装了Oracle和Power BI的笔记本电脑上运行不到一秒钟。与之形成对比的是，最初的查询大约需要30分钟。Microsoft，您可能希望了解您的产品如何通过DSN连接到较新的Oracle产品：

SELECT
    *
FROM
    (
        SELECT
            NULL table_qualifier,
            o1.owner         table_owner,
            o1.object_name   table_name,
            o1.object_type table_type,
            NULL remarks
        FROM
            all_objects o1
        WHERE
            o1.object_type = 'TABLE' and
            o1.owner not in ('SYS','SYSTEM')
        UNION
        SELECT
            NULL table_qualifier,
            o1.owner         table_owner,
            o1.object_name   table_name,
            o1.object_type table_type,
            NULL remarks
        FROM
            all_objects o1
        WHERE
            o1.object_type = 'VIEW' and
            o1.owner not in ('SYS','SYSTEM')
    ) tables
ORDER BY
    4,
    2,
    3

谢谢你，乔恩。我试试看。查询的慢运行部分是针对所有_对象的子查询。无用的两个子查询会及时执行。我的主要问题是，为什么要使用所有的\u对象而不是所有的\u tab\u列来生成模式/表列表？这似乎是一种效率极低的方法，@Arlie我相信这个查询是为了返回所有“类似于表”的东西。可以从中选择的任何内容，例如表、视图或指向另一个表或视图的同义词。这是有道理的，尽管我幽默地指出，任何同义词最终都会被过滤掉。我确实尝试了您推荐的脚本，通过禁用DSN上的timeout属性，让查询无限期运行。大约一小时后，它确实返回了结果。如果您有任何其他数据库优化建议，可能建议阅读，我洗耳恭听。在网上搜索之后，我发现了其他关于访问Oracle 12c和18c中sys.all_对象和sys.all_同义词的性能缓慢的报告。我这里的例子中的行为真的很奇怪。从所有_对象中选择count（）的查询需要25分钟才能运行。查询从所有对象中选择count（），其中object_type='TABLE'在0.10秒内运行。查询select count（*）从所有_对象中选择，其中object_in（'TABLE'，'VIEW'）将我返回到20分钟以上的运行时领域。所以，我同意你的看法，这似乎确实是甲骨文的问题。