问题描述
最近,我们将数据库从12C(12.1)升级到19C(19.8)。升级后,我们发现许多SQL报告运行缓慢。
我们有一些报告,记录超过60万张。这些报告过去在12C中需要18-20分钟,但现在完成这些报告需要35-40分钟。我们发现,对于这些报告的两个版本,初始读取几乎是相同的,这两个版本的报告是2-3分钟,但总读取时间从15-16分钟增加到了35-36分钟。
除了数据库升级之外,我们还没有对我们的硬件或网络或其他任何可能影响查询总获取时间的更改。
令人惊讶的是,当我在查询中添加“Order By”子句时,初始获取增加了几秒(由于排序开销) ,但总获取时间又回到了15-16分钟。
我们无法找出这个行为数据库的原因。Oracle是否没有将结果集存储到缓冲区高速缓存(没有排序条件) ,这可能是导致此行为的原因?这个版本的数据库中是否存在任何错误?
请帮帮我们。
我们有一些报告,记录超过60万张。这些报告过去在12C中需要18-20分钟,但现在完成这些报告需要35-40分钟。我们发现,对于这些报告的两个版本,初始读取几乎是相同的,这两个版本的报告是2-3分钟,但总读取时间从15-16分钟增加到了35-36分钟。
除了数据库升级之外,我们还没有对我们的硬件或网络或其他任何可能影响查询总获取时间的更改。
令人惊讶的是,当我在查询中添加“Order By”子句时,初始获取增加了几秒(由于排序开销) ,但总获取时间又回到了15-16分钟。
我们无法找出这个行为数据库的原因。Oracle是否没有将结果集存储到缓冲区高速缓存(没有排序条件) ,这可能是导致此行为的原因?这个版本的数据库中是否存在任何错误?
请帮帮我们。
专家解答
基于这个
Surprisingly when I added "Order By" clause to query
我的第一个假设是,这是一个网络问题,因为我们在重复数据消除方面对查询结果进行自动压缩,并且经过排序的数据消除重复数据将更好。
但最好的方法是通过
然后在跟踪文件上运行tkprof。请随意在此处发布查询的tkprof部分作为注释,我们将查看
Surprisingly when I added "Order By" clause to query
我的第一个假设是,这是一个网络问题,因为我们在重复数据消除方面对查询结果进行自动压缩,并且经过排序的数据消除重复数据将更好。
但最好的方法是通过
exec dbms_monitor.session_trace_enable(waits=>true) run your query exec dbms_monitor.session_trace_disable
然后在跟踪文件上运行tkprof。请随意在此处发布查询的tkprof部分作为注释,我们将查看
文章转载自askTom,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




